Hi,

I have one scenario where I can show the comeback of the "ghost" rids. but it requires a server where the rids have successfully cleaned and it is killed or crashes. In that case, if the "ghost" rids have not yet been trimmed from the changelog they can be recreated from information in the changelog. they can then also propagate to other servers

Could something similar have happened in your environment ?

Ludwig

On 06/12/2015 07:38 AM, Christoph Kaminski wrote:
I've been too early pleased :/ After ipactl restart of our first master (where we re-initialize from) are the 'ghost' rids again there...

I think there is something like a fs backup for dirsrv (changelog?) but where?

>
> we had the same problem (and some more) and yesterday we have
> successfully cleaned the gohst rid's
>
> our fix:
>
> 1. stop all cleanallruv Tasks, if it works with ipa-replica-manage
> abort-clean-ruv. It hasnt worked here. We have done it manually on
> ALL replicas with:
>  a) replica stop
>  b) delete all nsds5ReplicaClean from /etc/dirsrv/slapd-HSO/dse.ldif
>  c) replica start
>
> 2. prepare on EACH ipa a cleanruv ldif file with ALL ghost rids
> inside (really ALL from all ipa replicas, we has had some rids only
> on some replicas...)
> Example:
>
> dn: cn=replica,cn=dc\3Dexample,cn=mapping tree,cn=config
> changetype: modify
> replace: nsds5task
> nsds5task:CLEANRUV11
>
> dn: cn=replica,cn=dc\3Dexample,cn=mapping tree,cn=config
> changetype: modify
> replace: nsds5task
> nsds5task:CLEANRUV22
>
> dn: cn=replica,cn=dc\3Dexample,cn=mapping tree,cn=config
> changetype: modify
> replace: nsds5task
> nsds5task:CLEANRUV37
> ...
>
> 3. do a "ldapmodify -h 127.0.0.1 -D "cn=Directory Manager" -W -x -f
> $your-cleanruv-file.ldif" on all replicas AT THE SAME TIME :) we
> used terminator  for it (https://launchpad.net/terminator). You can
> open multiple shell windows inside one window and send to all at the
> same time the same commands...
>
> 4. we have done a re-initialize of each IPA from our first master
>
> 5. restart of all replicas
>
> we are not sure about the point 3 and 4. Maybe they are not
> necessary, but we have done it.
>
> If something fails look at defect LDAP entries in whole ldap, we
> have had some entries with 'nsunique-$HASH' after the 'normal' name.
> We have deleted them.
>
> MfG
> Christoph Kaminski
>
>






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

Reply via email to