> On Thu, Mar 12, 2009 at 02:04:17PM +0100, Simon Matter wrote: >> > Yep, definitely. Store them all, and refuse to start unless: >> > cyr_conf -C $oldfile is the same output as cyr_conf with the >> > -C option passed to 'master'. Spit out an error message >> > describing what's different and how to fix it. >> >> Hi Bron, >> >> cyr_conf sounds good :) >> >> For the "refuse to start", do you think it should be integrated into >> master or being kept in the init script? > > Init scripts. All this "config manglement" is supporting infrastructure, > not core operations. The init script would do all the initial config > setup into $configdir, and launch master with that config file and a > cyrus.conf as well. Very good, that's how I prefer it. > >> What would be very cool is a detect feature which detects things like >> database config from the configdir. That way it could also override >> configuration settings from the config files on startup and log about >> it. >> It sounds a bit dangerous, what do you think? > > Quite doable. It could probably just use "file" to figure out what sort > of database file was in use. Skiplist is certainly magic-checkable (the > first 20 bytes contain all the details), and I imagine BDB is similar. > > I'm _not_ so sure about berkeley-hash vs berkeley-btree, and I am pretty > certain it can't auto-detect berkeley-nosync or skiplist-unsafe! > > I'd rather have it detect the wrong type and abort than detect and log > on startup. This is a daemon that deals with files that people care > about, after all! OK, my point is that I have to care about upgrades of a whole distribution or people who move mailspool to a newer box. To make the spool portable the init scripts convert all BDB databases to skiplist. At startup it first converts all databases back to the configured version and then fires master. That way you can move a mailspool which is using an old BDB version to a newer box without requiring support for the old BDB on the new box. It all started as a dirty hack but seems to work quite well for a long time now. With the help of cyr_conf I'll be able to improve the mechanism and make things a bit more clean. Thanks for looking into it, it will be of great help. Regards, Simon ---- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
