Maldua's Zimbra FOSS Builds - Share your feedback

[Klug]

I just tried the search in GitHub (the same kind of search I made after previous patch was announced).
"org:Zimbra ZBUG-3794" still gives no answer.

By switching branch I was able to find fixed code about ZBUG-3794 just like you (and ZBUG-3816 but nothing about ZBUG-3817) in the GitHub web interface.

It might be GitHub related (indexing delay), I don't know. Or the fixed code only being a commit with no pull-request.
But it's true it's not hidden, it's there, you just have to search for it.

GitHub says the fix has been commited two weeks ago.
But I guess this branch was made public only when the announcement was made?
I cannot find this information (when the branch was made public) in GitHub web Interface.

[JDunphy]

So question for Synacor: Assuming that we are building from tags (and not from develop branches) are we properly updated if we just build 1 hour after the NE new patch announcement?

I would love to know this answer too because you have asked us to build by tags. If you are tagging individual FOSS repositories as you go in preparation for an eventual release patch; it is really important we know when to build because build.pl is pulling from a tag list we provide and will use the highest tag present and continues until it finds something from that list.

As an example: If this is our tag list.

Code: Select all

--git-default-tag=10.0.8,10.0.7,10.0.6,10.0.5,10.0.4,10.0.3,10.0.2,10.0.1,10.0.0-GA

And say there are 2 repositories to simplify the example... zm-admin-console and zm-mailbox. Lets say zm-mailbox was tagged 5 days ago at 10.0.8 and zm-admin-console is still tagged at 10.0.7 and you release Network version 10.0.8. We jump on the FOSS builds and pull in both these repositories and declare build 10.0.8 FOSS is available. Now 3 days after the release you update zm-admin-console and tag it at 10.0.8 which includes a critical security patch. That is the problem we are facing because we don't known when to build the FOSS version.

Currently showing the following 10.0.8 tags

Code: Select all

% ./build_zimbra.sh --show-tags |grep 10.0.8
10.0.8               2024-04-11 23:38:04            zm-admin-console    
10.0.8               2024-04-12 01:09:56            zm-aspell           
10.0.8               2024-04-11 23:42:34            zm-core-utils       
10.0.8               2024-04-11 23:49:10            zm-timezones        
10.0.8               2024-04-11 23:56:07            zm-web-client  

Please correct me if I am misunderstanding the issue and the build process given I am still trying to understand how it all works.

Jim

[ghen]

Additionally, 10.1.0 will be a bit more than 10.0.0 plus an additional tool. If you are a Network Edition customer, there is a Beta available (please contact the Sales for details). The Beta agreement includes an embargo, so you will not see information discussed here.

Hi John

What's the roadmap for RHEL 9 and Ubuntu 22 support? It was planned to be released with Zimba 10.1.0 (only), but I hear it's getting delayed once again.

For customers currently on RHEL 7 (EOL 30 June 2024), time to migrate is becoming *very* short (we prefer to skip RHEL 8 and move straight from 7 to 9).

[halfgaar]

Synopsis: about the zimbraCertAuthorityCertSelfSigned error. For me, it's because '/opt/zimbra/conf/ca/ca.pem' expired last month. Probably the difference in LDAP schema has solved itself in 10.0.8 from the last time I installed from the dev branch, but not sure.

Details:

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

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

For me, deployca seems to be the problem. The install log doesn't show the error, but the stdout on console did and mentioned ca.pem had expired:

Code: Select all

*** CONFIGURATION COMPLETE - press 'a' to apply
Select from menu, or press 'a' to apply config (? - help) a
Saving config in /opt/zimbra/config.23394...done.
Operations logged to /tmp/zmsetup.20240509-010113.log
Setting local config values...done.
Initializing core config...Setting up CA...O = CA, OU = Zimbra Collaboration Server, CN = meel.halfgaar.net
error 10 at 0 depth lookup: certificate has expired
error /opt/zimbra/conf/ca/ca.pem: verification failed
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 meel.halfgaar.net...already exists.
Setting Zimbra IP Mode...done.
Saving CA in ldap...failed.

-> it threw me back to bash then

And the CA indeed expired:

Code: Select all

# openssl x509 -text -in /opt/zimbra/conf/ca/ca.pem  | grep -A 3 Valid
        Validity
            Not Before: Apr 21 21:21:44 2019 GMT
            Not After : Apr 19 21:21:44 2024 GMT

