Calling all regressions
simon.matter at invoca.ch
Thu Mar 12 18:18:07 EDT 2009
> 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 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
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.
More information about the Info-cyrus