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
