And, although my convertd isn't starting, everything else passed my tests and I released it to production around 1500 EST Sunday.
Hot spots:
0) If you need --platform-override, don't forget that you do.
1) For some reason, the libphp5.so that comes in the packaged apache won't run properly on CentOS; replacing it with the stock lib from the distribution (which is 3MB instead of the 15MB of the one that comes with Zimbra, interestingly), fixes the problem, but the problem *happens* after the upgrade install.sh has called zmsetup.pl, so you have to rerun *only* zmsetup manually after fixing it. (This is an SELinux interaction on distros that install it; see the next comment on this thread.)
2) If your upgrade breaks, you may have trouble with it finding a valid LDAP configuration -- which it will *call* a "Valid backup". Don't be fooled. ;-)
3) The release notes will remind you that it's a good idea to do a dist-upgrade before you start the Zimbra upgrade. In fact, you can do it after; I did, and it proved to solve at least one problem which I can only describe as "everything's whacky". :-)
4) I did find that I had to run postfix's "postmap transport" by hand; the symptom is that when you try to hand-telnet to 25 and send a test message, MAIL FROM: will elicit no status reply at all.
5) Backups are good. I had a pair of 500GB RAID1 partitions on this mail server, on a mirrored pair of Seagate 1TB SATA drives. One had my (265GB!) Z5 install on it, and the other one was empty.
I used
rsync -avzH -e ssh --progress /appl/store1/zimbra518/ /appl/store2/zimbra603 to live-copy one to the other (which took over 90 minutes *just to set up* -- 7 million files or so -- and another 8 to 10 hours to run on the first pass; the second pass, after final shutdown on 5.0.18 took the same 90 to setup, but then about 90 more minutes to finish the cleanup copies).
My "/opt/zimbra" was a symlink to "/appl/store1/zimbra5018"; once my copy was done and I was ready to upgrade, I renamed that to /opt/zimbra5, and made a new /opt/zimbra symlink that pointed to /appl/store2/zimbra602.
At that point, *any time in the upgrade cycle*, my backout procedure consisted of...
1) Change the symlink back
2) Start Zimbra
That's my idea of a clean, fast backout, and easily justifies the time spent setting up for it -- especially since rsync allows you to do the *big* copy while still online; thanks to whomever noted that on the wiki whence I stole it. [ Late update: that's an AJCody trick; he has *lots* of good inside tricks on the wiki; go look. ]
When I had to dist-upgrade, I made an image to our fileserver using clonezilla (which, if you don't know about it, go find out. Now. I'll wait), and if for some reason, I had to back out after that and *5.0* wouldn't run post-OS-upgrade, I could then back out the OS upgrade as well. That was made easier because on this server, everything was on the root filesystem; multiple filesystems make it a touch more complicated... but
having your entire Zimbra install over on it's own filesystem makes everything So Much Easier.
The only backout that I can *not* easily manage is "after it's been running for a few days", and as has been discussed before, that's very difficult to accomplish in any case: you could tee-off incoming mail to a spool for replay, but getting into the right place in the pipeline for intra-domain messages is much more difficult -- and they wouldn't appear in people's sent folders anyway. [ Late addition: for more, see (and vote for :-)
Bug 43741 – RFE: Add 'replay' teeing facility to extend back-out support ]
But, as is our slogan here at work, "it is what it is". I'm not big enough to have a test machine, and it's very difficult to acceptance test anything as complicated as Zimbra anyway.
So far, so good; no one's complained, and it seems a bit faster running ZWC, too.
Bugzilla
Wiki
Source
Linear Mode
