Zimbra 3.1.0 FC3 --> Zimbra 3.1.1 Debian migration advice?

[shankwc]

I've got Zimbra 3.1 running on a 2.1Ghz Celeron with 2G ram with 300 mailboxes/users. They are about 50% web client and the rest are IMAP or POP. It was running very well until i upgraded to 3.1 and it has not been very stable since. frequently the logger process would eat all the CPU cycles. So now I just stop it altogether. Now it will run for almost 3 days at shot (yippie) before one of the processes bombs out and I have to shutdown & restart it.

I've got a shiny new dual Xeon server with 3G ram that I'm dedicating to Zimbra. Can anyone offer any advice as to how to move my users and mailboxes to the new server without bringing over the grief with it?

Thanks in advance.

[jholder]

Assuming you're using the Open Source Edition,
If you follow the backup and restore procedure in the wiki, everything will go smoothly.

http://wiki.zimbra.com/index.php?tit...ckup_Procedure

Make sure that when you restore, that you download the same build that is in the backup.

You can't do an upgrade during the restore process.

Good luck!

[shankwc]

If restore a backup copy of zimbra, won't I just be propagating the error/corruption that is causing my problem? I'm considering dumping the accounts for each domain into a zmprov file and importing them into the new server. Then doing an IMAP sync of each user account. Then switching the MX. I realize users may lose some of their Zimbra Web Client settings. Will I also lose their calendars and address books? How could I manually move those settings?

[shankwc]

Also, does the backup build work across OS versions? I'm using FC3 3.1.0. If I upgrade it to 3.1.1 then backup/restore to Debian 3.1.1 will that be a problem?

[jholder]

Originally Posted by shankwc

If restore a backup copy of zimbra, won't I just be propagating the error/corruption that is causing my problem?

Hi Shankwc,
What kind of problem are you having? Are you talking about the logger?

My experence has been doing a restore can often solve problems by re-creating settings and critical files.

It would be a good idea to migrate, then see if the problem occurs again. If it does, then we'll help you with that.

Originally Posted by shankwc

Also, does the backup build work across OS versions? I'm using FC3 3.1.0. If I upgrade it to 3.1.1 then backup/restore to Debian 3.1.1 will that be a problem?

Nope, shouldn't be a problem.

Good luck!

[shankwc]

The logger is one problem. I've had to just keep it off because it pegs my CPU to 97%. That's been annoying but livable. The real problem I've been having is with stability. Processes spontaneously die for no apparent reason (most often in the middle of the night). frequenty amavis stops (sometimes it's just clamd), other times it's the mailbox and the mta.

I upgraded o 3.1.1 late sat night. I still needed to stop the loggers, but it has been running all day Sun & Mon. Of course with holiday I doubt there were many users, so the rest of the week will be the real test.

Anyone have a fix as to why the logger is such a spaz? I suspect dspam because it was never a problem in 3.0.

[KevinH]

logger is having problems as the log files grow and that database fills. We've got a few bugs open against it and plan to fix those ASAP. If you can narrow down specific problems that would always help.

[shankwc]

Ok here is something I discovered in the last 5 minutes.

I just noticed (Today is Weds) that some of my smtpd recipient settings were lost when I did the 3.1.0 to 3.1.1 upgrade on sat night. Specifically, my whitelist entry was gone and the RBL entries were gone. (what tipped me off was that TLS was not working - I use this Supporting SPA and TLS for SMTP relaying to fix it).

I added the "!" per the forum instructions above (zmmta.cf) and restarted the MTA using zmmtactl start / stop

I then also added these 4 RBLs via the following zmprov command:

zmprov mcf zimbraMtaRestriction reject_invalid_hostname zimbraMtaRestriction reject_non_fqdn_hostname zimbraMtaRestriction reject_non_fqdn_sender zimbraMtaRestriction "reject_rbl_client dnsbl.njabl.org" zimbraMtaRestriction "reject_rbl_client opm.blitzed.org" zimbraMtaRestriction "reject_rbl_client relays.ordb.org" zimbraMtaRestriction "reject_rbl_client cbl.abuseat.org"

At this point I noticed that the server started to respond very slowly and CPU was upwards of 70% with the amavisd processes at the top of my "top" list.

I added my whitelist to postfix_recipient_restrictions.cf (check_sender_access hash:/opt/zimbra/postfix/conf/whitelist) and tried to restart the mta again (it's now noticably slower).

Since I noticed all this stuff happened around the time I was screwing with the postfix settings I decided to remove the RBL entries using the zmprov again. this time I restarted the mta AND amavisd (zmamavisdctl). My CPU returned to normal low %'s.

So is it normal for the black lists to cause amavisd to spaz?

UPDATE: it seems even after i reverted the RBL settings amavisd was still going crazy. looks like it requed about 4000 defered messages. these were junk messages from servers which we usually ignore. i guess that caused the problem.

[shankwc]

The instruction to migrate using the backup process seems to have worked. I had about 24G of mail to move, so I started the process a few days ago by setting up an rsync from my old server to my new one. Once most of the mail was sync'd the rsync process would only take a few minutes. Also, 2 weeks ago I moved my zimbra server to latest release so that I'm going from a 3.1.1FC3 to a 3.1.1.Debian.

So on the night of the switch, I have my new target box ready to go. I've already done a few blank installs and then removed them - so i know it should install ok. I rsyncd the running email one more time. I then stopped zimbra and rsyncd again. I shutdown the old server.

On the new server I put the zimbra folder in a safe spot (not /opt). I changed the hostname to mail and set the IP the same as my old server. I ran the install script and did a vanilla install because it's a new install (even if I left my zimbra dir in /opt it doesn't recognize any previous install). I moved the vanilla /opt/zimbra and replaced it with the one from my old server. I then ran the install script again and this time is realized it was doing an upgrade. It upgraded ok.

1 problem is that there was no init start script. Is this an oversight?

[bobby]

upgrade bug. just copy /opt/zimbra/libexec/zimbra to /etc/rc.d/init.d/