competition

[Jeffrey T Eaton]

On Sep 22, 2010, at 1:50 AM, Simon Matter wrote:

>> 
>>> Debian is still stuck on 2.2 and there seems to be no progress in that
>>> area.
>>> 
>>> The main problem they apparently have, is the migration path for the
>>> various
>>> DB files from 2.2 to 2.3.
>>> (The 2.3 version itself works fine as .deb packages)
>> 
>> What "migration path"?  Cyrus 2.3 supports all of the same database
>> backends that Cyrus 2.2 did.
> 
> I don't know the Debian packages well but from a quick look I did long
> time ago it seems like those packages leave quite some work to do by the
> user of the packages. That also means there are more ways for a user to
> break things which may stop them making the 2.3 packages go in easily.
> 
>> 
>> To the best of my knowledge, you can drop in Cyrus 2.3 binaries, and
>> with the same config files as 2.2 used, everything will just work.
>> You can't easily go back, because I believe that 2.3 will update
>> cyrus.index files to a format which 2.2 doesn't recognize, but that
>> shouldn't prevent anyone from upgrading.
> 
> IIRC it's a little bit more complicated. Beside BDB, there are also some
> steps to do at upgrade, like compiling sieve scripts, possibly converting
> its encoding.

To the best of my knowledge, the complied Sieve format has not changed since 2.2.  

> With BDB backends you have to make sure everything fits
> correctly. Binaries need to be linked against the correct version of BDB
> and also the on disk BDB files need to be of the same version. Now, think
> you want to do a distribution upgrade which comes with the latest greatest
> BDB release and new Cyrus binaries which are using them, but your spool is
> still on the old release... We all know how this ends.

This would be a problem anytime you upgrade BDB, independent of the version of Cyrus.  If you are rolling out a new distribution  with a new version of BDB, you will need to address this problem even if you don't upgrade Cyrus.  (Unless of course, you continue to ship a Cyrus built against the _old_ BDB, in which case the argument is irrelevant).

> The only solution - you can call it dirty workaround - I found for our
> RedHat EL RPMs was to convert all BDB databases to skiplist on Cyrus
> shutdown and convert them back on startup. That way the spool is always in
> a state which can be migrated once Cyrus is shutdown.
> Of course getting rid of any BDB in the default configuration of the RPM
> binaries has helped much to prevent BDB mess.


All of that said, I believe that, in general, you can safely upgrade BDB.  If you have a Cyrus installation using BDB X, you can drop in a new Cyrus using BDB Y, as long as everything is shut down in between.  You can't go back without effort, but upgrades should work.

And, as Bron has said, there's something wrong with the way Cyrus uses BDB.  I've never been able to understand BDB well enough to figure it out myself, nor have I ever found anyone who can help.  For what its worth, I solved the problem by not using BDB at all on the Cyrus systems I used.

-jeaton