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

[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
> > > 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'm sorry, -ENOATTACHMENT...

> 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 :-(

Yes, that is expected.  That happens because we replaced (long ago)
your original schema import code, which manually parsed the DRS schema
to build a Samba schema, with one that imports the DRS schema multiple
times, attempting a conversion.  Because we can get attributes before
the class they appear in, or a class before the parent or other
referenced class, we loop until those all import, but it does spew out
that message along the way.

> Andreas' autobuild will run through the end, but won't result in
> master.
> We can check if it has the same hidden problems.
> 
> metze
> 
-- 
Andrew Bartlett
https://samba.org/~abartlet/
Authentication Developer, Samba Team         https://samba.org
Samba Development and Support, Catalyst IT   
https://catalyst.net.nz/services/samba





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20160311/0a7316ad/signature-0001.sig>