On Friday 06 June 2008 18:58:11 Michael Ströder wrote:
Francis Swasey wrote:
On 6/5/08 11:50 AM, Michael Ströder wrote:
Howard Chu wrote:
Hallvard B Furuseth wrote:
You also need to walk through the database and delete any attributes object classes defined by the overlay.
IMHO, configuration changes should not result in changes to data.
That'll be at least any operational attributes since they must be hardcoded into the C source.
I wouldn't bother with that, since the schema definitions are still present. Those attributes would simply stop being updated/generated...
Hmm, I'd consider this to be seriously flawed. It strikes me that there might still exist operational attributes in some entries which are no longer maintained by the DSA and there's no schema information available anymore.
Think of backup/restore situations where slapadd checks the schema...
How is that different from pre-cn=config setups where the administrator shut down slapd and removed the schema from the slapd.conf and restarted slapd?
It's the same administrative responsibility to remove the use of the schema (and the attributes in the database) before removing the schema definition.
Yes, it has the same administrative consequences. But using cn=config makes the admins think that everything happens automagically. I foresee question on the mailing lists concerning this.
IMHO, the cleanest would be for any configuration change which would remove schema definitions should do a search for the use of those schema definitions, and fail with a suitable message if any of the schema definitions are in use.
Then the administrator: 1)Is aware of what changes need to occur before the configuration change can be made 2)Will not unknowingly remove data
An intelligent DUA should be able to prompt the administrator to delete the relevant data first, and effect the required changes to the data, before applying the configuration change.
The problem though is that at present some data (whose attribute definitions are marked as "NO-USER-MODIFICATION") cannot presently be removed. ppolicy attributes (pwdAccountLockedTime etc.) come to mind.
Regards, Buchan