Samba4 loading schema.ldif

Matthieu Patou mat at samba.org
Sun Apr 22 11:33:23 MDT 2012


On 04/22/2012 02:20 AM, Gémes Géza wrote:
> Hi Mat,
>> So I have patches that allow samba to not trash its schema when trying
>> to load this schema, I have also patches that makes the loading of
>> this schema almost ok, I still have an issue with the loading in just
>> 1 step the solution is to use a ldap URL as the ldap protocol doesn't
>> have a notion of transaction.
>>
>> I also think that X-NDS_CONTAINMENT should be implemented in
>> olschema2ldif (as possSuperior I guess).
>>
>> The main problem for you is that this schema has a name collision with
>> existing classes (dhcpclass and dhcpoptions).
>> So of course you can just rename the classes in your ldif file but
>> then I guess that the DHCP server won't work as expected. Another
>> solution is to defunct the two blocking classes but for the moment
>> it's not completely working in Samba.
>>
>> The patches are at:
>> http://gitweb.samba.org/?p=mat/samba.git;a=shortlog;h=refs/heads/misc
>>
>> They wait for a small review but you can try them it should be pretty
>> safe.
>>
> I've seen, that your patches were merged in master, however trying to
> load the attached ldif (generated with patched oLschema2ldif with
> X-NDS_CONTAINMENT mods) still waxes the schema.
Really ?
>   Looking at the modified
> schema ldb it seems, that it still misses the oMObjectClass attributes.
That's right I decided not to do the changes in the olschema2ldif but 
directly in the ldb modules, patch 
e3fa5d7d2ad8b7c6248a8df4a0841bf974a6b5a1 had this code:

+               el = ldb_msg_find_element(ac->msg, "attributeSyntax");
+               if (el) {
+                       /*
+                        * No need to scream if there isn't as we have 
code later on
+                        * that will take care of it.
+                        */
+                       const struct dsdb_syntax *syntax = 
find_syntax_map_by_ad_oid((const char *)el->values[0].data);
+                       if (!syntax) {
+                               DEBUG(9, ("Can't find dsdb_syntax object 
for attributeSyntax %s\n",
+                                               (const char 
*)el->values[0].data));
+                       } else {
+                               unsigned int v = 
ldb_msg_find_attr_as_uint(ac->msg, "oMSyntax", 0);
+                               const struct ldb_val *val = 
ldb_msg_find_ldb_val(ac->msg, "oMObjectClass");
+
+                               if (v == 0) {
+                                       ret = samdb_msg_add_uint(ldb, 
ac->msg, ac->msg, "oMSyntax", syntax->oMSyntax);
+                                       if (ret != LDB_SUCCESS) {
+                                               return ret;
+                                       }
+                               }
+                               if (!val) {
+                                       struct ldb_val val2 = 
ldb_val_dup(ldb, &syntax->oMObjectClass);
+                                       if (val2.length > 0) {
+                                               ret = 
ldb_msg_add_value(ac->msg, "oMObjectClass", &val2, NULL);
+                                               if (ret != LDB_SUCCESS) {
+                                                       return ret;
+                                               }
+                                       }
+                               }
+                       }
+               }
+


Which add oMObjectClass (if bug free).
> BTW I've overcome the name collision by applying the following ldif:
> dn: CN=DHCP-Class,CN=Schema,CN=Configuration,DC=kzsdabas,DC=hu
> changetype: modify
> replace: lDAPDisplayName
> lDAPDisplayName: msdHCPClass
>
> dn: CN=dhcp-Options,CN=Schema,CN=Configuration,DC=kzsdabas,DC=hu
> changetype: modify
> replace: lDAPDisplayName
> lDAPDisplayName: msdhcpOptions
Ok that's not a bad solution in fact as it's always possible to back to 
the MS solution by renaming the ISC DHCP solution, still it would be 
perfect if they starts to change the schema names so that it didn't collide.
> It probably makes MS DHCP Servers useless in the Domain, but I do not
> intend to have any MS servers anyway.
>
Matthieu.

-- 
Matthieu Patou
Samba Team
http://samba.org



More information about the samba-technical mailing list