[Freeipa-devel] LDAP conflicts resolution API

[Rich Megginson]

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.
> It would certainly cause some entries to "disappear", but it would also
> prevent some of the issues with have those entries.
>
> Simo.
>