Well, this is awkward: [root@slpidml01 slapd-UNIX-xxx-COM]# grep conn=170902 access* | wc -l 5453936 [root@slpidml01 slapd-UNIX-xxx-COM]#
On Thu, Sep 19, 2013 at 1:48 PM, KodaK <sako...@gmail.com> wrote: > Thanks. I've been running that against my logs, and this has to be > abnormal: > > err=32 129274 No Such Object > err=0 10952 Successful Operations > err=14 536 SASL Bind in Progress > err=53 39 Unwilling To Perform > err=49 3 Invalid Credentials (Bad Password) > > 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.) > > > On Tue, Sep 17, 2013 at 9:01 AM, Rich Megginson <rmegg...@redhat.com>wrote: > >> On 09/16/2013 07:57 PM, Dmitri Pal wrote: >> >> On 09/16/2013 12:02 PM, KodaK wrote: >> >> Yet another AIX related problem: >> >> 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: >> >> http://www-01.ibm.com/support/docview.wss?uid=isg1IV11344 >> >> "If an LDAP server fails to answer an LDAP query, secldapclntd caches >> the non-answered query negatively. This may happen if the LDAP server is down >> for example. After the LDAP server is back again secldapclntd will use >> the negative cache entry and the application initiating the original >> query will still fail until the cache entry expires." >> >> IBM is working on porting the fix to our specific TL and SP levels. >> >> 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.) >> >> 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. >> >> 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.) >> >> Does anyone have any troubleshooting suggestions? Any general "speed >> things up" suggestions on the IPA side? >> >> Thanks, >> >> --Jason >> >> -- >> The government is going to read our mail anyway, might as well make it >> tough for them. GPG Public key ID: B6A1A7C6 >> >> >> _______________________________________________ >> Freeipa-users mailing >> listFreeipa-users@redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> Is the server FreeIPA? >> 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? >> I would really start with the server side logs. >> >> >> As far as 389 goes, run logconv.pl against the access logs in >> /var/log/dirsrv/slapd-DOMAIN-COM >> >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager for IdM portfolio >> Red Hat Inc. >> >> >> ------------------------------- >> Looking to carve out IT costs?www.redhat.com/carveoutcosts/ >> >> >> >> _______________________________________________ >> Freeipa-users mailing >> listFreeipa-users@redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users@redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> > > > > -- > The government is going to read our mail anyway, might as well make it > tough for them. GPG Public key ID: B6A1A7C6 > -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6
_______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users