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:
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"


On Thu, May 7, 2015 at 2:25 AM, Janelle <janellenicol...@gmail.com>
Hi again..

Seems to be an ongoing theme (replication). How does one remove these?

unable to decode: {replica 9} 553ef80e000100090000

I am hoping this is a stupid question with a really simple answer
that I am simply missing?


Manage your subscription for the Freeipa-users mailing list:
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?


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.


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.


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.



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



Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to