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?
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.
Ciao, Michael.