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 releasesI 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:
BUILDS/RHEL8_64-KEPLER_T090000p321C090000p28ITS-900-20240418164143-FOSS-1020006/zcs-9.0.0_GA_1020006.RHEL8_64.20240418164143.tgzBUILDS/RHEL8_64-KEPLER_T090000p39C090000p38ITS-900-20240418173146-FOSS-1020007/zcs-9.0.0_GA_1020007.RHEL8_64.20240418173146.tgzBUILDS/RHEL8_64-DAFFODIL_T100005C100005ITS-1005-20240418195219-FOSS-1020008/zcs-10.0.5_GA_1020008.RHEL8_64.20240418195219.tgzBUILDS/RHEL8_64-DAFFODIL_T100006C100006ITS-1006-20240418201252-FOSS-1020009/zcs-10.0.6_GA_1020009.RHEL8_64.20240418201252.tgzBUILDS/RHEL8_64-DAFFODIL_T100007C100006ITS-1007-20240418203203-FOSS-1020010/zcs-10.0.7_GA_1020010.RHEL8_64.20240418203203.tgzNormal 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.
Statistics: Posted by liverpoolfcfan — Fri Apr 19, 2024 11:59 am