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
_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to