Howard replied:
This was just discussed on -technical as well. You can delete
individual
schema elements using ldapmodify. You cannot delete entire cn=config
entries
(using ldapdelete). There are no plans to change this behavior for
schema in
the future.
Using ldapmodify for individual entries is painful in the extreme, since each
entry only has a single
attribute...basically a monster string with all the schema constraints in it.
> > What about any entries that depend on the schema? Will they be
affected...
The answer is "it depends"...
Depends on what? I would really like to know what OpenLDAP does internally by
way of linking entries back to their
schema definitions, and when such linkages are used.
In general, once you start using a schema, you're stuck with it.
(Which is one
reason why ldapdelete for schema entries will never be implemented.)
That makes no sense. Checking to see if there are entries that depend on the
schema before attempting the delete and
declining the delete if there are such entries makes sense. A blanket refusal
to do such a delete is inappropriate, IMO.
You can
fine tune individual elements of it (alter definitions, add/remove
definitions), but there are issues that are still being worked on.
See ITS#5540 for one of the problems still in progress.
Not receiving any practical tips on how to update a whole private schema in one
fell swoop, here's what I did and what
seemed to work fine:
1) Delete all entries that depend on the schema you need to updated (used
ldapmodify)
2) Shut down slapd
3) sudo rm /etc/ldap/slapd.d/cn=config/cn=schema/cn={4}myschema.ldif. Change
the last part to refer to your custom
schema. I'm using latest Ubuntu Intrepid OpenLDAP, so the location of the
cn=config dir may be different for you.
4) Restart slapd
5) Use ldapadd to add your modified schema
6) Use ldapadd to re-add your schema entries.
This worked well for me, since I have entry deletion/creation ldif declarations
that are automatically generated by our
application....no problems detected so far.
Anyone see any issues with this approach?
Seems to me that the whole alternate configuration approach using cn=config in
the database is still very much a work in
progress.
--
Andrzej Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com
