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..
> The only thing I can think of was that on some(all? I'm not sure) for a
> while, during re-creating a master(s) 'named' was not listening at
> '127.0.0.1' - which was my fault as I constrained named's
'ifaces' via
> 'acls' (unintentionally)
> I think on the first master (which shows above issue) 'named' might have
> stopped/crashed at the time of new master(s) re-introduction.