If your certificate authority has increased their key requirements to 2048 bit your CSR may be rejected when generated like so:
# /opt/zimbra/bin/zmcertmgr createcsr comm -new "/C=CA/ST=ON/L=Toronto/O=Yourbusiness/OU=Yourdept/CN=mail.server.com"
Fortunately, the -keysize flag was added in Zimbra 6.x:
# /opt/zimbra/bin/zmcertmgr createcsr comm -new -keysize 2048 "/C=CA/ST=ON/L=Toronto/O=Yourbusiness/OU=Yourdept/CN=mail.server.com"
First check that port 80 is open on your server:
# iptables-save | grep 80 -A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
Switch to the zimbra user:
# su - zimbra
Turn on redirection to SSL:
zmtlsctl redirect
Now restart mailboxd:
[zimbra@mail ~]$ zmmailboxdctl stop Stopping mailboxd...done. [zimbra@mail ~]$ zmmailboxdctl start Starting mailboxd...done.
Now when your users connect to port 80 they will automatically be redirected to https://your-host-name.com
More information on zmtlsctl is available at http://www.zimbra.com/docs/os/6.0.8/administration_guide/A_app-command-line.13.13.html
You may need to open the LDAP port on your Zimbra server:
# iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 389 -j ACCEPT
Determine your Zimbra LDAP password:
# su - zimbra $ $ zmlocalconfig -s zimbra_ldap_password zimbra_ldap_password = XXXXXXXXXXXX
Open the Barracuda Spam Firewall administration interface. Click the Domains tab. Click the Modify link next to the domain(s) you would like to enable bad recipient rejection for. Click on the LDAP Configuration sub-tab under the Users tab. Retain all defaults except:
If you've tried to make a backup of your zimbra installation by taring /opt/zimbra you may have noticed the output either fills your available storage or is 80 gigs larger than the actual Zimbra installation.
This is caused by an 80 gig sparse file:
-rw------- zimbra/zimbra 85899345920 2013-03-10 19:40 /opt/zimbra/data/ldap/mdb/db/data.mdb # ls -lsah /opt/zimbra/data/ldap/mdb/db/ 5.6M -rw-------. 1 zimbra zimbra 80G Mar 10 19:40 data.mdb
This appears to be a new feature of Zimbra 8 that was introduced for performance reasons (https://wiki.zimbra.com/wiki/OpenLDAP_Performance_Tuning_8.0#Notes_on_MDB). We can get around it by telling tar to account for sparse-ness:
# tar -Scf zimbra.tar /opt/zimbra/
There appears to be a benign segfault from opendkim when Zimbra is shut down:
opendkim[4057]: segfault at 1f0 ip 0000003044209220 sp 00007fffa235bd48 error 4 in libpthread-2.12.so[3044200000+17000] opendkim[10772]: segfault at 1f0 ip 0000003044209220 sp 00007fffbd4e47a8 error 4 in libpthread-2.12.so[3044200000+17000]
The only solid reference to this I could find was at http://www.zimbra.com/forums/administrators/58839-mta-logger-logswatch-wont-start-also-opendkim-issue.html. These users appear to be using CentOS 6.3 as well which may indicate the problem is with libpthread and not in fact opendkim.