[Freeipa-users] Timeout (?) issues

[KodaK]

I didn't realize that DNS created one connection.  I thought it was one
connection spanning several days.


On Thu, Sep 19, 2013 at 2:51 PM, Rich Megginson <rmeggins at redhat.com> wrote:

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


-- 
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/8d955c04/attachment.htm>