[Freeipa-users] more replication fun

[Rob Crittenden]

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