I always use my own commercial certificate, so I'm unsure what this certificate authority (CA) is used for? I went into my records, and Apr 21 2019 was the day I scrambled for the famous remote code execution hack. So, in other words, I updated Zimbra (among others). Is that when these CAs are supposed to update?

This is related log stuff from the zmsetup log file:

Code: Select all

Thu May  9 01:01:14 2024 Adding /opt/zimbra/conf/ca/ca.pem to cacerts
Thu May  9 01:01:14 2024 *** Running as zimbra user: /opt/zimbra/bin/zmcertmgr addcacert /opt/zimbra/conf/ca/ca.pem
** Importing cert '/opt/zimbra/conf/ca/ca.pem' as 'zcs-user-ca' into cacerts '/opt/zimbra/common/lib/jvm/java/lib/security/cacerts'
** NOTE: restart mailboxd to use the imported certificate.
Thu May  9 01:01:16 2024 Upgrading from 10.0.6_GA_0124 to 10.0.8_GA_4200000

And about the LDAP schema differences, my post here shows the log excerpt, but there doesn't seem to be any actual invalid attributes? So, I'm not sure if that is also hitting me or not. Perhaps the development build of 10.0.6 is behind 10.0.8 enough that that is no longer a problem for me.

[adrian.gibanel.btactic]

For me, deployca seems to be the problem. The install log doesn't show the error, but the stdout on console did and mentioned ca.pem had expired:

Code: Select all

*** CONFIGURATION COMPLETE - press 'a' to apply
Select from menu, or press 'a' to apply config (? - help) a
Saving config in /opt/zimbra/config.23394...done.
Operations logged to /tmp/zmsetup.20240509-010113.log
Setting local config values...done.
Initializing core config...Setting up CA...O = CA, OU = Zimbra Collaboration Server, CN = meel.halfgaar.net
error 10 at 0 depth lookup: certificate has expired
error /opt/zimbra/conf/ca/ca.pem: verification failed
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 meel.halfgaar.net...already exists.
Setting Zimbra IP Mode...done.
Saving CA in ldap...failed.

-> it threw me back to bash then

And the CA indeed expired:

Code: Select all

# openssl x509 -text -in /opt/zimbra/conf/ca/ca.pem  | grep -A 3 Valid
        Validity
            Not Before: Apr 21 21:21:44 2019 GMT
            Not After : Apr 19 21:21:44 2024 GMT

I always use my own commercial certificate, so I'm unsure what this certificate authority (CA) is used for? I went into my records, and Apr 21 2019 was the day I scrambled for the famous remote code execution hack. So, in other words, I updated Zimbra (among others). Is that when these CAs are supposed to update?

This is related log stuff from the zmsetup log file:

Code: Select all

Thu May  9 01:01:14 2024 Adding /opt/zimbra/conf/ca/ca.pem to cacerts
Thu May  9 01:01:14 2024 *** Running as zimbra user: /opt/zimbra/bin/zmcertmgr addcacert /opt/zimbra/conf/ca/ca.pem
** Importing cert '/opt/zimbra/conf/ca/ca.pem' as 'zcs-user-ca' into cacerts '/opt/zimbra/common/lib/jvm/java/lib/security/cacerts'
** NOTE: restart mailboxd to use the imported certificate.
Thu May  9 01:01:16 2024 Upgrading from 10.0.6_GA_0124 to 10.0.8_GA_4200000

That seems to happen quite often.
If I'm not mistaken this is the original CA that Zimbra install, that's a self-signed certificate. When you install a commercial certificate it gets installed in another path and this original certificate (that the installer somehow tries to check always) does not get overwritten.

I tend to ignore that error.

[adrian.gibanel.btactic]

I'm running into the same issue with upgrading Ian's 10.0.6 (development build) to 10.0.8 now (Ubuntu 18.04). But I'm not sure what I'm supposed to see in terms of invalid attributes? This is my log:

Code: Select all

