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 XXXXX -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} 553ef80e000100090000 >>>>>>>> 55402c39000000090000 >>>>>>>> >>>>>>>> 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} 553eec64000400160000 >>>> 553eec64000400160000 >>>> >>>> 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