Fat Distribution Decision

Post feedback about our hosted demo or your local install. Tell us what you love and/or what you’d like to see added in the future.
1117segleaur
Posts: 46
Joined: Fri Sep 12, 2014 9:55 pm

Fat Distribution Decision

Postby 1117segleaur » Wed Jan 25, 2006 12:47 am

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.


14319KevinH
Ambassador
Ambassador
Posts: 4558
Joined: Fri Sep 12, 2014 9:52 pm

Fat Distribution Decision

Postby 14319KevinH » Wed Jan 25, 2006 2:40 am

[quote user="1117segleaur"]- 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.[/QUOTE]


The current release allows you to set any HTTP/S port you'd like at install time.
1117segleaur
Posts: 46
Joined: Fri Sep 12, 2014 9:55 pm

Fat Distribution Decision

Postby 1117segleaur » Wed Jan 25, 2006 2:10 pm

[QUOTE]The current release allows you to set any HTTP/S port you'd like at install time.[/QUOTE]
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.
Counsel
Posts: 11
Joined: Fri Sep 12, 2014 10:01 pm

Fat Distribution Decision

Postby Counsel » Mon Jul 10, 2006 8:29 am

(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 user="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).
...

[/QUOTE]
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...
halg
Posts: 3
Joined: Fri Sep 12, 2014 10:03 pm

Fat Distribution Decision

Postby halg » Tue Jul 11, 2006 12:35 am

[quote user="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...[/QUOTE]


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.
gmsmith
Outstanding Member
Outstanding Member
Posts: 432
Joined: Fri Sep 12, 2014 10:09 pm

Fat Distribution Decision

Postby gmsmith » Tue Jul 11, 2006 7:59 am

[quote user="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.[/QUOTE]
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.
halg
Posts: 3
Joined: Fri Sep 12, 2014 10:03 pm

Fat Distribution Decision

Postby halg » Tue Jul 11, 2006 5:16 pm

[quote user="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.[/QUOTE]
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.
6629ezajko
Posts: 23
Joined: Fri Sep 12, 2014 10:00 pm

Fat Distribution Decision

Postby 6629ezajko » Wed Jul 12, 2006 7:21 am

Is anyone interested in building Community Zimbra Fat Distro (ZFD)?
It would be Zimbra OSS based
10119metux
Advanced member
Advanced member
Posts: 75
Joined: Sat Sep 13, 2014 2:29 am

Fat Distribution Decision

Postby 10119metux » Wed Mar 05, 2014 6:59 pm

Hi folks,


just digging out an ancient topic, as it is _still_ valid on various points:
[quote user="halg"]

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.

[/QUOTE]
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 user="halg"]

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.

[/QUOTE]
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 user="17629anand"]

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.

[/QUOTE]
Exactly the reason why one wants to use the target OS' packaging infrastructure.
[quote user="17629anand"]

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.

[/QUOTE]
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 user="17629anand"]

You should think of the mysql instance inside the Zimbra mailbox

store as an embedded database.

[/QUOTE]
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 user="17629anand"]

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.

[/QUOTE]
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 user="17629anand"]

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 user="17629anand"]

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.

[/QUOTE]
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 user="17629anand"]

We fully intend to track 3rd party package versions and stay

current - managing risk through our QA processes.

[/QUOTE]
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 user="17629anand"]

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

sure.

[/QUOTE]
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)

The">https://gallery.zimbra.com/type/extra/zcs-package-management-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
13537storm
Advanced member
Advanced member
Posts: 163
Joined: Fri Sep 12, 2014 10:10 pm

Fat Distribution Decision

Postby 13537storm » Thu Mar 20, 2014 5:48 am

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

Return to “Users”

Who is online

Users browsing this forum: No registered users and 5 guests