Skip replication conflict entries in the IPA provider

[sssd-bot]

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/2605

• Created at 2015-03-16 12:26:19 by jhrozek
• Closed at 2020-03-24 14:06:48 as wontfix
• Assigned to mzidek

---

Replication conflict entries can break the IPA provider, for one reason because ldb can't handle them.

Any entries that use nsUniqueID in the RDN can be considered invalid by the client and skipped.

12:01 < sbose> jhrozek, btw, maybe an entry with nsuniqueid as RDN was the reason for the issue JR was seeing. Maybe it would be nice to have a general way to filter those entries in the IPA provider?
12:03 < jhrozek> sbose: maybe we could add some logic to the parsing function to skip entries that have multivalued RDN and the second component is nsUniqueID, yes
12:05 < sbose> jhrozek, if I understand it correctly nsUniqueID always indicates a broken entry, even if the RDN is single valued. You cannot create entries with this RDN manually. But before we add this we should get confirmation from the DS team.
12:06 < jhrozek> sbose: I see, I thought some IPA entries used a UUID in RDN?
12:06 < jhrozek> yes, we should
12:06 < jhrozek> ah, they use their own IPA UUID
12:06 < sbose> jhrozek, they use the ipaUUID
12:08 < ab> sbose: yes, it is result of conflict of replication if you have nsUniquieID in the RDN
12:09 < jhrozek> lkrispen: tbordaz: what do you think? Is it possible/wise for the IPA client to skip entries with nsUniqueID in the RDN?
12:10 < jhrozek> lkrispen: tbordaz: this would be to avoid bugs like https://bugzilla.redhat.com/show_bug.cgi?id=1202245
12:13 < lkrispen> jhrozek: the nsuniqueid is in the rdn either if it is a tombstone (normally a client shouldn't see this) or because of a replication conflict (adding same dn at the same time on two masters).
12:14 < lkrispen> a client can ignore these entries, but you should check why this can happen
12:15 < jhrozek> lkrispen: OK, so what if we skipped those entries during parsing but emited a syslog message so that admin knows something is wrong?
12:16 < jhrozek> maybe only first time such entry is hit to avoid flooding the syslog
12:16 < lkrispen> jhrozek: yes, if the admiin will read this :-) there is already a flag in the entry "replication conflict" which could also be monitored 
12:19 < jhrozek> lkrispen: how is the flag implemented? Is it some attribute?

Comments

---

Comment from jraquino at 2015-03-16 15:19:26

I'm not sure if sssd is caching hbac or sudo rules, but please be aware that both hbac and sudo seem to create DN's in this manner:
dn: ipaUniqueID=68aa6fee-1ac8-11e1-a9ff-9c8e9927cab0,cn=hbac,dc=example,dc=com

---

Comment from jhrozek at 2015-03-19 15:19:43

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.13 alpha

---

Comment from jhrozek at 2015-06-18 16:04:26

Should not block Alpha

milestone: SSSD 1.13 alpha => SSSD 1.13 beta
sensitive: => 0

---

Comment from jhrozek at 2015-07-04 16:23:02

Can be moved out again to make room.

milestone: SSSD 1.13.1 => SSSD 1.13.2

---

Comment from jhrozek at 2015-07-30 16:30:37

Fields changed

rhbz: => todo

---

Comment from jhrozek at 2015-08-20 14:28:37

Fields changed

owner: somebody => mzidek

---

Comment from jhrozek at 2015-09-17 16:16:53

Fields changed

milestone: SSSD 1.13.2 => SSSD 1.13.3

---

Comment from jhrozek at 2015-10-11 22:11:15

I'm moving the ticket to the next milestone, because 1.13 is already getting quite full and this kind of issues is possible to fix (and even should be fixed) on the server side.

milestone: SSSD 1.13.3 => SSSD 1.14 beta
priority: major => minor

---

Comment from jhrozek at 2016-02-16 14:21:09

Might make sense as code hardening, but only as a nice-to-have feature

milestone: SSSD 1.14 beta => SSSD 1.14 backlog

---

Comment from jhrozek at 2016-08-04 10:13:16

Fields changed

keywords: => easyfix

---

Comment from jhrozek at 2016-12-15 11:01:21

Since the 1.14 branch is transitioning into maintenance mode and new functionality is being developed in master which will become 1.15 eventually, I'm mass-moving tickets from the 1.14 backlog milestone to the "Future releases" milestone.

milestone: SSSD 1.14 backlog => SSSD Future releases (no date set yet)

---

Comment from jhrozek at 2017-02-24 14:54:29

Metadata Update from @jhrozek:

• Issue assigned to mzidek
• Issue set to the milestone: SSSD Future releases (no date set yet)

---

Comment from thalman at 2020-03-11 14:55:25

Metadata Update from @thalman:

• Custom field design_review reset (from 0)
• Custom field mark reset (from 0)
• Custom field patch reset (from 0)
• Custom field review reset (from 0)
• Custom field sensitive reset (from 0)
• Custom field testsupdated reset (from 0)
• Issue close_status updated to: None
• Issue tagged with: Canditate to close

---

Comment from pbrezina at 2020-03-24 14:06:47

Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfill this request I am closing the issue as wontfix.

If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.

Thank you for understanding.

---

Comment from pbrezina at 2020-03-24 14:06:49

Metadata Update from @pbrezina:

• Issue close_status updated to: wontfix
• Issue status updated to: Closed (was: Open)