On 10/20/2011 07:57 AM, Martin Kosek wrote:
On Thu, 2011-10-20 at 07:18 -0700, Nathan Kinder wrote:
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:
...
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.
I already implemented the conflict-find, conflict-show and
conflict-rename commands. But I really like your idea. Conflicts can
cause quite unpredictable effects for the user. Not every user can be
experienced enough to guess the replication conflicts cause that issues
and use the new conflict-* commands to fix it.
If all conflicts are stored to a special suffix, the end user experience
will be much better. I can adapt new commands so that user can manage
the conflicts when he get to it without side effects other ipa commands.
Nathan, do you think you will be able to implement this change for RHEL
6.3.0? I can create a RFE bugzilla.
Go ahead and create the RFE bug against 389. We will discuss it in our
weekly DS bug triage on Monday to determine the timeline.
Thanks,
Martin
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
