[Freeipa-users] Cant locate CSN after yum update

Fri May 19 06:51:58 UTC 2017

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.trefois at uni.lu <mailto:christophe.trefois at 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
>>
>> Facebook <https://www.facebook.com/trefex>Twitter 
>> <https://twitter.com/Trefex>Google Plus 
>> <https://plus.google.com/+ChristopheTrefois/>Linkedin 
>> <https://www.linkedin.com/in/trefoischristophe>skype
>>
>>
>> ----
>> 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 <lkrispen at redhat.com 
>>> <mailto:lkrispen at 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 at 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
>>>>
>>>> Facebook <https://www.facebook.com/trefex>Twitter 
>>>> <https://twitter.com/Trefex>Google Plus 
>>>> <https://plus.google.com/+ChristopheTrefois/>Linkedin 
>>>> <https://www.linkedin.com/in/trefoischristophe>skype
>>>>
>>>>
>>>> ----
>>>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20170519/3f485e47/attachment.htm>