Re: Question about upgrading and mismatched backends
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 versions. I'm not aware of any mupdate changes that would cause breakage between versions. 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. Thanks, Dave -- Dave McMurtrie, SPE Email Systems Team Leader Carnegie Mellon University, Computing Services 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
Re: Question about upgrading and mismatched backends
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 versions. I'm not aware of any mupdate changes that would cause breakage between versions. 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: cyrus-md5uuid-2.3.8 imapd-disable-referrals unified-murder-xfer-fix 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. Tim 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
Re: Question about upgrading and mismatched backends
On Wed, Apr 15, 2009 at 09:43:26AM -0400, Tim Champ wrote: 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 versions. I'm not aware of any mupdate changes that would cause breakage between versions. 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: Sorry I didn't get back to you today - I completely forgot about it! Yes - most of them are upstream. The naming has changed now that they are absorbed into git - but the commit messages are pretty close to what I had as the patch headers. What's on the webpage now is what we applied against 2.3.14 - a couple of them have gone into CVS, and I don't (yet) have a nice way to give a patch list against 2.3.14 that's also 100% up-to-date. Maybe create a divergent branch and have a CVS bits patch at the top of the list always cyrus-md5uuid-2.3.8 You don't want that any more - it's been replaced by sha1 GUIDs. imapd-disable-referrals Not us. unified-murder-xfer-fix Not us. 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. It will only sha1 new GUIDs. The old md5 UUID will be placed at the start of the space, so it will look like 02xx00 (excuse my inaccurate counting, I don't care that much ;) Something like that. They all start with 02 and end with a big block of zeros anyway. Bron. 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
