This is really appreciated. I have noticed an actual difference from what used to happen some years ago in this forum to nowadays. So... Thank you!
Zimbra 10 FOSS Installation Guide
- adrian.gibanel.btactic
- Outstanding Member

- Posts: 506
- Joined: Thu Jan 30, 2014 11:13 am
- Contact:
Re: Zimbra 10 FOSS Installation Guide
-
liverpoolfcfan
- Elite member

- Posts: 1217
- Joined: Sat Sep 13, 2014 12:47 am
Re: Zimbra 10 FOSS Installation Guide
Having tested all the alternatives, I am in no doubt that the only way to be successful in building/upgrading FOSS installations is to keep the basic build settings unaltered.
So,
PATCH_LEVEL must be left at GA. Adding anything further will sometimes break web client connectivity to the server, and will almost always break subsequent upgrades.
BUILD_NUMBER can be set - but has to be an integer. Hence the thought to use a 7-digit build number. 3-digit FOSS builder number (102 for me below) followed by a sequential 4-digit incrementing build number. Zimbra normally just uses the 4-digit incrementing build number.
BUILD_RELEASE is the only thing that looks safe to manipulate. Zimbra labels builds as JOULE, KEPLER and DAFFODIL for Release 8.8.15, 9.0 and 10.0 respectively. This can be seen in the Codename column on the https://wiki.zimbra.com/wiki/Zimbra_Releases page.
I have been working with Jim Dunphy on his build script https://wiki.zimbra.com/wiki/JDunphy-Co ... mbraScript and using an updated version I have seen no side effects thus far in adding details to the BUILD_RELEASE in the format of _<TagBuildRequested><TagBuildCloned><BuilderName> so , for example, the first build in the list below
RHEL8_64-KEPLER_T090000p321C090000p28ITS-900-20240418164143-FOSS-1020006
shows
RHEL8_64 - Platform
KEPLER - Release 9.0.0
_ - Extra data seperator
T090000p321 - The Tagged build requested was 9.0.0.p32.1
C090000p28 - The tagged build Cloned from the zm-build repository to build was 9.0.0.p28
ITS - The FOSS builder name supplied
900 - Zimbra's shorthand version number
20240418164143 - Zimbra's build timestamp
FOSS - Zimbra's identifier for a FOSS build
102006 - Build number consisting of 3-digit builder ID (102) followed by a 4-digit build sequence number.
Unfortunately, this added BUILD_NUMBER information does not show up anywhere in the webclient. It only shows in the name of build folder along with the builder's build number. The build number does show in the About box in the webclient, and it also forms part of the .tgz file produced so it ties everything together.
If you keep a log of builds as in the folder listing below, it is easy to tie a build number seen in the webclient back to what went into it.
Adopting these basic rules, I have built 5 releases
I have upgraded an 8.8.15.p45 standalone server through each of the 5 builds in turn, doing a basic smoke test on each build as I went, and apart from the 2 normal issues I encounter when upgrading to either 9 or 10 I have not seen any problems to date.
Normal issues encountered
/opt/zimbra/jetty_base/jetty.xml.in contains an embedded XML comment within a potentially commented block. This breaks the java XML parser and prevents zmmailboxdctl from starting following the upgrade. Deleting the spurious comment and restarting zmmailboxdctl resolves the issue. You will only encounter this if you disable HTTP compression - see viewtopic.php?p=313471 - Hopefully, this will get fixed before the next release.
/opt/zimbra/bin/zmcertmgr does not handle non-RSA certificates so it fails to handle my letsencrypt ECDSA certificates. I replace zmcertmgr with a patched version, and redeploy my "commercial" certificate. Note: I believe this might finally be fixed in the next release - fingers crossed.
Note: All of the above builds/upgrades were performed on Rocky Linux 8 (RHEL8 compatible). I do not have any Debian/Ubuntu servers to test the upgrade builds/installs on.
So,
PATCH_LEVEL must be left at GA. Adding anything further will sometimes break web client connectivity to the server, and will almost always break subsequent upgrades.
BUILD_NUMBER can be set - but has to be an integer. Hence the thought to use a 7-digit build number. 3-digit FOSS builder number (102 for me below) followed by a sequential 4-digit incrementing build number. Zimbra normally just uses the 4-digit incrementing build number.
BUILD_RELEASE is the only thing that looks safe to manipulate. Zimbra labels builds as JOULE, KEPLER and DAFFODIL for Release 8.8.15, 9.0 and 10.0 respectively. This can be seen in the Codename column on the https://wiki.zimbra.com/wiki/Zimbra_Releases page.
I have been working with Jim Dunphy on his build script https://wiki.zimbra.com/wiki/JDunphy-Co ... mbraScript and using an updated version I have seen no side effects thus far in adding details to the BUILD_RELEASE in the format of _<TagBuildRequested><TagBuildCloned><BuilderName> so , for example, the first build in the list below
RHEL8_64-KEPLER_T090000p321C090000p28ITS-900-20240418164143-FOSS-1020006
shows
RHEL8_64 - Platform
KEPLER - Release 9.0.0
_ - Extra data seperator
T090000p321 - The Tagged build requested was 9.0.0.p32.1
C090000p28 - The tagged build Cloned from the zm-build repository to build was 9.0.0.p28
ITS - The FOSS builder name supplied
900 - Zimbra's shorthand version number
20240418164143 - Zimbra's build timestamp
FOSS - Zimbra's identifier for a FOSS build
102006 - Build number consisting of 3-digit builder ID (102) followed by a 4-digit build sequence number.
Unfortunately, this added BUILD_NUMBER information does not show up anywhere in the webclient. It only shows in the name of build folder along with the builder's build number. The build number does show in the About box in the webclient, and it also forms part of the .tgz file produced so it ties everything together.
If you keep a log of builds as in the folder listing below, it is easy to tie a build number seen in the webclient back to what went into it.
Adopting these basic rules, I have built 5 releases
Code: Select all
BUILDS/RHEL8_64-KEPLER_T090000p321C090000p28ITS-900-20240418164143-FOSS-1020006/zcs-9.0.0_GA_1020006.RHEL8_64.20240418164143.tgz
BUILDS/RHEL8_64-KEPLER_T090000p39C090000p38ITS-900-20240418173146-FOSS-1020007/zcs-9.0.0_GA_1020007.RHEL8_64.20240418173146.tgz
BUILDS/RHEL8_64-DAFFODIL_T100005C100005ITS-1005-20240418195219-FOSS-1020008/zcs-10.0.5_GA_1020008.RHEL8_64.20240418195219.tgz
BUILDS/RHEL8_64-DAFFODIL_T100006C100006ITS-1006-20240418201252-FOSS-1020009/zcs-10.0.6_GA_1020009.RHEL8_64.20240418201252.tgz
BUILDS/RHEL8_64-DAFFODIL_T100007C100006ITS-1007-20240418203203-FOSS-1020010/zcs-10.0.7_GA_1020010.RHEL8_64.20240418203203.tgz
Normal issues encountered
/opt/zimbra/jetty_base/jetty.xml.in contains an embedded XML comment within a potentially commented block. This breaks the java XML parser and prevents zmmailboxdctl from starting following the upgrade. Deleting the spurious comment and restarting zmmailboxdctl resolves the issue. You will only encounter this if you disable HTTP compression - see viewtopic.php?p=313471 - Hopefully, this will get fixed before the next release.
/opt/zimbra/bin/zmcertmgr does not handle non-RSA certificates so it fails to handle my letsencrypt ECDSA certificates. I replace zmcertmgr with a patched version, and redeploy my "commercial" certificate. Note: I believe this might finally be fixed in the next release - fingers crossed.
Note: All of the above builds/upgrades were performed on Rocky Linux 8 (RHEL8 compatible). I do not have any Debian/Ubuntu servers to test the upgrade builds/installs on.
- halfgaar
- Outstanding Member

