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 


ipa conflict-del DN

This command would delete conflicting LDAP objects altogether:
ipa conflict-del 

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.


It would certainly cause some entries to "disappear", but it would also
prevent some of the issues with have those entries.


Freeipa-devel mailing list

Reply via email to