Buchan Milne wrote:
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.
SHOULD NOT or MUST NOT (in spirit of RFC 2119)?
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.
Would be a possible option too.
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.
The question is whether a change in the dynamic configuration justifies
requiring the use of slapcat/manual edit/slapadd. The main aim for
deploying back-config is to minimize down time, isn't it?