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/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 >>> 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 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 :-( Help? ~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 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 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/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 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/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 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 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/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 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
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 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
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 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