On 10/18/2017 09:06 AM, john.bowman--- via FreeIPA-users wrote:
> Howdy!  Looks like the IPA application crashed on one of our servers (RHEL 6) 
> early this morning and after restarting it I saw the following in 
> /var/log/dirsrv/slapd-TLD/errors log:
>
> [18/Oct/2017:07:35:49 -0500] - slapd started.  Listening on All Interfaces 
> port 389 for LDAP requests
> [18/Oct/2017:07:35:49 -0500] - Listening on All Interfaces port 636 for LDAPS 
> requests
> [18/Oct/2017:07:35:49 -0500] - Listening on /var/run/slapd-TLD.socket for 
> LDAPI requests
> [18/Oct/2017:07:35:59 -0500] NSMMReplicationPlugin - agmt="cn=meToidm1.tld 
> (idm1:389): Replica has a different generation ID than the local data.
> [18/Oct/2017:07:36:03 -0500] NSMMReplicationPlugin - agmt="cn=meToidm2..tld" 
> (idm2:389): Replica has a different generation ID than the local data.
> [18/Oct/2017:07:36:03 -0500] NSMMReplicationPlugin - agmt="cn=meToidm1.tld" 
> (idm1:389): Replica has a different generation ID than the local data.
These errors indicate that the database on the server and remote replica
do not have the same origin.  Which means either the replica was not
initialized from this server, or the local db or the remote was
overwritten from a different import.  Or perhaps the database got
corrupted if the Directory Server crashed.  Either way they are now out
of sync, and you need to reinitialize the replication agreements.  The
issue is which direction to initialize replication:  idm1 -> idm2 or
idm2 to idm1?  You have to figure out which one has the correct/current
data set, then use that server to initialize the other.  Once you
initialize the agreements these errors should go away and replication
should work. 
>
> And that same message appears in the error log on the hosts that have a 
> replication agreement with this node.   And it does not appear to be 
> replicating with the other nodes as well.
>
> I searched for that message and found:
>
> https://access.redhat.com/solutions/136993
>
> But that implies that this is from a failed install and that is not the same 
> situation.   
>
> Any ideas on the best method to clean this up would be appreciated.
>
> Thanks!
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

Reply via email to