Installing Zimbra on VServer
|This article applies to the following ZCS versions.|
Installation on VServer
These instructions are specifically for Debian VServers, but should be able to be applied to just about any system
WARNING - Upgrading Zimbra will overwrite all of these files - you must patch them after installing and each upgrade.
|Alternate Vserver Install Method
Since Vserver version 2.2 or so, default behaviour for interpreting 127.0.0.1 by a vserver has been to use the IP in /etc/vservers/vservername/interfaces/0/ip instead. This means a daemon binding to localhost according to /etc/hosts of 127.0.0.1 will instead bind to, say, an external IP address of 188.8.131.52 for example.
This can make setting up Zimbra in a vserver trivial - in fact, ZCS5.0GA works right out of the box in this way in a Debian vserver if all the debian packages Zimbra needs are installed. No modification of any of the configurations or services is required - yes, this means the most of this document is somewhat moot (except prerequisites et al), and describes manually converting all bindings to an RFC1918 address instead of letting the vserver do the mapping.
However there are of course caveats: Anything that binds to 127.0.0.1 is likely meant not to be exposed to the internet. This may or maynot be a problem (anyone with Zimbra security expertise please comment).
Conversely, the solution is not to make the first IP of your vserver an RFC 1918 IP address for 127.0.0.1 to bind to instead - the issue is that daemons connecting out to the net will use the first IP in the vserver - which can't get very far if its an RFC1918 address.
There may be solutions that involve policy routing tables or changing the way vservers' IP routing is done that may enable this easily (please add comments).
An alternate soution, which isn't elegant, is to use a real IP as interfaces/0/ip for your Zimbra vserver, let Zimbra bind its localhost daemons to it, and IP Tables on the external vserver host and firewall off the ports for that IP that should not be exposed. (A list of ports to firewall to be added.) - Mathx 09:02, 2 March 2008 (PST)
Debian and VServers
Remember when running a linux-vserver.org Vserver that the host machine will be arping for all the IPs in the Vservers. It will also accept any connections in its tcp stack for any IP in a vserver if the TCP stack has a deamon bound to *:port - ie postfix listening on *:25 on the vserver host will interfere with postfix on 184.108.40.206:25 on the vserver. Make sure you have bound ALL daemon ports (smtp, ssmpt, imap2, imap3, imaps, etc etc) to specific Ips on the host. How to do this is beyond the scope of this page, but generally check config files (/etc/postfix/conf/main.cf, /etc/dovecot.conf, /etc/apache/httpd.conf, etc) for Listen or Interface or other equivalent statements. When in doubt, RTFM.
Base debian vservers, depending on your package selection dont have many packages needed by zimbra installed by default.
All packages required for installing Zimbra 4.5 (5.0 requires a few more, use apt-file search /missing/file/path to find which package has it) are:
apt-get install libgetopt-mixed-perl file libc6-i686 sudo libidn11 curl fetchmail libgmp3c2 libxml2 libstdc++6 openssl libexpat1 libpcre3 libltdl3 ssh
5.0.2GA The install.sh script now checks to ensure 127.0.0.1 is in /etc/hosts, quite frustratingly. You can edit install.sh or keep 127.0.0.1 in /etc/hosts until you are ready to start Zimbra, then put your RFC1918 IP for localhost back in.
Make sure you have a localhost entry and also an entry with your primary IP. For example:
127.0.0.1 localhost.localdomain localhost 220.127.116.11 mail.somehost.zimbra mail
Note: It may be better in a vserver to use an RFC 1918 IP address for localhost instead of 127.0.0.1 - 127.0.0.1 is not bound to localhost on the vserver, it is on the host machine itself. No vserver process can use this IP. You can also use another IP on localnet (127.0.0.0/8) if you so wish, but there may be caveats with vservers I am not yet aware of. I use RFC1918 addresses without any problems right now. In examples below I have 10.5.6.7 as localhost in /etc/hosts.
The Zimbra logger process doesn't seem to startup. "zmcontrol status" on my system shows:
vserver:~# /opt/zimbra/bin/zmcontrol status Host vserver.somedomain antispam Stopped antivirus Stopped ldap Running logger Stopped mailbox Stopped mta Stopped snmp Stopped spell Running vserver:~#
The logger uses MySQL. I'm guessing there is some problem with privileges and/or connecting to localhost in the "mysql" database. Just a hunch though.
I installed Zimbra on a new VServer and the logger seemd to startup properly. "zmcontrol status" shows it running after several stops/starts. However, I'm still not getting any log data. All statistics windows say "Data not available yet.". Oh well.
Update: With 4.5, logger seems to work just fine, but seemed to require a manual start as zimbra user. Additionally I have seen zmlogger running, but the admin console says it's not. Still figuring this out.
Update: With 5.0GA everything seems to work fine and start by itself. Only stopping the logger doesnt seem to work, and requires a manual kill after shutting down zimbra.
The postfix main.cf config file is auto generated by zmmtaconfig internally before postfix is run, so any changes you make to postfix/conf/main.cf will be overwritten. So you must edit /opt/zimbra/conf/zmmta.cf - in fact, any file in /opt/zimbra/conf that has 127.0.0.1 in it should be changed. For eg if you have chosen 10.5.6.7 as your RFC 1918 internal IP address in the vserver to act as localhost, then you could well do this:
cd /opt/zimbra/conf && mkdir bak new && cp * bak && for i in *; do sed 's/127\.0\.0\.1/10.5.6.7/g' $i > new/$i; done && mv new/* . && rmdir new
to replace all 127.0.0.1's with 10.5.6.7 en masse (and keep a backup of the originals in bak/)
If you are not comfortable with the command above, here is a simpler version (This one does not create backups! You have to do it!). You have to enter this command in /opt/zimbra/conf dir:
for i in *; do sed -i 's/127\.0\.0\.1/10.5.6.7/g' $i; done;
If you want to modify your mynetworks line in postfix in zimbra, the config is stored in LDAP and must be modified there:
zmprov modifyServer your.server.domain.com zimbraMtaMyNetworks '10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.5.6.7'
for eg if you are using 10.5.6.7 as the internal localhost IP. It may not hurt to add your real external IP here as well (as it would only allow email from that IP through the mail system, which shouldnt hurt). If you do not do this, you may get "mail relaying denied" when you try to send mail out of the zimbra system as a user. Please see ZimbraMtaMyNetworks for more information on this setting.
postfix/conf/master.cf however is NOT autogenerated, and so needs editing in the postfix/conf dir:
10.5.6.7:10025 inet n - n - - smtpd -o mynetworks=127.0.0.1/8,10.5.6.7
Where, again, 10.5.6.7 is your RFC1918 internal IP address chosen to replace your localhost ip (127.0.0.1). Do not forget to change the mynetworks line as well, or your AV will not be able to connect back to postfix on 10025 for final delivery.
Note: Avoid using your external internet IP address here, picking an RFC1918 replacement IP for 127.0.0.1 is a better idea in terms of security. You do not want this port open to the internet, as it may be DOSsable or other security issues (buffer overflows, etc) may arise. If you don't absolutely need a port open to the internets, don't open it.
Amavis & ClamAV
Edit /opt/zimbra/amavisd/sbin/amavisd (main Perl script) and explicitly add the IP address of the Zimbra VServer to the "inet_acl" line. I.e:
@inet_acl = qw( 127.0.0.1 18.104.22.168 [::1] ); # allow SMTP access only from localhost
Postfix should then be able to talk to Amavis.
Note: if your vserver first ip (in interfaces/0) is an external IP you'll need to include this in the inet_acl statement or it will not be allowed to connect to itself.
$inet_socket_bind = '127.0.0.1'; # limit socket bind to loopback interface
$inet_socket_bind = '10.11.12.5'; # no loopback in vserver, use your rfc1918 internal ip bound to your vserver
also few lines down:
$notify_method = 'smtp:[127.0.0.1]:10025'; # change these to also match your internal $forward_method = 'smtp:[127.0.0.1]:10025'; # rfc 1918 ip addr (can use inet ip, but not recommended)
A bunch of filters in /opt/zimbra/conf/amavisd.conf also need updating from 127.0.0.1:(port) to whatever IP you are using.
Additionally configs in /opt/zimbra/conf/dspam.conf needs changing as well, such as LocalMX et al. - other delivery filters need to be uncommented from their defaults (which are all 127.0.0.1) to be your internal IP address - if this is not done they will attempt to connect to 127.0.0.1 which will map to your first vserver IP, which is likely your external IP, and if ACLs are not setup properly, they will be blocked and mail will sit in the postfix queue and not be processed for spam and virus filtering. (You'll see mail transport unavailable and conversation with hostname[x.y.z.d] timed out while receiving the initial server greeting if you have this problem - include your external IP in the inet_acl for amavis as per above as a workaround).
Note: there are extra configs that autogenerate more configs for Amavis and FreshClam in /opt/zimbra/conf - be sure to change all the 127.0.0.1 IP addresses in those files to your chosen RFC 1918 address (see postfix above). They must be changed in both /opt/zimbra/conf/amavis.conf and amavis.conf.in (if you changed them in the master binary as above, you can just comment them out in here so they dont override the master - however, the master may get upgraded later, and all your changes may be wiped, but so might amavis.conf(.in) anyway too...)
Vserver /tmp size
My install of Zimbra wouldn't start clamd with my default debian 16m of /tmp ramdisk space in my vserver. I had to edit /etc/vservers/(name)/fstab and increase it to 128m (though smaller may work, I didnt test), and restart the vserver. 128m lets it start anyway, not sure if I'll run out during operations.
Nominally, I move /tmp to /tmpram and edit /etc/vservers/vservername/fstab to reflect this so that /tmp is on the regular filesystem - with kernel buffering of disk, there isn't a speed/access time issue, and if a vserver user needs to know their ramdisk isn't backed to real media (thus causing IO when sync'ing this to disk), they can use /tmpram. In a huge Zimbra install this might make a difference, depending on how much use of /tmp Zimbra makes. -- Mathx 09:07, 2 March 2008 (PST)
While trying to get tomcat to start on our Vserver, we kept getting this error in catalina.out:
Invalid initial heap size: -Xms8001m The specified size exceeds the maximum representable size. Could not create the Java virtual machine.
By default, tomcat will use 50% of the system memory available (as defined in tomcat_java_heap_memory_percent). On our 16Gb machine, Tomcat tried to use 8Gb and failed. You can override this default by issuing:
zmlocalconfig -e tomcat_java_heap_memory_percent="6"
Where the 6 means 6% (983.04Mb in our case).
Same deal with zmmailboxd, it has a heap size default of 40%. Change, for example, to 5:
zmlocalconfig -e mailboxd_java_heap_memory_percent="5"
If Tomcat doesn't start for you (ie running 'ps auxwf' doesnt show java running anything, and 'lsof -i' doesn't show anything listening on the :7071 port - the Zimbra admin interface port), then zmmta has failed to start. Check /opt/zimbra/apache-tomcat*/logs/catalina.out for errors. My most common one was finding that the IMAP and SMTP ports were already bound - by IMAP and SMTP running on the host of the vserver. (See notes at top of this section on binding daemons to single IPs). I am not quite sure why Tomcat is responsible for running the IMAP daemons, but it is.
Distro Specific Settings
Security limits (SuSE OSS 10.0 vserver)
Edit /etc/security/limits.conf and comment the last two lines - otherwise the su command won't work and the installation will fail.
# End of file #zimbra soft nofile 10000 #zimbra hard nofile 10000
Rerun /opt/zimbra/libexec/zmsetup.pl to complete the setup.
Ubuntu 8.04 and the case of 127.0.0.1
A bit of trouble can be encountered (eg. the whole thing doesn't work) if you miss the following settings. It occured under Ubuntu 8.04 Server 32bit with linux vserver 22.214.171.124. Most processess want to bind themselves to 127.0.0.1. Due to the fact that lo is not present by default you need to create a new interface. You do this by:
cp -r /etc/vservers/vserver1/interfaces/0 /etc/vservers/vserver1/interfaces/1
and afterwards edit the contents of the files in dir 0 so that they would contain 127.0.0.1/8, lo. This way you bind the guest 127.0.0.1 interface to the host's lo interface. It is not recommended to do! With vserver version 2.3+ you don't need to worry about LO interfaces...