Re: [Freeipa-users] Question about removed replica, take two
Ludwig, Thank you! John DeSantis 2016-10-05 10:43 GMT-04:00 Ludwig Krispenz: > Hi, > > the RUV in the replication agreement is maintained to control changelog > trimming, no changes should be deleted from the changelog which have not > been seen by all consumers. Since not always a connection for a replication > agreement can be established, eg if the consumer is down, this information > is made persistent and kept in the replication agreement. > So, if you have references to removed servers in the agreement this should > do no harm since teh changes have alredy be removed from the changelog > during cleanallruv. > The only scenario a problem could arise is if you reinstall a replica on one > of the removed with a new replica ID, then you could end up with two replica > ids with the same url and get the attrlist_replace errors. > > The removal of the replica id from the replication agreement RUV is noe > handled by cleanallruv (upstream ticket #48414), but you can edit the > dse.ldif and remove them manually > > Regards, > Ludwig > > > On 10/05/2016 03:07 PM, John Desantis wrote: >> >> Hello all (again), >> >> I think my reference to a disease prevented my message from being >> delivered, despite seeing it posted on the list archive. I apologize >> in advance for the additional "noise". >> >> Anyways, I was hoping some lingering questions could be answered >> regarding some visible entries via ldapsearch, which manifest a >> removed replica's hostname [1]. >> >> Running the ipa-replica-manage and ipa-csreplica-manage commands do >> not show the host in question any longer, but when I run a few >> directory searches on each replica using the commands below: >> >> # ldapsearch -Y GSSAPI -o ldif-wrap=no -h localhost -D "cn=directory >> manager" -b "cn=config" objectclass=nsds5replica >> # ldapsearch -Y GSSAPI -o ldif-wrap=no -h localhost -D "cn=directory >> manager" -b "cn=config" objectclass=nsds5replicationagreement >> >> I'm able to see the old host on the master, but not on the replicas. See >> below. >> >> # master, replica id 4: >> ldapsearch -Y GSSAPI -o ldif-wrap=no -h localhost -D "cn=directory >> manager" -b "cn=config" objectclass=nsds5replica|grep oldhost >> nsDS5ReplicaBindDN: >> >> krbprincipalname=ldap/oldhost.dom.dom@dom.dom.dom,cn=services,cn=accounts,dc=dom,dc=dom,dc=dom >> >> ldapsearch -Y GSSAPI -o ldif-wrap=no -h localhost -D "cn=directory >> manager" -b "cn=config" objectclass=nsds5replicationagreement|grep >> oldhost >> nsds50ruv: {replica 24 ldap://oldhost.dom.dom.dom:389} >> 5447f2520018 5447f8610018 >> nsruvReplicaLastModified: {replica 24 ldap://oldhost.dom.dom.dom:389} >> >> nsds50ruv: {replica 24 ldap://oldhost.dom.dom.dom:389} >> 5447f2520018 5447f56b00020018 >> nsruvReplicaLastModified: {replica 24 ldap://oldhost.dom.dom.dom:389} >> >> >> It's listed twice due to the other hosts in the topology. >> >> # replica id 22 >> ldapsearch -Y GSSAPI -o ldif-wrap=no -h localhost -D "cn=directory >> manager" -b "cn=config" objectclass=nsds5replica|grep oldhost >> ldapsearch -Y GSSAPI -o ldif-wrap=no -h localhost -D "cn=directory >> manager" -b "cn=config" objectclass=nsds5replicationagreement|grep >> oldhost >> >> # replica id 21 >> ldapsearch -Y GSSAPI -o ldif-wrap=no -h localhost -D "cn=directory >> manager" -b "cn=config" objectclass=nsds5replica|grep oldhost >> ldapsearch -Y GSSAPI -o ldif-wrap=no -h localhost -D "cn=directory >> manager" -b "cn=config" objectclass=nsds5replicationagreement|grep >> oldhost >> >> The other two replicas no longer have the reference to the old host >> after the CLEANALLRUV and CLEANRUV tasks performed by ldapmodify. I >> then read via [2] that the dse.ldif could be manually edited to remove >> references, but I'm not sure if that should be done if the general >> opinion is that the old references aren't going to cause a problem. >> Based upon the information above, is having a reference to the hold >> host via the ldapsearch outputs above going to be a problem? If the >> entry shouldn't be there, should the ldapmodify be performed against >> the >> "cn=meTomaster.dom.dom.dom,cn=replica,cn=dc\3Ddom\2Cdc\3Ddom\2Cdc\3Ddom,cn=mapping >> tree,cn=config" bases? >> >> For reference, these are the commands I ran to get to state [1]: >> >> # master >> ldapmodify -x -W -h localhost -D "cn=directory manager" <> dn: cn=replica,cn=dc\3Ddom\2Cdc\3Ddom\2Cdc\3Ddom,cn=mapping tree,cn=config >> changetype: modify >> replace: nsds5task >> nsds5task: CLEANALLRUV24 >> EOF >> >> ldapmodify -a -x -W -h localhost -D "cn=directory manager" <> dn: cn=abort 24,cn=abort cleanallruv,cn=tasks,cn=config >> objectclass: extensibleObject >> cn: abort 24 >> replica-base-dn: dc=dom,dc=dom,dc=dom >> replica-id: 24 >> EOF >> >> ldapmodify -h localhost -p 389 -x -W -D "cn=directory manager" <> dn: cn=clean 97,cn=cleanallruv,cn=tasks,cn=config >> changetype: add >> objectclass: top >> objectclass: extensibleObject
Re: [Freeipa-users] Question about removed replica, take two
Hi, the RUV in the replication agreement is maintained to control changelog trimming, no changes should be deleted from the changelog which have not been seen by all consumers. Since not always a connection for a replication agreement can be established, eg if the consumer is down, this information is made persistent and kept in the replication agreement. So, if you have references to removed servers in the agreement this should do no harm since teh changes have alredy be removed from the changelog during cleanallruv. The only scenario a problem could arise is if you reinstall a replica on one of the removed with a new replica ID, then you could end up with two replica ids with the same url and get the attrlist_replace errors. The removal of the replica id from the replication agreement RUV is noe handled by cleanallruv (upstream ticket #48414), but you can edit the dse.ldif and remove them manually Regards, Ludwig On 10/05/2016 03:07 PM, John Desantis wrote: Hello all (again), I think my reference to a disease prevented my message from being delivered, despite seeing it posted on the list archive. I apologize in advance for the additional "noise". Anyways, I was hoping some lingering questions could be answered regarding some visible entries via ldapsearch, which manifest a removed replica's hostname [1]. Running the ipa-replica-manage and ipa-csreplica-manage commands do not show the host in question any longer, but when I run a few directory searches on each replica using the commands below: # ldapsearch -Y GSSAPI -o ldif-wrap=no -h localhost -D "cn=directory manager" -b "cn=config" objectclass=nsds5replica # ldapsearch -Y GSSAPI -o ldif-wrap=no -h localhost -D "cn=directory manager" -b "cn=config" objectclass=nsds5replicationagreement I'm able to see the old host on the master, but not on the replicas. See below. # master, replica id 4: ldapsearch -Y GSSAPI -o ldif-wrap=no -h localhost -D "cn=directory manager" -b "cn=config" objectclass=nsds5replica|grep oldhost nsDS5ReplicaBindDN: krbprincipalname=ldap/oldhost.dom.dom@dom.dom.dom,cn=services,cn=accounts,dc=dom,dc=dom,dc=dom ldapsearch -Y GSSAPI -o ldif-wrap=no -h localhost -D "cn=directory manager" -b "cn=config" objectclass=nsds5replicationagreement|grep oldhost nsds50ruv: {replica 24 ldap://oldhost.dom.dom.dom:389} 5447f2520018 5447f8610018 nsruvReplicaLastModified: {replica 24 ldap://oldhost.dom.dom.dom:389} nsds50ruv: {replica 24 ldap://oldhost.dom.dom.dom:389} 5447f2520018 5447f56b00020018 nsruvReplicaLastModified: {replica 24 ldap://oldhost.dom.dom.dom:389} It's listed twice due to the other hosts in the topology. # replica id 22 ldapsearch -Y GSSAPI -o ldif-wrap=no -h localhost -D "cn=directory manager" -b "cn=config" objectclass=nsds5replica|grep oldhost ldapsearch -Y GSSAPI -o ldif-wrap=no -h localhost -D "cn=directory manager" -b "cn=config" objectclass=nsds5replicationagreement|grep oldhost # replica id 21 ldapsearch -Y GSSAPI -o ldif-wrap=no -h localhost -D "cn=directory manager" -b "cn=config" objectclass=nsds5replica|grep oldhost ldapsearch -Y GSSAPI -o ldif-wrap=no -h localhost -D "cn=directory manager" -b "cn=config" objectclass=nsds5replicationagreement|grep oldhost The other two replicas no longer have the reference to the old host after the CLEANALLRUV and CLEANRUV tasks performed by ldapmodify. I then read via [2] that the dse.ldif could be manually edited to remove references, but I'm not sure if that should be done if the general opinion is that the old references aren't going to cause a problem. Based upon the information above, is having a reference to the hold host via the ldapsearch outputs above going to be a problem? If the entry shouldn't be there, should the ldapmodify be performed against the "cn=meTomaster.dom.dom.dom,cn=replica,cn=dc\3Ddom\2Cdc\3Ddom\2Cdc\3Ddom,cn=mapping tree,cn=config" bases? For reference, these are the commands I ran to get to state [1]: # master ldapmodify -x -W -h localhost -D "cn=directory manager"
[Freeipa-users] Question about removed replica, take two
Hello all (again), I think my reference to a disease prevented my message from being delivered, despite seeing it posted on the list archive. I apologize in advance for the additional "noise". Anyways, I was hoping some lingering questions could be answered regarding some visible entries via ldapsearch, which manifest a removed replica's hostname [1]. Running the ipa-replica-manage and ipa-csreplica-manage commands do not show the host in question any longer, but when I run a few directory searches on each replica using the commands below: # ldapsearch -Y GSSAPI -o ldif-wrap=no -h localhost -D "cn=directory manager" -b "cn=config" objectclass=nsds5replica # ldapsearch -Y GSSAPI -o ldif-wrap=no -h localhost -D "cn=directory manager" -b "cn=config" objectclass=nsds5replicationagreement I'm able to see the old host on the master, but not on the replicas. See below. # master, replica id 4: ldapsearch -Y GSSAPI -o ldif-wrap=no -h localhost -D "cn=directory manager" -b "cn=config" objectclass=nsds5replica|grep oldhost nsDS5ReplicaBindDN: krbprincipalname=ldap/oldhost.dom.dom@dom.dom.dom,cn=services,cn=accounts,dc=dom,dc=dom,dc=dom ldapsearch -Y GSSAPI -o ldif-wrap=no -h localhost -D "cn=directory manager" -b "cn=config" objectclass=nsds5replicationagreement|grep oldhost nsds50ruv: {replica 24 ldap://oldhost.dom.dom.dom:389} 5447f2520018 5447f8610018 nsruvReplicaLastModified: {replica 24 ldap://oldhost.dom.dom.dom:389} nsds50ruv: {replica 24 ldap://oldhost.dom.dom.dom:389} 5447f2520018 5447f56b00020018 nsruvReplicaLastModified: {replica 24 ldap://oldhost.dom.dom.dom:389} It's listed twice due to the other hosts in the topology. # replica id 22 ldapsearch -Y GSSAPI -o ldif-wrap=no -h localhost -D "cn=directory manager" -b "cn=config" objectclass=nsds5replica|grep oldhost ldapsearch -Y GSSAPI -o ldif-wrap=no -h localhost -D "cn=directory manager" -b "cn=config" objectclass=nsds5replicationagreement|grep oldhost # replica id 21 ldapsearch -Y GSSAPI -o ldif-wrap=no -h localhost -D "cn=directory manager" -b "cn=config" objectclass=nsds5replica|grep oldhost ldapsearch -Y GSSAPI -o ldif-wrap=no -h localhost -D "cn=directory manager" -b "cn=config" objectclass=nsds5replicationagreement|grep oldhost The other two replicas no longer have the reference to the old host after the CLEANALLRUV and CLEANRUV tasks performed by ldapmodify. I then read via [2] that the dse.ldif could be manually edited to remove references, but I'm not sure if that should be done if the general opinion is that the old references aren't going to cause a problem. Based upon the information above, is having a reference to the hold host via the ldapsearch outputs above going to be a problem? If the entry shouldn't be there, should the ldapmodify be performed against the "cn=meTomaster.dom.dom.dom,cn=replica,cn=dc\3Ddom\2Cdc\3Ddom\2Cdc\3Ddom,cn=mapping tree,cn=config" bases? For reference, these are the commands I ran to get to state [1]: # master ldapmodify -x -W -h localhost -D "cn=directory manager"
[Freeipa-users] Question about removed replica
Hello all, Like a case of herpes, I'm back! Anyways, I was hoping some lingering questions could be answered regarding some visible entries via ldapsearch, which manifest a removed replica's hostname [1]. Running the ipa-replica-manage and ipa-csreplica-manage commands do not show the host in question any longer, but when I run a few directory searches on each replica using the commands below: # ldapsearch -Y GSSAPI -o ldif-wrap=no -h localhost -D "cn=directory manager" -b "cn=config" objectclass=nsds5replica # ldapsearch -Y GSSAPI -o ldif-wrap=no -h localhost -D "cn=directory manager" -b "cn=config" objectclass=nsds5replicationagreement I'm able to see the old host on the master, but not on the replicas. See below. # master, replica id 4: ldapsearch -Y GSSAPI -o ldif-wrap=no -h localhost -D "cn=directory manager" -b "cn=config" objectclass=nsds5replica|grep oldhost nsDS5ReplicaBindDN: krbprincipalname=ldap/oldhost.dom.dom@dom.dom.dom,cn=services,cn=accounts,dc=dom,dc=dom,dc=dom ldapsearch -Y GSSAPI -o ldif-wrap=no -h localhost -D "cn=directory manager" -b "cn=config" objectclass=nsds5replicationagreement|grep oldhost nsds50ruv: {replica 24 ldap://oldhost.dom.dom.dom:389} 5447f2520018 5447f8610018 nsruvReplicaLastModified: {replica 24 ldap://oldhost.dom.dom.dom:389} nsds50ruv: {replica 24 ldap://oldhost.dom.dom.dom:389} 5447f2520018 5447f56b00020018 nsruvReplicaLastModified: {replica 24 ldap://oldhost.dom.dom.dom:389} It's listed twice due to the other hosts in the topology. # replica id 22 ldapsearch -Y GSSAPI -o ldif-wrap=no -h localhost -D "cn=directory manager" -b "cn=config" objectclass=nsds5replica|grep oldhost ldapsearch -Y GSSAPI -o ldif-wrap=no -h localhost -D "cn=directory manager" -b "cn=config" objectclass=nsds5replicationagreement|grep oldhost # replica id 21 ldapsearch -Y GSSAPI -o ldif-wrap=no -h localhost -D "cn=directory manager" -b "cn=config" objectclass=nsds5replica|grep oldhost ldapsearch -Y GSSAPI -o ldif-wrap=no -h localhost -D "cn=directory manager" -b "cn=config" objectclass=nsds5replicationagreement|grep oldhost The other two replicas no longer have the reference to the old host after the CLEANALLRUV and CLEANRUV tasks performed by ldapmodify. I then read via [2] that the dse.ldif could be manually edited to remove references, but I'm not sure if that should be done if the general opinion is that the old references aren't going to cause a problem. Based upon the information above, is having a reference to the hold host via the ldapsearch outputs above going to be a problem? If the entry shouldn't be there, should the ldapmodify be performed against the "cn=meTomaster.dom.dom.dom,cn=replica,cn=dc\3Ddom\2Cdc\3Ddom\2Cdc\3Ddom,cn=mapping tree,cn=config" bases? For reference, these are the commands I ran to get to state [1]: # master ldapmodify -x -W -h localhost -D "cn=directory manager"