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: ute...@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....@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....@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....@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 ? It would certainly cause some entries to "disappear", but it would also prevent some of the issues with have those entries. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel