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