- Posts: 250
- Joined: Sat Sep 13, 2014 12:54 am
- Location: Netherlands
- ZCS/ZD Version: Ubuntu 22.04, Maldua/Btactic FOSS
- Contact:
Re: Zimbra 10 FOSS Installation Guide
The upgrades of zimbra-php and the others I mentioned have made their way into the 10.0 repo:
Code: Select all
zimbra-php:
Installed: 7.4.27-1zimbra8.7b3.18.04
Candidate: 8.3.0-1zimbra8.7b3.18.04
Version table:
8.3.0-1zimbra8.7b3.18.04 500
500 https://repo.zimbra.com/apt/1000 bionic/zimbra amd64 Packages
*** 7.4.27-1zimbra8.7b3.18.04 500
500 https://repo.zimbra.com/apt/1000 bionic/zimbra amd64 Packages
100 /var/lib/dpkg/status
7.3.25-1zimbra8.7b3.18.04 500
500 https://repo.zimbra.com/apt/1000 bionic/zimbra amd64 Packages
7.3.1-1zimbra8.7b3.18.04 500
500 https://repo.zimbra.com/apt/1000 bionic/zimbra amd64 Packages
5.6.31-1zimbra8.7b2.18.04 500
500 https://repo.zimbra.com/apt/87 bionic/zimbra amd64 Packages
500 https://repo.zimbra.com/apt/1000 bionic/zimbra amd64 Packages
Consider seriously: because of the history of exploits: block Zimbra web interface with VPN, firewall or HTTP proxy.
-
Klug
- Ambassador

