SRV records were missing for _ldaps_tcp. I added them in for the IPA servers and that knocked out some of the errors, but there are still a lot. I suspect these boxes are overloaded with bad dns queries (probably due to something I've messed up.)
Any help would be appreciated, but I'm opening a RH ticket. Thanks, --Jason On Thu, Sep 19, 2013 at 1:57 PM, KodaK <sako...@gmail.com> wrote: > 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 > -- 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