Maldua's Zimbra FOSS Builds - 2024 Year Feedback [Archive]

[adrian.gibanel.btactic]

---

Maldua's Zimbra FOSS Builds - Forum Threads

Please choose the current year feedback thread and submit your feedback there.

- Maldua's Zimbra FOSS Builds - 2024 Year Feedback [Archive] (This thread)
- Maldua's Zimbra FOSS Builds - 2025 Year Feedback
- Maldua's Zimbra FOSS Builds - 2026 Year Feedback [Current]











---

This thread is about getting feedback from Maldua's Zimbra FOSS Builds.

Releases can be found at the Maldua’s Zimbra Foss Builds Downloads Page.

I will be updating this thread when a new release is available.

Notes:

• These pre-releases will become releases if 15 days after being public there has not been any negative feedback.
• These are not official Zimbra/Synacor builds.

Updates made to this post:

• 2024 03 26: New fancy downloads page available where every release is shown.
• 2024 12 24: Thread becomes a 2024 archive.
• 2025 11 22: Thread becomes an index of archives.
• 2025 12 13: Updated links to new project url.
• 2026 01 10: 2025 thread is no longer the current one. 2026 thread is the new current thread.

[adrian.gibanel.btactic]

Hello,

Maldua's Zimbra 10.0.7 FOSS Builds have just been released.

Please share your experience when upgrading or installing from scratch.

Thank you very much!

Notes:

• This pre-release will become an stable release if 15 days after being public there has not been any major negative feedback.
• This is not an official Zimbra/Synacor build.

[scantec]

Hello,

Using your build to upgrade from 10.0.6 I always get "Saving config key 'zimbraCertAuthorityCertSelfSigned' via zmprov modifyConfig...failed (rc=2)" error (seen this before with other builds).

I suspect this has to do with different ldap schema as said on viewtopic.php?p=313162#p313162

Thanks

[JDunphy]

Hello,

Using your build to upgrade from 10.0.6 I always get "Saving config key 'zimbraCertAuthorityCertSelfSigned' via zmprov modifyConfig...failed (rc=2)" error (seen this before with other builds).

I suspect this has to do with different ldap schema as said on viewtopic.php?p=313162#p313162

Thanks

It was attempting to do this from tracking that message to zmcertmgr at saveConfKey (Note: I have converted it to corresponding command line syntax from perl):

Code: Select all

% zmprov -m -l modifyconfig zimbraCertAuthorityCertSelfSigned `cat /opt/zimbra/conf/ca/ca.key`

You can verify via this:

Code: Select all

% zmprov -m -l getconfig zimbraCertAuthorityCertSelfSigned

The -l means local ldap and the -m means master I believe ... In your install logs generated by the upgrade process, was there any mention of ldap issues or file permission with /opt/zimbra/conf/ca, etc, etc. Was it running? Do you have anything happening with ldap_is_master attribute?

Here is what I believe it wanted to do and from my upgrade of 10.0.5 FOSS to 10.0.7 FOSS

Code: Select all

Mon Mar 18 17:48:12 2024 Saving CA in ldap...
Mon Mar 18 17:48:12 2024 *** Running as zimbra user: /opt/zimbra/bin/zmcertmgr deployca
** Saving config key 'zimbraCertAuthorityCertSelfSigned' via zmprov modifyConfig...ok
** Saving config key 'zimbraCertAuthorityKeySelfSigned' via zmprov modifyConfig...ok
** Importing cert '/opt/zimbra/ssl/zimbra/ca/ca.pem' as 'my_ca' into cacerts '/opt/zimbra/common/lib/jvm/java/lib/security/cacerts'
** NOTE: restart mailboxd to use the imported certificate.
** Cleaning up 9 files from '/opt/zimbra/conf/ca'
...

Following the code is a little bit of a chore... zmsetup.pl -> zmupgrade.pm -> zmcertmgr if I understood what I was reading. No guarantee with perl ... but I believe it was the zmcertmgr deployca that caused your failure.

I build the same way so I should be looking at the correct code base for 10.0.7 FOSS. Maybe Adrian or others have some ideas.

Jim

[liverpoolfcfan]

@adrian

I notice that your 10.0.7 build reports that it was built with

Code: Select all

ENV_CACHE_CLEAR_FLAG=true ./build.pl --ant-options -DskipTests=true --git-default-tag=10.0.7,10.0.6,10.0.5,10.0.4,10.0.2,10.0.1,10.0.0-GA,10.0.0 --build-release-no=10.0.7 --build-type=FOSS --build-release=LIBERTY --build-release-candidate=GA-10.0.7-maldua --build-thirdparty-server=files.zimbra.com --no-interactive

