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.
Fat Distribution Decision
-
14319KevinH
- Ambassador
- Posts: 4558
- Joined: Fri Sep 12, 2014 9:52 pm
Fat Distribution Decision
[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.
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
[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.
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.
Fat Distribution Decision
(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...
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...
Fat Distribution Decision
[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.
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.
Fat Distribution Decision
[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.
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.
Fat Distribution Decision
[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.
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
Is anyone interested in building Community Zimbra Fat Distro (ZFD)?
It would be Zimbra OSS based
It would be Zimbra OSS based
-
10119metux
- Advanced member
- Posts: 75
- Joined: Sat Sep 13, 2014 2:29 am
Fat Distribution Decision
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/z ... t-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
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/z ... t-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
- Posts: 163
- Joined: Fri Sep 12, 2014 10:10 pm
Fat Distribution Decision
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
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