[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Issue when injecting a new AttributeTypes in OpenLdap



On 4/12/11 11:19 PM, Howard Chu wrote:
Emmanuel LÃcharny wrote:
On 4/12/11 8:52 PM, Howard Chu wrote:

Not a piece of cake !
As Hallvard said, OpenLDAP already supports dynamic schema changes,
and changes take effect immediately without any restart required. And,
as noted, throwing all dynamic changes into a single cn=subschema
subentry (or 99user.ldif as some other servers do) is messy.
I prefer to keep things well organized, with related schema elements
all in their own entry. This makes schema development and management a
lot easier and understandable, particularly when you're wondering what
schema element came from where.
We do allow modification in both cn=schema (cn=subschema in OpenLDAP)
and in ou=schema (cn=schema,cn=config in OpenLDAP) in ApacheDS, and
whether you modify one or the other, both are impacted.

Considering that the cn=(sub)schema is just a virtual DiT (ie, it's
built on the fly when a user request it), it's should not be a real
problem to update it.

What kind of problem can you foresee, Howard ?

Performing an update is not the problem. Funneling updates of cn=subschema into meaningful branches of the schema tree is the problem.
Got it.

We have a workaround for that : each schema is stored in it's own sub-entry, with each schema element in a dedicated sub-entry :

ou=schema
  cn=core
    ou=attributeTypes
      m-oid=2.5.4.4 (sn)
      ...
    ou=objectClasses
    ...
  cn=system
  ...

With such a structure, the mapping is straightforward (note that we added a x-schema extension in the schema elements to retrieve the schema they will be stored in). Now, for every newly added schema element, as we can't require this x-schema to be present (otherwise it would not be portable), they will be added to a special schema file, named 'other'.

wdyt ?

--
Regards,
Cordialement,
Emmanuel LÃcharny
www.iktek.com