However, The zm-build instructions for 10.0.6 list

Code: Select all

ENV_CACHE_CLEAR_FLAG=true ./build.pl --ant-options -DskipTests=true --git-default-tag=10.0.6,10.0.5,10.0.4,10.0.3,10.0.2,10.0.1,10.0.0-GA --build-release-no=10.0.0 --build-type=FOSS --build-release=LIBERTY --build-release-candidate=GA --build-thirdparty-server=files.zimbra.com --no-interactive

In your tag string you are including 10.0.0 in addition to 10.0.0-GA. Are you sure you ought to be doing so?

Is there a danger you might be pulling in some undesired files?

Vincent

[adrian.gibanel.btactic]

@adrian

I notice that your 10.0.7 build reports that it was built with

Code: Select all

ENV_CACHE_CLEAR_FLAG=true ./build.pl --ant-options -DskipTests=true --git-default-tag=10.0.7,10.0.6,10.0.5,10.0.4,10.0.2,10.0.1,10.0.0-GA,10.0.0 --build-release-no=10.0.7 --build-type=FOSS --build-release=LIBERTY --build-release-candidate=GA-10.0.7-maldua --build-thirdparty-server=files.zimbra.com --no-interactive

However, The zm_build instructions for 10.0.6 list

Code: Select all

ENV_CACHE_CLEAR_FLAG=true ./build.pl --ant-options -DskipTests=true --git-default-tag=10.0.6,10.0.5,10.0.4,10.0.3,10.0.2,10.0.1,10.0.0-GA --build-release-no=10.0.0 --build-type=FOSS --build-release=LIBERTY --build-release-candidate=GA --build-thirdparty-server=files.zimbra.com --no-interactive

In your tag string you are including 10.0.0 in addition to 10.0.0-GA. Are you sure you ought to be doing so?

Vincent

Yes, I'm sure.
The guy from Synacor has told me in another thread that 10.0.0 was not needed at all but he has never explained why. So I cannot take his word on this.
In any case it should not matter all. If it's true that 10.0.0-GA (or a more recent tag) is going to be available in all of the affected repos then 10.0.0 won't be used at all so... Why bother if it's there or not?

The build.pl script might be frightening to read but, in the end it loops through the --git-default-tag values till one of the specific tags/branches happen to exist and then it stops there for that repo.

[adrian.gibanel.btactic]

Hello,

Using your build to upgrade from 10.0.6

Can you confirm that your 10.0.6 build was built from develop branch and not from tags?
Maybe a build from @ianw1974 ?

[adrian.gibanel.btactic]

Using your build to upgrade from 10.0.6 I always get "Saving config key 'zimbraCertAuthorityCertSelfSigned' via zmprov modifyConfig...failed (rc=2)" error (seen this before with other builds).

When you start a new installation/upgrade they ask you to choose to a temporary file where the installation logs will be saved.
Is there anything else that has more output related to that command in that temporary file?

You can also use tail -f file.log to track in realtime what happens.

[adrian.gibanel.btactic]

Using your build to upgrade from 10.0.6 I always get "Saving config key 'zimbraCertAuthorityCertSelfSigned' via zmprov modifyConfig...failed (rc=2)" error (seen this before with other builds).

I suspect this has to do with different ldap schema as said on viewtopic.php?p=313162#p313162

Well, I don't think the error is related to the ldap schema because zimbraCertAuthorityCertSelfSigned exists in Maldua's ZCS FOSS 10.0.7.
However, I do not discard that you won't find the ldap schema issues described there if your ZCS FOSS 10.0.6 build is based on develop branch.
So, yes, I think it's worth for you to manually remove those ldap schema additional attributes (with a VPS snapshot before doing that).

I guess that this cannot be automated with any ldap related script because you are not adding data but removing it but I'm not an ldap expert.

[scantec]

Hello,

"The -l means local (file system access to the ldap sparse file I think) and bypasses the requirements for a running ldap and the -m means master I believe ... In your install logs generated by the upgrade process, was there any mention of ldap issues or file permission with /opt/zimbra/conf/ca, etc, etc. Do you have anything happening with ldap_is_master attribute?"

I don't get any mention to ldap issues or permissions.
I already tried to recreate/deploy ca before upgrade successfully but the error is the same.

This happened before when upgrading from 10.0.5 to 10.0.6 when I tried to upgrade with another build. The only solution was to upgrade with Ian build (which was the one used to upgrade from 8.8.15), that's why I suspect this has to do with different ldap schema/attributes

Thanks