[Dovecot] Dovecot 1.2/2.0 coexistence guide?
I am running Dovecot 1.2.16 and considering moving up to 2.0.8. I have found http://wiki2.dovecot.org/Upgrading/2.0 but there's not a lot about deploying a 2.0 server alongside an existing 1.2. Any hints on a seamless approach to this, especially one that might allow me to upgrade individual users in place, without moving their maildirs into a new tree and still avoid issues with 1.2/2.0 sharing access?
- Tom Talpey tmtalpey@gmail.com:
I am running Dovecot 1.2.16 and considering moving up to 2.0.8. I have found http://wiki2.dovecot.org/Upgrading/2.0 but there's not a lot about deploying a 2.0 server alongside an existing 1.2. Any hints on a seamless approach to this, especially one that might allow me to upgrade individual users in place, without moving their maildirs into a new tree and still avoid issues with 1.2/2.0 sharing access? I'm switching back and forth between 1.2 and 2.0. No need to worry.
-- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebrandt@charite.de | http://www.charite.de
Ralf Hildebrandt wrote:
- Tom Talpey tmtalpey@gmail.com:
Any hints on a seamless approach to this, especially one that might allow me to upgrade individual users in place, without moving their maildirs into a new tree and still avoid issues with 1.2/2.0 sharing access? I'm switching back and forth between 1.2 and 2.0. No need to worry.
Ralf, on the same server machines - ie, switch off 1.2, start 2.0, or on different servers, one running 1.2, another running 2.0?
And, in your case, where are the user maildirs? On the same machines as the servers? Somewhere else?
thanks, Ron
- Ron Leach ronleach@tesco.net:
Ralf Hildebrandt wrote:
- Tom Talpey tmtalpey@gmail.com:
Any hints on a seamless approach to this, especially one that might allow me to upgrade individual users in place, without moving their maildirs into a new tree and still avoid issues with 1.2/2.0 sharing access? I'm switching back and forth between 1.2 and 2.0. No need to worry.
Ralf, on the same server machines - ie, switch off 1.2, start 2.0, or on different servers, one running 1.2, another running 2.0?
Of course on the same machine.
And, in your case, where are the user maildirs? On the same machines as the servers? Somewhere else?
In my case on the same machine, but since both 2.0 and 1.2 use the same setup, how does that matter?
-- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebrandt@charite.de | http://www.charite.de
Ralf Hildebrandt wrote:
- Ron Leach ronleach@tesco.net:
Ralf Hildebrandt wrote:
I'm switching back and forth between 1.2 and 2.0. No need to worry.
Ralf, on the same server machines - ie, switch off 1.2, start 2.0, or on different servers, one running 1.2, another running 2.0?
Of course on the same machine.
Fair enough. I was thinking of using 2.0 as a 'new system' during a general migration to both: (a) new server hardware, and (b) updated OS - not wanting to upgrade the OS in-situ with critical applications running
And, in your case, where are the user maildirs? On the same machines as the servers? Somewhere else?
In my case on the same machine, but since both 2.0 and 1.2 use the same setup, how does that matter?
I wouldn't start to guess - I know relatively little. But I was interested in your experience, and opinion; it's clear from many of your contributions that you're running some serious systems, and just thought to ask.
In essence, just trying to see if the co-existence principles, that the OP was thinking about, would help or hinder in the more general problems of migration of architecture, especially if the dovecot server were to be migrated elsewhere while leaving the maildirs 'where they were' and able to drop back to v1 in case of problems.
(Migration to different system arrangements is really a topic in itself, and I don't want to hijack this thread, just explaining what I was thinking around.)
Thanks for the reply, Ron
- Ron Leach ronleach@tesco.net:
In essence, just trying to see if the co-existence principles, that the OP was thinking about, would help or hinder in the more general problems of migration of architecture, especially if the dovecot server were to be migrated elsewhere while leaving the maildirs 'where they were' and able to drop back to v1 in case of problems.
That's another option, yep. So far I'm using 2.0 for stuff like expunging old crap from the users' mailboxes (doveadm expunge is such a cool tool)
-- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebrandt@charite.de | http://www.charite.de
On 5.12.2010, at 16.40, Tom Talpey wrote:
I am running Dovecot 1.2.16 and considering moving up to 2.0.8. I have found http://wiki2.dovecot.org/Upgrading/2.0 but there's not a lot about deploying a 2.0 server alongside an existing 1.2. Any hints on a seamless approach to this, especially one that might allow me to upgrade individual users in place, without moving their maildirs into a new tree and still avoid issues with 1.2/2.0 sharing access?
Added to wiki: Once running v2.0, it's safe to downgrade to v1.2.5 or newer. Older versions don't understand some of the changes to index files and will log errors.
It's also safe to run v1.2 and v2.0 in parallel, even accessing the same index files.
On 12/5/2010 2:25 PM, Timo Sirainen wrote:
On 5.12.2010, at 16.40, Tom Talpey wrote:
I am running Dovecot 1.2.16 and considering moving up to 2.0.8. I have foundhttp://wiki2.dovecot.org/Upgrading/2.0 but there's not a lot about deploying a 2.0 server alongside an existing 1.2. Any hints on a seamless approach to this, especially one that might allow me to upgrade individual users in place, without moving their maildirs into a new tree and still avoid issues with 1.2/2.0 sharing access?
Added to wiki: Once running v2.0, it's safe to downgrade to v1.2.5 or newer. Older versions don't understand some of the changes to index files and will log errors.
It's also safe to run v1.2 and v2.0 in parallel, even accessing the same index files.
Thanks. I was hoping to find an easy way to do the latter (run both versions in parallel on the same server), since I want to migrate users individually. It would be important to use the same locking settings right?
It turns out to be rather a challenge to build dovecot 2.0 using independent paths from 1.2, so they can be installed and run alongside one another. Playing with --prefix and --exec-prefix in the 2.0.x configure options comes close, but sharing the runtime directory hierarchy really tripped me up. Then I thought maybe changing the $PACKAGE in configure could point the paths to /usr/lib/dovecot2,/etc/dovecot2 and so on, but that was an even bigger problem (many directories in the build config are apparently hardcoded to "dovecot/".
So, I just installed 2.0.8 on a separate server and deployed a test user or two. With good success, I might add, so I don't foresee any issues. Thanks for your help.
Tom Talpey wrote:
On 12/5/2010 2:25 PM, Timo Sirainen wrote:
It's also safe to run v1.2 and v2.0 in parallel, even accessing the same index files.
So, I just installed 2.0.8 on a separate server and deployed a test user or two.
Out of interest, Tom, (thinking about migrating from v1 to v2 ourselves, as well as migrating the maildirs to new hardware) what did you do next?
Did you leave both servers up (that v2 can co-exist and use the same indexes is quite a promising route for live-migration), and let v2 'look' at the v1 mails? I think this would mean that only Dovecot 2 would need to be reconfigured.
Or did you move the v1 mails across to the v2 server (and if you did that, did you have any problems)? Moving the mails also implies reconfiguring the MTA as well, I think, so this step isn't only a Dovecot reconfiguration issue.
Be interested to hear what you did.
regards, Ron
(copy; apologies, hadn't sent to list)
On 12/9/2010 10:31 AM, Ron Leach wrote:
Tom Talpey wrote:
On 12/5/2010 2:25 PM, Timo Sirainen wrote:
It's also safe to run v1.2 and v2.0 in parallel, even accessing the same index files.
So, I just installed 2.0.8 on a separate server and deployed a test user or two.
Did you leave both servers up (that v2 can co-exist and use the same indexes is quite a promising route for live-migration), and let v2 'look' at the v1 mails? I think this would mean that only Dovecot 2 would need to be reconfigured.
Or did you move the v1 mails across to the v2 server (and if you did that, did you have any problems)? Moving the mails also implies reconfiguring the MTA as well, I think, so this step isn't only a Dovecot reconfiguration issue.
I ended up not trying to deploy both 1.2 and 2.0 dovecot servers on the same machine. Even after mangling the various configure options to let the bin, sbin, lib and libexec directories coexist, the /var and /etc dirs were still an issue, and in the end I didn't want to have all my path settings tweaked, then have to un-tweak them to actually migrate. Also, there's the issue of multiple network listeners so I'd have to mangle ports, too.
I don't have much of an issue with MTA integration because I'm just using fetchmail to perform that. My MTA is just dovecot deliver, and it's easy to redirect it with fetchmailrc and dovecot settings. So I just cloned the victim maildir tree, set "keep" in fetchmail, and tested.
In the end, the testing was so successful that I just cut the server over after a couple of days. Mostly I waited just to be confident that I had all the dovecot.conf settings finalized. The doveconf tool did a pretty good job of it, but there were a few new settings to try, and I had an explicit auth_executable line that didn't carry forward to the new binaries. All were quite straightforward.
- Tom Talpey tmtalpey@gmail.com:
I ended up not trying to deploy both 1.2 and 2.0 dovecot servers on the same machine. Even after mangling the various configure options to let the bin, sbin, lib and libexec directories coexist, the /var and /etc dirs were still an issue, and in the end I didn't want to have all my path settings tweaked, then have to un-tweak them to actually migrate.
Very odd. I simply used
./configure --prefix=/usr/dovecot-2
and that was it.
Of course I had to change some paths in the config, but that was all.
Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebrandt@charite.de | http://www.charite.de
On 12/9/2010 2:10 PM, Ralf Hildebrandt wrote:
- Tom Talpeytmtalpey@gmail.com:
I ended up not trying to deploy both 1.2 and 2.0 dovecot servers on the same machine. Even after mangling the various configure options to let the bin, sbin, lib and libexec directories coexist, the /var and /etc dirs were still an issue, and in the end I didn't want to have all my path settings tweaked, then have to un-tweak them to actually migrate.
Very odd. I simply used
./configure --prefix=/usr/dovecot-2
and that was it.
Of course I had to change some paths in the config, but that was all.
My target system is a NAS appliance and many of its filesystems are not persistent across reboot. Changing only the prefix is not sufficient to make a successful configuration. Unfortunately.
participants (4)
-
Ralf Hildebrandt
-
Ron Leach
-
Timo Sirainen
-
Tom Talpey