[Freeipa-devel] LDAP conflicts resolution API

[Martin Kosek]

On Wed, 2011-10-19 at 09:51 -0600, Rich Megginson wrote:
> On 10/19/2011 09:46 AM, Simo Sorce wrote:
> > On Wed, 2011-10-19 at 17:33 +0200, Martin Kosek wrote:
> >> Hello all,
> >>
> >> I am now investigating how to deal with LDAP conflicts resolution
> >> between replicas. Conflicting LDAP objects may be created if 2 LDAP
> >> objects (users, hosts, etc) with the same DN are created on disconnected
> >> replicas. When the replicas synchronize again, 389-ds renames one of the
> >> objects to something like this:
> >>
> >> nsuniqueid=0a950601-435311e0-86a2f5bd-3cd26022+uid=utest,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
> >>
> >> for users OR
> >>
> >> fqdn=rhel61-client3.testrelm+nsuniqueid=807bb87f-652211e0-9e848fb2-f0f04a39,cn=computers,cn=accounts,dc=testrelm
> >>
> >> for hosts.
> >>
> >> Records like this then cannot be handled via IPA commands and can cause
> >> a wide range of problems. There are already 2 tickets filed:
> >>
> >> https://fedorahosted.org/freeipa/ticket/1025
> >> https://fedorahosted.org/freeipa/ticket/1174
> >>
> >> Since we cannot avoid creating these objects, we can at least help
> >> mitigate the consequences and help user remove the conflicts using our
> >> CLI (or WebUI in the future).
> >>
> >> I would like to propose a simple plugin to manage these conflicts:
> >>
> >> 1) ipa confict-find
> >> This command would find all conflicting LDAP objects using filter
> >> nsds5ReplConflict=*. Since this plugin would work with all LDAP objects
> >> we support, the most straightforward implementation would be to display
> >> raw LDAP data.
> >>
> >> I am still thinking if we could make the output prettier by finding what
> >> LDAP object is in conflict (user, host, sudorule) and display the
> >> objects in standard way as we do in ipa user-show, ipa host-show or ipa
> >> sudorule-show. I guess we could identify the conflicting object type by
> >> comparing its parent DN to all known LDAP objects container_dn.
> >>
> >> Raw LDAP data output would look like this:
> >>
> >> $ ipa conflic-find
> >> -----------------
> >> 3 conflicts found
> >> -----------------
> >> dn: nsuniqueid=02631581-fa5f11e0-bb339359-34a214df+uid=utest2,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
> >> memberOf: cn=ipausers,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
> >> mepManagedEntry: cn=utest2,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
> >> displayName: User Test
> >> cn: User Test
> >> objectClass: top
> >> objectClass: person
> >> objectClass: organizationalperson
> >> objectClass: inetorgperson
> >> objectClass: inetuser
> >> objectClass: posixaccount
> >> objectClass: krbprincipalaux
> >> objectClass: krbticketpolicyaux
> >> objectClass: ipaobject
> >> objectClass: mepOriginEntry
> >> loginShell: /bin/sh
> >> sn: Test
> >> gecos: User Test
> >> homeDirectory: /home/utest2
> >> krbPwdPolicyReference: cn=global_policy,cn=IDM.LAB.BOS.REDHAT.COM,cn=kerberos,
> >>   dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
> >> krbPrincipalName: utest2 at IDM.LAB.BOS.REDHAT.COM
> >> givenName: User
> >> uid: utest2
> >> initials: UT
> >> uidNumber: 1451000003
> >> gidNumber: 1451000003
> >> ipaUniqueID: 0636d5b6-fa5f-11e0-b85b-00163e6f5efc
> >>
> >>
> >> dn: nsuniqueid=02631582-fa5f11e0-bb339359-34a214df+cn=utest2,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
> >> description: User private group for utest2
> >> gidNumber: 1451000003
> >> objectClass: posixgroup
> >> objectClass: ipaobject
> >> objectClass: mepManagedEntry
> >> objectClass: top
> >> cn: utest2
> >> mepManagedBy: uid=utest2,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
> >> ipaUniqueID: 0639ee7c-fa5f-11e0-b85b-00163e6f5efc
> >>
> >>
> >> dn: nsuniqueid=af8a5d81-fa6011e0-bb339359-34a214df+fqdn=foo.example.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
> >> cn: foo.example.com
> >> objectClass: ipaobject
> >> objectClass: nshost
> >> objectClass: ipahost
> >> objectClass: pkiuser
> >> objectClass: ipaservice
> >> objectClass: krbprincipalaux
> >> objectClass: krbprincipal
> >> objectClass: top
> >> fqdn: foo.example.com
> >> managedBy: fqdn=foo.example.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=bos,
> >>   dc=redhat,dc=com
> >> krbPrincipalName: host/foo.example.com at IDM.LAB.BOS.REDHAT.COM
> >> serverHostName: foo
> >> ipaUniqueID: d069dff8-fa60-11e0-874e-00163e6f5efc
> >>
> >>
> >>
> >> User could then copy&paste DNs to manipulate the objects further:
> >>
> >> 2) ipa conflict-show DN
> >>
> >> This command would show chosen conflicting object closer + the original object it conflicts with:
> >>
> >> $ ipa conflict-show 'nsuniqueid=02631582-fa5f11e0-bb339359-34a214df+cn=utest2,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com'
> >> dn: fqdn=foo.example.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
> >> cn: foo.example.com
> >> objectClass: ipaobject
> >> objectClass: nshost
> >> objectClass: ipahost
> >> objectClass: pkiuser
> >> objectClass: ipaservice
> >> objectClass: krbprincipalaux
> >> objectClass: krbprincipal
> >> objectClass: top
> >> fqdn: foo.example.com
> >> managedBy: fqdn=foo.example.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=bos,
> >>   dc=redhat,dc=com
> >> krbPrincipalName: host/foo.example.com at IDM.LAB.BOS.REDHAT.COM
> >> serverHostName: foo
> >> ipaUniqueID: 94b378e8-fa60-11e0-867b-00163e2d6a08
> >>
> >> dn: nsuniqueid=af8a5d81-fa6011e0-bb339359-34a214df+fqdn=foo.example.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
> >> cn: foo.example.com
> >> objectClass: ipaobject
> >> objectClass: nshost
> >> objectClass: ipahost
> >> objectClass: pkiuser
> >> objectClass: ipaservice
> >> objectClass: krbprincipalaux
> >> objectClass: krbprincipal
> >> objectClass: top
> >> fqdn: foo.example.com
> >> managedBy: fqdn=foo.example.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=bos,
> >>   dc=redhat,dc=com
> >> krbPrincipalName: host/foo.example.com at IDM.LAB.BOS.REDHAT.COM
> >> serverHostName: foo
> >> ipaUniqueID: d069dff8-fa60-11e0-874e-00163e6f5efc
> >>
> >>
> >> 3) When user decides what to do with the conflicting object, he would use the following commands:
> >>
> >> ipa conflict-rename DN NEW_RDN
> >>
> >> This command would change the conflicting LDAP objects RDN to foo2.example.com:
> >> $ ipa conflict-rename 'nsuniqueid=af8a5d81-fa6011e0-bb339359-34a214df+fqdn=foo.example.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com' foo2.example.com
> >>
> >> OR
> >>
> >> ipa conflict-del DN
> >>
> >> This command would delete conflicting LDAP objects altogether:
> >> ipa conflict-del 'nsuniqueid=af8a5d81-fa6011e0-bb339359-34a214df+fqdn=foo.example.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com'
> >>
> >>
> >> Thoughts, comments?
> > Sounds good to me.
> > But I wonder if we can tell DS to create/move these conflicting objects
> > into a cn=conflicts subtree by means of configuration ?
> Not automatically, no.

So maybe a new DS plugin should do the trick? We would just have to
store original DN to some attribute if we want to enable user to just
rename the conflicting object to its original location.

Martin

> > It would certainly cause some entries to "disappear", but it would also
> > prevent some of the issues with have those entries.
> >
> > Simo.
> >
>