Results 1 to 4 of 4

Thread: KISS (keeping things simple :)

  1. #1
    Join Date
    Sep 2005
    Posts
    6
    Rep Power
    10

    Default KISS (keeping things simple :)

    Hi guys,

    I went for an install on Debian Sarge - using the source package, building the RPM's, converting them to DEB files (debian packages) with alien, modifying the install.sh script (and friends) to use dpkg rather than rpm, and so on and so forth.

    My problem now is, that some of the precompiled packages depend on libraries that I don't have (which is no wonder) - for example openldap depends on a libssl that I don't have (and can't get for Sarge).

    What I would *love* to do, is, to use the existing Postfix, OpenLDAP, Apache, Tomcat, etc. etc. etc. packages - then, the Zimbra packages would not have to include all those other already existing already packaged applications.

    This would be a *major* benefit for security updates as well - if all the big packages come bundled together, you'd have to update all of them if there is a patch for one of them (you would be installing new Zimbra packages to get a simple fix for, for example, OpenLDAP).

    Now, is there any problem in just using the plain postfix, plain openldap and plain apache/tomcat?

    I guess that Zimbra is modifying the configuration files heavily and calling helper applications (newaliases from postfix for example), therefore I would have to tell Zimbra about the location of those applications and files. Or?

    Am I smoking crack, or would it indeed be possible to make Zimbra a really "light" distribution, not including half the known universe of packages?

    I'd really love to work on a Debian package for Zimbra, or just generally working on getting it to run smoothly there. Right now, I'm trying to figure out how to get it to run *and* retain my sanity, well, what's left of it anyway

    Where do I poke to tell Zimbra that postfix/apache/tomcat/openldap/mysql live somewhere else in the filesystem? Is it even possible or have you patched any of those applications so the 'native' ones can't do the job?

    Thanks

  2. #2
    Join Date
    Aug 2005
    Location
    San Mateo, CA
    Posts
    4,789
    Rep Power
    19

    Default

    You hit the nail right on the head. Our goal is to get to a Zimbra *light* type source release, which will allow you to point to your local versions. We just aren't there yet. We are working on un-wrapping the unportable things we use today namely iptables and rpm. Those work very well on Red Hat and friends. They don't work as well on other OS flavors. Once that is done we can focus on supporting more distros.

    So there is no magic bullet at this time. We will get there in stages, first unwrapping the incompatible things, then allowing support for more precompiled dependencies and finally the ability to just reference an existing dependency or the source.

    Getting to a Zimbra *light* also saves both you and us bandwidth so it's a good thing in the long run as well.

  3. #3
    Join Date
    Sep 2005
    Posts
    6
    Rep Power
    10

    Default

    Quote Originally Posted by KevinH
    We are working on un-wrapping the unportable things we use today namely iptables and rpm. Those work very well on Red Hat and friends.
    iptables: If one ran with standard postfix/apache/... there would be no reason to do port remapping. At least that is my oppinion as a security conscious administrator - I trust those applications to drop privileges, and I trust my security updates for whenever a flaw is discovered. (As I understand it, iptables is only needed for port remapping, which again is only needed because postifx/apache/... is run as the zimbra user - is that correct?)

    rpm: Well, if there's just one or two packages to install, the administrator will do apt-get or urpmi or rpm or whatever in order to install them - just as he does with any other package. As I see it, the need to work with rpm disappears as soon as Zimbra is distributed as "just Zimbra"


    Quote Originally Posted by KevinH
    So there is no magic bullet at this time. We will get there in stages, first unwrapping the incompatible things, then allowing support for more precompiled dependencies and finally the ability to just reference an existing dependency or the source.

    Getting to a Zimbra *light* also saves both you and us bandwidth so it's a good thing in the long run as well.
    As I see it, I can have postfix/apache/tomcat/openldap/mysql installed on my server in two minutes from now (apt-get install postfix openldap ...). Now, if I were to continue from there, I would need some way of telling the (also installed) Zimbra that it must call /usr/sbin/newaliases rather than /opt/zimbra/postfix/sbin/newaliases. I guess I can find out how to do that.

    But is there any fundamental reason why what I am trying to do will not be possible? Something I have overlooked? (like patches to the precompiled software giving it functionality that the standard versions don't have?)

    If not, I'll get right on to beating my Zimbra install with a very large hammer until it uses the standard postfix/openldap/...

    I *so* look forward to seeing this run

  4. #4
    Join Date
    Aug 2005
    Location
    San Mateo, CA
    Posts
    4,789
    Rep Power
    19

    Default

    iptables - Correct. We use it for port remapping. We are removing this use in future releases.

    rpm - Correct. Long term not everyone will use rpm.

    Here's a little more back ground on why we currently chose to "fat pkg"

    http://www.zimbra.com/forums/showthr...?p=513#post513

    We modify the config files of postfix/mysql/openldap, so our tools that look for those would have to be tweaked. Your also right that the zm* commands in /opt/zimbra/bin are in some caes copies of the standard commands so you'd need to link or point to those if you have the dependancies installed in diffent places. We also modify cyrus saslauthd to auth against our LDAP, so you'd have to use our version there. I can't think of anything else at the moment.

Posting Permissions

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