Page 1 of 2 12 LastLast
Results 1 to 10 of 20

Thread: Fat Distribution Decision

  1. #1
    paintbuoy is offline Banned
    Join Date
    Sep 2005
    Posts
    7
    Rep Power
    0

    Question Fat Distribution Decision

    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


  2. #2
    anand is offline Zimbra Employee
    Join Date
    Sep 2005
    Posts
    274
    Rep Power
    9

    Default you raise some very good points

    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.

  3. #3
    omry_y is offline Starter Member
    Join Date
    Sep 2005
    Posts
    2
    Rep Power
    9

    Default atrocities

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

  4. #4
    lfarkas is offline Active Member
    Join Date
    Nov 2005
    Location
    Hungary
    Posts
    38
    Rep Power
    9

    Default

    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.

  5. #5
    KevinH's Avatar
    KevinH is offline Expert Member
    Join Date
    Aug 2005
    Location
    San Mateo, CA
    Posts
    4,789
    Rep Power
    19

    Default

    Quote 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.

  6. #6
    KevinH's Avatar
    KevinH is offline Expert Member
    Join Date
    Aug 2005
    Location
    San Mateo, CA
    Posts
    4,789
    Rep Power
    19

    Default

    Quote 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.

  7. #7
    lfarkas is offline Active Member
    Join Date
    Nov 2005
    Location
    Hungary
    Posts
    38
    Rep Power
    9

    Default

    Quote 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?

  8. #8
    marcmac is offline Expert Member
    Join Date
    Sep 2005
    Posts
    2,103
    Rep Power
    13

    Default binary locations

    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.

  9. #9
    halg is offline New Member
    Join Date
    Jan 2006
    Posts
    3
    Rep Power
    9

    Default Which files external to /opt get modified by Zimbra install and runtime?

    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.
    Quote 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?
    Quote 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.
    Quote 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?
    Quote 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

  10. #10
    marcmac is offline Expert Member
    Join Date
    Sep 2005
    Posts
    2,103
    Rep Power
    13

    Default files modified

    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.

Page 1 of 2 12 LastLast

LinkBacks (?)

  1. 11-26-2007, 01:54 AM

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. Nested distribution lists
    By Britt in forum Administrators
    Replies: 6
    Last Post: 05-10-2013, 04:01 AM
  2. Replies: 2
    Last Post: 12-10-2010, 04:19 AM
  3. Replies: 2
    Last Post: 01-24-2007, 03:53 AM
  4. Orphaned alias for a distribution list
    By area in forum Administrators
    Replies: 0
    Last Post: 09-17-2006, 08:22 PM
  5. Distribution list problem
    By achow in forum Users
    Replies: 1
    Last Post: 05-15-2006, 08:45 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •