Question about upgrading and mismatched backends
champ at umbc.edu
Wed Apr 15 09:43:26 EDT 2009
Dave McMurtrie wrote:
> Tim Champ wrote:
>> Hello all. My first time to post, I only recently joined the list. I'm
>> digging in deeply on an inherited cyrus install, and looking to upgrade.
>> My goal is to put a new backend server in place for our setup. Our
>> basic setup is 3 front-ends, 4 back-ends and a mupdate server.
>> I'm looking to add a back-end for multiple reasons, but I would like to
>> set it up with cyrus 2.3.14 to kill two birds with one stone. I realize
>> some additional options for the config file now exist, with delayed
>> delete for folders (which we're looking forward to) and others.
> Hi Tim,
> You don't mention what version the other members of your murder are running.
> There was a change to the sieve protocol wrt how it doles out a
> capability response. 2.3.14 should work with old or new sieve clients,
> so that shouldn't be a problem.
> I'm not aware of any lmtp changes that would cause breakage between
> I'm not aware of any mupdate changes that would cause breakage between
> Ken mentioned to me that there may have been some changes to how XFER
> works (moving mailboxes between backend servers), but he couldn't
> remember details off the top of his head. Even if he did, we'd need to
> know which versions your other nodes are running.
Completely thought it, and didn't type it! Sorry! The current version
of all parts is 2.3.8 with some patches from fastmail applied. Also, we
have the patch for the sieve xfer bug that existed in that version.
I've read through each of the fastmail patches, and most appear
integrated into the current releases of Cyrus. The only ones of note
that I was unsure of are named:
I don't know how much this helps anyone to have the names, but I wanted
to throw them out there. The md5uuid one did a lot of changes in order
to deal with these, but I don't see (yet) how they were integrated into
the current releases. I also don't see this patch currently from
fastmail. I did see that SHA1 is now the preferred way of deal with
this, but I wanted to confirm the backward compatibility if possible.
That "xfer" fix above did only minimal changes, but I didn't see them
directly in the code. I was unsure if this was somehow re-worked to
make that patch un-needed. It only appears to have done changes to
mboxlist.c to "allow localcreate to go through if we're creating the
mailbox locally and it currently exists on a remote server to facilitate
mailbox moves" as the comment says in the patch.
Hope that info helps, thanks for the fast response and help. If more
info is needed, please let me know.
More information about the Info-cyrus