Notice the lessons in the "chicken and egg" problem you mention above have been considered before in database-ish systems config.
Mysql/Mariadb) as well as ldap servers 'slapd' have config files that contain only the minimum of items necessary to connect to the (currently local only) database, leaving the bulk of config items in the database. Some have struggled mightily to retain backward compatibility by implementing both, reading the legacy first then allowing it to be overwritten by the in-db stuff.
The much debated Windows system has an example of retaining configuration tables, currently also implemented in Citadel in the aptly named "system configuration" message. More or less under the theme: "last known good". It's a good idea already half implemented in Citadel. Citadel actually has the same concept of saving previous configs items, stored right now in the database:
Notice line 164 in serv_expire.c:
/* Don't purge messages containing system configuration, dumbass. */
That was written because old system config messages were retained (but as yet not offered as backups if the 'latest and greatest' fails to start).
So, ah, you know, while you're at it, let's have the "system configuration stored as message" notion get merged into this "all config items in one place" thinking.
I ask that you look at each item in the config, to decide which ought to be 'the same' across any version of citadel serving the same userbase, and which are specific to the local instance (directory for the datafiles, etc). Consider storing the config item data element's retrieval to use a key that includes the instance named in the local config file for all local-only settings, with the 'userbase global' settings using a zero length string as the key.
Last, consider creating a read-only "distro specific default config" which is written into the "active config" when it's empty or corrupt.
-HC
