ZCS – A changelog by Daniel Mettler

September 10, 2017September 13, 2017

How to upgrade Zimbra/ZCS 8.8 GA from Ubuntu 14.04 LTS to 16.04 LTS

When upgrading Ubuntu 14.04 LTS to 16.04 LTS the usual way, ‘do-release-upgrade’ will by default remove 3rd party packages. For a Zimbra/ZCS server this means that Zimbra/ZCS packages would be automatically removed when upgrading to Ubuntu 16.04 LTS.

Luckily, there’s a neat little trick to prevent ‘do-release-upgrade’ from removing Zimbra/ZCS packages during the upgrade. Here’s how to do it:

Open two screen sessions (or two terminal sessions) on your Zimbra/ZCS server
```
 $ screen -R
```
Block at least the SMTP and SMTPS ports (to prevent clients from accessing the server, consider blocking the IMAP and IMAPS ports too, or all ports but SSH and port 1022) for your Zimbra/ZCS server on your firewall (to stop the delivery of messages).
Backup the server or make a snapshot, just in case anything goes wrong
Stop Zimbra/ZCS:
```
 $ sudo /etc/init.d/zimbra stop
```

Make sure the system is current:

 $ sudo apt-get update && sudo apt-get upgrade

Start the Ubuntu distro upgrade process:
```
 $ sudo do-release-upgrade
```
(if you don’t have do-release-upgrade, you have to execute ‘sudo apt-get install update-manager-core’ first)
When prompted by ‘do-release-upgrade’ that the third party sources have been disabled, re-enable those third party sources. To do this, open ‘/etc/apt/sources.list.d/zimbra.list’ with an editor (e.g. nano, vim) in another terminal/screen session and change its content from:
```
# deb [arch=amd64] https://repo.zimbra.com/apt/87 xenial zimbra # disabled on upgrade to xenial
# deb-src [arch=amd64] https://repo.zimbra.com/apt/87 xenial zimbra # disabled on upgrade to xenial
```
to
```
deb [arch=amd64] https://repo.zimbra.com/apt/87 xenial zimbra
deb-src [arch=amd64] https://repo.zimbra.com/apt/87 xenial zimbra
```
Then return to the first terminal/screen session and let ‘do-release-upgrade’ continue with the upgrade process (i.e. hit ‘enter’).
When you get informed about the packages that will be removed (BTW, in the detail view you can see that the Zimbra packages will now be upgraded, not removed) and upgraded and asked whether you want to start the upgrade, confirm this.
Note: Don’t worry about minor error messages like:E: changelog for this version is not (yet) available; try https://launchpad.net/ubuntu/+source/zimbra-perl-socket/+changelogYou can safely ignore them.
Agree to all suggestions by ‘do-release-upgrade’ (e.g. the removal of files in /var/log/sysstat/ and whether you allow ssh to be restarted). In my case, it was also fine to go with the maintainer versions of the config files.
When the upgrade process is finished, let ‘do-release-upgrade’ reboot the system.

After this, Zimbra/ZCS should work nicely again, on Ubuntu 16.04 LTS.

Note: It can take Zimbra/ZCS quite some time to properly start all its services (it’s Java, after all). Sometimes, the output of ‘$ sudo /etc/init.d/zimbra status’ and what’s listed in the service monitoring section of the Zimbra/ZCS admin webUI can thus be inconsistent. Sometimes, it’s even necessary to stop and start Zimbra/ZCS a couple of times (with ‘/etc/init.d/zimbra’) after an upgrade until all services run nicely.
Also note that Zimbra’s new dedicated ‘imapd’ service won’t run properly, unless it’s configured manually, as shown in the Zimbra Collaboration Administrator Guide version 8.8.3. If it doesn’t run properly, this service will simply be ignored in a single server setup, your Zimbra/ZCS will thus likely work as usual.

If there are any problems or if you want to be extra cautious, you can also additionally download Zimbra/ZCS 8.8 for 16.04 LTS manually and run its installer again:

$ sudo ./install.sh

If everything is fine, unblock the SMTP and SMTPS (and IMAP and IMAPS) ports again.

If things aren’t fine, simply roll-back from the snapshot or restore the whole server from the backup.

You might then want to try a fresh install according to the official Zimbra/ZCS migration manual: How to move ZCS to another server.

(Source: Kudos to vchong68 for his valuable hint in his forum post)

May 23, 2014May 23, 2014

Zimbra Desktop Update to 7.2.5 on Mac OS X Mavericks

When Updating Zimbra Desktop (documentation) to the latest version on Mac OS X 10.9.3 (Mavericks), the installation of the update fails. The hint how to work around this bug is quite subtle, well hidden in the Zimbra Desktop 7.2.5 release notes and even wrong and misleading, so here’s the corrected hint:

