I need know how to perform a update on all softwares included on zimbra pack. For example, i found here an tutorial about how to upgrade the clamav software:
Updating CLAMAV - Zimbra :: Wiki
But, i need upgrade ALL softwares used by zimbra, like spamassassign, amavisd, mysql, cyrus-sasl, openldap and postfix.
I'm asking about it, reminding the security fix on posfix and other softwares.
If today was announced a urgent patch to fix some serious security bug in one of these packages, how can I apply this patch?
Whereas sometimes there is no patch, but a new version with the bug fixed. How can I do this upgrade?
This is a very serious matter that the team zimbra should take into consideration.
Thankz.
How to perform an UPDADE of zimbra components
How to perform an UPDADE of zimbra components
I am also interested in knowing how to update third-party programs (postfix, ldap, mysql, etc..) security is very important.
How to perform an UPDADE of zimbra components
You don't update individual packages, you use the downloaded Zimbra version and update the complete stack of products.
How to perform an UPDADE of zimbra components
How long between each update? and what if an application needs an update urgently due to a critical error? How is the response time between the error and updating Zimbra?
***********************
Cuanto tiempo hay entre cada actualización? y que pasa si una de las aplicaciones necesita una actualización urgente debido a un error crÃÂtico? Cuánto es el tiempo de repuesta entre el error y la actualización de zimbra?
***********************
Cuanto tiempo hay entre cada actualización? y que pasa si una de las aplicaciones necesita una actualización urgente debido a un error crÃÂtico? Cuánto es el tiempo de repuesta entre el error y la actualización de zimbra?
How to perform an UPDADE of zimbra components
Look through the Product Portal and see how often Zimbra is updated and released.
How to perform an UPDADE of zimbra components
[quote user="10330phoenix"]You don't update individual packages, you use the downloaded Zimbra version and update the complete stack of products.[/QUOTE]
I have to disagree with this philosophy when it comes to antivirus and antispam products embedded in a larger application. The environment changes much more rapidly for antivirus products than does the Zimbra product as a whole.
Also, for some organizations, upgrading of the entire mail system just to satisfy the need for a single component update is not very practical. As an example, you don't upgrade a whole Exchange solution just because of a single component. In some cases, upgrading can break dependent services. Because of this, some upgrades are put off as long as possible and/or other workarounds are deployed instead of fixing the actual problem.
I would suggest to Zimbra that incorporating the ability to upgrade just the ClamAV engine through a Zimbra-supplied interface or script would allow Zimbra to maintain their quality-control standards while allowing the installed userbase to maintain an up-to-date and responsive antivirus solution between releases of complete Zimbra products.
I am a big fan of Zimbra and want to see it thrive. This is why I am posting my opinion and a suggested solution that can be a win-win for everyone.
Sincerely,
Chris Gauthier
Network Administrator
I have to disagree with this philosophy when it comes to antivirus and antispam products embedded in a larger application. The environment changes much more rapidly for antivirus products than does the Zimbra product as a whole.
Also, for some organizations, upgrading of the entire mail system just to satisfy the need for a single component update is not very practical. As an example, you don't upgrade a whole Exchange solution just because of a single component. In some cases, upgrading can break dependent services. Because of this, some upgrades are put off as long as possible and/or other workarounds are deployed instead of fixing the actual problem.
I would suggest to Zimbra that incorporating the ability to upgrade just the ClamAV engine through a Zimbra-supplied interface or script would allow Zimbra to maintain their quality-control standards while allowing the installed userbase to maintain an up-to-date and responsive antivirus solution between releases of complete Zimbra products.
I am a big fan of Zimbra and want to see it thrive. This is why I am posting my opinion and a suggested solution that can be a win-win for everyone.
Sincerely,
Chris Gauthier
Network Administrator
How to perform an UPDADE of zimbra components
Sorry, but I have to disagree with your comments about the updating of the AV engine. How many other mail systems integrate, out of the box, a AV engine ? I would bet Exchang$ does not have this and you would have to upgrade the third party software manually. That said it would be useful if there was a upgrade script, but the problem is the number of different releases of ZCS. The manual upgrade process is trivial; and at the end of the day how many people leave their install at default and do not try and tweak it in their own special kind of way 
How to perform an UPDADE of zimbra components
[quote user="k7sle"]I have to disagree with this philosophy when it comes to antivirus and antispam products embedded in a larger application. The environment changes much more rapidly for antivirus products than does the Zimbra product as a whole.[/QUOTE]The original question wasn't just about the A/V or A/S components. You can actually upgrade the A/V components, you search the forums for details, however, if you're an NE customer any changes you make to replace individual components will not receive support from Zimbra.
[quote user="k7sle"]Also, for some organizations, upgrading of the entire mail system just to satisfy the need for a single component update is not very practical. As an example, you don't upgrade a whole Exchange solution just because of a single component. In some cases, upgrading can break dependent services. Because of this, some upgrades are put off as long as possible and/or other workarounds are deployed instead of fixing the actual problem.[/QUOTE]How about the example of replacing the Postifx component of Zimbra? That would involve downtime for the whole mail system. The point about the integrated packages is they are modified to fit in with the Zimbra architecture, changing single components is more than just installing a single package, a complete install is somewhat trivial to do but obviously involves some unavailability of the mail system.
[quote user="k7sle"]I would suggest to Zimbra that incorporating the ability to upgrade just the ClamAV engine through a Zimbra-supplied interface or script would allow Zimbra to maintain their quality-control standards while allowing the installed userbase to maintain an up-to-date and responsive antivirus solution between releases of complete Zimbra products.
I am a big fan of Zimbra and want to see it thrive. This is why I am posting my opinion and a suggested solution that can be a win-win for everyone.[/QUOTE]If you have any suggestions on how the upgrade of individual components can be achieved then feel free to search bugzilla for any current RFEs or file a detailed request of your suggestions.
[quote user="k7sle"]Also, for some organizations, upgrading of the entire mail system just to satisfy the need for a single component update is not very practical. As an example, you don't upgrade a whole Exchange solution just because of a single component. In some cases, upgrading can break dependent services. Because of this, some upgrades are put off as long as possible and/or other workarounds are deployed instead of fixing the actual problem.[/QUOTE]How about the example of replacing the Postifx component of Zimbra? That would involve downtime for the whole mail system. The point about the integrated packages is they are modified to fit in with the Zimbra architecture, changing single components is more than just installing a single package, a complete install is somewhat trivial to do but obviously involves some unavailability of the mail system.
[quote user="k7sle"]I would suggest to Zimbra that incorporating the ability to upgrade just the ClamAV engine through a Zimbra-supplied interface or script would allow Zimbra to maintain their quality-control standards while allowing the installed userbase to maintain an up-to-date and responsive antivirus solution between releases of complete Zimbra products.
I am a big fan of Zimbra and want to see it thrive. This is why I am posting my opinion and a suggested solution that can be a win-win for everyone.[/QUOTE]If you have any suggestions on how the upgrade of individual components can be achieved then feel free to search bugzilla for any current RFEs or file a detailed request of your suggestions.
How to perform an UPDADE of zimbra components
[quote user="10330phoenix"]The original question wasn't just about the A/V or A/S components. You can actually upgrade the A/V components, you search the forums for details, however, if you're an NE customer any changes you make to replace individual components will not receive support from Zimbra.[/QUOTE]
I apologize if I misread the OP's question. I did not originally interpret that the OP wants to be able to update/upgrade any single component of Zimbra. On that point, I disagree with the OP. I'll comment on that below, however. My first interpretation is that it was primarily for AV. My concern is for AV because it is the most dynamic of the components with respect to definitions and engine updates. Definitions are a moot point and not at issue. However, in my experience, ClamAV engine updates appear to break Zimbra as soon as a new engine is released.
You are right, I *could* upgrade my AV component, except for three critical reasons stopping me:
1. Ubuntu 6.06 LTS Server (Zimbra server's platform) has GCC Bug PR28045 and cannot successfully complete the ./configure script for compiling ClamAV from source. (Upgrading my server is not a financially feasible option at this time, nor do I have the time to do so.)
2. I lose any support I might be allowed (no matter if it is NE or FOSS) by altering to a non-standard, non-supported configuration.
3. I don't have the expertise or time to research, test, and implement an upgrade to just ClamAV. At this point, I have taken the step of just disabling that service for my server. I have a whopping 3 mailboxes and about 6 aliases that are hosted by Zimbra because of its innovation and quality.
[quote user="10330phoenix"]How about the example of replacing the Postifx component of Zimbra? That would involve downtime for the whole mail system. The point about the integrated packages is they are modified to fit in with the Zimbra architecture, changing single components is more than just installing a single package, a complete install is somewhat trivial to do but obviously involves some unavailability of the mail system.[/QUOTE]
While my example of Exchange is not the strongest example out there, it is about as close as I can come because Exchange and Zimbra are about it when is comes to mail systems of this nature.
I am not really intending to suggest users be able to upgrade anything other than the ClamAV engine. I agree that it is impractical to upgrade other components like postfix or the imap daemon. Those components are really part of the core of Zimbra.
ClamAV is the part that seems to break things for me when it has an engine update. I do not upgrade every time there is a .01-incremented release of Zimbra partly because Zimbra "just works." I seem to hit Zimbra upgrades every .02-.04 versions apart. In addition, I do not have the luxury of the potential downtime in upgrading Zimbra and/or my operating system. While I do not have a large number of users, elderly parents tend to be constantly when their son's (my) mail server is down. It is also my primary form of electronic communication.
[quote user="10330phoenix"]If you have any suggestions on how the upgrade of individual components can be achieved then feel free to search bugzilla for any current RFEs or file a detailed request of your suggestions.[/QUOTE]
This is a good idea. I should do that. I have a question regarding submitting RFE bugs. How technical does an RFE need to be? Are the staff members who triage and assign these "bugs" looking for an implementation or would being able to explain my concept clearly and succinctly be sufficient?
Kind regards,
Chris
I apologize if I misread the OP's question. I did not originally interpret that the OP wants to be able to update/upgrade any single component of Zimbra. On that point, I disagree with the OP. I'll comment on that below, however. My first interpretation is that it was primarily for AV. My concern is for AV because it is the most dynamic of the components with respect to definitions and engine updates. Definitions are a moot point and not at issue. However, in my experience, ClamAV engine updates appear to break Zimbra as soon as a new engine is released.
You are right, I *could* upgrade my AV component, except for three critical reasons stopping me:
1. Ubuntu 6.06 LTS Server (Zimbra server's platform) has GCC Bug PR28045 and cannot successfully complete the ./configure script for compiling ClamAV from source. (Upgrading my server is not a financially feasible option at this time, nor do I have the time to do so.)
2. I lose any support I might be allowed (no matter if it is NE or FOSS) by altering to a non-standard, non-supported configuration.
3. I don't have the expertise or time to research, test, and implement an upgrade to just ClamAV. At this point, I have taken the step of just disabling that service for my server. I have a whopping 3 mailboxes and about 6 aliases that are hosted by Zimbra because of its innovation and quality.
[quote user="10330phoenix"]How about the example of replacing the Postifx component of Zimbra? That would involve downtime for the whole mail system. The point about the integrated packages is they are modified to fit in with the Zimbra architecture, changing single components is more than just installing a single package, a complete install is somewhat trivial to do but obviously involves some unavailability of the mail system.[/QUOTE]
While my example of Exchange is not the strongest example out there, it is about as close as I can come because Exchange and Zimbra are about it when is comes to mail systems of this nature.
I am not really intending to suggest users be able to upgrade anything other than the ClamAV engine. I agree that it is impractical to upgrade other components like postfix or the imap daemon. Those components are really part of the core of Zimbra.
ClamAV is the part that seems to break things for me when it has an engine update. I do not upgrade every time there is a .01-incremented release of Zimbra partly because Zimbra "just works." I seem to hit Zimbra upgrades every .02-.04 versions apart. In addition, I do not have the luxury of the potential downtime in upgrading Zimbra and/or my operating system. While I do not have a large number of users, elderly parents tend to be constantly when their son's (my) mail server is down. It is also my primary form of electronic communication.
[quote user="10330phoenix"]If you have any suggestions on how the upgrade of individual components can be achieved then feel free to search bugzilla for any current RFEs or file a detailed request of your suggestions.[/QUOTE]
This is a good idea. I should do that. I have a question regarding submitting RFE bugs. How technical does an RFE need to be? Are the staff members who triage and assign these "bugs" looking for an implementation or would being able to explain my concept clearly and succinctly be sufficient?
Kind regards,
Chris