[Freeipa-users] Timeout (?) issues

[Rich Megginson]

On 09/19/2013 12:57 PM, KodaK wrote:
> Well, this is awkward:
>
> [root at slpidml01 slapd-UNIX-xxx-COM]# grep conn=170902 access* | wc -l
> 5453936
> [root at slpidml01 slapd-UNIX-xxx-COM]#

Why is it awkward?

>
>
> On Thu, Sep 19, 2013 at 1:48 PM, KodaK <sakodak at gmail.com 
> <mailto:sakodak at 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
>     <rmeggins at redhat.com <mailto:rmeggins at 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 list
>>>         Freeipa-users at redhat.com  <mailto:Freeipa-users at redhat.com>
>>>         https://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 <http://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/  <http://www.redhat.com/carveoutcosts/>
>>
>>
>>
>>
>>         _______________________________________________
>>         Freeipa-users mailing list
>>         Freeipa-users at redhat.com  <mailto:Freeipa-users at redhat.com>
>>         https://www.redhat.com/mailman/listinfo/freeipa-users
>
>
>         _______________________________________________
>         Freeipa-users mailing list
>         Freeipa-users at redhat.com <mailto:Freeipa-users at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20130919/f9fe39e2/attachment.htm>