Issue # 88878: Unable to install Zimbra Desktop on OS X Mavericks machine.
Workaround: If launching Zimbra Desktop fails on an
OS X Mavericks machine, you can override your security
settings to open Zimbra Desktop:
1. In the Finder, locate the Zimbra Desktop .mpkg file. This
can likely be found in the Applications folder [wrong, see my notes below!].
2. Press the Control-key and click the file.
3. Choose Open from the pop-up menu.
4. Click Open.

Important hint: The ‘Zimbra Desktop.mpkg’ file is NOT located in the Applications folder though, but in a mounted ‘update.dmg’ image, named “Zimbra Desktop Installer” (its icon is probably shown on your desktop), and only as long as the warning dialog is being displayed (do NOT close it before running ‘Zimbra Desktop.mpkg’!). Further, auto-mounting of update.dmg only works the first time right after booting – otherwise, you either need to reboot your Mac or manually mount

/private/tmp/zdupdate/update.dmg

(e.g. by copying [optional] and double-clicking it).

Addendum: This update was obviously packaged in a rush and wasn’t tested well on Mac OS X Mavericks (I seriously hope that’s not a bad omen for the future support of ZD on Mac OS X!). For example, after updating ZD to 7.2.5 GA build 12038, I can’t compose new messages anymore as there’s the following Java error when clicking on the “New” button:

HTTP ERROR 500

Problem accessing /zimbra/public/launchNewWindow.jsp. Reason:

    PWC6033: Unable to compile class for JSP

PWC6199: Generated servlet error:
The type java.util.regex.Pattern cannot be resolved. It is indirectly referenced from required .class files

PWC6199: Generated servlet error:
The import java.util.regex.Pattern cannot be resolved

Caused by:

org.apache.jasper.JasperException: PWC6033: Unable to compile class for JSP

PWC6199: Generated servlet error:
The type java.util.regex.Pattern cannot be resolved. It is indirectly referenced from required .class files

PWC6199: Generated servlet error:
The import java.util.regex.Pattern cannot be resolved


	at org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:123)
	at org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:296)
	at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:376)
	at org.apache.jasper.compiler.Compiler.compile(Compiler.java:437)
	at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:608)
	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:360)
	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:486)
	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:380)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:814)
	at com.zimbra.webClient.servlet.JspServlet.service(JspServlet.java:64)
	at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
	at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166)
	at com.zimbra.cs.servlet.SetHeaderFilter.doFilter(SetHeaderFilter.java:79)
	at com.zimbra.webClient.filters.SetHeaderFilter.doFilter(SetHeaderFilter.java:239)
	at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
	at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388)
	at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:218)
	at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
	at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
	at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:422)
	at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
	at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
	at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
	at org.mortbay.jetty.handler.rewrite.RewriteHandler.handle(RewriteHandler.java:230)
	at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
	at org.mortbay.jetty.Server.handle(Server.java:326)
	at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:585)
	at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:971)
	at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
	at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
	at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:415)
	at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:429)
	at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:451)

Composing new messages on the ZCS web interface still works fine.

December 17, 2013October 17, 2013

Zimbra ZCS: OpenDKIM not running

After upgrading Debian, OpenDKIM sometimes stops running or fails to properly restart. If you don’t actively monitor your ZCS server, the only way to detect this is either through a growing mail queue of unsent messages or through a note in the ZCS server admin panel.

Usually, manually restarting either OpenDKIM itself or the whole ZCS server once “fixes” the problem:

# service zimbra restart

# /etc/init.d/zimbra restart

In other cases, fixing the permissions may help:

# /opt/zimbra/libexec/zmfixperms -verbose -extended

(source)

August 22, 2013July 21, 2013

Delete duplicate e-mail messages

If you need to delete duplicate e-mail messages on an IMAP server, take a look at this useful IMAP de-duplicator script:

IMAP de-duplicator – IMAPdedup

As IMAPdedup is a command line interface tool (a python script), it’s particularly useful for:

automated deletion of duplicates (as it can be called from other scripts)
extraordinarily big mailboxes or if you have many subfolders (as there’s no intervention by the user required)
if you have console/shell access to the IMAP server (as you can then run the script on the server itself, speeding the de-duplication process further up)

I also found that it deals relatively well with failures (e.g. when a folder is read-only and hence messages can’t be deleted): It simply reports them on the screen and carries on.

Here’s a quick’n’dirty bash script to de-dup the inbox and all subfolders of the specified account:

#!/bin/sh
# Delete all duplicate messages in all folders of said account.
# Note that we connect through SSL (-x) to the default port.

SERVER="my.server.com"
USER="mylogin"
PASS="mypass"

for folder in `imapdedup.py -s $SERVER -x -u $USER -w $PASS -l`;
do
 imapdedup.py -s $SERVER -x -u $USER -w $PASS $folder
