Samba4 loading schema.ldif

Gémes Géza geza at
Mon Apr 23 14:45:03 MDT 2012

Hello Matthieu,
> On 04/23/2012 12:00 PM, Gémes Géza wrote:
>> Hello Mat,
>>>> Hello Geza,
>>>>>>> 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. Looking at the
>>>>>>> modified
>>>>>>> schema ldb it seems, that it still misses the oMObjectClass
>>>>>>> attributes.
>>>>>>> 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
>>>>>>> It probably makes MS DHCP Servers useless in the Domain, but I
>>>>>>> do not
>>>>>>> intend to have any MS servers anyway.
>>>>>> Does this LDIF work against a Windows server?
>>>>>> If we allow this in samba, we need to make sure that there are
>>>>>> no instances of this classes and attributes in the directory,
>>>>>> otherwise we'll get corruption.
>>>>>> metze
>>>>> Hi,
>>>>> Before I would propose any inclusion or recommendation I'm going to
>>>>> test
>>>>> it against a Windows 2008 R2 server.
>>>>> BTW. I'm not really sure that this rename is needed at all,
>>>>> because ISC
>>>>> DHCP is looking for the cn attribute, and not the lDAPDisplayName.
>>>> But that's not that simple, you can't have two attributes with the
>>>> same ldapdisplayname, I'm really unsure that ISC is using just CN.
>>>> When it creates and fetch object from the dhcp* classes it will check
>>>> for attributes and those attributes have the ldapdisplayname of the
>>>> schemaAttributes.
>>>> That means that the ldapdisplayname is really important, more
>>>> important than the CN in fact.
>>>> My patches are at:
>>>> It's not rebased on the latest version of master, I'll try to do it
>>>> soon.
>>> I really confirm that my setup with master
>>> (5b5b696c1e36dc7f81da24158e0853290084dec8) is really working (once I
>>> rename the two ldapdisplayname of MS attributes):
>>> ./bin/ldbmodify -H ldap:// -U administrator%totoTATA123
>>> ~/dhcp3.ldif
>>> Modified 76 records successfully
>>> After loading the schema, I can search the database not only the
>>> schema is not toasted but newly created classes are here.
>>> ./bin/ldbsearch -H ldap:// -U administrator%totoTATA123
>>> --cross-ncs '(ldapdisplayname=dhcppo*)' dn
>>> # record 1
>>> dn: CN=dhcpPool6,CN=Schema,CN=Configuration,DC=home,DC=matws,DC=net
>>> # record 2
>>> dn: CN=dhcpPoolDN,CN=Schema,CN=Configuration,DC=home,DC=matws,DC=net
>>> # record 3
>>> dn: CN=dhcpPool,CN=Schema,CN=Configuration,DC=home,DC=matws,DC=net
>>> I didn't try to do anything useful but I expect this to work.
>>> Matthieu.
>> Thank you for the hard work you we put into this.
>> Could you tell me when will your patches be merged to master, or which
>> one (981fe20523dd9c0bffa4ffb6037e690b8947b6d6 and
>> b5649e6d0f50ec253e20e86fed9fd506716c4209 maybe?) of your unmerged
>> patches should I try out.
> Well first as I said it works well with master for me so maybe there
> is something wrong for you, can you retry with a fresh provision just
> to see.
> Then you'd better off trying the whole branch as I don't think patches
> will apply very well.
> Matthieu.
Will try it with a fresh provision (I was and still am on master (used
to rebuild in the evening)) (was on an upgraded samba3). But before that
I try to fix oLschema2ldif.



More information about the samba-technical mailing list