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

[Stefan Metzmacher]

Am 11.03.2016 um 06:58 schrieb Andrew Bartlett:
> On Thu, 2016-03-10 at 20:55 +0100, Stefan Metzmacher wrote:
>> 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 fo
>>>> r
>>>> 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.
> 
> My best guess is that with replication less broken, that we progress
> further, hit an issue with the schema build code, and somehow the
> casefold pointer (that is what is being used in the ldb DN code where
> it faults) becomes NULL (probably use after free).  But this is all
> conjecture, and what we really need to do is get a debugger and
> valgrind onto the case where this happens.

It seems it was not related and it's now pushed to master.

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/20160314/7386a430/signature.sig>