(...)
Thu May  9 01:02:11 2024 Marking zimbra-proxy as installed. Services for zimbra-proxy will be enabled.
Thu May  9 01:02:12 2024 Updating zimbraLDAPSchemaVersion to version '1673397105'
Thu May  9 01:02:12 2024 entering function: gcf zimbraLDAPSchemaVersion=1673397105
Thu May  9 01:02:12 2024 Updating cached global config attribute zimbraLDAPSchemaVersion=1673397105
Thu May  9 01:02:12 2024 *** Running as zimbra user: /opt/zimbra/bin/zmprov -r -m -l mcf  zimbraLDAPSchemaVersion '1673397105'
ERROR: account.INVALID_ATTR_NAME (invalid attr name: invalid attr name - unable to modify attributes: ldap host=meel.halfgaar.net:389: entry update failed) (cause: com.zimbra.cs.ldap.LdapException$LdapInvalidAttrNameException invalid attr name - unable to modify attributes: ldap host=meel.halfgaar.net:389: entry update failed)
Thu May  9 01:02:14 2024 Updating global config and COS's with attributes introduced after 10.0.6_GA...
Thu May  9 01:02:14 2024 *** Running as zimbra user: zmjava com.zimbra.cs.account.ldap.upgrade.LdapUpgrade -b 27075 -v 10.0.6_GA


--------------
com.zimbra.cs.account.ldap.upgrade.LdapUpgrade -b 27075 -v 10.0.6_GA
--------------

------------------------------
Upgrading global config:

Checking global config attribute: zimbraHelpModernURL[11.0.0]
    skipping - does not have a default value

Checking global config attribute: zimbraMailSieveScriptMaxSize[11.0.0]
    skipping - already has value: 0
    
etc
etc

And about the LDAP schema differences, my post here shows the log excerpt, but there doesn't seem to be any actual invalid attributes? So, I'm not sure if that is also hitting me or not. Perhaps the development build of 10.0.6 is behind 10.0.8 enough that that is no longer a problem for me.

That log excerpt was actually from zmsetup.log or from what you saw while you update Zimbra?
Be aware that there are some commands that are only shown in the log files.

[adrian.gibanel.btactic]

Also related to the LDAP schema differences I have started to think about a downgrade script draft using ldapmodify and similar tools.

Not sure when I will be able to delve some time onto that task.

[halfgaar]

That seems to happen quite often.
If I'm not mistaken this is the original CA that Zimbra install, that's a self-signed certificate. When you install a commercial certificate it gets installed in another path and this original certificate (that the installer somehow tries to check always) does not get overwritten.

I tend to ignore that error.

So you're thinking that it's not a fatal error? It's just that the last line on the stdout on my terminal was 'Saving CA in ldap...failed'. And the tail of zmsetup.log for it is:

Code: Select all

Updating local config and LDAP
Thu May  9 01:05:09 2024 done.
Thu May  9 01:05:09 2024 Creating server entry for meel.halfgaar.net...
Thu May  9 01:05:09 2024 Returning cached server config attribute for meel.halfgaar.net: zimbraId=be493fd4-02a5-4cc1-8ede-ce0a6a85848f
Thu May  9 01:05:09 2024 already exists.
Thu May  9 01:05:09 2024 Setting Zimbra IP Mode...
Thu May  9 01:05:09 2024 Updating cached config attribute for Server meel.halfgaar.net: zimbraIPMode=ipv4
Thu May  9 01:05:09 2024 *** Running as zimbra user: /opt/zimbra/bin/zmprov -r -m -l ms meel.halfgaar.net  zimbraIPMode 'ipv4'
Thu May  9 01:05:11 2024 done.
Thu May  9 01:05:11 2024 *** Running as zimbra user: /opt/zimbra/libexec/zmiptool >/dev/null 2>/dev/null
Thu May  9 01:05:22 2024 Saving CA in ldap...
Thu May  9 01:05:22 2024 *** Running as zimbra user: /opt/zimbra/bin/zmcertmgr deployca
** Saving config key 'zimbraCertAuthorityCertSelfSigned' via zmprov modifyConfig...failed (rc=2)
Thu May  9 01:05:25 2024 failed.

end-of-file

That log excerpt was actually from zmsetup.log or from what you saw while you update Zimbra?
Be aware that there are some commands that are only shown in the log files.

That came from zmsetup.log. I expected the invalid attributes to be listed, but it doesn't, and it formulates it really weird:

Code: Select all

ERROR: account.INVALID_ATTR_NAME (invalid attr name: invalid attr name - unable to modify attributes: ldap host=meel.halfgaar.net:389: entry update failed) (cause: com.zimbra.cs.ldap.LdapException$LdapInvalidAttrNameException invalid attr name - unable to modify attributes: ldap host=meel.halfgaar.net:389: entry update failed)

