Dear Ludwig,

Thank you for the explanations. Now I understand.

Strangely then, the problem csn was on the replica that we had to reinitialize. 
How could such a csn disappear?

Thanks again for the help. Much appreciated.
Sent from my iPhone

> On 19 May 2017, at 08:47, Ludwig Krispenz <lkris...@redhat.com> wrote:
> 
> 
>> On 05/18/2017 05:35 PM, Christophe TREFOIS wrote:
>> Dear Ludwig,
>> 
>> Thanks for your help in IRC to guide me in running the right commands.
>> 
>> Here is the output, toto1 and toto2 are CA master, and toto3 and toto4 are 
>> non CA master. The problematic replica was toto3, and after re-init, we 
>> haven’t seen any errors in the log anymore.
>> 
>> https://paste.fedoraproject.org/paste/j8c30CZPyh8rPymjbKSvZF5M1UNdIGYhyRLivL9gydE=
>> 
>> I also ran ipa-replica-manage on all replicas to all replicas, so total of 
>> 16 command, and found all of them reported “incremental update succeeded”.
>> 
>> As discussed, I’m not sure what I’m looking at with the RUV stuff above, and 
>> any explanation for a newcomer to ldap / ds / freeipa would be greatly 
>> appreciated.
> ok, here is a quick explanation of the csn/ruv stuff. 
> 
> each change applied on a server gets a CSN (change sequence number), it 
> basically consists of a timestamp and an identifier of the replica where it 
> was originally applied, so in 59095fe1000b00120000 there is a time stamp: 
> 59095fe1 and a replicaid: 0012 == 18, the rest of the csn isused to serialize 
> csns within the one second resolution of a timestamp.
> a change is applied to the main database and written to the changelog, with 
> the csn as key.
> 
> now each replica keeps track of the latest csn it has seen for each 
> replicaID, so you get a vector of max csns, this is called RUV (replica 
> update vector).
> In a replication session, the supplier compares its own ruv with the ruv of 
> the consumer and so decides if it has changes which the consumer has not yet 
> seen.
> based on the consumer ruv it determines the start csn to send updates.
> 
> 
>> 
>> Thanks a lot for your help!
>> 
>> Kind regards,
>> Christophe aka Trefex
>> 
>>> On 18 May 2017, at 17:04, Christophe TREFOIS <christophe.tref...@uni.lu> 
>>> wrote:
>>> 
>>> Hi Ludwig,
>>> 
>>> Since we were scared, we did a full re-init of that specific replica from 
>>> the CA master, and it looks like the issue is not appearing anymore.
>>> 
>>> Is this sufficient, or should we still investigate ?
>>> 
>>> Thanks for your help!
>>> Christophe
>>> -- 
>>> 
>>> Dr Christophe Trefois, Dipl.-Ing.  
>>> Technical Specialist / Post-Doc
>>> 
>>> UNIVERSITÉ DU LUXEMBOURG
>>> 
>>> LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE
>>> Campus Belval | House of Biomedicine  
>>> 6, avenue du Swing 
>>> L-4367 Belvaux  
>>> T: +352 46 66 44 6124 
>>> F: +352 46 66 44 6949  
>>> http://www.uni.lu/lcsb
>>> 
>>>         
>>> 
>>> 
>>> ----
>>> This message is confidential and may contain privileged information. 
>>> It is intended for the named recipient only. 
>>> If you receive it in error please notify me and permanently delete the 
>>> original message and any copies. 
>>> ----
>>>   
>>> 
>>>> On 18 May 2017, at 16:11, Ludwig Krispenz <lkris...@redhat.com> wrote:
>>>> 
>>>> hi,
>>>> 
>>>> there was a change that in the case of a missing csn ds would not silently 
>>>> use a "close" one and continue, but log an error, backoff and retry - 
>>>> after updates on other masters the staring csn coudl change and 
>>>> replication continue.
>>>> 
>>>> Now, in your case the csn reported missing: 59095fe1000b00120000
>>>> has a time stamp from May,3rd, so it could very well be correct that this 
>>>> csn is no longer found in the changelog.
>>>> 
>>>> To continue analysis, could you provide the replicaids of all your current 
>>>> replicas, and which is the replicaid of the sever logging the change and 
>>>> the ruvs of the replicas from all servers.
>>>> ldapsearch  .... -D "cn=directory manager" .... -b cn=config 
>>>> "objectclass=nsds5replica" nsds50ruv
>>>> 
>>>> Regards,
>>>> Ludwig
>>>> 
>>>>> On 05/18/2017 03:09 PM, Christophe TREFOIS wrote:
>>>>> Hi all,
>>>>> 
>>>>> Did a yum update on one of my replicas, non CA master, and upgrade was 
>>>>> successful (ipupgrade.log) said so. 
>>>>> 
>>>>> 
>>>>> Hwoever, now every few seconds I get the following message. 
>>>>> https://paste.fedoraproject.org/paste/wS4x9KvD3EB0gv2HAsj6X15M1UNdIGYhyRLivL9gydE=
>>>>> 
>>>>> Does anybody know how to proceed and if this is important?
>>>>> ipa-replica-manage says, backing off, retrying later, so not sure if 
>>>>> replication happens successfully or not and what to do ??
>>>>> 
>>>>> Setup: CentOS 7.3 all up-to-date, 2 CA master, 2 non CA master in diamond 
>>>>> replication.
>>>>> 
>>>>> Remaining replicas were upgraded today as well, and don’t seem to 
>>>>> complain. Only 1 of them complains.
>>>>> 
>>>>> 389-ds-base-libs-1.3.5.10-20.el7_3.x86_64
>>>>> 389-ds-base-1.3.5.10-20.el7_3.x86_64
>>>>> 
>>>>> 
>>>>> [root@lums3 ~]# rpm -qa | grep ipa
>>>>> libipa_hbac-1.14.0-43.el7_3.14.x86_64
>>>>> python-iniparse-0.4-9.el7.noarch
>>>>> ipa-admintools-4.4.0-14.el7.centos.7.noarch
>>>>> python2-ipaserver-4.4.0-14.el7.centos.7.noarch
>>>>> python2-ipalib-4.4.0-14.el7.centos.7.noarch
>>>>> sssd-ipa-1.14.0-43.el7_3.14.x86_64
>>>>> python-ipaddress-1.0.16-2.el7.noarch
>>>>> python2-ipaclient-4.4.0-14.el7.centos.7.noarch
>>>>> ipa-server-common-4.4.0-14.el7.centos.7.noarch
>>>>> ipa-client-common-4.4.0-14.el7.centos.7.noarch
>>>>> ipa-client-4.4.0-14.el7.centos.7.x86_64
>>>>> ipa-common-4.4.0-14.el7.centos.7.noarch
>>>>> python-libipa_hbac-1.14.0-43.el7_3.14.x86_64
>>>>> ipa-server-4.4.0-14.el7.centos.7.x86_64
>>>>> 
>>>>> Thanks a lot for any pointers,
>>>>> Christophe 
>>>>> -- 
>>>>> 
>>>>> Dr Christophe Trefois, Dipl.-Ing.  
>>>>> Technical Specialist / Post-Doc
>>>>> 
>>>>> UNIVERSITÉ DU LUXEMBOURG
>>>>> 
>>>>> LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE
>>>>> Campus Belval | House of Biomedicine  
>>>>> 6, avenue du Swing 
>>>>> L-4367 Belvaux  
>>>>> T: +352 46 66 44 6124 
>>>>> F: +352 46 66 44 6949  
>>>>> http://www.uni.lu/lcsb
>>>>> 
>>>>>         
>>>>> 
>>>>> 
>>>>> ----
>>>>> This message is confidential and may contain privileged information. 
>>>>> It is intended for the named recipient only. 
>>>>> If you receive it in error please notify me and permanently delete the 
>>>>> original message and any copies. 
>>>>> ----
>>>>>   
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> -- 
>>>> 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
>> 
> 
> -- 
> 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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

-- 
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

Reply via email to