[PATCH] samba-tool dbcheck: handle missing objectClass

[Andrew Bartlett]

On Thu, 2014-02-27 at 16:23 +1300, Andrew Bartlett wrote:
> On Thu, 2014-02-27 at 14:58 +1300, Andrew Bartlett wrote:
> > On Tue, 2014-02-25 at 12:25 +0100, Felix Botner wrote:
> > > Am Dienstag, 25. Februar 2014, 10:22:30 schrieb Felix Botner: 
> > > > I am not sure and we cannot reproduce this on a regular basis but it happens
> > > > in multiserver environments (after the replication) and all objects lacking
> > > > the objectClass have been "\0ADEL:" objects.
> > > 
> > > unfortunately, that is not completely true. This also affects normal (non-
> > > deleted) objects.
> > > 
> > > dn: CN=WIN-PC,CN=Computers,DC=abc,DC=ucs
> > > instanceType: 4
> > > whenChanged: 20140211141300.0Z
> > > uSNCreated: 182964
> > > uSNChanged: 182964
> > > objectGUID: 98c7d79d-bf52-4b4c-b461-51ee0a907593
> > > operatingSystem: Windows 7 Professional
> > > operatingSystemVersion: 6.1 (7601)
> > > operatingSystemServicePack: Service Pack 1
> > > msDS-SupportedEncryptionTypes: 28
> > > distinguishedName: CN=WIN-PC,CN=Computers,DC=abc,DC=ucs
> > 
> > This is a very serious issue, and I have been pointed at
> > https://bugzilla.samba.org/show_bug.cgi?id=10398 in connection with
> > this.  I agree we have no option but to delete these objects given how
> > little information remains.
> > 
> > However, we must ensure this does not happen again - these attributes
> > are mandatory, and if we get corrupt objects over DRS, I think we should
> > reject the replication.
> 
> Attached are two patches.  One fixes our existing dbcheck code to work
> when --attrs=cn is specified, and the other implements a test to ensure
> that remains the case.  I also attach a fixed version of your patch for
> the same issue.

Stepping back to the dbcheck stage, I've been thinking about what we
should do here.  I think these patches are still good, and are needed
because it is the only way to un-break a domain controller that has got
these object, but we should continue to work to ensure it doesn't happen
again.

I don't know if they still work after our repl_meta_data changes (it may
well not), but in many ways that doesn't matter, the first priority
should be detecting the corruption on-disk.

What we should do next is write a test that detects an 'unsorted'
replPropertyMetaData, because that would indicate the same thing, that
objectClass is not recorded there also, or that we have it sorted wrong
due to the additional schema.  If it 'just' additional schema, then
fixing that should just be a matter of doing the sort in the python.

Given all this, can you review these patches and suggest a way forward?

Thanks,

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



-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-dbcheck-Ensure-dbcheck-can-operate-with-attrs-set.patch
Type: text/x-patch
Size: 1585 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20140321/9a221e18/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-samba-tool-dbcheck-handle-missing-objectClass.patch
Type: text/x-patch
Size: 3882 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20140321/9a221e18/attachment-0001.bin>