[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Schema update using back-config

Pierangelo Masarati wrote:

> I'm not sure I understand the question. For the specific case of
> items moving from core.schema into the code, we would ship a new
> schema file and discard the old one, just as we do now. Since the
> server needs to be restarted for the new schema_prep code to take
> effect anyway, the old schema file can simply be replaced.

 It is my understanding that as soon as you store back-config data
 into the underlying database, the slapd.conf is no longer used.  So
 the only way to have the new schema files parsed in is remove the
 underlying (back-ldif) database and start from scratch, but I'm
 afraid this would not preserve changes occured via protocol.  Or am I
 missing something?

> I suppose we should be prepared to start distributing LDIF schema
> files. But regardless, I see this as an offline / manual update
> process; you can just edit the back-ldif files directly or replace
> them with new copies.

 This is an option; I considered that, although it might be error
 prone as the underlying database should be mainly accessed via API
 and not manually (and it could eventually become a back-bdb, and I
 envisage sci-fi scenarios where back-config is using back-ldap for
 remote storage of the configuration...;)

Part of the motivation in creating back-ldif was to provide a data store that is human-readable and editable. So for the time being, manual editing is the method I would recommend. In the future I suppose we could either add an Overwrite flag to slapadd, and allow objects to be replaced that way, or write some version of a slapmodify command.

 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support