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?

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?

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.

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