[PATCH] samba-tool dbcheck: handle name conflict objects

Andrew Bartlett abartlet at samba.org
Mon Mar 31 02:59:24 MDT 2014


On Thu, 2014-03-20 at 16:01 +1300, Andrew Bartlett wrote:
> On Wed, 2014-03-19 at 18:01 +0100, Felix Botner wrote:
> > Am Mittwoch, 5. März 2014, 10:16:37 schrieb Andrew Bartlett:
> > > What we need now is to improve the tool, because conflict resolution is
> > > a manual process, not one that we can do anything more than guide.
> > > 
> > > The tool should present both objects to the user, and ask them which one
> > > should survive.  You will have to find the other record by figuring out
> > > what the name would have been.   We can have --yes simply prune the
> > > conflict record (which will be the newer record), but the admin should
> > > be presented with the choice, and be able to keep the conflict record
> > > instead.
> > 
> > Yes, i see that, how should i ask the user
> > 
> > (a)
> > 
> > Found conflict object and corresponding non-conflict object!
> > Delete conflict object "conflict dn"? [Y,n] -> n
> > Delete the non-conflict object "non-conflict dn"? [Y,n] -> y
> > Rename the conflict object to "non-conflict dn"? [Y,n] -> y
> > 
> > if --fix is set, the default would be to delete all conflict objects
> > 
> > (b)
> > 
> > Found conflict object and corresponding non-conflict object! 
> > Which object should be deleted?
> >   [1] the conflict object (dn)
> >   [2] the non-conflict object (dn)
> >   [3] none
> > [1, 2, 3] -> 2
> > Should the conflict object be renamed to 'non-conflict dn'? [Y,n] -> y
> > 
> > (b) is maybe a bit more user friendly, because we present them all the options 
> > (delete conflict or delete non-conflict) in one step not just "delete 
> > conflict" as in (a)
> 
> I think b) is much better.  I think the second step should be combined
> with the choice - leaving the conflict object but removing the original
> DN makes little sense to me.  
> 
> I'm happy for --fix --yes to delete the conflict DN in the
> --check-for-conflicts mode. 
> 
> > > 
> > > It also shouldn't be presented as an ERROR - it isn't an error, but can
> > > be cleaned up.  Perhaps call it 'WARNING:' instead?
> > 
> > OK
> > 
> > > 
> > > Also, we shouldn't specify the DBCHECK control - the deletion needs to
> > > be a normal delete, and go though the normal processes.
> > >
> > 
> > Yes
> >  
> > > Finally, as I mentioned before we also should have a test for this,
> > > running on and fixing real conflicts generated by
> > > source4/torture/drs/python/replica_sync.py, and on a test database
> > > (perhaps the same one you plan to submit for the missing objectclass).
> 
> This is the critical part - this will only happen rarely I hope, and we
> need tests to ensure it all works. 

Felix,

Do you need any more help reworking these patches or understanding what
is required in the tests?  I would like to get these in to Samba once
that is done.

Andrew Bartlett

-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba




More information about the samba-technical mailing list