[Freeipa-users] Re: Stale/ghost RUVs that cannot be removed
Thanks German, I can confirm this worked and the ghost replicas were removed.
Much appreciated for the assistance.
Thanks,
Goran
> On May 29, 2017, at 11:40 AM, German Parente wrote:
>
> Hi,
>
> you could try this operation manually but please, be sure that all the
> replicas are up and running:
>
> ldapmodify -a -D "cn=directory manager" -W << EOF
> dn: cn=clean 3, cn=cleanallruv, cn=tasks, cn=config
> objectclass: extensibleObject
> replica-base-dn:
> replica-id: 3
> replica-force-cleaning: yes
> cn: clean 3
> EOF
>
> should be something like dc=ecobee,dc=com ?
>
> that's the way to add a cleanallruv task manually. You should repeat this
> with replica id "4"
>
> regards,
>
> German.
>
>
>
> On Mon, May 29, 2017 at 5:07 PM, Goran Marik via FreeIPA-users
> wrote:
> Hi,
>
> We are troubleshooting an sync issue that started after a freeipa upgrade
> (yum update) to the latest Centos 7.3 mid-April. One of the problems that
> happen is that we see stale RUVs that cannot be deleted. Here is the output
> of list-ruv and clean-run:
>
> “””
> ipa-replica-manage list-ruv
> Directory Manager password:
> unable to decode: {replica 3} 57020ed900060003 57020ed900060003
> unable to decode: {replica 4} 5702fe5b00050004 5702fe5b00050004
> Replica Update Vectors:
> inf01.prod.ecobee.com:389: 6
> inf02.dev.ecobee.com:389: 8
> inf01.dev.ecobee.com:389: 7
> inf02.prod.ecobee.com:389: 5
> Certificate Server Replica Update Vectors:
> inf02.prod.ecobee.com:389: 1095
> inf01.dev.ecobee.com:389: 1295
> inf02.dev.ecobee.com:389: 1190
> inf01.prod.ecobee.com:389: 1195
> “””
>
> “””
> ipa-replica-manage clean-ruv 3
> Directory Manager password:
>
> unable to decode: {replica 3} 57020ed900060003 57020ed900060003
> unable to decode: {replica 4} 5702fe5b00050004 5702fe5b00050004
> Replica ID 3 not found
> “””
>
> The ipa_consistecy_script reports this issue as two ghost replicas ("Ghost
> Replicas 2222FAIL”). The
> clean-dangling-ruv reports that that are no dangling RUVs.
>
> Our version is VERSION: 4.4.0, API_VERSION: 2.213, on Centos 7.3.1611
>
> In the list archives, I found one case from 2015 that sound similar and was
> possible fixed, but not confirmed, with a script cleanallruv.pl, but I
> haven’t been able to find more info on that. Any further help would be
> appreciated.
>
>
> Thanks,
> Goran
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: Stale/ghost RUVs that cannot be removed
Hi,
you could try this operation manually but please, be sure that all the
replicas are up and running:
ldapmodify -a -D "cn=directory manager" -W << EOF
dn: cn=clean 3, cn=cleanallruv, cn=tasks, cn=config
objectclass: extensibleObject
replica-base-dn:
replica-id: 3
replica-force-cleaning: yes
cn: clean 3
EOF
should be something like dc=ecobee,dc=com ?
that's the way to add a cleanallruv task manually. You should repeat this
with replica id "4"
regards,
German.
On Mon, May 29, 2017 at 5:07 PM, Goran Marik via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:
> Hi,
>
> We are troubleshooting an sync issue that started after a freeipa upgrade
> (yum update) to the latest Centos 7.3 mid-April. One of the problems that
> happen is that we see stale RUVs that cannot be deleted. Here is the output
> of list-ruv and clean-run:
>
> “””
> ipa-replica-manage list-ruv
> Directory Manager password:
> unable to decode: {replica 3} 57020ed900060003 57020ed900060003
> unable to decode: {replica 4} 5702fe5b00050004 5702fe5b00050004
> Replica Update Vectors:
> inf01.prod.ecobee.com:389: 6
> inf02.dev.ecobee.com:389: 8
> inf01.dev.ecobee.com:389: 7
> inf02.prod.ecobee.com:389: 5
> Certificate Server Replica Update Vectors:
> inf02.prod.ecobee.com:389: 1095
> inf01.dev.ecobee.com:389: 1295
> inf02.dev.ecobee.com:389: 1190
> inf01.prod.ecobee.com:389: 1195
> “””
>
> “””
> ipa-replica-manage clean-ruv 3
> Directory Manager password:
>
> unable to decode: {replica 3} 57020ed900060003 57020ed900060003
> unable to decode: {replica 4} 5702fe5b00050004 5702fe5b00050004
> Replica ID 3 not found
> “””
>
> The ipa_consistecy_script reports this issue as two ghost replicas ("Ghost
> Replicas 2222FAIL”). The
> clean-dangling-ruv reports that that are no dangling RUVs.
>
> Our version is VERSION: 4.4.0, API_VERSION: 2.213, on Centos 7.3.1611
>
> In the list archives, I found one case from 2015 that sound similar and
> was possible fixed, but not confirmed, with a script cleanallruv.pl, but
> I haven’t been able to find more info on that. Any further help would be
> appreciated.
>
>
> Thanks,
> Goran
>
> --
> Goran Marik
> Senior Systems Developer
>
> ecobee
> 250 University Ave, Suite 400
> Toronto, ON M5H 3E5
>
>
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
