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.
many thanks, L