attid fixes (Re: [SCM] Samba Shared Repository - branch master updated)

[Stefan Metzmacher]

Am 10.03.2016 um 19:40 schrieb Andrew Bartlett:
> On Thu, 2016-03-10 at 13:10 +0100, Stefan Metzmacher wrote:
> 
>> This explains a lot! Do we have dbcheck code to fix this?
> 
> Not to fix it - as you know we find the attid that isn't in the schema,
> but I chickened out of fixing it, because we would have to guess
> (intuit) which attribute it was meant to point to, which might actually
> be an empty attribute and so not present. 
> 
> I was going to say we are saved by using msDS-IntID in the non-schema
> partitions, but of course that has been its own disaster.  Given that
> extra factor, I really don't know if we will hit this in the wild, and
> would rather see a genuine customer/user situation with it before
> embarking on a dbcheck fix.  I would first advise re-replication in any
> case.
> 
>> I'm also wondering if it really correct that the prefix map will
>> differ in a pure Windows domain. Shouldn't the destination dc
>> import the prefix map from the source dc when replicating schema
>> changes?
>>
>> But the fact that [MS-DRSR] has a LocalAttidFromRemoteAttid()
>> function,
>> it might also be possible the prefixMap will be different on Windows
>> too.
>> Are you able to verify this?
> 
> I haven't yet, and in any case by now we have in-the-wild Samba domains
> with differing prefixMap values.
> 
> It would depend on what order we saw the OIDs in, which is why this is
> a flapping test.  The majority of custom schema users add only the sudo
> schema, and that uses only one OID prefix, so is 'safe'.
> 
> That a whole new class of attributeID values for msDS-IntID was created
> indicates to me that this was a problem for MS too. 
> 
>> For I created https://bugzilla.samba.org/show_bug.cgi?id=11783 for
>> this
>> and this can be pushed with the bug url and my review.

I canceled my autobuild after seeing a panic and other failures,
in the background replication, which might be related.

See the attached files, look for:

#22 0x00002aaad8292eda in dsdb_replicated_objects_commit
(ldb=0x2aaadb438130, working_schema=0x2aaae242e2e0,
objects=0x2aaae4411990, notify_uSN=0x2aaae522ed10) at
../source4/dsdb/repl/replicated_objects.c:837
        werr = {w = 3789606832}
        ext_res = 0x0
        cur_schema = 0x2aaae2971da0
        new_schema = 0x0
        ret = 0
        seq_num1 = 26673
        seq_num2 = 4294967296
        used_global_schema = true
        tmp_ctx = 0x2aaae1bdd380
        __FUNCTION__ = "dsdb_replicated_objects_commit"

I also noticed:
../source4/dsdb/schema/schema_syntax.c:1021: Unknown governsID 0x005A000D
../source4/dsdb/schema/schema_syntax.c:1076: Unknown attributeID_id
0x005C000D
is also still present :-(

Andreas' autobuild will run through the end, but won't result in master.
We can check if it has the same hidden problems.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20160310/45983726/signature.sig>