Page 2 of 2 FirstFirst 12
Results 11 to 20 of 20

Thread: Fat Distribution Decision

  1. #11
    segleaur is offline Active Member
    Join Date
    Sep 2005
    Location
    Somewhere south of the border at this point... nice and sunny
    Posts
    47
    Rep Power
    9

    Cool Looking into it...

    k, i'm a Roundcube user right now, and I am interested in a thin distrib for a few reasons, based on the fact that i use mac os x server for everything here:

    - i've got about 10 users that are off and on the server's network, and i decided to use opendirectory for everything (that means, client software management (forcing certain network options, software update servers, preferences, etc), AFP shares, centralised authentication, etc).

    - there are other websites (subdomains) running on the same server. from what i can tell from the other posts (i haven't had a chance to install or really look over the code yet, so i may not be accurate with this), it seems that zimbra owns http/s ports - which might make this a bit difficult.

    now, i don't care about running two instances of mysql, but it's not as simple as to reeningeer the built-in zimbra ldap to authenticate all users against everything else (such as AFP, FTP, console login, shells, radius).

    i don't even mind having to configure zimbra from a CLI, that's trivial (squirrelmail works that way, roundcube works that way - from vi, horde works that way - doesn't quite matter, i'm used to it by now).

    anyway, just a quick note on why this makes sense for me, but maybe it's not the case for everyone and i understand the zimbra team's position on preferring releasing fat distribs, instead of thin distribs.

    i'll look into it, if i can come up with something workable, i'll let you guys know.
    cheers,

    rodolfo

  2. #12
    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 segleaur
    - there are other websites (subdomains) running on the same server. from what i can tell from the other posts (i haven't had a chance to install or really look over the code yet, so i may not be accurate with this), it seems that zimbra owns http/s ports - which might make this a bit difficult.

    The current release allows you to set any HTTP/S port you'd like at install time.
    Looking for new beta users -> Co-Founder of Acompli. Previously worked at Zimbra (and Yahoo! & VMware) since 2005.

  3. #13
    segleaur is offline Active Member
    Join Date
    Sep 2005
    Location
    Somewhere south of the border at this point... nice and sunny
    Posts
    47
    Rep Power
    9

    Default

    The current release allows you to set any HTTP/S port you'd like at install time.
    cool. so that's one less thing to worry about. i could simply run it as https only, and have a redirect statement in, let's say the unsecure instance of apache to redirect http://webmail to https://webmail.
    cheers,

    rodolfo

  4. #14
    Counsel is offline Member
    Join Date
    Nov 2005
    Posts
    11
    Rep Power
    9

    Default

    (Likely this is obsolete and has been resolved, but I couldn't help but be troubled...)

    The software looks like it would solve many problems at small firms.

    However, if, in response to a question about how the software alters a system (and where it alters it), Zimbra responds:

    Quote Originally Posted by 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).

    ...
    I do not understand the thought process of Zimbra support here...

    Please tell me you have a list of what the installation process does to a linux distribution that the package is released under.

    I would hate to tell my clients, "Install it and find out..."

    I would recommend, from a support-oriented paradigm, that ZIMBRA install the package and find out. It is, after all, your software...

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

    Default

    Quote Originally Posted by Counsel
    (Likely this is obsolete and has been resolved, but I couldn't help but be troubled...)

    The software looks like it would solve many problems at small firms.

    However, if, in response to a question about how the software alters a system (and where it alters it), Zimbra responds:



    I do not understand the thought process of Zimbra support here...

    Please tell me you have a list of what the installation process does to a linux distribution that the package is released under.

    I would hate to tell my clients, "Install it and find out..."

    I would recommend, from a support-oriented paradigm, that ZIMBRA install the package and find out. It is, after all, your software...

    Thank you, Councel. It is good to know someone else out there is sensible.

    Well, I went ahead (months ago) and installed Zimbra and hoped it would not irreparably destroy my system if I tried to uninstall it. Zimbra was slower than a pig, thank you, even with 1GB and only 2 users testing it. So, no thanks, time to uninstall. It took me weeks to undo all of the changes, and even then the system did not seem to work as it did before (which had been perfect before I installed Zimbra).

    I ended up re-installing the entire Fedora system. Needless to say, I will never trust anything some cluck on a forum says when it comes to "just trust the system." Intuition told me I should not have trusted him, based on my years of admin and support experience. Shame on me.

    Now. Listen up: If you had pulled this garbage in a trading company, or a nuclear plant, or anywhere else uptime and fallback capability are critical to an operation, you would have been fired on the spot. I realize you don't get paid to do this work, but please be more careful with such advice in the future.

    Counsel is 100% correct. It is YOUR software, and therefore YOUR responsibility.

  6. #16
    gmsmith is offline Moderator
    Join Date
    Apr 2006
    Location
    Williamsburg, VA
    Posts
    451
    Rep Power
    9

    Default

    Quote Originally Posted by halg
    Thank you, Councel. It is good to know someone else out there is sensible.

    Well, I went ahead (months ago) and installed Zimbra and hoped it would not irreparably destroy my system if I tried to uninstall it. Zimbra was slower than a pig, thank you, even with 1GB and only 2 users testing it. So, no thanks, time to uninstall. It took me weeks to undo all of the changes, and even then the system did not seem to work as it did before (which had been perfect before I installed Zimbra).

    I ended up re-installing the entire Fedora system. Needless to say, I will never trust anything some cluck on a forum says when it comes to "just trust the system." Intuition told me I should not have trusted him, based on my years of admin and support experience. Shame on me.

    Now. Listen up: If you had pulled this garbage in a trading company, or a nuclear plant, or anywhere else uptime and fallback capability are critical to an operation, you would have been fired on the spot. I realize you don't get paid to do this work, but please be more careful with such advice in the future.

    Counsel is 100% correct. It is YOUR software, and therefore YOUR responsibility.
    Years of IT Management experience tells me when I am trying an application such as Zimbra, I do so on a machine that can be scrapped and rebuilt without impacting any production resources.

    There was something obviously wrong with your machine/install if it was slow for 2 users and you were using anything close to a modern processor and had normal resource availability.

    Zimbra is a complex application and interacts with the operating system. If you can't understand it, you have no business complaining about it if it doesn't work the way *you* expect it to work.

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

    Default You missed my point ...

    Quote Originally Posted by gmsmith
    Years of IT Management experience tells me when I am trying an application such as Zimbra, I do so on a machine that can be scrapped and rebuilt without impacting any production resources.

    There was something obviously wrong with your machine/install if it was slow for 2 users and you were using anything close to a modern processor and had normal resource availability.

    Zimbra is a complex application and interacts with the operating system. If you can't understand it, you have no business complaining about it if it doesn't work the way *you* expect it to work.
    Nope. That wasn't it.

    The issue wasn't about how the system works, or how it performed, or whether I understood how it worked. The issue was about fallback.

    I didn't care so much that I had to remove it from my system -- for whatever reasons you may care to attribute that decision -- it was simply that removing it from the system was more complex and insidious than I expected based on the "good advice" of someone on this list who thought I should take the very approach you suggested.

    Let's say for a moment that the system I tried out Zimbra on really was a "scrap and rebuild" machine. Let's say the system tested out OK and I deployed it to a live production machine. That's where the rub is.

    The installation instructions indicate that Zimbra should be the only application on the system. And it was in my case. I think the real lesson here is that, in the future, I will stay away from turn-key solutions like this that cannot co-exist with others or be rolled-back in a straight-forward fashion.

  8. #18
    ezajko is offline Intermediate Member
    Join Date
    Nov 2005
    Posts
    24
    Rep Power
    9

    Default Fat Distribution Decision - Anyone interested???

    Is anyone interested in building Community Zimbra Fat Distro (ZFD)?

    It would be Zimbra OSS based

  9. #19
    metux is offline Loyal Member
    Join Date
    Feb 2012
    Posts
    81
    Rep Power
    3

    Default

    Hi folks,


    just digging out an ancient topic, as it is _still_ valid on various points:

    Quote Originally Posted by halg View Post
    I didn't care so much that I had to remove it from my system -- for whatever reasons you may care to attribute that decision -- it was simply that removing it from the system was more complex and insidious than I expected based on the "good advice" of someone on this list who thought I should take the very approach you suggested.
    That's exactly one of the major reasons, why _any_ software should be properly packaged (using the target's packaging infrastructure).
    (and yes: I also apply this statement to embedded devices).

    In the meantime, situation had become a bit better: at least installer just pulls in a bunch of .deb's/.rpm's.
    But still it does it directly, instead of properly using package repositories. So, at the one hand, we cannot
    do automatic (non-interactive) installs, and also need to resolve external depencies manually.
    With a clean design it would be done simply via 'apt-get install' / 'yum install'.

    Quote Originally Posted by halg View Post
    Let's say for a moment that the system I tried out Zimbra on really was a "scrap and rebuild" machine. Let's say the system tested out OK and I deployed it to a live production machine. That's where the rub is.
    Another point why everything should go via the target platform's package management infrastructure:
    Once the operator has tested everything (being new install or upgrade) on a test system, he'll need to
    do that on the production system. And this process must be as simple/straightforward as possible.
    And there also needs a simple way back (quick downgrade - just in case of any problem).
    Especially for that tasks, it's very helpful when the operator can do that the usual way (IOW: the
    target platform's package management infrastructure), as he's very used to that and therefore
    can react quickly. (having to search around on the website to look for the previous version,
    download/unpack it and then run through the whole installer just eats up much time).

    ----

    Quote Originally Posted by anand View Post
    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.
    Exactly the reason why one wants to use the target OS' packaging infrastructure.

    Quote Originally Posted by anand View Post
    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.
    Why should Zimbra require removing SASL ?

    If you _really_ need your own (patched) SASL, just add your own
    'zimbra-sasl' package and install it to a different location, so it doesn't
    conflict with upstream.

    Pretty trivial.

    Not sure how it was in 2006, but today, the real change in SASL i can see is
    the additional (Zimbra/SOAP-based) auth mechanism - that can be done via
    an shared library, no need to directly patch the sasl package.

    Quote Originally Posted by anand View Post
    You should think of the mysql instance inside the Zimbra mailbox
    store as an embedded database.
    Having an separate mysql instance just for Zimbra certainly is not a bad idea
    (even though operators might want to use external servers for various reasons,
    eg. for optimized hardware or filesystem, etc).

    BUT: for that it's absolutely not required to bundle the whole package with Zimbra.
    Starting multiple mysql instances in different locations/configurations is _trivial_.

    Quote Originally Posted by anand View Post
    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.
    What kind of 'screwing up' ?
    Having some additional packages installed, certainly can't be a technical reason
    (maybe a ideological one, but that really shouldn't be of our business here ;-o).
    And once Zimbra is removed, those extra packages will be automatically removed
    by the package manager (if nobody else still uses them) - that's what a package
    manager is for.

    [QUOTE=anand;514]
    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.]
    [QUOTE]

    Well, putting system configuration somewhere else than /etc/ is a total break of FHS,
    and the definition of FHS has a lot of damn good reasons, I certainly dont wanna
    repeat here.

    Anyways, what stopped you from simply putting that stuff to /etc/zimbra/ ?

    Quote Originally Posted by anand View Post
    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.
    Pretty trivial: pick a number of supported distros (today, w/ IronMaiden, we only
    have four distros/versions), and properly support them. Folks with other distros
    should just pick one of the supported distros and put it into a jail/container.

    In fact, when looking at our customer installations (I think we're probably one
    of the largest partners in Germany), there's not a single Zimbra instance, which
    is not virtualized.

    Meanwhile, lxc is pretty mature in the mainline kernels, so it shouldn't be a big
    deal to fully put the whole thing into a container:

    * put everything on a recent debian stable
    * add your packages into your own repo
    * write a little (distro-specific) installer script, that just bootstraps the container
    with Zimbra and also add some wrapper scripts for easier maintenance
    from within the various distros.

    Yes, it could be that simple. In fact, Proxmox folks went pretty much that route
    from day one.

    Quote Originally Posted by anand View Post
    We fully intend to track 3rd party package versions and stay
    current - managing risk through our QA processes.
    Well, when I look at the current source tree, I see lots of really outdated packages.
    If you were using distros packages, everyone would automatically get security
    updates for all those 3rdparty packages directly from the distros. But with your
    approach, we need to wait until you guys someday (hopefully) kept up.

    Quote Originally Posted by anand View Post
    Should we have done thin packages to begin with? I am not so
    sure.
    I am absolutely sure: YES.
    And I'd even go a step further: you should have operated on package management
    based methodology from day one - beginning that in the source tree.

    And yes: having dozens of tarballs (and patches) for all the 3rdparty packages
    in one big-fat source tree is a really bad idea. Instead have a separate repo
    for each package (synced with upstream) and just rebase your patches onto the
    recent upstream releases. Individual packages should be built individually,
    using the target distro's package management infrastructure, and put into
    the corresponding binpkg repos, so they can be directly installed via the
    distro's package management.

    In fact, for all my projects, all packages are built and deployed through the
    target distro's packaging infrastructure and put into corresponding apt/yum repos.

    And this also includes Zimbra extensions (Zimlets, Skins, mailboxd extensions, etc),
    which are exclusively deployed zmpkg.

    Speaking of Zimbra extensions:

    The deployment process here still is pure horror. Everything that 'zmzimlet deploy'
    does is just unpacking the zip file to certain locations (plural!) and adds some record
    to LDAP. For _really trivial_ zimlets, that just contain of some javascript stuff, that
    _might_ be enough (assuming your javascript code doesnt conflict anywhere - especially
    when using certain 3rdparty libs), but as soon as you're doing slightly more complex
    things including java side, there's big trouble ahead:

    a) pretty likely you're going to use some Zimbra API which is not per default available
    in the zimlet container. So, you'll need to _manually_ symlink the right jar's there.

    b) if you're adding some jar's, they tend to land in ./lib/jars (hmm, why not in the
    zimlet container ?) - when removing the zimlet, they're NOT going to be removed
    automatically

    c) quite likely, you're going to use some 3rdparty libs there, which of course also
    need to be deployed. and pretty likely, some other zimlet will also be using/shipping
    this library, but perhaps in a different version. so the last one installed will win.

    d) for other things (eg. mailboxd extensions), there's not even any deployment
    mechanism whatsoever - everything needs to be done manually

    Absolutely unncessary to say that this is pure hell for operators.

    Therefore we've developed ZMPKG which is an dpkg/apt-based package management
    infrastructure, running inside Zimbra context (completely orthogonal to the OS/distro),
    so also running on rpm-based platforms. (we never ever deploy a single Zimbra
    extensions without zmpkg)

    https://gallery.zimbra.com/type/extr...ement-system-0

    The whole thing is GPL, and running on large-scale customers (thousands of users)
    for years now. We offered it for upstream inclusion about two years ago - talked
    talked w/ Thom and Jon. Firstly they seem very interested, but then simply stopped
    answering. No idea what happened behind the doors, but that could have been
    a MAJOR improvement to IronMaiden release. (it still was in beta stage at that time).

    In fact, after these years, I dont have the impression, that Zimbra folks aren't
    interested in any community contribution at all. Very sad.


    cu

  10. #20
    storm's Avatar
    storm is offline Advanced Member
    Join Date
    May 2006
    Location
    London, UK
    Posts
    181
    Rep Power
    9

    Default

    Your comments are right on the mark, metux.

    It's very sad that ZMPKG was not adopted, or at least an explanation given.

    Another reason for thin clients is that it would potentially increase distribution amongst small sized users, with the increased ease of discovery, install, and upgrade that comes with being within the major distributions repositories, and not being the psychological barrier that comes a download a website that entails extra work install and to regularly keep up-to-date.

    Zimbra is dichotomous, whether by intention or inadvertently, there is a kit of community involvement but it's fragmented and responses, collaboration between community Zimbra developers, and communication general is fragmented.

    Will Zimbra (ex Telligent) transform that.


    Sent from my HTC One using Tapatalk

Page 2 of 2 FirstFirst 12

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
  •