While we do not modify postfix/mysql/ldap per se, we do configure them
significantly or we define schema or we add some data into their
stores. In the case of postfix we define about half a dozen lookup
tables. For openldap there are zimbra.schema and zimbra.ldif et al.
MySQL needs to be loaded up with zimbra schema in db.sql. Tomcat also
is heavily configured with Zimbra specific server.xml. The scripts
inside the zimbra sources that manage mysql, postfix, etc config files
make assumptions about all these components living inside /opt/zimbra.
Think of it this way: we treat mysql, openldap and postfix as
components embedded inside a Zimbra installation. Contrast this with
a hypothetical Zimbra packaging that would use the mysql installed in
Our motivation is to make the install extremely simple for people that
download the binaries. They should/do not have to scramble to get the
correct version of postfix, openldap etc, that we have tested - or
worry about conflicts with versions in /usr/bin.
For porters, I suggest you try to rebuild the binaries we have inside
ThirdParty for your platform. Eg, compile postfix the same way we do,
and drop a binary inside ThirdParty, and make sure it installs inside
/opt/zimbra/postfix in your platform (might need some Makefile edits
if we have any RH/Fedora hardcodes :-). In other words - don't try to
shoe-horn your distros' postfix into a Zimbra install - it's not that
that's not possible - it's just a longer road.
I am sure there are going to be folks who do not like our /opt/zimbra
approach ("hey why aren't my Zimbra config files in /etc?" crowd). As
a long time Linux user, I am not too fond of /opt requiring packages
either. Zimbra install may get to an /etc friendly install at some
point (and distros might beat us to it), but for now if you are
porting, try to play the /opt/zimbra game and make your life simpler.