[IPA] SID allocation using DNA plugin

[Andrew Bartlett]

On Thu, 2009-11-12 at 03:09 -0500, Endi Sukma Dewata wrote:
> Andrew,
> 
> Attached is a 'preview' of the changes I'm making for removing the
> dependency on the full Samba 3 schema shipped with FDS and instead
> using a subset of Samba 3 schema shipped with Samba.
> 
> In this patch I'm converting examples/LDAP/samba3.schema into AD-LDIF
> using the oLschema2ldif. As I mentioned earlier, there are some
> attributes that I had to add before it can be loaded properly.
> 
> 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.  

> I also removed some of the mappings I added previously because it's
> no longer necessary with partial Samba 3 schema (no more conflicts).
> 
> 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. 

> I also moved some of the FDS-specific variables into the FDSBackend
> class for better encapsulation. There are some other OpenLDAP-specific
> variables also, but that's for another patch.
> 
> I've tested this patch on top of the latest code from master branch
> with the default, FDS, and OpenLDAP backend. So far everything seems
> to be working consistently, there's no more crashing.
> 
> Are these ok so far? Thanks!

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). 

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20091112/652e7789/attachment.pgp>