<html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 03/08/2017 11:39 AM, Christopher Young wrote: </div> <blockquote cite="mid:CAC1p532GyUHeRU3s-Bkrcba_U2PUC6ynwktttTREbXKV3jTAcg@mail.gmail.com" type="cite"> <div dir="auto">My replication scheme has things like so: orldc-prod-ipa01 <--> orldc-prod-ipa02 <--> bohdc-prod-ipa01 I had run re-initialize on orldc-prod-ipa02 (--from orldc-prod-ipa01) AND re-initialize on bohdc-prod-ipa01 (--from orldc-prod-ipa02). </div> </blockquote> Yeah if you still "The remote replica has a different database generation ID than the local database" messages then things are out of sync. Okay, I'm not an IPA guy, just DS. So lets do this the DS way... Export the replica database from orldc-prod-ipa01: # stop-dirsrv # db2ldif -r -n userroot -a /tmp/replica.ldif copy this LDIF to the other two servers and import it: # stop-dirsrv # ldif2db -n userroot -i /tmp/replica.ldif ** If you get permissions errors then temporarily disable selinux, and enable it after all the exports/imports are complete. Once this is done, go back and start all the servers: start-dirsrv Done! <blockquote cite="mid:CAC1p532GyUHeRU3s-Bkrcba_U2PUC6ynwktttTREbXKV3jTAcg@mail.gmail.com" type="cite"> <div dir="auto"> That is where i'm currently at with the same errors. Any additional thoughts beyond just destroying 'orldc-prod-ipa02' and bohdc-prod-ipa01 and re-installing them as new replicas? As always, many thanks. On Tue, Mar 7, 2017 at 7:40 PM, Mark Reynolds <<a moz-do-not-send="true" href="mailto:mareynol@redhat.com">mareynol@redhat.com</a>> wrote: > > > On 03/07/2017 06:08 PM, Christopher Young wrote: >> I had attempted to do _just_ a re-initialize on orldc-prod-ipa02 >> (using --from orldc-prod-ipa01), but after it completes, I still end >> up with the same errors. What would be my next course of action? > I have no idea. Sounds like the reinit did not work if you keep getting > the same errors, or you reinited the wrong server (or the wrong > direction) Remember you have to reinit ALL the replicas - not just one. >> >> To clarify the error(s) on orldc-prod-ipa01 are: >> ----- >> Mar 7 18:04:53 orldc-prod-ipa01 ns-slapd: >> [07/Mar/2017:18:04:53.549127059 -0500] NSMMReplicationPlugin - >> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >> (orldc-prod-ipa02:389): The remote replica has a different database >> generation ID than the local database. You may have to reinitialize >> the remote replica, or the local replica. >> .... >> ----- >> >> >> On orldc-prod-ipa02, I get: >> ----- >> Mar 7 18:06:00 orldc-prod-ipa02 ns-slapd: >> [07/Mar/2017:18:06:00.290853165 -0500] NSMMReplicationPlugin - >> agmt="cn=masterAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >> (orldc-prod-ipa01:389): The remote replica has a different database >> generation ID than the local database. You may have to reinitialize >> the remote replica, or the local replica. >> Mar 7 18:06:01 orldc-prod-ipa02 ns-slapd: >> [07/Mar/2017:18:06:01.715691409 -0500] attrlist_replace - attr_replace >> (nsslapd-referral, <a class="moz-txt-link-freetext" href="ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca">ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca</a>) >> failed. >> Mar 7 18:06:01 orldc-prod-ipa02 ns-slapd: >> [07/Mar/2017:18:06:01.720475590 -0500] attrlist_replace - attr_replace >> (nsslapd-referral, <a class="moz-txt-link-freetext" href="ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca">ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca</a>) >> failed. >> Mar 7 18:06:01 orldc-prod-ipa02 ns-slapd: >> [07/Mar/2017:18:06:01.728588145 -0500] attrlist_replace - attr_replace >> (nsslapd-referral, <a class="moz-txt-link-freetext" href="ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca">ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca</a>) >> failed. >> Mar 7 18:06:04 orldc-prod-ipa02 ns-slapd: >> [07/Mar/2017:18:06:04.286539164 -0500] NSMMReplicationPlugin - >> agmt="cn=masterAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >> (orldc-prod-ipa01:389): The remote replica has a different database >> generation ID than the local database. You may have to reinitialize >> the remote replica, or the local replica. >> Mar 7 18:06:05 orldc-prod-ipa02 ns-slapd: >> [07/Mar/2017:18:06:05.328239468 -0500] attrlist_replace - attr_replace >> (nsslapd-referral, <a class="moz-txt-link-freetext" href="ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca">ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca</a>) >> failed. >> Mar 7 18:06:05 orldc-prod-ipa02 ns-slapd: >> [07/Mar/2017:18:06:05.330429534 -0500] attrlist_replace - attr_replace >> (nsslapd-referral, <a class="moz-txt-link-freetext" href="ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca">ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca</a>) >> failed. >> Mar 7 18:06:05 orldc-prod-ipa02 ns-slapd: >> [07/Mar/2017:18:06:05.333270479 -0500] attrlist_replace - attr_replace >> (nsslapd-referral, <a class="moz-txt-link-freetext" href="ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca">ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca</a>) >> failed. >> ----- >> >> >> I'm trying to figure out what my next step(s) would be in this >> situation. Would that be to completely remove those systems are >> replicas (orldc-prod-ipa02 and bohdc-prod-ipa01) and then completely >> recreate the replicas? >> >> I appreciate all the responses. I'm still trying to figure out what >> options to use for db2ldif, but I'm looking that up to at least try >> and look at the DBs. >> >> Thanks, >> >> Chris >> >> On Tue, Mar 7, 2017 at 4:23 PM, Mark Reynolds <<a moz-do-not-send="true" href="mailto:mareynol@redhat.com">mareynol@redhat.com</a>> wrote: >>> >>> On 03/07/2017 11:29 AM, Christopher Young wrote: >>>> Thank you very much for the response! >>>> >>>> To start: >>>> ---- >>>> [root@orldc-prod-ipa01 ~]# rpm -qa 389-ds-base >>>> 389-ds-base-1.3.5.10-18.el7_3.x86_64 >>>> ---- >>> You are on the latest version with the latest replication fixes. >>>> So, I believe a good part of my problem is that I'm not _positive_ >>>> which replica is good at this point (though my directory really isn't >>>> that huge). >>>> >>>> Do you have any pointers on a good method of comparing the directory >>>> data between them? I was wondering if anyone knows of any tools to >>>> facilitate that. I was thinking that it might make sense for me to >>>> dump the DB and restore, but I really don't know that procedure. As I >>>> mentioned, my directory really isn't that large at all, however I'm >>>> not positive the best bullet-item listed method to proceed. (I know >>>> I'm not helping things :) ) >>> Heh, well only you know what your data should be. You can always do a >>> <a moz-do-not-send="true" href="http://db2ldif.pl">db2ldif.pl</a> on each server and compare the ldif files that are >>> generated. Then pick the one you think is the most up to date. >>> >>> <a moz-do-not-send="true" href="https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Populating_Directory_Databases-Exporting_Data.html#Exporting-db2ldif">https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Populating_Directory_Databases-Exporting_Data.html#Exporting-db2ldif</a> >>> >>> Once you decide on a server, then you need to reinitialize all the other >>> servers/replicas from the "good" one. Use " ipa-replica-manage >>> re-initialize" for this. >>> >>> <a moz-do-not-send="true" href="https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/ipa-replica-manage.html#initialize">https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/ipa-replica-manage.html#initialize</a> >>> >>> That's it. >>> >>> Good luck, >>> Mark >>> >>>> Would it be acceptable to just 'assume' one of the replicas is good >>>> (taking the risk of whatever missing pieces I'll have to deal with), >>>> completely removing the others, and then rebuilding the replicas from >>>> scratch? >>>> >>>> If I go that route, what are the potential pitfalls? >>>> >>>> >>>> I want to decide on an approach and try and resolve this once and for all. >>>> >>>> Thanks again! It really is appreciated as I've been frustrated with >>>> this for a while now. >>>> >>>> -- Chris >>>> >>>> On Tue, Mar 7, 2017 at 8:45 AM, Mark Reynolds <<a moz-do-not-send="true" href="mailto:mareynol@redhat.com">mareynol@redhat.com</a>> wrote: >>>>> What version of 389-ds-base are you using? >>>>> >>>>> rpm -qa | grep 389-ds-base >>>>> >>>>> >>>>> comments below.. >>>>> >>>>> On 03/06/2017 02:37 PM, Christopher Young wrote: >>>>> >>>>> I've seen similar posts, but in the interest of asking fresh and >>>>> trying to understand what is going on, I thought I would ask for >>>>> advice on how best to handle this situation. >>>>> >>>>> In the interest of providing some history: >>>>> I have three (3) FreeIPA servers. Everything is running 4.4.0 now. >>>>> The originals (orldc-prod-ipa01, orldc-prod-ipa02) were upgraded from >>>>> the 3.x branch quite a while back. Everything had been working fine, >>>>> however I ran into a replication issue (that I _think_ may have been a >>>>> result of IPv6 being disabled by my default Ansible roles). I thought >>>>> I had resolved that by reinitializing the 2nd replica, >>>>> orldc-prod-ipa02. >>>>> >>>>> In any case, I feel like the replication has never been fully stable >>>>> since then, and I have all types of errors in messages that indicate >>>>> something is off. I had single introduced a 3rd replica such that the >>>>> agreements would look like so: >>>>> >>>>> orldc-prod-ipa01 -> orldc-prod-ipa02 ---> bohdc-prod-ipa01 >>>>> >>>>> It feels like orldc-prod-ipa02 & bohdc-prod-ipa01 are out of sync. >>>>> I've tried reinitializing them in order but with no positive results. >>>>> At this point, I feel like I'm ready to 'bite the bullet' and tear >>>>> them down quickly (remove them from IPA, delete the local >>>>> DBs/directories) and rebuild them from scratch. >>>>> >>>>> I want to minimize my impact as much as possible (which I can somewhat >>>>> do by redirecting LDAP/DNS request via my load-balancers temporarily) >>>>> and do this right. >>>>> >>>>> (Getting to the point...) >>>>> >>>>> I'd like advice on the order of operations to do this. Give the >>>>> errors (I'll include samples at the bottom of this message), does it >>>>> make sense for me to remove the replicas on bohdc-prod-ipa01 & >>>>> orldc-prod-ipa02 (in that order), wipe out any directories/residual >>>>> pieces (I'd need some idea of what to do there), and then create new >>>>> replicas? -OR- Should I export/backup the LDAP DB and rebuild >>>>> everything from scratch. >>>>> >>>>> I need advice and ideas. Furthermore, if there is someone with >>>>> experience in this that would be interested in making a little money >>>>> on the side, let me know, because having an extra brain and set of >>>>> hands would be welcome. >>>>> >>>>> DETAILS: >>>>> ================= >>>>> >>>>> >>>>> ERRORS I see on orldc-prod-ipa01 (the one whose LDAP DB seems the most >>>>> up-to-date since my changes are usually directed at it): >>>>> ------ >>>>> Mar 6 14:36:24 orldc-prod-ipa01 ns-slapd: >>>>> [06/Mar/2017:14:36:24.434956575 -0500] NSMMReplicationPlugin - >>>>> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >>>>> (orldc-prod-ipa02:389): The remote replica has a different database >>>>> generation ID than the local database. You may have to reinitialize >>>>> the remote replica, or the local replica. >>>>> Mar 6 14:36:25 orldc-prod-ipa01 ipa-dnskeysyncd: ipa : INFO >>>>> LDAP bind... >>>>> Mar 6 14:36:25 orldc-prod-ipa01 ipa-dnskeysyncd: ipa : INFO >>>>> Commencing sync process >>>>> Mar 6 14:36:26 orldc-prod-ipa01 ipa-dnskeysyncd: >>>>> ipa.ipapython.dnssec.keysyncer.KeySyncer: INFO Initial LDAP dump >>>>> is done, sychronizing with ODS and BIND >>>>> Mar 6 14:36:27 orldc-prod-ipa01 ns-slapd: >>>>> [06/Mar/2017:14:36:27.799519203 -0500] NSMMReplicationPlugin - >>>>> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >>>>> (orldc-prod-ipa02:389): The remote replica has a different database >>>>> generation ID than the local database. You may have to reinitialize >>>>> the remote replica, or the local replica. >>>>> Mar 6 14:36:30 orldc-prod-ipa01 ns-slapd: >>>>> [06/Mar/2017:14:36:30.994760069 -0500] NSMMReplicationPlugin - >>>>> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >>>>> (orldc-prod-ipa02:389): The remote replica has a different database >>>>> generation ID than the local database. You may have to reinitialize >>>>> the remote replica, or the local replica. >>>>> Mar 6 14:36:34 orldc-prod-ipa01 ns-slapd: >>>>> [06/Mar/2017:14:36:34.940115481 -0500] NSMMReplicationPlugin - >>>>> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >>>>> (orldc-prod-ipa02:389): The remote replica has a different database >>>>> generation ID than the local database. You may have to reinitialize >>>>> the remote replica, or the local replica. >>>>> Mar 6 14:36:35 orldc-prod-ipa01 named-pkcs11[32134]: client >>>>> 10.26.250.66#49635 (56.10.in-addr.arpa): transfer of >>>>> '56.10.in-addr.arpa/IN': AXFR-style IXFR started >>>>> Mar 6 14:36:35 orldc-prod-ipa01 named-pkcs11[32134]: client >>>>> 10.26.250.66#49635 (56.10.in-addr.arpa): transfer of >>>>> '56.10.in-addr.arpa/IN': AXFR-style IXFR ended >>>>> Mar 6 14:36:37 orldc-prod-ipa01 ns-slapd: >>>>> [06/Mar/2017:14:36:37.977875463 -0500] NSMMReplicationPlugin - >>>>> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >>>>> (orldc-prod-ipa02:389): The remote replica has a different database >>>>> generation ID than the local database. You may have to reinitialize >>>>> the remote replica, or the local replica. >>>>> Mar 6 14:36:40 orldc-prod-ipa01 ns-slapd: >>>>> [06/Mar/2017:14:36:40.999275184 -0500] NSMMReplicationPlugin - >>>>> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >>>>> (orldc-prod-ipa02:389): The remote replica has a different database >>>>> generation ID than the local database. You may have to reinitialize >>>>> the remote replica, or the local replica. >>>>> Mar 6 14:36:45 orldc-prod-ipa01 ns-slapd: >>>>> [06/Mar/2017:14:36:45.211260414 -0500] NSMMReplicationPlugin - >>>>> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >>>>> (orldc-prod-ipa02:389): The remote replica has a different database >>>>> generation ID than the local database. You may have to reinitialize >>>>> the remote replica, or the local replica. >>>>> ------ >>>>> >>>>> These messages indicate that the replica does not have the same database as >>>>> the master. So either the master or the replica needs to be reinitialized., >>>>> More on this below... >>>>> >>>>> >>>>> Errors on orldc-prod-ipa02: >>>>> ------ >>>>> r 6 14:16:04 orldc-prod-ipa02 ipa-dnskeysyncd: ipa : INFO >>>>> Commencing sync process >>>>> Mar 6 14:16:04 orldc-prod-ipa02 ipa-dnskeysyncd: >>>>> ipa.ipapython.dnssec.keysyncer.KeySyncer: INFO Initial LDAP dump >>>>> is done, sychronizing with ODS and BIND >>>>> Mar 6 14:16:05 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:05.934405274 -0500] attrlist_replace - attr_replace >>>>> (nsslapd-referral, <a class="moz-txt-link-freetext" href="ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca">ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca</a>) >>>>> failed. >>>>> Mar 6 14:16:05 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:05.937278142 -0500] attrlist_replace - attr_replace >>>>> (nsslapd-referral, <a class="moz-txt-link-freetext" href="ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca">ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca</a>) >>>>> failed. >>>>> Mar 6 14:16:05 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:05.939434025 -0500] attrlist_replace - attr_replace >>>>> (nsslapd-referral, <a class="moz-txt-link-freetext" href="ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca">ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca</a>) >>>>> failed. >>>>> >>>>> These are harmless "errors" which have been removed in newer versions of >>>>> 389-ds-base. >>>>> >>>>> Mar 6 14:16:06 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:06.882795654 -0500] >>>>> agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389) - >>>>> Can't locate CSN 58bdf8f5000200070000 in the changelog (DB rc=-30988). >>>>> If replication stops, the consumer may need to be reinitialized. >>>>> Mar 6 14:16:06 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:06.886029272 -0500] NSMMReplicationPlugin - >>>>> changelog program - agmt="cn=meTobohdc-prod-ipa01.passur.local" >>>>> (bohdc-prod-ipa01:389): CSN 58bdf8f5000200070000 not found, we aren't >>>>> as up to date, or we purged >>>>> >>>>> This "could" also be a known issue that is fixed in newer versions of >>>>> 389-ds-base. Or this is a valid error message due to the replica being >>>>> stale for a very long time and records actually being purged from the >>>>> changelog before they were replicated. >>>>> >>>>> Mar 6 14:16:06 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:06.888679268 -0500] NSMMReplicationPlugin - >>>>> agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389): >>>>> Data required to update replica has been purged from the changelog. >>>>> The replica must be reinitialized. >>>>> Mar 6 14:16:06 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:06.960804253 -0500] NSMMReplicationPlugin - >>>>> agmt="cn=masterAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >>>>> (orldc-prod-ipa01:389): The remote replica has a different database >>>>> generation ID than the local database. You may have to reinitialize >>>>> the remote replica, or the local replica. >>>>> >>>>> Okay, so your replication agreements/servers are not in sync. I suspect you >>>>> created a new replica and used that to initialize a valid replica which >>>>> broke things. Something like that. You need to find a "good" replica >>>>> server and reinitialize the other replicas from that server. These errors >>>>> needs to addressed asap, as it's halting replication for those agreements >>>>> which explains the "instability" you are describing. >>>>> >>>>> Mark >>>>> >>>>> Mar 6 14:16:08 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:08.960622608 -0500] attrlist_replace - attr_replace >>>>> (nsslapd-referral, <a class="moz-txt-link-freetext" href="ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca">ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca</a>) >>>>> failed. >>>>> Mar 6 14:16:08 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:08.968927168 -0500] attrlist_replace - attr_replace >>>>> (nsslapd-referral, <a class="moz-txt-link-freetext" href="ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca">ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca</a>) >>>>> failed. >>>>> Mar 6 14:16:08 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:08.976952118 -0500] attrlist_replace - attr_replace >>>>> (nsslapd-referral, <a class="moz-txt-link-freetext" href="ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca">ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca</a>) >>>>> failed. >>>>> Mar 6 14:16:09 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:09.972315877 -0500] NSMMReplicationPlugin - >>>>> agmt="cn=masterAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >>>>> (orldc-prod-ipa01:389): The remote replica has a different database >>>>> generation ID than the local database. You may have to reinitialize >>>>> the remote replica, or the local replica. >>>>> Mar 6 14:16:10 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:10.034810948 -0500] >>>>> agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389) - >>>>> Can't locate CSN 58bdf8f5000200070000 in the changelog (DB rc=-30988). >>>>> If replication stops, the consumer may need to be reinitialized. >>>>> Mar 6 14:16:10 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:10.040020359 -0500] NSMMReplicationPlugin - >>>>> changelog program - agmt="cn=meTobohdc-prod-ipa01.passur.local" >>>>> (bohdc-prod-ipa01:389): CSN 58bdf8f5000200070000 not found, we aren't >>>>> as up to date, or we purged >>>>> Mar 6 14:16:10 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:10.042846879 -0500] NSMMReplicationPlugin - >>>>> agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389): >>>>> Data required to update replica has been purged from the changelog. >>>>> The replica must be reinitialized. >>>>> Mar 6 14:16:13 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:13.013253769 -0500] attrlist_replace - attr_replace >>>>> (nsslapd-referral, <a class="moz-txt-link-freetext" href="ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca">ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca</a>) >>>>> failed. >>>>> Mar 6 14:16:13 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:13.021514225 -0500] attrlist_replace - attr_replace >>>>> (nsslapd-referral, <a class="moz-txt-link-freetext" href="ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca">ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca</a>) >>>>> failed. >>>>> Mar 6 14:16:13 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:13.027521508 -0500] attrlist_replace - attr_replace >>>>> (nsslapd-referral, <a class="moz-txt-link-freetext" href="ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca">ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca</a>) >>>>> failed. >>>>> Mar 6 14:16:13 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:13.110566247 -0500] NSMMReplicationPlugin - >>>>> agmt="cn=masterAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >>>>> (orldc-prod-ipa01:389): The remote replica has a different database >>>>> generation ID than the local database. You may have to reinitialize >>>>> the remote replica, or the local replica. >>>>> Mar 6 14:16:14 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:14.179819300 -0500] >>>>> agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389) - >>>>> Can't locate CSN 58bdf8f5000200070000 in the changelog (DB rc=-30988). >>>>> If replication stops, the consumer may need to be reinitialized. >>>>> Mar 6 14:16:14 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:14.188353328 -0500] NSMMReplicationPlugin - >>>>> changelog program - agmt="cn=meTobohdc-prod-ipa01.passur.local" >>>>> (bohdc-prod-ipa01:389): CSN 58bdf8f5000200070000 not found, we aren't >>>>> as up to date, or we purged >>>>> Mar 6 14:16:14 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:14.196463928 -0500] NSMMReplicationPlugin - >>>>> agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389): >>>>> Data required to update replica has been purged from the changelog. >>>>> The replica must be reinitialized. >>>>> Mar 6 14:16:17 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:17.068292919 -0500] attrlist_replace - attr_replace >>>>> (nsslapd-referral, <a class="moz-txt-link-freetext" href="ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca">ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca</a>) >>>>> failed. >>>>> Mar 6 14:16:17 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:17.071241757 -0500] attrlist_replace - attr_replace >>>>> (nsslapd-referral, <a class="moz-txt-link-freetext" href="ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca">ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca</a>) >>>>> failed. >>>>> Mar 6 14:16:17 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:17.073793922 -0500] attrlist_replace - attr_replace >>>>> (nsslapd-referral, <a class="moz-txt-link-freetext" href="ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca">ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca</a>) >>>>> failed. >>>>> ------ >>>>> >>>>> >>>>> Thanks in advance!!! >>>>> >>>>> -- Chris >>>>> >>>>> > </div> </blockquote> </body> </html>