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
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
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?
Some operational attributes could be removed with the help of the Relax
Rules extended control. Unfortunately one would also have to specify the
behaviour of this control concerning ppolicy attributes.