It says 'invalid attr name: invalid attr name', as though the attribute is an empty string.

Anyway, I can easily try the upgrade again because I have easy and fast virtual machine snapshots. So, I'll to run this before the upgrade next:

Code: Select all

/opt/zimbra/bin/zmcertmgr createca -new
/opt/zimbra/bin/zmcertmgr deployca

Also related to the LDAP schema differences I have started to think about a downgrade script draft using ldapmodify and similar tools.

Not sure when I will be able to delve some time onto that task.

I subscribed to the issue. I may fix my issue by hand, if ldap is indeed my problem, but it'd be a good tool.

[adrian.gibanel.btactic]

That seems to happen quite often.
If I'm not mistaken this is the original CA that Zimbra install, that's a self-signed certificate. When you install a commercial certificate it gets installed in another path and this original certificate (that the installer somehow tries to check always) does not get overwritten.

I tend to ignore that error.

So you're thinking that it's not a fatal error? It's just that the last line on the stdout on my terminal was 'Saving CA in ldap...failed'. And the tail of zmsetup.log for it is:

Code: Select all

Updating local config and LDAP
Thu May  9 01:05:09 2024 done.
Thu May  9 01:05:09 2024 Creating server entry for meel.halfgaar.net...
Thu May  9 01:05:09 2024 Returning cached server config attribute for meel.halfgaar.net: zimbraId=be493fd4-02a5-4cc1-8ede-ce0a6a85848f
Thu May  9 01:05:09 2024 already exists.
Thu May  9 01:05:09 2024 Setting Zimbra IP Mode...
Thu May  9 01:05:09 2024 Updating cached config attribute for Server meel.halfgaar.net: zimbraIPMode=ipv4
Thu May  9 01:05:09 2024 *** Running as zimbra user: /opt/zimbra/bin/zmprov -r -m -l ms meel.halfgaar.net  zimbraIPMode 'ipv4'
Thu May  9 01:05:11 2024 done.
Thu May  9 01:05:11 2024 *** Running as zimbra user: /opt/zimbra/libexec/zmiptool >/dev/null 2>/dev/null
Thu May  9 01:05:22 2024 Saving CA in ldap...
Thu May  9 01:05:22 2024 *** Running as zimbra user: /opt/zimbra/bin/zmcertmgr deployca
** Saving config key 'zimbraCertAuthorityCertSelfSigned' via zmprov modifyConfig...failed (rc=2)
Thu May  9 01:05:25 2024 failed.

end-of-file

Just to be clear I was referring to:

Code: Select all

error 10 at 0 depth lookup: certificate has expired
error /opt/zimbra/conf/ca/ca.pem: verification failed
done.
Deploying CA to /opt/zimbra/conf/ca ...done.
Setting replication password...done.

.

The other part:

Code: Select all

Saving CA in ldap...failed.

-> it threw me back to bash then

seems to be indeed a problem.

[liverpoolfcfan]

It is quite weird what the installation script is doing.

I have a LetsEncrypt certificate on my test server. I put the LetsEncrypt CA certificates (X1-Root, X2-Root, E1) into the file /opt/zimbra/conf/ca/ca.pem

It passes the "openssl verify" test - but the installation script goes ahead and creates a new CA cert regardless and deploys it.

Code: Select all

Thu May  9 16:38:51 2024 *** Running as root user: /opt/zimbra/common/bin/openssl verify -purpose sslserver -CAfile /opt/zimbra/conf/ca/ca.pem /opt/zimbra/conf/ca/ca.pem | egrep "^error 10"
Thu May  9 16:38:51 2024 *** Running as zimbra user: /opt/zimbra/bin/zmcertmgr createca 
** Using CA cert in '/opt/zimbra/ssl/zimbra/ca/ca.pem'
** Using CA private key in '/opt/zimbra/ssl/zimbra/ca/ca.key'
** Using Commercial CA cert in '/opt/zimbra/ssl/zimbra/commercial/commercial_ca.crt'
Thu May  9 16:38:52 2024 done.
Thu May  9 16:38:52 2024 Deploying CA to /opt/zimbra/conf/ca ...
Thu May  9 16:38:52 2024 *** Running as zimbra user: /opt/zimbra/bin/zmcertmgr deployca -localonly

It continues afterwards to recognise the existence of a commercial certificate and uses it.

All quite confusing!