Discussion:
[Freeipa-users] Cant locate CSN after yum update
Christophe TREFOIS
2017-05-18 13:09:55 UTC
Permalink
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


[***@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] <http://skype:Trefex?call>

----
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.
----
Ludwig Krispenz
2017-05-18 14:11:58 UTC
Permalink
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
Post by Christophe TREFOIS
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
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
Christophe TREFOIS
2017-05-18 15:04:47 UTC
Permalink
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] <http://skype:Trefex?call>

----
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 <***@redhat.com<mailto:***@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


[***@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
Christophe TREFOIS
2017-05-18 15:35:13 UTC
Permalink
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.

Thanks a lot for your help!

Kind regards,
Christophe aka Trefex

On 18 May 2017, at 17:04, Christophe TREFOIS <***@uni.lu<mailto:***@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] <http://skype:Trefex?call>


----
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 <***@redhat.com<mailto:***@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


[***@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
Ludwig Krispenz
2017-05-19 06:51:58 UTC
Permalink
Post by Christophe TREFOIS
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.
Post by Christophe TREFOIS
Thanks a lot for your help!
Kind regards,
Christophe aka Trefex
Post by Christophe TREFOIS
On 18 May 2017, at 17:04, Christophe TREFOIS
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.
----
Post by Ludwig Krispenz
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
Post by Christophe TREFOIS
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
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
--
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
--
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
Christophe TREFOIS
2017-05-19 07:00:24 UTC
Permalink
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
Post by Ludwig Krispenz
Post by Christophe TREFOIS
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.
Post by Christophe TREFOIS
Thanks a lot for your help!
Kind regards,
Christophe aka Trefex
Post by Christophe TREFOIS
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.
----
Post by Christophe TREFOIS
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
Post by Christophe TREFOIS
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
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
--
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
--
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
Loading...