Re: Deleting overlays from cn=config

[Buchan Milne <bgmilne@staff.telkomsa.net>]

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