Reloading the full schema in upgradeprovision

Matthieu Patou mat at
Mon Jul 12 15:14:25 MDT 2010

  On 12/07/2010 02:24, Andrew Bartlett wrote:
> 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 I guess you want me to do this:
diff --git a/source4/scripting/bin/upgradeprovision 
index f72883d..46d5fe0 100755
--- a/source4/scripting/bin/upgradeprovision
+++ b/source4/scripting/bin/upgradeprovision
@@ -943,8 +943,6 @@ def reload_full_schema(samdb, names):

      current ="objectClass=*", 
-    tmpldb = samba.samdb.SamDB(global_schema=False, am_rodc=False)
      schema_ldif = ""
      prefixmap_data = ""

@@ -958,8 +956,8 @@ def reload_full_schema(samdb, names):
      # We don't actually add this ldif, just parse it
      prefixmap_ldif = "dn: cn=schema\nprefixMap:: %s\n\n" % prefixmap_data

-    dsdb._dsdb_set_schema_from_ldif(tmpldb, prefixmap_ldif, schema_ldif)
-    samdb.set_schema_from_ldb(tmpldb)
+    dsdb._dsdb_set_schema_from_ldif(samdb, prefixmap_ldif, schema_ldif)
+    samdb.set_schema_from_ldb(samdb)

to get this:;a=blobdiff;f=source4/scripting/bin/upgradeprovision;h=46d5fe03695aa31609e0984e5adab27c709c516d;hp=0ecf73d89ee3346b9f1972e7f28d876597867413;hb=3b4aab7d671c139ec7e1f37e280221eb7f98ed35;hpb=2da85d19dcc428420bf1f04ba40e80f377367dc1

>>>> 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.
Ok didn't find the time to make the test yet !

Matthieu Patou
Samba Team

More information about the samba-technical mailing list