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: 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 ?
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.



_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to