Fixing Cron Jobs in Zimbra 8 on CentOS 6.3

In a previous post, I detailed some preliminary steps for installing Zimbra 8 GA on CentOS 6.3.  Today, I realized that my server status was not accurately reporting the status of various Zimbra services and server metrics.  A little digging around showed me that none of the Zimbra 8 cron jobs were running or properly scheduled.  Here is how I solved my problem:

First, install cronie:

# yum install cronie

This will provide us with a familiar crontab interface, and it will make it much easier to add the Zimbra 8 cron jobs to our system.  Next, we must remove exim so that we don't have another sendmail on our system to pollute our running process name space:

# rpm -e --nodeps exim

Leaving exim installed will conflict with Zimbra's MTA.  If the MTA fails to start, you might encounter the following errors:

[zimbra@zimbra ~]$ zmmtactl start
Rewriting configuration files...done.
postfix/postfix-script: warning: not owned by root: /opt/zimbra/postfix-2.10-20120422.2z/conf/main.cf
postfix/postfix-script: warning: not owned by root: /opt/zimbra/postfix-2.10-20120422.2z/conf/master.cf
postfix/postfix-script: warning: not owned by root: /opt/zimbra/postfix-2.10-20120422.2z/conf/master.cf.in
postfix/postfix-script: warning: not owned by root: /opt/zimbra/postfix-2.10-20120422.2z/conf/tag_as_foreign.re
postfix/postfix-script: warning: not owned by root: /opt/zimbra/postfix-2.10-20120422.2z/conf/tag_as_originating.re
 

Run the following commands as root:

# /opt/zimbra/libexec/zmfixperms --verbose --extended
# su - zimbra 
# zmmtactl restart

Next, navigate to the Zimbra 8 crontabs directory:

[root@zimbra crontabs]# pwd

/opt/zimbra/zimbramon/crontabs

From here, we have to concatenate all of our cron files into one easy to digest crontab:

[root@zimbra crontabs]# cat crontab >> crontab.zimbra

[root@zimbra crontabs]# cat crontab.ldap >> crontab.zimbra

[root@zimbra crontabs]# cat crontab.logger >> crontab.zimbra

[root@zimbra crontabs]# cat crontab.mta >> crontab.zimbra

[root@zimbra crontabs]# cat crontab.store >> crontab.zimbra

Finally, we use crontab to load the new crontab.zimbra file:

[root@zimbra crontabs]# crontab crontab.zimbra

A quick 'crontab -l' will show our current crontab, and after a few minutes, Zimbra 8 on CentOS 6.3 should be properly reporting server statistics, performing regular house keeping, and more.  There may be a better way to go about this, but I haven't found one as of yet.  Before putting this into production, please test thoroughly.  If I encounter any other issues, I will either update this post or create an entirely new post (depending on the scope of the problem).

Zimbra 8 GA on CentOS 6.3

Much to the pleasure of many SysAdmins, Zimba 8 General Availability has been announced by VMware.  I have been planning on migrating to the Zimbra Open Source for my commercial email platform.  (I will migrate clients over using imapsync.)  Due to my upcoming Space Walk deployment, I decided early this year to standardize my department on CentOS.  Naturally, I figure it is time to update my CentOS VM template to 6.3, and give Zimbra 8 a test.  

When I setup my CentOS Linux Virtual Machines, I prefer to attach multiple SCSI vmdk files as my guest storage; usually 25 GB thin-provisioned disks.  Then, when building my template, I tend to place /boot and /swap on one disk, and use the rest of the space for LVM.  This allows me to quickly add more space to my Virtual Machine down the line without having to power down or restart my guest OS; a feature that is very important for capacity planning and meeting  my SLAs.  I also like to forgo setting resource reservations, and opt instead for resource limits.  My standard VM template has 4 GB RAM, 4x vCPUs, 4000 MHz CPU limit, and a 4096 MB (4 GB) RAM limit.  Also, installing VMware tools, while sometimes a pain (and outside scope of this blog), is beneficial for tighter management from vCenter.

After choosing the "basic server" packages from my 64 bit net install, I ran the following commands:

# yum install wget sudo sysstat libidn gmp libtool-ltdl compat-glib vixie-cron nc perl

Then, after using WinSCP to upload my zcs folder to /root, I modified the following permissions:

# chmod +x install.sh && chmod +x ./bin/get_plat_tag.sh 

I also discovered that Zimbra 8 expects libstdc++.so.6 in /usr/lib.  So, I made a symbolic link:

# ln -s /usr/lib64/libstdc++.so.6 /usr/lib/libstdc++.so.6

Then, I modified /etc/hosts with my public IP and FQDN of my new Zimbra host.  Also, be sure to setup a DNS MX record in your zone file (it is better to have DNS up to date before installing ZCS).

Now, since this edition of Zimbra is built for RHEL, we need to run the following command to install Zimbra on our host:

# ./install.sh --platform-override

That's it.  From here, it is up to the SysAdmin to configure iptables according to their internal policy, and to make any other changes to the system as needed (while following change control and management best practices; naturally).  The easiest Zimbra build to start with is the "all in one" server, and I refer the reader to the Zimbra Documentation, Wiki, and community forums for installation and configuration instructions.  You may also want to consider adding a commercial SSL certificate from your favorite vendor (if/when putting this host into production).  

One of the features of Zimbra that I love so much is the modular design - this makes building a Zimbra cluster(s) much simpler than products from some unnamed competitors.  =)  For more advanced deployments, I recommend the reader consult the resources listed above.

EvolveBDR v0.0.2 - a Bacula OVF

EvolveBDR v0.0.2 is a portable OVF format Virtual Machine pre-configured to run Bacula as easily as possible.  EvolveBDR aims to supply sane default configurations to allow SysAdmins to rapidly deploy EvolveBDR in their environments while greatly minimizing the learning curve necessary to successfully implement Bacula as a file level backup solution.

I spend a large portion of my time on the internet haunting /r/SysAdmin on Reddit.  A common question on that venerable forum often contains something similar to "Can you please recommend a low cost/FOSS enterprise backup solution?"  I and many others are quick to recommend Bacula, BackupPC, Areca, Cobian Backup, and Veeam's free edition.  Personally, I find myself recommending Bacula more often than not; a proven solution that has been in development for the better part of a decade; if not longer.

The power of Bacula comes with a small price: a learning curve that is often difficult for the novice *NIX administrator; especially for the Jr. Admin who finds themselves in a primarily Windows-based environment.  (This is not a judgement against their skill-sets or a denigration of their worth as a SysAdmin.)  The creation of EvolveBDR is a response to this challenge with a OVF format Virtual Machine which comes pre-configured to use Bacula as a file based backup solution using hard disks as the primary archival medium.

Some features you may find interesting:

• The virtual appliance has been built on top of TurnKey Core v12.0 RC.
• The file system lives on top of LVM for rapid provisioning of more disk space without rebooting the VM.
• CurlFtpFs to make remote backups easier.
• A default volume pool and Windows-friendly FileSets (one at the moment for Win2k3; Win2008 on the way) to help Windows SysAdmins spend less time configuring Bacula and more time implementing EvolveBDR/Bacula in their environment.

It should be noted that EvolveBDR is still being developed and tested.  If you insist on using this in production, you do so at your own risk.  It is also recommended that you change all of the currently configured passwords to something a little more secure than 'bacula'.  ;)