Fat Distribution Decision

[paintbuoy]

I have only been pointed to Zimbra recently and I really like the browser interface and the tagging/searching capabilities.
What I am a bit confused about is the bundling of MySQL, OpenLDAP, SpamAssassian, ClamAV, etc with the Zimbra application files.

I can understand why you have chosen to distribute like this for control reasons as it makes for a smooth install. But it seems like an awful lot of doubling up when most of these core applications exist in every distribution already with their own security patch mechanisms and maintainers.

Is there any plans to release a standalone version of Zimbra without the dependencies (MySQL, OpenLDAP, ClamAV, SpamA, etc)? I would really like to deploy Zimbra in place of many other mail systems but I will only do this if and when I can install the core Zimbra package without all the preexisting applications as I want to only run the latest RH/SuSE versions.
I just can't stomach the thought of running two versions of each app or migrating all data off the existing SQL/LDAP servers to the new (but potentially out of date) Zibra instances.

If there are plans for a 'Zimbra Lite' release then this is great, but if not it would be interesting to know why. Creating MySQL databases, adding an ldap schema and configuring ClamAV/SpamAssassian is not hard.

If it is just a time/documentation factor I would love to help out if it means I can install it into my existing MySQL/LDAP/ClamAV/SA/Java infrastructure. I have a couple of spare servers sitting around with CentOS and SuSE and a tonne of MySQL/OpenLDAP/SA/ClamAV experience.

Regards,


David

[anand]

There are tradeoffs to fat packaging vs thin. Here is some of our
thinking that landed us in fat packages:

Ease of install was big driver. We modify cyrus saslauthd. In
the future, maintainers of SASL obliging, this change will be
pushed upstream. In the meantime, imagine if installing zimbra
required you to remove your cyrus-sasl. Don't know about you, but
rpm --test -e cyrus-sasl
makes me a little nervous at this stage.

You should think of the mysql instance inside the Zimbra mailbox
store as an embedded database.

At this time, we have a LOT of people trying to install ZCS, and
kick the tires. Many of them would like that any trial install of
Zimbra not screw up their distro installation - everything being
in /opt/zimbra adds some insurance and level of comfort. Going
forward, for every new release with a lot of features that people
want to quickly install and try, they should feel comfortable that it is
not going to do "atrocious" things to their /etc directory. [One
person's atrocious is another persons normal. Such is life.]

Large and/or mission critical Zimbra installations will expect to
run on versions we have tested - and we'd like to minimize the
variation across distros - to ease our lives.

We fully intend to track 3rd party package versions and stay
current - managing risk through our QA processes.

All that having been said, in the future, would we like to see thin
packages? Absolutely! Like I said in the debian port thread - we
fully expect that someone else will beat us to it.

Should we have done thin packages to begin with? I am not so
sure.

On a related note, we are also working on cutting the download sizes
in cases where you want just the ZCS sources, or if we haven't rolled
mysql version then you shouldn't have to downloaded it again to go the
the next dot release or milestone build of ZCS.

[omry_y]

speaking of atrocities, forwarding port 25 is defenitely one.
took me quite some time to figure what went wrong after I uninstalled zcs.

[lfarkas]

ok. so it seems someone have to start to find out how can we drop packages one-by-one from the main zcs packages. than it'd be useful to documnet which packages are patched and which are the same as the upstream. ie. only sasl was modified? than if i'll have some free time, i'll try to drop as many packages from it as possible and document it.

[KevinH]

Originally Posted by omry_y

speaking of atrocities, forwarding port 25 is defenitely one.
took me quite some time to figure what went wrong after I uninstalled zcs.

Jut to be clear we don't use iptables in 3.0 M2 and forward.

[KevinH]

Originally Posted by lfarkas

ok. so it seems someone have to start to find out how can we drop packages one-by-one from the main zcs packages. than it'd be useful to documnet which packages are patched and which are the same as the upstream. ie. only sasl was modified? than if i'll have some free time, i'll try to drop as many packages from it as possible and document it.

We only patch SASL but the other packages are configured to run in /opt/zimbra so even if you remove our pkgs the local versions will not be configured to use the config tools we ship.

[lfarkas]

Originally Posted by KevinH

We only patch SASL but the other packages are configured to run in /opt/zimbra so even if you remove our pkgs the local versions will not be configured to use the config tools we ship.

this are hardcoded into the config tools or be able to configure the location of these pkgs?

[marcmac]

In order to accomplish this, you'd probably have to edit all of the scripts in bin and libexec, as well as the /etc/sudoers file. You'll also have to duplicate or adapt all of our config files to your versions/locations.

[halg]

Sorry I have not been on this forum until about a month ago when my gf found Zimbra and wanted me to install it. Like others here, I am concerned about multiple installations of, e.g., mysql server on the same Linux box.

Originally Posted by anand

You should think of the mysql instance inside the Zimbra mailbox
store as an embedded database.

I can think of it any way you want. Or any way I want. I have no problem conceptually. The concern is having multiple mysql servers, e.g., competing to serve the mysql service port.

So, without me having to try the Zimbra install to find out, can you just tell me if you modify /etc/services or other files in /etc ? Quotes, below, contraindicate each other in terms of what files external to /opt get modified by Zimbra. Do Zimbra apps use their own internal /etc/services-like file under /opt?

Originally Posted by anand

At this time, we have a LOT of people trying to install ZCS, and
kick the tires. Many of them would like that any trial install of
Zimbra not screw up their distro installation - everything being
in /opt/zimbra adds some insurance and level of comfort. Going
forward, for every new release with a lot of features that people
want to quickly install and try, they should feel comfortable that it is
not going to do "atrocious" things to their /etc directory. [One
person's atrocious is another persons normal. Such is life.]

I am not sure whether this paragraph was written in the current or future tense ("people...would like that any trial version ..."). Does the current release install EVERYTHING for Zimbra into /opt? Any exceptions we might want to know about? The install docs do not get into this much detail; they just tell you to disable any running versions of mysql, etc.

Originally Posted by KevinH

We only patch SASL but the other packages are configured to run in /opt/zimbra so even if you remove our pkgs the local versions will not be configured to use the config tools we ship.

Let's say what I have concluded so far is correct. How hard is it to get my SASL back to its original state?

Originally Posted by marcmac

In order to accomplish this, you'd probably have to edit all of the scripts in bin and libexec, as well as the /etc/sudoers file. You'll also have to duplicate or adapt all of our config files to your versions/locations.

I would hope you mean the bin and libexec under /opt, and not anywhere else under the Linux root directory?

So, /etc/sudoers is another file external to /opt that gets modified by Zimbra?

Again, can we get an impact listing of all the files external to /opt that get modified by Zimbra, either in installation or during administration and use of the running Zimbra system?

Sorry I am so damn anal about all this.

Thanks,
Hal

[marcmac]

This is an incomplete list:
/etc/passwd
/etc/group
/etc/sudoers
/etc/sysog.conf
/var/log/zimbra.log
/etc/ld.so.conf
/etc/logrotate.conf (or /etc/logrotate.d/zimbra, depending)
/var/spool/cron/zimbra (or wherever your distro keeps crontabs)
/etc/fstab

For a complete list - install it and find out - or download and peruse the source. (Which, if you're as concerned as you seem to be, is probably the best way to go).

To address some of your other points - how hard is it to get your sasl back to it's original state? Not hard at all, since we install our own sasl, and don't touch yours.

What about port conflicts?

We run sql on a non-standard port (7306). The only things we run on standard ports are the public services - http/s, ldap, smtp, pop/s, imap/s

Again, all of the questions you asked could be answered with a vmware download and a test installation.