[Fedora-directory-devel] Samba4 onto Fedora DS

[Pete Rowley]

Andrew Bartlett wrote:

>On Tue, 2006-08-22 at 10:03 -0700, Pete Rowley wrote:
>  
>
>>It would be bad form to remove a standard attribute and replace it with 
>>one of the same name  but different OID.  It would be better to use the 
>>standard attribute.
>>    
>>
>
>What would go wrong if I did that?  
>
>  
>
Those rare clients that actually did the right thing and checked schema 
would break. Clients that request by OID would also break. These are 
admittedly few and far between but it seems a shame to punish those who 
do the right thing. It would technically make the server non-LDAP 
standards compliant, and that's actually a big deal even if nothing breaks.

>When I started with OpenLDAP, I initially tried to load standard schema,
>then Microsoft's modifications, but very quickly got into a mess:
>Because I wanted a reproducible solution, I didn't want to edit these
>schema files, but they declared objectClasses that I had to override.  
>  
>
I do understand your pain. The MS schema that is derived from the 
standards is actually not compliant to them - MS made some modifications.

>So I ended up just using the converted AD schema.
>  
>
This is OK to get by for now, but I would strongly suggest an approach 
that is more accomodating to the standards and also existing deployments 
- few major deployers will want to change the standard schema.

>Would it be possible to split the 00core.ldif into 'attributes required
>for the operation of the directory' and 'core ldap standards'?
>
Sure, all of the schema files are just split as a matter of convenience 
and managability.

>  What
>will happen if I fail to load the 'attributes required for operation of
>the directory'?
>  
>
The directory won't operate? :)


-- 
Pete

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3241 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-directory-devel/attachments/20060822/f80b2331/attachment.bin>