Revision as of 20:22, 10 June 2009 by Publiski (talk | contribs) (New page: Please note that VServer is an unsupported product for use with Zimbra, and there may be more issues than presented below in attempting to operate Zimbra while using it. I present the fol...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Please note that VServer is an unsupported product for use with Zimbra, and there may be more issues than presented below in attempting to operate Zimbra while using it. I present the following strictly to educate on the issues you are likely to encounter if you are considering VServer, and this is strongly discouraged and again unsupported by Zimbra.

Use at your own peril.

Issues unrelated to platform: We've encountered three issues unrelated to platform. These could just as easily manifest themselves in a RedHat environment as ours and are all related to security.


Unless I missed it (which is quite possible), the Zimbra documentation does not expose all dependent packages. It is recommended security practice to only install what is needed to provide fewer vectors for attack. Thus, secure installation will likely hit some of the issues we encountered. We have included the following dependencies in our internal documentation. Some have been installed at other's recommendation while we were flailing for a solution and have not been verified as essential. I certainly wouldn't mind someone going through these to determine which are essential. I would suggest including the essential ones in the Zimbra documentation:

yum install tar bzip2 gzip less man fetchmail sudo libidn curl gmp compat-libstdc++-33 compat-libstdc++-296 libtool-ltdl vixie-cron file cpio zip wget sysstat xfs lsof strace pstack pcre gmp libtool-ltdl unrar p7zip freeze lzop arj arc zoo lha cabextract tnef perl-Convert-TNEF perl-Unix-Syslog perl-Digest-HMAC perl-IO-Socket-SSL perl-LDAP perl-MIME-Types psacct words perl-DBD-MySQL

Many of these were not obvious. We found them by perusing zimbra.log (I believe) and seeing clam (I believe) complain that several file handlers were missing.


Because SSH is such a dangerous protocol, it is common security practice to change it from listening on default port 22. We did this and found that certain Zimbra processes (I forget which) assumed it was running on port 22. Zimbra might want to make this configurable or examine for variation, e.g., perhaps read the sshd_config file although I'm not sure if all implementations of SSH use such a file - RedHat certainly does.

THREE For performance and security reasons, we move /tmp to RAM and, since it is a separate partition, set it nosuid,noexec,nodev. This did not directly cause a problem but it did create a problem when processing a large number of backlogged statistics with zmlogprocess. A note somewhere in the documentation might be helpful.

CENTOS issues We encountered a single CentOS specific issue. CentOS 5.3 uses rsyslog instead of syslog. RHEL 5.3 also includes rsyslog but does not make it the default. Thus, solving this problem would not only prevent questions from CentOS users (and then aggravating them by telling them CentOS is not supported) but will also spare you grief from RHEL customers who may have a need to run rsyslog instead of syslog.

The problem manifests itself in the installation routine which attempts to modify the /etc/syslog.conf file and then restart the syslogd service and logrotate which attempts to restart syslogd. A simple check for whether syslogd or rsyslogd is being used and a tiny amount of conditional logic would easily solve this problem.

VSERVER issues These were more complex and, as I suspect you would prefer to not support VServer, I'll simply state them here although I do believe supporting VServer could open up the VPS market to Zimbra.

We needed to expose /proc/vmstat for statistics collection and the stats will reflect the entire vserver host and not just the zimbra guest.

We needed to exclude the /opt/zimbra/db/data and /opt/zimbra/logger/db/data directories from the hashify function.

We needed (well not really but it made life simpler) to disable the Single IP Special Handling and enable masked loopback addressing.

I believe there is still an open bug where the Zimbra administrative console inserts incorrect information into the SubjAltName of requested certificates. That had nothing to do with platforms or security but is a true Zimbra bug.

Jump to: navigation, search