lejeczek via FreeIPA-users wrote:
On 05/01/2022 12:47, Rob Crittenden wrote:
> lejeczek via FreeIPA-users wrote:
>>
>> On 04/01/2022 22:09, Rob Crittenden wrote:
>>> lejeczek via FreeIPA-users wrote:
>>>> Hi guys.
>>>>
>>>> -> $ ipa-healthcheck
>>>> ..
>>>> {
>>>> "source": "ipahealthcheck.ds.replication",
>>>> "check": "ReplicationCheck",
>>>> "result": "WARNING",
>>>> "uuid":
"7ff8f869-36c8-411c-9c44-7cb323deaf95",
>>>> "when": "20220104193941Z",
>>>> "duration": "0.574693",
>>>> "kw": {
>>>> "key": "DSREPLLE0002",
>>>> "items": [
>>>> "Replication",
>>>> "Conflict Entries"
>>>> ],
>>>> "msg": "There were 2 conflict entries found under
the
>>>> replication
>>>> suffix \"o=ipaca\"."
>>>> }
>>>>
>>>> I have found some old tips here from the list but I'm not sure what
to
>>>> do with it.
>>>>
>>>> -> $ ldapsearch -H ldaps://$(hostname) -W -D 'cn=Directory
Manager' -b
>>>> 'o=ipaca'
'(&(objectClass=ldapSubEntry)(nsds5ReplConflict=*))'
>>>> nsds5ReplConflict
>>>> Enter LDAP Password:
>>>> # extended LDIF
>>>> #
>>>> # LDAPv3
>>>> # base <o=ipaca> with scope subtree
>>>> # filter: (&(objectClass=ldapSubEntry)(nsds5ReplConflict=*))
>>>> # requesting: nsds5ReplConflict
>>>> #
>>>>
>>>> # 7c395f01-6d6211ec-a624dc4c-7402d017 + admin-dzien.mine.private,
>>>> people, ipaca
>>>> dn:
>>>>
nsuniqueid=7c395f01-6d6211ec-a624dc4c-7402d017+uid=admin-dzien.mine.privat
>>>>
>>>>
>>>> e,ou=people,o=ipaca
>>>> nsds5ReplConflict: namingConflict (ADD)
>>>> uid=admin-dzien.mine.private,ou=people
>>>> ,o=ipaca
>>>>
>>>> # e6ed9901-6d6811ec-affe8b51-4855b2e0 + admin-swir.mine.private,
>>>> people,
>>>> ipaca
>>>> dn:
>>>>
nsuniqueid=e6ed9901-6d6811ec-affe8b51-4855b2e0+uid=admin-swir.mine.private
>>>>
>>>>
>>>> ,ou=people,o=ipaca
>>>> nsds5ReplConflict: namingConflict (ADD)
>>>> uid=admin-swir.mine.private,ou=people,
>>>> o=ipaca
>>>>
>>>> Remove either entries?
>>> I'd suggest dropping the attribute list and look at the entire conflict
>>> entry just to see if anything else was included.
>>>
>>> Chances are that yes, these can both be dropped. I assume that the
>>> CA is
>>> otherwise working fine?
>>>
>>> I'm curious how this came about. Were you were standing up a bunch of
>>> new servers simultaneously?
>>>
>>> rob
>>>
>> From looking at 'raw' LDAP tree I would not know - is there a way to
>> confirm/validate CA health?
> What I'm asking is what does the rest of the conflict entry contain?
>
> healthcheck does some basic validation by retrieving a certificate and
> testing that some certificates aren't revoked.
>
> Given that this failed on an ADD it means that the entry was already
> properly created on a different server which is why it should be safe to
> remove the conflict entries. If you want to hedge your bet, assuming the
> conflict contains anything useful, you can save off a copy of it before
> removing it.
>
> rob
-> $ ldapsearch -LLL -H ldaps://$(hostname) -W -D 'cn=Directory Manager'
-b 'o=ipaca' '(&(objectClass=ldapSubEntry)(nsds5ReplConflict=*))'
Enter LDAP Password:
dn:
nsuniqueid=7c395f01-6d6211ec-a624dc4c-7402d017+uid=admin-dzien.mine.privat
e,ou=people,o=ipaca
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: cmsuser
objectClass: extensibleobject
objectClass: ldapsubentry
uid: admin-dzien.mine.private
cn: admin-dzien.mine.private
sn: admin-dzien.mine.private
usertype: adminType
userstate: 1
userPassword:: e..
dn:
nsuniqueid=e6ed9901-6d6811ec-affe8b51-4855b2e0+uid=admin-swir.mine.private
,ou=people,o=ipaca
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: cmsuser
objectClass: extensibleobject
objectClass: ldapsubentry
uid: admin-swir.mine.private
cn: admin-swir.mine.private
sn: admin-swir.mine.private
usertype: adminType
userstate: 1
userPassword:: e..
IMHO you can safely delete these. Saving the ldapsearch output is a
reasonable way to back it up just in case.
rob