Re: [Freeipa-users] More replication fun
Janelle wrote: > On 10/5/15 10:16 AM, Simo Sorce wrote: >> On 05/10/15 11:11, Janelle wrote: >>> So here is a fun question -- how is this possible? >>> >>> from ipa-replica-manage list-ruv >>> >>> ipa002.example.com 389 6 >>> ipa003.example.com 389 30 <- Huh??? >>> ipa003.example.com 389 33 <- >>> ipa004.example.com 389 24 >> >> ipa003 was reinstalled but the RUV was not properly cleaned >> >> Simo. >> >> > So there is no conflict even with a duplicate like that? I mean the > server only physically exists once, so I guess it should not cause a > problem. I mean replication seems to be working, it just seems odd that > I saw that. You would think that the normal ipa-replica-manage "del" > options would do all the proper cleaning, but apparently not. I'd recommend cleaning the unused RUV as it causes the directory server to do work on it, even if it results in nothing. The server should clean up RUVs upon deletion but it is done as a task which can fail, but by that point the agreement is already gone. rob -- 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
Re: [Freeipa-users] More replication fun
On 10/5/15 10:16 AM, Simo Sorce wrote: On 05/10/15 11:11, Janelle wrote: So here is a fun question -- how is this possible? from ipa-replica-manage list-ruv ipa002.example.com 389 6 ipa003.example.com 389 30 <- Huh??? ipa003.example.com 389 33 <- ipa004.example.com 389 24 ipa003 was reinstalled but the RUV was not properly cleaned Simo. So there is no conflict even with a duplicate like that? I mean the server only physically exists once, so I guess it should not cause a problem. I mean replication seems to be working, it just seems odd that I saw that. You would think that the normal ipa-replica-manage "del" options would do all the proper cleaning, but apparently not. Thanks for the clarification. ~J -- 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
Re: [Freeipa-users] More replication fun
On 05/10/15 11:11, Janelle wrote: So here is a fun question -- how is this possible? from ipa-replica-manage list-ruv ipa002.example.com 389 6 ipa003.example.com 389 30 <- Huh??? ipa003.example.com 389 33 <- ipa004.example.com 389 24 ipa003 was reinstalled but the RUV was not properly cleaned Simo. -- Simo Sorce * Red Hat, Inc * New York -- 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
Re: [Freeipa-users] more replication fun
Janelle wrote:
On 5/7/15 12:59 AM, thierry bordaz wrote:
On 05/07/2015 05:39 AM, Janelle wrote:
On 5/6/15 8:12 PM, Vaclav Adamec wrote:
Hi,
Mike Reynolds recommend cleanallruv script (IPA RUV unable to decode
thread), if you are sure that's not any live replica server behind
this id than just try cleanallruv.pl -w X -b dc= -r 9
Vasek
On Thu, May 7, 2015 at 2:25 AM, Janelle janellenicol...@gmail.com
wrote:
Hi again..
Seems to be an ongoing theme (replication). How does one remove these?
unable to decode: {replica 9} 553ef80e00010009
55402c390009
I am hoping this is a stupid question with a really simple answer
that I am simply missing?
~J
--
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
Thank you Vasek,
I am curious however. I have been running OpenLDAP configs with 20 or
more servers in replication for over 5 years. In all that time, I
think I have had replication issues 5 times. In the 6 months of
working with FreeIPA, replication issues are constant. From reading
the threads, I am not the only one in this predicament. Is there any
history on why replication is so problematic in FreeIPA?
regards
~J
Hi Janelle,
This is a large question and I have no precise answer. My
understanding of OpenLDAP replication vs RHDS replication is that
it is not based on the same approach syncrepl vs
replica_agreement. Both are working. Replication is complex and
when I compare RHDS with others DS implementation using the same
approach (replica_agreement) I can say that RHDS is doing a good
job in terms of performance, stability and robustness.
Replication is sensitive to administrative tasks, backup-restore,
reinit, upgrade, schema update. This is possibly your case we have
seen 'unable to decode' during upgrade/cleanruv and still
investigating that bug.
thanks
thierry
All of this makes good sense - in fact, even the OpenLDAP vs 389-ds
issues and replication. Yes, in the environment I had, there were a
couple of masters, and the reset were read-only, which meant keeping in
sync - easy.
Now, I was looking through the archives and can't seem to find the
recommended way to delete one of these:
unable to decode {replica 22} 553eec6400040016 553eec6400040016
I think someone mentioned a script, but I can't find it. I have
several replicas in this state and would like to try and clean them up.
The interesting thing is - the replicas in this state
seehttps://www.redhat.com/archives/freeipa-users/2015-May/msg00062.htmlm to
have a
higher CPU load as based on uptime. Interesting.
Thanks
~J
See https://www.redhat.com/archives/freeipa-users/2015-May/msg00062.html
It would be nice to know if this style of RUV could be acted on by
ipa-replica-manage. I added this bit as a catch-all so no RUV would be
invisibly skipped if it didn't match the regex I wrote. If this kind of
RUV could indeed still be cleaned it would be nice to know and we could
make that possible.
rob
--
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
Re: [Freeipa-users] more replication fun
On 5/7/15 12:59 AM, thierry bordaz wrote:
On 05/07/2015 05:39 AM, Janelle wrote:
On 5/6/15 8:12 PM, Vaclav Adamec wrote:
Hi,
Mike Reynolds recommend cleanallruv script (IPA RUV unable to decode
thread), if you are sure that's not any live replica server behind
this id than just try cleanallruv.pl -w X -b dc= -r 9
Vasek
On Thu, May 7, 2015 at 2:25 AM, Janelle janellenicol...@gmail.com
wrote:
Hi again..
Seems to be an ongoing theme (replication). How does one remove these?
unable to decode: {replica 9} 553ef80e00010009
55402c390009
I am hoping this is a stupid question with a really simple answer
that I am simply missing?
~J
--
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
Thank you Vasek,
I am curious however. I have been running OpenLDAP configs with 20 or
more servers in replication for over 5 years. In all that time, I
think I have had replication issues 5 times. In the 6 months of
working with FreeIPA, replication issues are constant. From reading
the threads, I am not the only one in this predicament. Is there any
history on why replication is so problematic in FreeIPA?
regards
~J
Hi Janelle,
This is a large question and I have no precise answer. My
understanding of OpenLDAP replication vs RHDS replication is that
it is not based on the same approach syncrepl vs
replica_agreement. Both are working. Replication is complex and
when I compare RHDS with others DS implementation using the same
approach (replica_agreement) I can say that RHDS is doing a good
job in terms of performance, stability and robustness.
Replication is sensitive to administrative tasks, backup-restore,
reinit, upgrade, schema update. This is possibly your case we have
seen 'unable to decode' during upgrade/cleanruv and still
investigating that bug.
thanks
thierry
All of this makes good sense - in fact, even the OpenLDAP vs 389-ds
issues and replication. Yes, in the environment I had, there were a
couple of masters, and the reset were read-only, which meant keeping in
sync - easy.
Now, I was looking through the archives and can't seem to find the
recommended way to delete one of these:
unable to decode {replica 22} 553eec6400040016 553eec6400040016
I think someone mentioned a script, but I can't find it. I have
several replicas in this state and would like to try and clean them up.
The interesting thing is - the replicas in this state seem to have a
higher CPU load as based on uptime. Interesting.
Thanks
~J
--
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
Re: [Freeipa-users] more replication fun
On 05/08/2015 05:30 PM, Rob Crittenden wrote:
Janelle wrote:
On 5/7/15 12:59 AM, thierry bordaz wrote:
On 05/07/2015 05:39 AM, Janelle wrote:
On 5/6/15 8:12 PM, Vaclav Adamec wrote:
Hi,
Mike Reynolds recommend cleanallruv script (IPA RUV unable to
decode
thread), if you are sure that's not any live replica server behind
this id than just try cleanallruv.pl -w X -b dc= -r 9
Vasek
On Thu, May 7, 2015 at 2:25 AM, Janelle janellenicol...@gmail.com
wrote:
Hi again..
Seems to be an ongoing theme (replication). How does one remove
these?
unable to decode: {replica 9} 553ef80e00010009
55402c390009
I am hoping this is a stupid question with a really simple answer
that I am simply missing?
~J
--
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
Thank you Vasek,
I am curious however. I have been running OpenLDAP configs with 20 or
more servers in replication for over 5 years. In all that time, I
think I have had replication issues 5 times. In the 6 months of
working with FreeIPA, replication issues are constant. From reading
the threads, I am not the only one in this predicament. Is there any
history on why replication is so problematic in FreeIPA?
regards
~J
Hi Janelle,
This is a large question and I have no precise answer. My
understanding of OpenLDAP replication vs RHDS replication is that
it is not based on the same approach syncrepl vs
replica_agreement. Both are working. Replication is complex and
when I compare RHDS with others DS implementation using the same
approach (replica_agreement) I can say that RHDS is doing a good
job in terms of performance, stability and robustness.
Replication is sensitive to administrative tasks, backup-restore,
reinit, upgrade, schema update. This is possibly your case we have
seen 'unable to decode' during upgrade/cleanruv and still
investigating that bug.
thanks
thierry
All of this makes good sense - in fact, even the OpenLDAP vs 389-ds
issues and replication. Yes, in the environment I had, there were a
couple of masters, and the reset were read-only, which meant keeping in
sync - easy.
Now, I was looking through the archives and can't seem to find the
recommended way to delete one of these:
unable to decode {replica 22} 553eec6400040016 553eec6400040016
I think someone mentioned a script, but I can't find it. I have
several replicas in this state and would like to try and clean them up.
The interesting thing is - the replicas in this state
seehttps://www.redhat.com/archives/freeipa-users/2015-May/msg00062.htmlm
to have a
higher CPU load as based on uptime. Interesting.
Thanks
~J
See https://www.redhat.com/archives/freeipa-users/2015-May/msg00062.html
hopefully it does, if not maybe Mark can help to get rid of it
It would be nice to know if this style of RUV could be acted on by
ipa-replica-manage. I added this bit as a catch-all so no RUV would be
invisibly skipped if it didn't match the regex I wrote. If this kind
of RUV could indeed still be cleaned it would be nice to know and we
could make that possible.
I think this kind of RUV should never exist, strange enough we have a
hard time to reproduce it in the lab, but out in the real world they
seem to proliferate.
Any help to reproduce is greatly appreciated.
Ludwig
rob
--
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
Re: [Freeipa-users] more replication fun
Janelle wrote:
On 5/8/15 8:43 AM, Ludwig Krispenz wrote:
On 05/08/2015 05:30 PM, Rob Crittenden wrote:
Janelle wrote:
On 5/7/15 12:59 AM, thierry bordaz wrote:
On 05/07/2015 05:39 AM, Janelle wrote:
On 5/6/15 8:12 PM, Vaclav Adamec wrote:
Hi,
Mike Reynolds recommend cleanallruv script (IPA RUV unable to
decode
thread), if you are sure that's not any live replica server behind
this id than just try cleanallruv.pl -w X -b dc= -r 9
Vasek
On Thu, May 7, 2015 at 2:25 AM, Janelle janellenicol...@gmail.com
wrote:
Hi again..
Seems to be an ongoing theme (replication). How does one remove
these?
unable to decode: {replica 9} 553ef80e00010009
55402c390009
I am hoping this is a stupid question with a really simple answer
that I am simply missing?
~J
--
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
Thank you Vasek,
I am curious however. I have been running OpenLDAP configs with 20 or
more servers in replication for over 5 years. In all that time, I
think I have had replication issues 5 times. In the 6 months of
working with FreeIPA, replication issues are constant. From reading
the threads, I am not the only one in this predicament. Is there any
history on why replication is so problematic in FreeIPA?
regards
~J
Hi Janelle,
This is a large question and I have no precise answer. My
understanding of OpenLDAP replication vs RHDS replication is that
it is not based on the same approach syncrepl vs
replica_agreement. Both are working. Replication is complex and
when I compare RHDS with others DS implementation using the same
approach (replica_agreement) I can say that RHDS is doing a good
job in terms of performance, stability and robustness.
Replication is sensitive to administrative tasks, backup-restore,
reinit, upgrade, schema update. This is possibly your case we have
seen 'unable to decode' during upgrade/cleanruv and still
investigating that bug.
thanks
thierry
All of this makes good sense - in fact, even the OpenLDAP vs 389-ds
issues and replication. Yes, in the environment I had, there were a
couple of masters, and the reset were read-only, which meant keeping in
sync - easy.
Now, I was looking through the archives and can't seem to find the
recommended way to delete one of these:
unable to decode {replica 22} 553eec6400040016
553eec6400040016
I think someone mentioned a script, but I can't find it. I have
several replicas in this state and would like to try and clean them up.
The interesting thing is - the replicas in this state
seehttps://www.redhat.com/archives/freeipa-users/2015-May/msg00062.htmlm
to have a
higher CPU load as based on uptime. Interesting.
Thanks
~J
See https://www.redhat.com/archives/freeipa-users/2015-May/msg00062.html
hopefully it does, if not maybe Mark can help to get rid of it
It would be nice to know if this style of RUV could be acted on by
ipa-replica-manage. I added this bit as a catch-all so no RUV would
be invisibly skipped if it didn't match the regex I wrote. If this
kind of RUV could indeed still be cleaned it would be nice to know
and we could make that possible.
I think this kind of RUV should never exist, strange enough we have a
hard time to reproduce it in the lab, but out in the real world they
seem to proliferate.
Any help to reproduce is greatly appreciated.
Ludwig
rob
One last question regarding this (I hope).
Now I am trying to re-add a server that does not show up in replica
list, has no outstanding clean-ruv tasks, BUT - I still get:
The host ipa03.example.com already exists on the master server.
You should remove it before proceeding:
% ipa host-del ipa03.example.com
BUT - trying that results in:
ipa: ERROR: invalid 'hostname': An IPA master host cannot be deleted or
disabled
I'm guessing the replica was removed without being formally deleted. You
can remove it with: ipa-replica-manage del --force --cleanup
ipa03.example.com
rob
--
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
Re: [Freeipa-users] more replication fun
On 5/8/15 8:43 AM, Ludwig Krispenz wrote:
On 05/08/2015 05:30 PM, Rob Crittenden wrote:
Janelle wrote:
On 5/7/15 12:59 AM, thierry bordaz wrote:
On 05/07/2015 05:39 AM, Janelle wrote:
On 5/6/15 8:12 PM, Vaclav Adamec wrote:
Hi,
Mike Reynolds recommend cleanallruv script (IPA RUV unable to
decode
thread), if you are sure that's not any live replica server behind
this id than just try cleanallruv.pl -w X -b dc= -r 9
Vasek
On Thu, May 7, 2015 at 2:25 AM, Janelle janellenicol...@gmail.com
wrote:
Hi again..
Seems to be an ongoing theme (replication). How does one remove
these?
unable to decode: {replica 9} 553ef80e00010009
55402c390009
I am hoping this is a stupid question with a really simple answer
that I am simply missing?
~J
--
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
Thank you Vasek,
I am curious however. I have been running OpenLDAP configs with 20 or
more servers in replication for over 5 years. In all that time, I
think I have had replication issues 5 times. In the 6 months of
working with FreeIPA, replication issues are constant. From reading
the threads, I am not the only one in this predicament. Is there any
history on why replication is so problematic in FreeIPA?
regards
~J
Hi Janelle,
This is a large question and I have no precise answer. My
understanding of OpenLDAP replication vs RHDS replication is that
it is not based on the same approach syncrepl vs
replica_agreement. Both are working. Replication is complex and
when I compare RHDS with others DS implementation using the same
approach (replica_agreement) I can say that RHDS is doing a good
job in terms of performance, stability and robustness.
Replication is sensitive to administrative tasks, backup-restore,
reinit, upgrade, schema update. This is possibly your case we have
seen 'unable to decode' during upgrade/cleanruv and still
investigating that bug.
thanks
thierry
All of this makes good sense - in fact, even the OpenLDAP vs 389-ds
issues and replication. Yes, in the environment I had, there were a
couple of masters, and the reset were read-only, which meant keeping in
sync - easy.
Now, I was looking through the archives and can't seem to find the
recommended way to delete one of these:
unable to decode {replica 22} 553eec6400040016
553eec6400040016
I think someone mentioned a script, but I can't find it. I have
several replicas in this state and would like to try and clean them up.
The interesting thing is - the replicas in this state
seehttps://www.redhat.com/archives/freeipa-users/2015-May/msg00062.htmlm
to have a
higher CPU load as based on uptime. Interesting.
Thanks
~J
See https://www.redhat.com/archives/freeipa-users/2015-May/msg00062.html
hopefully it does, if not maybe Mark can help to get rid of it
It would be nice to know if this style of RUV could be acted on by
ipa-replica-manage. I added this bit as a catch-all so no RUV would
be invisibly skipped if it didn't match the regex I wrote. If this
kind of RUV could indeed still be cleaned it would be nice to know
and we could make that possible.
I think this kind of RUV should never exist, strange enough we have a
hard time to reproduce it in the lab, but out in the real world they
seem to proliferate.
Any help to reproduce is greatly appreciated.
Ludwig
rob
That little ldapmodify - did indeed do the trick In fact, it seemed to
replicate the clean correctly and it disappeared from all my replicas
in a few seconds.
Let me see if I can reproduce in my lab.
Thank you
~J
--
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
Re: [Freeipa-users] more replication fun
On 05/07/2015 05:39 AM, Janelle wrote:
On 5/6/15 8:12 PM, Vaclav Adamec wrote:
Hi,
Mike Reynolds recommend cleanallruv script (IPA RUV unable to decode
thread), if you are sure that's not any live replica server behind
this id than just try cleanallruv.pl -w X -b dc= -r 9
Vasek
On Thu, May 7, 2015 at 2:25 AM, Janelle janellenicol...@gmail.com
wrote:
Hi again..
Seems to be an ongoing theme (replication). How does one remove these?
unable to decode: {replica 9} 553ef80e00010009 55402c390009
I am hoping this is a stupid question with a really simple answer
that I am simply missing?
~J
--
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
Thank you Vasek,
I am curious however. I have been running OpenLDAP configs with 20 or
more servers in replication for over 5 years. In all that time, I
think I have had replication issues 5 times. In the 6 months of
working with FreeIPA, replication issues are constant. From reading
the threads, I am not the only one in this predicament. Is there any
history on why replication is so problematic in FreeIPA?
regards
~J
Hi Janelle,
This is a large question and I have no precise answer. My
understanding of OpenLDAP replication vs RHDS replication is that it
is not based on the same approach syncrepl vs replica_agreement.
Both are working. Replication is complex and when I compare RHDS
with others DS implementation using the same approach
(replica_agreement) I can say that RHDS is doing a good job in terms
of performance, stability and robustness.
Replication is sensitive to administrative tasks, backup-restore,
reinit, upgrade, schema update. This is possibly your case we have
seen 'unable to decode' during upgrade/cleanruv and still
investigating that bug.
thanks
thierry
--
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
Re: [Freeipa-users] more replication fun
Hi,
Mike Reynolds recommend cleanallruv script (IPA RUV unable to decode
thread), if you are sure that's not any live replica server behind
this id than just try cleanallruv.pl -w X -b dc= -r 9
Vasek
On Thu, May 7, 2015 at 2:25 AM, Janelle janellenicol...@gmail.com wrote:
Hi again..
Seems to be an ongoing theme (replication). How does one remove these?
unable to decode: {replica 9} 553ef80e00010009 55402c390009
I am hoping this is a stupid question with a really simple answer that I am
simply missing?
~J
--
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
--
-- May the fox be with you ...
/\
(~(
) ) /\_/\
(_=---_(@ @)
( \ /
/|/\|\ V
--
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
Re: [Freeipa-users] more replication fun
On 5/6/15 8:12 PM, Vaclav Adamec wrote:
Hi,
Mike Reynolds recommend cleanallruv script (IPA RUV unable to decode
thread), if you are sure that's not any live replica server behind
this id than just try cleanallruv.pl -w X -b dc= -r 9
Vasek
On Thu, May 7, 2015 at 2:25 AM, Janelle janellenicol...@gmail.com wrote:
Hi again..
Seems to be an ongoing theme (replication). How does one remove these?
unable to decode: {replica 9} 553ef80e00010009 55402c390009
I am hoping this is a stupid question with a really simple answer that I am
simply missing?
~J
--
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
Thank you Vasek,
I am curious however. I have been running OpenLDAP configs with 20 or
more servers in replication for over 5 years. In all that time, I think
I have had replication issues 5 times. In the 6 months of working with
FreeIPA, replication issues are constant. From reading the threads, I am
not the only one in this predicament. Is there any history on why
replication is so problematic in FreeIPA?
regards
~J
--
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
