[Citadel Development] Re: Config System
Looks like it's reverted. I hope I got that right.
[Citadel Development] Re: Config System
OOPS I seem to have accidentally merged the configdb into git master. I will attempt to revert that!!!
[Citadel Development] Re: Config System
Ok, the new config system is done, and it seems to work. I was able to migrate-in-place a citadel.config to the new config database, with no problems. citadel.control gets folded in next.
[Citadel Development] Re: Config System
That's an implementation detail (and a correct one) -- the point is that it no longer happens inside Citadel itself.
[Citadel Development] Re: Config System
the -u should be fetched from /etc/defaults/citadel from the startup scripts. The startup script itself should be static.
[Citadel Development] Re: Config System
Here's what I'm leaning towards now ... * If there is a "citadel" user, use that as default * Otherwise, citserver will expect either the -r (run as root) or the new -u (run as user...) options to be present * Startup scripts implementing the -u option shall be written by setup scripts.
[Citadel Development] Re: Config System
or - other idea, stat some db file, and pick the uid from that, and just have it specify once at start?
[Citadel Development] Re: Config System
yes - and since thats a very special case, make it a commandline option. Citadel will work for most who do easy install, .deb, .rpm or ebuild. And if it doesn't, they need to edit their init scripts.
[Citadel Development] Re: Config System
The username won't *always* be "citadel" ... most of the time it will, but not always. (On a lot of sites, including mine, it's "bbs")
[Citadel Development] Re: Config System
hm, so you have to create the db files as root and chown them? Regarding the uid, if not commandline, doing getpwnam of the user citadel to get the uid sounds clever to me - since that should be the default, and like -h the others are very special cases...
[Citadel Development] Re: Config System
So it seems that the only configuration variable that's really giving us a chicken-and-egg problem is 2config.c_ctdluid, which specifies the uid under which Citadel server should run (after it's done binding to low numbered sockets and things like that). I wonder if it would make sense to simply make that a command line switch.
[Citadel Development] Re: Config System
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
