<div dir="ltr">SRV records were missing for _ldaps_tcp. I added them in for the IPA servers and that knocked out some of the errors, but there are still a lot. I suspect these boxes are overloaded with bad dns queries (probably due to something I've messed up.)<div>
<br></div><div>Any help would be appreciated, but I'm opening a RH ticket.</div><div><br></div><div>Thanks,</div><div><br></div><div>--Jason</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Sep 19, 2013 at 1:57 PM, KodaK <span dir="ltr"><<a href="mailto:sakodak@gmail.com" target="_blank">sakodak@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Well, this is awkward:<div><br></div><div><div>[root@slpidml01 slapd-UNIX-xxx-COM]# grep conn=170902 access* | wc -l </div>
<div>5453936</div><div>[root@slpidml01 slapd-UNIX-xxx-COM]# </div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra">
<br><br><div class="gmail_quote">On Thu, Sep 19, 2013 at 1:48 PM, KodaK <span dir="ltr"><<a href="mailto:sakodak@gmail.com" target="_blank">sakodak@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Thanks. I've been running that against my logs, and this has to be abnormal:<div><br></div><div><div>err=32 129274 No Such Object </div><div>err=0 10952 Successful Operations </div>
<div>err=14 536 SASL Bind in Progress </div><div>err=53 39 Unwilling To Perform </div><div>err=49 3 Invalid Credentials (Bad Password)</div></div><div><br>
</div><div>I'm still trying to figure out why there are so many error 32s. Are there any usual suspects I should know about? (That's just the current access log, btw.)</div></div><div><div>
<div class="gmail_extra"><br><br>
<div class="gmail_quote">On Tue, Sep 17, 2013 at 9:01 AM, Rich Megginson <span dir="ltr"><<a href="mailto:rmeggins@redhat.com" target="_blank">rmeggins@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div><div>
<div>On 09/16/2013 07:57 PM, Dmitri Pal
wrote:<br>
</div>
<blockquote type="cite">
On 09/16/2013 12:02 PM, KodaK wrote:
<blockquote type="cite">
<div dir="ltr">Yet another AIX related problem:
<div><br>
</div>
<div>The AIX LDAP client is called secldapclntd (sure, they
could make it more awkward, but the budget ran out.) I'm
running into the issue detailed here:</div>
<div><br>
</div>
<div><a href="http://www-01.ibm.com/support/docview.wss?uid=isg1IV11344" target="_blank">http://www-01.ibm.com/support/docview.wss?uid=isg1IV11344</a></div>
<div><br>
</div>
<div>"<span style="color:rgb(51,51,51)">If an LDAP server
fails to answer an LDAP query, </span><span style="color:rgb(51,51,51)">secldapclntd caches the </span><span style="color:rgb(51,51,51)">non-answered query negatively.
This may happen if the </span><span style="color:rgb(51,51,51)">LDAP server is </span><span style="color:rgb(51,51,51)">down for example. After the
LDAP server is back again </span><span style="color:rgb(51,51,51)">secldapclntd </span><span style="color:rgb(51,51,51)">will use the negative cache
entry and the application </span><span style="color:rgb(51,51,51)">initiating the </span><span style="color:rgb(51,51,51)">original query will still fail
until the cache entry </span><span style="color:rgb(51,51,51)">expires."</span></div>
<div><br>
</div>
<div>IBM is working on porting the fix to our specific TL and
SP levels.</div>
<div><br>
</div>
<div>What I'm concerned with here, though, is *why* is it
timing out? I don't know what the current timeout values
are (AIX sucks, etc.)</div>
<div><br>
</div>
<div>I don't see timeout issues on my Linux boxes, which leads
me to believe that either the sssd timouts are longer or
that sssd is just more robust when dealing with timeouts.</div>
<div><br>
</div>
<div> I believe I'm seeing similar behavior with LDAP sudo on
AIX as well, because I occasionally have to re-run sudo
commands because they initially fail (and I know I'm using
the right passwords.) However, sudo doesn't appear to have
a cache (or it handles caching better.)</div>
<div><br>
</div>
<div>Does anyone have any troubleshooting suggestions? Any
general "speed things up" suggestions on the IPA side?</div>
<div><br>
</div>
<div>Thanks,</div>
<div><br>
</div>
<div>--Jason<br clear="all">
<div><br>
</div>
-- <br>
The government is going to read our mail anyway, might as
well make it tough for them. GPG Public key ID: B6A1A7C6 </div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Freeipa-users mailing list
<a href="mailto:Freeipa-users@redhat.com" target="_blank">Freeipa-users@redhat.com</a>
<a href="https://www.redhat.com/mailman/listinfo/freeipa-users" target="_blank">https://www.redhat.com/mailman/listinfo/freeipa-users</a></pre>
</blockquote>
<br>
Is the server FreeIPA?<br>
Can see in the server logs what is actually happening is it the
server that really takes time or there is a network connectivity
issue or FW is dropping packets?<br>
I would really start with the server side logs.<br>
</blockquote>
<br></div></div>
As far as 389 goes, run <a href="http://logconv.pl" target="_blank">logconv.pl</a> against the access logs in
/var/log/dirsrv/slapd-DOMAIN-COM<br>
<blockquote type="cite"><div> <br>
<br>
<pre cols="72">--
Thank you,
Dmitri Pal
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
<a href="http://www.redhat.com/carveoutcosts/" target="_blank">www.redhat.com/carveoutcosts/</a>
</pre>
<br>
<fieldset></fieldset>
<br>
</div><div><pre>_______________________________________________
Freeipa-users mailing list
<a href="mailto:Freeipa-users@redhat.com" target="_blank">Freeipa-users@redhat.com</a>
<a href="https://www.redhat.com/mailman/listinfo/freeipa-users" target="_blank">https://www.redhat.com/mailman/listinfo/freeipa-users</a></pre>
</div></blockquote>
<br>
</div>
<br>_______________________________________________<br>
Freeipa-users mailing list<br>
<a href="mailto:Freeipa-users@redhat.com" target="_blank">Freeipa-users@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/freeipa-users" target="_blank">https://www.redhat.com/mailman/listinfo/freeipa-users</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br>The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6
</div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6
</div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6
</div>