Reloading the full schema in upgradeprovision

[Andrew Bartlett]

On Sun, 2010-07-11 at 17:58 +0400, Matthieu Patou wrote:
> On 11/07/2010 17:25, Andrew Bartlett wrote:
> > On Sun, 2010-07-11 at 16:07 +0400, Matthieu Patou wrote:
> >> Andrew, Metze and others,
> >>
> >> Can you give me your point of view on a solution like this to allow
> >> upgradeprovision to reload the full schema (mdw thank you not to point
> >> any formatting pbs as this code is a poc and I am waiting for technical
> >> remarks).
> >>
> >> We need to reload the full schema because depending how old is your
> >> provision you do not have all the schema elements in it, so we start
> >> with an external schema (as it is done in provision). This works great
> >> but then due to schema enforcement that appeared lately we will face
> >> situation when an object modified, that has an attribute defined only in
> >> the schema of the updated provision (ie. think of an upgraded provision
> >> with openchange schema ...), will not be allowed to be modified because
> >> it violate the schema.
> >>
> >> The idea of this patch is to wait until upgradeprovision has added the
> >> missing schema elements, then force a reload of the full schema that
> >> contains existing classes and attributes (and potentially the ones added
> >> by the user) and also the missing one brought by the update.
> > Yes, that sounds like a good idea.  but why:
> >
> > +    dsdb._dsdb_set_schema_from_ldif(tmpldb, prefixmap_ldif,
> > schema_ldif)
> > +    samdb.set_schema_from_ldb(tmpldb)
> >
> > Can't you set it directly on the samdb, without the extra ldb?
> >
> Well I don't know seems doable, won't we loose the indexes ?

it may cause a re-index, but I don't think it will do any harm.

> What about the hidden attributes, will it remove the existing content of 
> the schema.ldb (well it's new name ...).

dsdb_set_schema_from_ldif does not change the database, just sets the
schema that is currently in use.  There really shouldn't be a difference
between doing it on the temp ldb first, and then setting it on the main
ldb with set_schema_from_ldb(). 

> >> So can you have a look at the patch, I don't like much the way the
> >> prefixMap is done, but fetching the one from the provision schema gives
> >> me a blob and I'm not sure I can unpack it in a  drsblobs.prefixMapBlob
> >> and then get the list of oid (or maybe with drsuapi_MSPrefixMap_Ctr).
> > Why do you need to unpack it?  But yes, the correct approach is very
> > much the same as what we try to do in the libnet_vampire code.
> Well I tried something like that:
> 
> prefixmap_ldif = "dn: cn=schema\nprefixMap:: %s\n\n" % str(res[0]["prefixMap"])
> 
> But it didn't work very well ... I mean I had errors, I can redo a tests just to get the right error message

You will need to base64 encode it. 

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: 190 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100712/4f55b0f0/attachment.pgp>