[IPA] SID allocation using DNA plugin

Endi Sukma Dewata edewata at redhat.com
Thu Nov 12 09:54:16 MST 2009


Andrew,

----- "Andrew Bartlett" <abartlet at samba.org> wrote:

> > The schemaIdGuid currently is generated by hashing the OID using MD5.
> > If we use another method such as SHA256 that generates longer hash
> > values, can I just use the first 16 byte as the GUID? Would that
> > increase the risk of collision, or does it matter at all?

> It really does not matter.  Given what we use it for (a pipelined
> process), we could just make it random, or the binary form of the OID
> padded with zeros, but I like it being a bit deterministic.  

> > In the provisioning tool the Schema object creation has been moved
> > inside the xxxBackend class so that each backend can generate a
> custom
> > schema that works for the backend. This allows FDSBackend to add
> > additional prefix maps without changing the global prefixMap.txt.

> That's not quite what I meant.  We should keep the Schema as was for the
> Samba schema, but *also* create a new schema object in the FDS and
> OpenLDAP backends, that has the schema used by the backends only. That
> way, we don't put backend classes into the client-visible schema.  

> Essentially: we want to reuse the schema code, but with different data.
> Once upon a time, this didn't even share code, but some of the tables
> and 'create a schema string from a ldap entry' were close enough that it
> became silly to keep two similar sets of code. 

Ok, I'll be making some changes on those things.

> The only thing I don't like is the change to schema_syntax.c, and that's
> just because I'll need to look at it more carefully to understand that
> it's safe (the schema code is at the core of way we use LDB in Samba4). 

Sorry, I should have removed it. It was added because the oLschema2ldif
originally didn't generate the oMSyntax so I had to do a lookup using the
OID. But now that I have added oMSyntax in the oLschema2ldif, the change
to schema_syntax.c is no longer necessary.

Thanks.

--
Endi S. Dewata


More information about the samba-technical mailing list