[PATCH] samba-tool dbcheck: handle missing objectClass

[Felix Botner]

Am Mittwoch, 26. März 2014, 13:09:39 schrieb Andrew Bartlett:
> On Sat, 2014-03-22 at 22:10 +1300, Andrew Bartlett wrote:
> > On Fri, 2014-03-21 at 08:58 +0100, Stefan (metze) Metzmacher wrote:
> > > Hi Felix,
> > > 
> > > > +    def err_missing_objectclass(self, dn):
> > > > +        """handle object without objectclass"""
> > > > +        self.report("ERROR: missing objectclass in object %s" % (dn))
> > > > +        if not self.confirm_all("Delete object'%s'?" % dn,
> > > > 'fix_all_missing_objectclass'): +            self.report("Not
> > > > deleting object with missing objectclass '%s'" % dn) +           
> > > > return
> > > > +        if self.do_delete(dn, ["local_oid:%s:0" %
> > > > dsdb.DSDB_CONTROL_DBCHECK], +                          "Failed to
> > > > remove DN %s" % dn):
> > > > +            self.report("Removed DN %s" % dn)
> > > 
> > > do_delete aleady adds DSDB_CONTROL_DBCHECK.
> > 
> > OK, I'll drop that.  I'll also put some more thought into the message
> > and proposed action.  I'm hoping Felix can confirm that a samba-tool drs
> > replicate --local --sync-all can fix the objects, and if so we might
> > wish to suggest that (and if that isn't possible, say no other replica
> > any longer, we should set a control to just purge the object).
> > 
> > > I'm wondering if it would be possible to reconstruct the objectClass
> > > based on the objectCategory?
> > 
> > I asked the same thing.  The issue is that these objects only have
> > 'recently changed' attributes, not the whole object.  The bug that
> > created them was due to a misunderstanding between the source and
> > destination replica DC about which USNs had been sent to the destination
> > replica.
> > 
> > objectCategory would be in the same class - added at the time of add,
> > and so not replicated.  Additionally, this seems to happen most often
> > with deleted objects, which also don't have the objectCategory.
> 
> I don't have any way to test this, so what I've done is as much as I
> think is reasonable in the hope that when we next see a corrupt database
> we can work to make this recoverable.
> 
> In the meantime, at least it detects this condition, and suggests a
> solution.
> 
> Felix:  This changes your patch a little, please give your OK on that.

OK, totally fine with me


-- 

Felix Botner

Open Source Software Engineer

Univention GmbH
be open
Mary-Somerville-Str.1
28359 Bremen
Tel. : +49 421 22232-0
Fax : +49 421 22232-99

<botner at univention.de>
http://www.univention.de

Geschäftsführer: Peter H. Ganten
HRB 20755 Amtsgericht Bremen
Steuer-Nr.: 71-597-02876