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.
Am Donnerstag 11 Dezember 2008 16:39:24 schrieb Andrzej Jan Taramina:
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.
But is very time consuming and resource intensive. E.g. checking for the presence of an AttributeType requires a full scan of the database if that AttributeType is not indexed, I think. Additionally this check would have to be done with the thread pool paused (i.e. no other operation would be processed) or at least with every database set into read only mode, to avoid races. I am not even sure if it would be possilbe with all backends types that we currently support (think of back-ldap or back-meta).
A blanket refusal to do such a delete is inappropriate, IMO.
But the safest option we can currently offer, IMO.
[..]
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:
- 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?
I should work I think.
Seems to me that the whole alternate configuration approach using cn=config in the database is still very much a work in progress.
I'd say it works pretty well already in most cases. And yes of course things can always be improved. Help with that is always welcome, BTW.
Ralf Haferkamp writes:
Am Donnerstag 11 Dezember 2008 16:39:24 schrieb Andrzej Jan Taramina:
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.
But is very time consuming and resource intensive. E.g. checking for the presence of an AttributeType requires a full scan of the database if that AttributeType is not indexed, I think.
An index would be insufficient for such a check, because a schema element can be part of an attribute value. The DN and "Name and Optional UID" syntaxes contain attribute types. Guide/Enhanced Guide contain object classes (as does objectClass itself of course). OID contains either.
The schema attributes themselves must be checked, and inheritance. Also configuration, both config known to slapd like access control and that known to modules like the attributes restricted by the "unique" overlay.
Or much of the latter could be dropped, in favor of a reference count or garbage collection. But either way, modules must provide a way to ask them if they are using a schema element.
A blanket refusal to do such a delete is inappropriate, IMO.
But the safest option we can currently offer, IMO.
Could add a "trust me, I know what I'm doing" control. slapd only accepts potentially fatal cn=config changes if that control is set.
openldap-software@openldap.org
-
Andrzej Jan Taramina -
Hallvard B Furuseth -
Ralf Haferkamp