11:44 a.m.
Thank you, Rob, for pointing me in the right direction.
"ipa-replica-manage list-ruv" lists the two unused RUVs which matched the
number of Ghost reported:
# ipa-replica-manage list-ruv
Directory Manager password:
unable to decode: {replica 29} 627e26a50005001d0000 627e26a50005001d0000
unable to decode: {replica 42} 627e21590005002a0000 627e21590005002a0000
Replica Update Vectors:
...
Certificate Server Replica Update Vectors:
...
[root@ipa0 ~]#
"ipa-replica-manage clean-dangling-ruv" cleaned one of the two.
Followed https://access.redhat.com/solutions/1529903 manually cleaned the
second one (by ldapmodify).
Thanks again, Rob, for your help.
Kathy.
On Thu, Jun 9, 2022 at 6:02 AM Rob Crittenden <rcritten(a)redhat.com> wrote:
Kathy Zhu via FreeIPA-users wrote:
> Hello team,
>
> We use ipa_check_consistency
> <https://github.com/peterpakos/checkipaconsistency/blob/master/README.md
> tool
> to check IPA master consistency every night via cron. One of the masters
> failed at Ghost last night. Here is the check for Ghost:
>
> |ldapsearch -o ldif-wrap=no -ZZ -LLLx -h ipa1.example.com
> <http://ipa1.example.com> -D ||"cn=Directory Manager"| |-W -s sub
>
-b ||"dc=example,dc=com"|
|"(&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff))"|
|nscpentrywsi|
>
> What is the significance of this inconsistency? Is there a way to fix
> this other than reinitialize?
It is a check for unused RUV. Did you recently remove a server?
ipa-replica-manage(1) has several commands to help identify and clean
these up.
For the gory details see
https://directory.fedoraproject.org/docs/389ds/howto/howto-cleanruv.html
rob