- Posts: 2932
- Joined: Mon Dec 16, 2013 11:35 am
- Location: France - Drôme
- ZCS/ZD Version: All of them
- Contact:
Re: Zimbra 10 FOSS Installation Guide
The release notes for 9.0P40 and 10.0.8 (just got the mail) say it's PHP 8.0.3 (quite outdated) and not 8.3.0...
I guess the release notes are wrong.
I guess the release notes are wrong.
- adrian.gibanel.btactic
- Outstanding Member

- Posts: 506
- Joined: Thu Jan 30, 2014 11:13 am
- Contact:
Re: Zimbra 10 FOSS Installation Guide
Can you create a new thread about the Zimbra Builder ids (as I call them) or FOSS Builder numbers (as you call them) so that I can link to it from Maldua's documentation?liverpoolfcfan wrote: ↑Fri Apr 19, 2024 11:59 am BUILD_NUMBER can be set - but has to be an integer. Hence the thought to use a 7-digit build number. 3-digit FOSS builder number (102 for me below) followed by a sequential 4-digit incrementing build number. Zimbra normally just uses the 4-digit incrementing build number.
I'd rather not have not to maintain such a thread.
Thank you very much!
- Oldfart423
- Posts: 19
- Joined: Tue Aug 02, 2022 9:47 pm
- Location: US
- ZCS/ZD Version: 10.0.8 OSE (Lab test platform)
Re: Zimbra 10 FOSS Installation Guide
A bit late to the 10 FOSS party, and migrating a Zextras 9.0 FOSS build to Ian's 10.0.8.GA.0224.UBUNTU20.64 build, so far everything is running smooth. Big thanks to those that put these builds out, as I just assumed I would never have the option to upgrade to 10.x zimbra and considered moving away from zimbra.
I had a question for those running the FOSS builds, when it comes time to patch them, do we have to run through the upgrade/install process each time, or will it pull patches from the zimbra repos? I have yet to test that process and just want to make sure I have a path to maintain a patched version.
Thanks
I had a question for those running the FOSS builds, when it comes time to patch them, do we have to run through the upgrade/install process each time, or will it pull patches from the zimbra repos? I have yet to test that process and just want to make sure I have a path to maintain a patched version.
Thanks
Re: Zimbra 10 FOSS Installation Guide
Yes with one caveat. There is what is commonly called third party repository and Zimbra is currently providing these updates which arrive via the package mgmt for your distribution. Examples of what is in here are nginx, openssl, ldap, etc, etc. Then there is the stuff the community is building which is from Zimbra's public github which installs via the install.sh command. That is for both new installs and updates. Ian's scripts and builds are an example of this. I don't believe we have anyone building all the 3rd party yet. I believe there is one FOSS build that attempts to use repositories for their updates but I think it was ubuntu based and I have not tried it as we are RHEL 8 here. I also only run the network version in production so am participating in the FOSS to learn how it all works. I tried to list various projects here: https://wiki.zimbra.com/wiki/JDunphy-Co ... d_ProjectsOldfart423 wrote: ↑Tue Jun 11, 2024 12:14 pm I had a question for those running the FOSS builds, when it comes time to patch them, do we have to run through the upgrade/install process each time, or will it pull patches from the zimbra repos? I have yet to test that process and just want to make sure I have a path to maintain a patched version.
An addition point in case it isn't understood - There are FOSS builds based on tags (Zimbra will tag parts of the system in github and their build.pl script is smart enough to use the newest tag up to the tag specified) and what is referred to as the development branch. Ian's are the latest from development that is shared on github. Adrian's Maldua builds are based on tag builds. Zimbra has spent a lot of effort recently reworking documentation and the build scripts so that building by tags is possible and from my experimentation seems to work every time now. Unfortunately, that brings us to another caveat with mixing FOSS builds and tag build during updates. Sometimes if you are using the latest FOSS development version, the schema can be newer or contain new components that will be in the next release of Zimbra. If you attempted to upgrade your FOSS development build to a FOSS tag build there could be a potential for problems. FOSS Development builds are probably better thought of as date based builds and the tag builds are based on a closer approximation to the NETWORK versioning... 10.0.8, 8.8.15 P40, etc.
Having said that, it isn't clear to me that the NETWORK builds and the FOSS tag builds have every patch even if they claim the same version number... I would think the development version might have more patches but then you are getting a lot of other stuff that is incoming as they say. We have a few questions in these boards about this but I don't believe it has been answered completely what is going on with how they are managing their private repositories used in the NETWORK builds and the public repositories for builds that the FOSS community is using. If anyone has more information, please share.
Disclaimer: I do not run FOSS but that is my understanding of how it fits together.
HTH,
Jim
- Oldfart423
- Posts: 19
- Joined: Tue Aug 02, 2022 9:47 pm
- Location: US
- ZCS/ZD Version: 10.0.8 OSE (Lab test platform)
Re: Zimbra 10 FOSS Installation Guide
Definitely helps! Thank you for the detailed response. This is just a small test platform, so far it seems very solid.
Thanks again
Thanks again
-
innotelinc
- Posts: 25
- Joined: Tue Sep 05, 2023 3:49 pm
- Location: Springfield, MA, USA
- ZCS/ZD Version: Zimbra 10.1.10_GA_1270000
- Contact:
Re: Zimbra 10 FOSS Installation Guide
Here is the latest build I just built for Ubuntu 20
https://repo.innotel.us/zcs-10.0.8_GA_1 ... 203518.tgz
Please let me know if there are any issues
https://repo.innotel.us/zcs-10.0.8_GA_1 ... 203518.tgz
Please let me know if there are any issues
Zimbra 10.1.10_GA_1270000 (build 20250807191119)
ask me how @ dhunter@innotel.us
ask me how @ dhunter@innotel.us
Re: Zimbra 10 FOSS Installation Guide
After several days of work, I confirm the availability of Version 10.1 FOSS for Ubuntu 22.04 (no bug detected) and version 20.04.
For more information, contact me privately.
Here is the log of an update from 10.0 to 10.1 under Ubuntu 20.04:
For more information, contact me privately.
Here is the log of an update from 10.0 to 10.1 under Ubuntu 20.04:
Code: Select all
Running Post Installation Configuration:
Setting defaults from saved config in /opt/zimbra/.saveconfig/config.save
HOSTNAME=zimbra10.localhost.com
LDAPHOST=zimbra10.localhost.com
LDAPPORT=389
SNMPTRAPHOST=zimbra10.localhost.com
SMTPSOURCE=admin@zimbra10.localhost.com
SMTPDEST=admin@zimbra10.localhost.com
SNMPNOTIFY=yes
SMTPNOTIFY=yes
LDAPROOTPW=*
LDAPZIMBRAPW=*
LDAPPOSTPW=*
LDAPREPPW=*
LDAPAMAVISPW=*
LDAPNGINXPW=*
Restoring existing configuration file from /opt/zimbra/.saveconfig/localconfig.xml...done
Copying /tmp/install.log.PZOYiX0U to /opt/zimbra/log
Operations logged to /tmp/zmsetup.20240728-174701.log
Adding /opt/zimbra/conf/ca/ca.pem to cacerts
Upgrading from 10.0.0_GA_4518 to 10.1.0_GA_4633
Stopping zimbra services...done.
This appears to be 10.0.0_GA
Starting mysql...done.
Checking ldap status...not running.
Checking ldap status...not running.
Starting ldap...done.
Running mysql_upgrade...done.
Stopping mysql...done.
Updating zimbraLDAPSchemaVersion to version '1717060748'
Updating global config and COS's with attributes introduced after 10.0.0_GA...done.
Stopping ldap...done.
Upgrade complete.
Checking ldap status....not running.
Starting ldap...done.
Setting defaults...done.
Setting defaults from existing config...done.
Checking for port conflicts
Setting defaults from ldap...done.
Saving config in /opt/zimbra/config.29464...done.
Operations logged to /tmp/zmsetup.20240728-174701.log
Setting local config values...done.
Initializing core config...Setting up CA...done.
Deploying CA to /opt/zimbra/conf/ca ...done.
Setting replication password...done.
Setting Postfix password...done.
Setting amavis password...done.
Setting nginx password...done.
Creating server entry for zimbra10.localhost.com...already exists.
Setting Zimbra IP Mode...done.
Saving CA in ldap...done.
Saving SSL Certificate in ldap...done.
Setting spell check URL...done.
Setting service ports on zimbra10.localhost.com...done.
Setting Keyboard Shortcut Preferences...done.
Setting zimbraFeatureTasksEnabled=TRUE...done.
Setting zimbraFeatureBriefcasesEnabled=TRUE...done.
Setting TimeZone Preference...done.
Initializing mta config...done.
Setting services on zimbra10.localhost.com...done.
Adding zimbra10.localhost.com to zimbraMailHostPool in default COS...done.
Creating user spam.ij1zeepy@zimbra10.localhost.com...already exists.
Creating user ham.6htenikcn@zimbra10.localhost.com...already exists.
Creating user virus-quarantine.g2yv8mhuz9@zimbra10.localhost.com...already exists.
Setting spam training and Anti-virus quarantine accounts...done.
Configuring SNMP...done.
Setting up syslog.conf...done.
Setting zimbraLicenseNotificationEmail...done.
Configuring Onlyoffice...
Generating AllFonts.js, please wait...Done
Generating presentation themes, please wait...Done
Generating js caches, please wait...Done
Onlyoffice configuration done.
### [INFORMATION] => Restart all the service as zimbra user. Run zmcontrol restart. ###
# su - zimbra -c "zmcontrol restart"
Starting mysql...done.
Setting zimbraReverseProxySSLProtocols...done.
Setting mailboxd_java_options...done.
Setting zimbra_zmjava_options...done.
Setting ldap_common_tlsciphersuite...done.
Setting ldap_common_tlsprotocolmin...done.
Setting amavis_sslversion...done.
Setting java options...done.
Checking ldap status....not running.
Starting ldap...done.
Starting servers...done.
Enabling jetty logging...done.
Checking for deprecated zimlets...done.
Checking for network zimlets in LDAP...done.
Finished removing network zimlets.
Installing common zimlets...
com_zimbra_phone...done.
com_zimbra_mailarchive...done.
com_zextras_client...done.
com_zextras_zextras...done.
com_zimbra_webex...done.
com_zimbra_bulkprovision...done.
com_zimbra_tooltip...done.
com_zimbra_attachcontacts...done.
com_zimbra_url...done.
com_zimbra_ymemoticons...done.
com_zimbra_proxy_config...done.
com_zimbra_connect_classic...done.
com_zimbra_viewmail...done.
com_zimbra_adminversioncheck...done.
com_zimbra_gotourl...done.
com_zimbra_attachmail...done.
com_zimbra_email...done.
com_zimbra_date...done.
com_zimbra_srchhighlighter...done.
com_zimbra_connect_modern...done.
com_zimbra_cert_manager...done.
Finished installing common zimlets.
Getting list of all zimlets...done.
Updating non-standard zimlets...
Finished updating non-standard zimlets.
Restarting mailboxd...done.
Skipping creation of default domain GAL sync account - existing install detected.
Setting up zimbra crontab...done.
Moving /tmp/zmsetup.20240728-174701.log to /opt/zimbra/log
Configuration complete - press return to exit