<div dir="ltr">This is ridiculous, right?<div><br></div><div>IPA server 1:<br><div><br></div><div><div># for i in $(ls access*); do echo -n $i:\ ;grep err=32 $i | wc -l; done</div><div>access: 248478</div><div>access.20130916-043207: 302774</div>
<div>access.20130916-123642: 272572</div><div>access.20130916-201516: 294308</div><div>access.20130917-081053: 295060</div><div>access.20130917-144559: 284498</div><div>access.20130917-231435: 281035</div><div>access.20130918-091611: 291165</div>
<div>access.20130918-154945: 275792</div><div>access.20130919-014322: 296113</div></div><div><br></div><div>IPA server 2:</div><div><br></div><div><div>access: 4313</div><div>access.20130909-200216: 4023</div><div>access.20130910-200229: 4161</div>
<div>access.20130911-200239: 4182</div><div>access.20130912-200249: 5069</div><div>access.20130913-200258: 3833</div><div>access.20130914-200313: 4208</div><div>access.20130915-200323: 4702</div><div>access.20130916-200332: 4532</div>
</div><div><br></div><div><br></div><div>IPA server 3:</div><div><br></div><div><div>access: 802</div><div>access.20130910-080737: 3876</div><div>access.20130911-080748: 3902</div><div>access.20130912-080802: 3678</div><div>
access.20130913-080810: 3765</div><div>access.20130914-080826: 3524</div><div>access.20130915-080907: 4142</div><div>access.20130916-080916: 4930</div><div>access.20130917-080926: 4769</div><div>access.20130918-081005: 2879</div>
</div></div><div><br></div><div>IPA server 4:</div><div><div><br></div><div>access: 2812</div><div>access.20130910-003051: 4095</div><div>access.20130911-003105: 3623</div><div>access.20130912-003113: 3606</div><div>access.20130913-003125: 3581</div>
<div>access.20130914-003135: 3758</div><div>access.20130915-003150: 3935</div><div>access.20130916-003159: 4184</div><div>access.20130917-003210: 3859</div><div>access.20130918-003221: 5110</div></div><div><br></div><div>
<br></div><div>The vast majority of the err=32 messages are DNS entries.</div><div><br></div><div>Here are some samples:</div><div><br></div><div><div>[19/Sep/2013:18:19:51 -0500] conn=9 op=169764 SRCH base="idnsName=<a href="http://xxx.com">xxx.com</a>,idnsname=<a href="http://unix.xxx.com">unix.xxx.com</a>,cn=dns,dc=unix,dc=xxx,dc=com" scope=0 filter="(objectClass=idnsRecord)" attrs=ALL</div>
<div>[19/Sep/2013:18:19:51 -0500] conn=9 op=169764 RESULT err=32 tag=101 nentries=0 etime=0</div></div><div><br></div><div><div>[19/Sep/2013:18:19:51 -0500] conn=9 op=169774 SRCH base="idnsName=<a href="http://slpoxacl01.unix.xxx.com">slpoxacl01.unix.xxx.com</a>,idnsname=<a href="http://unix.xxx.com">unix.xxx.com</a>,cn=dns,dc=unix,dc=xxx,dc=com" scope=0 filter="(objectClass=idnsRecord)" attrs=ALL</div>
<div>[19/Sep/2013:18:19:51 -0500] conn=9 op=169774 RESULT err=32 tag=101 nentries=0 etime=0</div></div><div><br></div><div>[19/Sep/2013:18:19:51 -0500] conn=9 op=169770 SRCH base="idnsName=<a href="http://sla400q1.unix.xxx.com">sla400q1.unix.xxx.com</a>,idnsname=<a href="http://unix.xxx.com">unix.xxx.com</a>,cn=dns,dc=unix,dc=xxx,dc=com" scope=0 filter="(objectClass=idnsRecord)" attrs=ALL<br>
</div><div><div>[19/Sep/2013:18:19:51 -0500] conn=9 op=169770 RESULT err=32 tag=101 nentries=0 etime=0</div></div><div><br></div><div><div>[19/Sep/2013:18:19:51 -0500] conn=9 op=169772 SRCH base="idnsName=<a href="http://magellanhealth.com">magellanhealth.com</a>,idnsname=<a href="http://unix.magellanhealth.com">unix.magellanhealth.com</a>,cn=dns,dc=unix,dc=magellanhealth,dc=com" scope=0 filter="(objectClass=idnsRecord)" attrs=ALL</div>
<div>[19/Sep/2013:18:19:51 -0500] conn=9 op=169772 RESULT err=32 tag=101 nentries=0 etime=0</div></div><div><br></div><div>So far today there are over half a million of these. That can't be right.</div><div><br></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Sep 19, 2013 at 3:05 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">I didn't realize that DNS created one connection. I thought it was one connection spanning several days.</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">
On Thu, Sep 19, 2013 at 2:51 PM, 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>On 09/19/2013 12:57 PM, KodaK wrote:<br>
</div>
<blockquote type="cite">
<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]# <br>
</div>
</div>
</div>
</blockquote>
<br></div>
Why is it awkward?<div><div><br>
<br>
<blockquote type="cite">
<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>
</blockquote>
<br>
</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>