On 09/19/2013 12:57 PM, KodaK wrote:
Well, this is awkward:
[root@slpidml01 slapd-UNIX-xxx-COM]# grep conn=170902 access* | wc -l
5453936
[root@slpidml01 slapd-UNIX-xxx-COM]#
Why is it awkward?
On Thu, Sep 19, 2013 at 1:48 PM, KodaK <sako...@gmail.com
<mailto: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 <mailto: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 list
Freeipa-users@redhat.com <mailto:Freeipa-users@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@redhat.com <mailto:Freeipa-users@redhat.com>
https://www.redhat.com/mailman/listinfo/freeipa-users
_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com <mailto: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