done

If you only have to de-duplicate messages in a small folder, you could also use the following de-duplication add-on for Mozilla Thunderbird:

Remove Duplicate Messages Add-on for Thunderbird

Note however that the ‘Remove Duplicate Messages’ add-on is intended for interactive use only, not for batch processing. I also noticed that it fails at cleaning big mail folders (e.g. containing 50’000 messages).

April 6, 2013March 27, 2013

Moving Zimbra Collaboration Server to a new IP address

Here’s a quick overview how to migrate a ZCS mail server (based on Ubuntu) to a new IP address:

0) Not covered here: Adjusting DNS entries. Make sure you lower the TTLs of the relevant DNS entries a couple of days in advance in order to minimize downtime for clients (e.g. set a TTL of 300 for a 5 minute downtime).

1) Set the new IP address in:
* The relevant DNS entries
* /etc/network/interfaces
* /etc/hosts
* If ZCS runs in a container/VM, don’t forget to adjust its IP address too.

2) If the new IP address is part of a new subnet, make sure to add this new subnet to ZCS’s trusted_networks, otherwise, sending (relaying) messages through ZCS from Zimbra Desktop (or any other mail client) won’t work[1]. This can be set using ZCS’s web admin interface (i.e. https://mail.myserver.com:7071/zimbraAdmin/):
Navigate to “Server settings”, then open the “MTA” tab and set something analogous to the following in “MTA Trusted Networks”:
127.0.0.0/8 w.x.y.z/26

3) Restart networking and the ZCS services (it’s important, as this adjusts the trusted_network setting in ZCS’s amavisd too):
# /etc/init.d/zimbra stop
# /etc/init.d/networking restart
# /etc/init.d/zimbra start

Alternatively, just reboot the server, particularly if it runs in a VM.

Voilà!

Note: The need for the adjustments in step 2) might come as a surprise. Authenticated messages to be relayed through ZCS apparently seem to originate from the external IP address, not localhost/127.0.0.1.

[1] A typical postfix error message might look like:
Delivery Failure Notification: Invalid address: somebody . com.zimbra.cs.mailbox.MailSender$SafeSendFailedException: MESSAGE_NOT_DELIVERED; chained exception is: com.zimbra.cs.mailclient.smtp.InvalidRecipientException: RCPT failed: Invalid recipient somebody@somedomain.com: 554 5.7.1 : Relay access denied

June 22, 2011June 22, 2011

Zimbra Collaboration Server: Best tested platform?

First: Of course, all listed supported ZCS platforms are tested platforms.

The interesting thing is that according to internal sources, most boxes in Zimbra’s test farm now run Ubuntu instead of Fedora/RH/Centos. Way to go, VMWare!

June 6, 2011June 22, 2011

Zimbra Collaboration Server: Troubles after updating to ZCS 7.1.1 – here’s the solution.

Generally, Zimbra‘s update scripts for ZCS run smoothly. However, after updating ZCS from 7.0.1 to 7.1.1 on Ubuntu 10.04.2 LTS a couple of days ago, I noticed that most of the server’s services crashed within 1-2 hours after starting the (virtual) server.

To make a long debugging story short, here’s a summary of the problem:

The update script doesn’t properly remove old entries in /etc/rsyslog.conf when creating a new dedicated rsyslog configuration file for zimbra (/etc/rsyslog.d/60-zimbra.conf). This makes rsyslog log its own logging due to double rule entries – making /var/log/zimbra-stats.log grow at 2 MB/s. Like this, zimbra effectively DOSes itself as the server runs out of free disk space in no time (my above-average 12 GB of free space were filled within about 1 hour 40 minutes).

And here’s the solution:

1. Stop rsyslog to stop it from filling up your disk with nonsense: ‘/etc/init.d/rsyslog stop’ or ‘service rsyslog stop’
2. If necessary (i.e. if the updated server has been running for several minutes already), reclaim your free disk space by deleting/emptying big log files in /var/log, e.g. zimbra-stats.log, zimbra.log, mail.info, mail.log, mail.err, mail.warn etc.
3. Edit /etc/rsyslog.conf and remove the entries (likely at the end of the file) that look similar to these:
local0.* @mail.yourserver.com local1.* @mail.yourserver.com auth.* @mail.yourserver.com local0.* -/var/log/zimbra.log local1.* -/var/log/zimbra-stats.log auth.* -/var/log/zimbra.log mail.* @mail.yourserver.com mail.* -/var/log/zimbra.log
(these are now in /etc/rsyslog.d/60-zimbra.conf)
4. Restart rsyslog: ‘service rsyslog restart’
5. Restart ZCS if it doesn’t run properly anymore: /etc/init.d/zimbra restart (you may even have to reboot the whole box if that doesn’t work)