[Freeipa-devel] LDAP conflicts resolution API

[Nathan Kinder]

On 10/19/2011 11:22 PM, Martin Kosek wrote:
> 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.
No, I think an RFE to change the existing replication plug-in to allow 
an alternate conflict area would be best.  Simo and I had discussed this 
possibility a long time back.  We would allow one to configure a suffix 
to put conflicts in to prevent them from being in the tree that clients use.
> Martin
>
>>> It would certainly cause some entries to "disappear", but it would also
>>> prevent some of the issues with have those entries.
>>>
>>> Simo.
>>>
>