Michael Ströder wrote:
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?
Yes, I agree 100%. Any changes to cn=config MUST NOT result in any manual intervention (except at the moment creating a new driectory i.e. it must exist on the file system first).
The will always be a manual step needed in backups like Howard discussed further up the thread.