I have an IdM/freeipa installation with around 30 replicas. I have an entry for a computer that exist across all of those replicas. However, one of the replicas has incorrect data in the DN, with the correct data found in a conflict entry. (It appears that that entry was created on that replica, somehow didn't get replicated anywhere else, and then the entry was created again on a different replica.)
I would like to resolve this naming conflict. The documentation (RHDS 10 Admin Guide, §15.26.1) states that the correct way to "promote" a conflict entry to the active entry is to first delete the active entry and then rename the conflict entry. (I'm running an old version of IdM that uses a 389-ds that doesn't include the dsconf utility.)
But it seems to me that if I send a delete operation to the replica with the bad data, it's just going to replicate that delete operation to all the other replicas, deleting the correct data from all the other replicas, which seems like an awfully dramatic action to take. To reiterate, the correct data exists on all of the other replicas in an entry with the same DN as the entry with the bad data on the "bad" replica.
I have tried to recreate this situation with a new DN that doesn't reference active systems, but I have been unsuccessful.
Can someone confirm that deleting the bad entry from the bad replica will cause the good entries on all the good replicas to also be deleted? If so, is there a better way to resolve this conflict? (At the moment, I'm inclined to just reinitialize the data on this one replica.)
Hi William,
If you delete an entry, the delete operation will indeed be replayed but you must be aware that for replicated operation, that is the target entry nsuniqueid that matters rather than the dn, You should double check that the good entry have a different nsuniqueid than the bad one (it should be the same than the conflict entry), if that is the case deleting the bad entry should not remove the good ones: Either it will delete a conflict entry associated with the bad entry (if it exists) or it will fail to replay that change.
Regards, Pierre
On Thu, Jan 11, 2024 at 7:39 PM William Faulk d4hgcdgdmj@liamekaens.com wrote:
I have an IdM/freeipa installation with around 30 replicas. I have an entry for a computer that exist across all of those replicas. However, one of the replicas has incorrect data in the DN, with the correct data found in a conflict entry. (It appears that that entry was created on that replica, somehow didn't get replicated anywhere else, and then the entry was created again on a different replica.)
I would like to resolve this naming conflict. The documentation (RHDS 10 Admin Guide, §15.26.1) states that the correct way to "promote" a conflict entry to the active entry is to first delete the active entry and then rename the conflict entry. (I'm running an old version of IdM that uses a 389-ds that doesn't include the dsconf utility.)
But it seems to me that if I send a delete operation to the replica with the bad data, it's just going to replicate that delete operation to all the other replicas, deleting the correct data from all the other replicas, which seems like an awfully dramatic action to take. To reiterate, the correct data exists on all of the other replicas in an entry with the same DN as the entry with the bad data on the "bad" replica.
I have tried to recreate this situation with a new DN that doesn't reference active systems, but I have been unsuccessful.
Can someone confirm that deleting the bad entry from the bad replica will cause the good entries on all the good replicas to also be deleted? If so, is there a better way to resolve this conflict? (At the moment, I'm inclined to just reinitialize the data on this one replica.) -- _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Oh, that's surprising to me.
The LDAP spec seems to indicate that the only possible argument for a delete operation is a DN, and, while I still can't reproduce the problem with unimportant entries, access logs on replicas where deletes are being replicated to seem to imply that the remote server is just requesting a normal delete operation specifying the DN, and the access logs don't seem to show any sort of search to determine the DN from the nsuniqueid (or anything else).
So, and I'm sorry to say this, but: Are you sure? Keep in mind that I'm running an old version of 389-ds: v1.3.11, I think. Maybe the replication protocol is handled in such a way that access logs are showing an action that is ultimately what's happening, even if it's not exactly how the request was actually made?
(I genuinely do appreciate the input.)
William Faulk wrote:
Oh, that's surprising to me.
The LDAP spec seems to indicate that the only possible argument for a delete operation is a DN, and, while I still can't reproduce the problem with unimportant entries, access logs on replicas where deletes are being replicated to seem to imply that the remote server is just requesting a normal delete operation specifying the DN, and the access logs don't seem to show any sort of search to determine the DN from the nsuniqueid (or anything else).
So, and I'm sorry to say this, but: Are you sure? Keep in mind that I'm running an old version of 389-ds: v1.3.11, I think. Maybe the replication protocol is handled in such a way that access logs are showing an action that is ultimately what's happening, even if it's not exactly how the request was actually made?
(I genuinely do appreciate the input.)
Is it possible to share the entries, redacted is fine? The two on the oddball server and the one across the others?
What Pierre is saying is that if you you want to make sure that the nsuniqueid in the conflict entry is different from the "right" entries on the other servers, otherwise you will delete them all.
rob
Sorry. I did confirm that the nsuniqueid of the bad replica's active entry is different from the other replicas' entries and I forgot to say that. (The conflict entry's nsuniqueid and the entries on the good replicas match, too.) Here are the entries, with names and crypto stuff redacted, but everything else verbatim:
good: https://pastebin.com/N2AZNXAH bad: https://pastebin.com/MMMzqwN3
My concern is that the access logs seem to contradict what Pierre said: that replicated deletes are basing the delete on the nsuniqueid. If I can get a confirmation that the logs are lying to me, that's fine. I just want to be doubly sure.
That said, I then have a concern about the group memberships on the conflict entry once it's renamed. I can't imagine that it will acquire the correct groups just by being renamed. Am I going to just need to fix that up manually? (That may be outside the scope of this mailing list.)
Hi William,
Referring to the entries by nsuniqueid is one fundamental point of the replication protocol. dn are not reliable enough to identify an entry (remember that entries may be renamed and that replication protocol is asynchronous. nsuniqueid was created to be able to identify uniquely an entry among the replicas) When sending an update the supplier add a special control to the replayed operation containing the nsuniqueid, the csn and some other data, the consumer use the control to get these data and although the operation is logged with the original dn, it is applied on the entry with the nsuniqueid.
Regards Pierre
On Fri, Jan 12, 2024 at 12:02 AM William Faulk d4hgcdgdmj@liamekaens.com wrote:
Sorry. I did confirm that the nsuniqueid of the bad replica's active entry is different from the other replicas' entries and I forgot to say that. (The conflict entry's nsuniqueid and the entries on the good replicas match, too.) Here are the entries, with names and crypto stuff redacted, but everything else verbatim:
good: https://pastebin.com/N2AZNXAH bad: https://pastebin.com/MMMzqwN3
My concern is that the access logs seem to contradict what Pierre said: that replicated deletes are basing the delete on the nsuniqueid. If I can get a confirmation that the logs are lying to me, that's fine. I just want to be doubly sure.
That said, I then have a concern about the group memberships on the conflict entry once it's renamed. I can't imagine that it will acquire the correct groups just by being renamed. Am I going to just need to fix that up manually? (That may be outside the scope of this mailing list.) -- _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Thanks for the confirmation.
I'll follow up with the results, just in case anyone in the future comes across this thread, and to let folks know how the membership gets handled upon rename of the conflict entry.
I was prepping to make this change and realized there's a part of the documentation I don't understand.
It says to delete the active entry, then perform a modrdn on the conflict entry, then delete the old RDN value of the naming attribute.
That last step can't be correct in this case, right? The naming attribute isn't changing.
Their actual example is:
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: nsuniqueid=66446001-1dd211b2+uid=adamss,dc=example,dc=com changetype: modrdn newrdn: uid=NewValue deleteoldrdn: 0
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: uid=NewValue,dc=example,dc=com changetype: modify delete: uid uid: adamss - delete: nsds5ReplConflict -
But if you're trying to promote the conflict entry to replace the bad active entry, the naming attribute value isn't changing. That is, the "NewValue" in their example is the same as the old value: "adamss". Surely following these directions naively is going to result in deleting the naming attribute altogether. Unless maybe the schema prevents it from deleting the last value?
Am I correct in thinking I should just skip that part, while continuing to delete the nsds5ReplConflict attribute?
Hi William,
IMHO, In your case simply deleting the entry should be enough: When deleting the entry, URP (i.e the conflict resolution protocol) should detect that there was an associated conflict entry and rename the conflict entry as the main entry. (Not 100% sure because there are exceptions in case of multiple conflicts, but from what you described, you are probably in the simple case)
FYI: About deleting the naming attribute value. You are right: you should not delete it if you do not change the naming attribute. Anyway you just cannot do it: such the modify operation fails with either schema violation or operation not allowed on rdn
Regards Pierre
On Fri, Jan 12, 2024 at 10:50 PM William Faulk d4hgcdgdmj@liamekaens.com wrote:
I was prepping to make this change and realized there's a part of the documentation I don't understand.
It says to delete the active entry, then perform a modrdn on the conflict entry, then delete the old RDN value of the naming attribute.
That last step can't be correct in this case, right? The naming attribute isn't changing.
Their actual example is:
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: nsuniqueid=66446001-1dd211b2+uid=adamss,dc=example,dc=com changetype: modrdn newrdn: uid=NewValue deleteoldrdn: 0
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: uid=NewValue,dc=example,dc=com changetype: modify delete: uid uid: adamss
delete: nsds5ReplConflict
But if you're trying to promote the conflict entry to replace the bad active entry, the naming attribute value isn't changing. That is, the "NewValue" in their example is the same as the old value: "adamss". Surely following these directions naively is going to result in deleting the naming attribute altogether. Unless maybe the schema prevents it from deleting the last value?
Am I correct in thinking I should just skip that part, while continuing to delete the nsds5ReplConflict attribute? -- _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
I completed this last night. I found that deleting the active entry did not automatically promote the conflict entry. I still had to perform the modrdn operation.
Also, in addition to deleting the "nsds5ReplConflict" attrbute, I also manually deleted the "ConflictCSN" attribute, and the "ldapsubentry" value from the "objectclass" attribute.
And it didn't magically get added to the groups that the formerly active entry and the same entry in the other IdM replicas was in. I had to add them manually, using IdM utilities, on the replica where this change took place. (I actually only had to add one group; the other memberships were based on that one group, so adding it to that group added it to the others.)
After that, though, the entry on this server matched the entries on the other replicas except for "entryusn", "entryid", and "modifyTimestamp", which I believe are all normal variances.
Thanks for your help.
By the way, Red Hat support spent four days failing to even understand the question that you answered for me in half an hour: that deleting the active entry here wouldn't delete it on the other replicas. I asked them three or four times, each time getting a response that either explained to me how to delete the conflict entry, or failing to address the idea that it might delete the entry on the replicas, until I was finally told that it was impossible to promote the conflict entry, despite the documentation providing a procedure exactly for that, and that I would have to reinitialize the data on that replica.
If anyone has any suggestions for a vendor that can provide decent IdM support, I'd love to hear it.
Again, many thanks to everyone here.
Hello William, I am sorry to read you had a not so ideal support experience, I located a case number that seems to match this thread, and we will look into what can be improved, and maybe even we should try to discuss the situation with a meeting. I think it is important to ring an alarm in the support ticket system when there is some sort of dissatisfaction in the resolution, timing, or environment awareness that is related to the reported issue and particular technology, so the case can be presented to a next level, or somebody with a specific knowledge, or escalated if needed. This would be a different topic, but being able to reach the creators and developers of a software directly, those with the best knowledge of very specific features, freely, is amazing, those developers are not support engineers, but till spend time here, so I am very glad to see a thriving community of users in this list, from newbies to what I call "power users" with operational experience ( the "real world"). Thanks all for participating, M.
On Thu, Jan 18, 2024 at 8:50 AM William Faulk d4hgcdgdmj@liamekaens.com wrote:
I completed this last night. I found that deleting the active entry did not automatically promote the conflict entry. I still had to perform the modrdn operation.
Also, in addition to deleting the "nsds5ReplConflict" attrbute, I also manually deleted the "ConflictCSN" attribute, and the "ldapsubentry" value from the "objectclass" attribute.
And it didn't magically get added to the groups that the formerly active entry and the same entry in the other IdM replicas was in. I had to add them manually, using IdM utilities, on the replica where this change took place. (I actually only had to add one group; the other memberships were based on that one group, so adding it to that group added it to the others.)
After that, though, the entry on this server matched the entries on the other replicas except for "entryusn", "entryid", and "modifyTimestamp", which I believe are all normal variances.
Thanks for your help.
By the way, Red Hat support spent four days failing to even understand the question that you answered for me in half an hour: that deleting the active entry here wouldn't delete it on the other replicas. I asked them three or four times, each time getting a response that either explained to me how to delete the conflict entry, or failing to address the idea that it might delete the entry on the replicas, until I was finally told that it was impossible to promote the conflict entry, despite the documentation providing a procedure exactly for that, and that I would have to reinitialize the data on that replica.
If anyone has any suggestions for a vendor that can provide decent IdM support, I'd love to hear it.
Again, many thanks to everyone here.
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
389-users@lists.fedoraproject.org
-
Marc Sauton -
Pierre Rogier -
Rob Crittenden -
William Faulk