That looks like the output I just got shown below:
dn: cn=mapping tree,cn=config dn: cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config dn: cn=meToipa2.example.com,cn=replica,cn=dc\3Dexample\ 2Cdc\3Dcom,cn=mapping tree,cn=config nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof idnssoaserial entryusn krblastsuccessfulauth krblastfailedauth krbloginfailedcount nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE entryusn krblasts uccessfulauth krblastfailedauth krbloginfailedcount Thanks, _____________________________________________________ John Moyer Director, IT Operations On Aug 27, 2013, at 10:14 AM, Rob Crittenden <[email protected]> wrote: > John Moyer wrote: >> Ok, so we tried to implement this again, and as soon as we put on a >> server that authenticates heavily the IPA came to it's knees again. >> This time I was able to watch it closely and try to troubleshoot a lot >> more, and also know exactly what server caused it (Mercurial with help >> of bamboo). This runs fine on a normal old openldap servers. The >> user is logging in very quickly and each time it logs in I can see in >> the logs that the krbLastsuccessfullogin parameter (or whatever it is >> called) is updated over and over and over in the changelog >> (/var/lib/dirsrv/slapd-$instanceid/db) those logs are filling VERY >> quickly and then disappear fairly quickly as well. >> >> Issue 1: This is causing severe disk latency which obviously slows >> everything down wait times were around 25%+ >> Issue 2: These changes need to be replicated to my slave server thus >> adding to the mess >> >> >> My question is, why does the IPA server fail to keep up with the load >> when the openLDAP server didn't have an issue. Indexes? >> >> >> I'm running the following: >> >> CentOS release 6.4 (Final) >> 389-ds-base-1.2.11.15-20.el6_4.x86_64 >> 389-ds-base-libs-1.2.11.15-20.el6_4.x86_64 >> ipa-python-3.0.0-26.el6_4.4.x86_64 >> ipa-admintools-3.0.0-26.el6_4.4.x86_64 >> ipa-pki-common-theme-9.0.3-7.el6.noarch >> python-iniparse-0.3.1-2.1.el6.noarch >> ipa-server-3.0.0-26.el6_4.4.x86_64 >> ipa-pki-ca-theme-9.0.3-7.el6.noarch >> ipa-server-selinux-3.0.0-26.el6_4.4.x86_64 >> libipa_hbac-1.9.2-82.7.el6_4.x86_64 >> ipa-client-3.0.0-26.el6_4.4.x86_64 >> libipa_hbac-python-1.9.2-82.7.el6_4.x86_64 >> >> >> So I've implemented this server anyway (against my better judgement with >> these issues and just made the user that logs into mercurial a local >> user instead of IPA). >> >> Also note before I did that for fun I implemented a RAM disk to put the >> change logs on, and that dropped the wait time to 0 (except bursts where >> it would raise to 30 to write the access log) but the CPU drove to 100% >> trying to keep up with the load. I have also killed the replication as >> well. >> >> Any help would be appreciated. >> > > krblastsuccessfulauth should be excluded from replication, though I guess > that doesn't prevent it from ending up in the changelog. > > You can confirm that they are excluded by searching the agreements: > > $ ldapsearch -LLL -x -b 'cn=mapping tree,cn=config' -D 'cn=directory manager' > -W nsDS5ReplicatedAttributeList nsDS5ReplicatedAttributeListTotal > > They should look like: > > nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof > idnssoaserial entryusn krblastsuccessfulauth krblastfailedauth > krbloginfailedcount > > nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE entryusn > krblastsuccessfulauth krblastfailedauth krbloginfailedcount > > rob
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Freeipa-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-users
