Ludwig,
Thank you!
John DeSantis
2016-10-05 10:43 GMT-04:00 Ludwig Krispenz <lkris...@redhat.com>:
> 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}
>> 5447f252000000180000 5447f861000000180000
>> nsruvReplicaLastModified: {replica 24 ldap://oldhost.dom.dom.dom:389}
>> 00000000
>> nsds50ruv: {replica 24 ldap://oldhost.dom.dom.dom:389}
>> 5447f252000000180000 5447f56b000200180000
>> nsruvReplicaLastModified: {replica 24 ldap://oldhost.dom.dom.dom:389}
>> 00000000
>>
>> 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" <<EOF
>> 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" <<EOF
>> 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" <<EOF
>> dn: cn=clean 97,cn=cleanallruv,cn=tasks,cn=config
>> changetype: add
>> objectclass: top
>> objectclass: extensibleObject
>> replica-base-dn: dc=dom,dc=dom,dc=dom
>> replica-id: 97
>> cn: clean 97
>> EOF
>>
>> # single host which hung on CLEANALLRUV
>> ldapmodify -a -x -W -h localhost -D "cn=directory manager" <<EOF
>> dn: cn=replica,cn=dc\3Ddom\2Cdc\3Ddom\2Cdc\3Ddom,cn=mapping tree,cn=config
>> changetype: modify
>> replace: nsds5task
>> nsds5task: CLEANRUV24
>> EOF
>>
>>
>> [1]
>> https://www.redhat.com/archives/freeipa-users/2016-August/msg00331.html
>> [2] https://www.redhat.com/archives/freeipa-users/2015-June/msg00382.html
>>
>> Thanks!
>> John DeSantis
>>
>
> --
> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
> Commercial register: Amtsgericht Muenchen, HRB 153243,
> Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill,
> Eric Shander
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
