> On Tue, Mar 10, 2009 at 01:33:00PM -0400, Wesley Craig wrote: >> On 10 Mar 2009, at 08:51, Michael Menge wrote: >> > I think i should rephrase my question. >> > >> > Is there a way for cyrus to know that it was updated >> > since the last time it did run, so it can do the things >> > suggested by Bron. >> >> Perhaps we should add a config option with no default whose value >> must be the version of the software you're running. > > Hmmm.... v2.3.13-fmsvn18309-5c1c69c4 ;) It makes inplace updates > a cow, since cyrus detects the new file and automatically closes > old processes and starts new ones. Pretty tricky. > > Though a configuration with no default that said "running Cyrus 2.3 > series" would be reasonable. > > Actually, I think at this point I would recommend releasing > Cyrus 2.4 based on our current stable plus this change, and > require a config variable that said "I'm running Cyrus 2.4". > > At this point I would also recommend revisiting EVERY config > option and making the default be the best value (in our humble > opinions) rather than the backwards compatible one. I have > written about this before - and I think it's a jump we should > take pretty soon, to get all new users using the best possible > options without having to maintain a giant config file. As a package maintainer I would be happy to see some more advanced options being the default. My rpms have different defaults but that requires patching not only the options file but also the docs to reflect the changes. Unfortunately it can still lead to confusion if people "forget" to read the manpage and other docs. About the config variable discussed above: Since my rpms do quite some magick to make upgrades work without any user intervention, I had this problem for a long time. One should keep in mind that having old config files is one thing, the other thing are old configdir/spooldirs. My solution for the latter was to maintain a db config file in the rpm package, and maintain another db config file in the configdir. That way the init script evaulates the two db configs and the imapd config, it they don't match it takes any action it needs and then writes the new config to the configdir. That way you can also transfer a configdir/spooldir from another server with different cyrus-imapd version to the current server and things will still work correctly. Or you can change imapd.conf and the changes will take effect on the configdir on startup. At the moment the db config includes the db version and the sieve version like this: annotation_db=skiplist duplicate_db=skiplist mboxkey_db=skiplist mboxlist_db=skiplist ptscache_db=skiplist quota_db=quotalegacy seenstate_db=skiplist sieve_version=2.2.3 statuscache_db=skiplist subscription_db=flat tlscache_db=skiplist My question is how can all this be implemented in cyrus-imapd without too many changes. What about having a function to read all current setting (something like postconf does in postfix) and have cyrus-imapd maintain a copy of this in the configdir? That way cyrus-imapd or the init script could check whether both configs match enough and they action or refuse to start if they don't match. The config file should not only include configurable options but also internal options like what I did with the sieve_version to reflect internal changes. Cyrus-imapd does handles a lot of those changes on the fly but not all, live upgrading sieve scripts, and those should be found in the configs. 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
