We completed the upgrade from 5.0.4 to 5.0.5 this weekend on one of our ZCS installations.
The upgrade went pretty well, but we did have some challenges. If anyone from Zimbra would like me to file a bug report, please let me know.
We had previously installed and then removed three test themes. These themes were reinstalled for some reason during the upgrade, and the final custom (production) theme was not (although the production theme's directory in the skins directory was still there).
to remove all of the test skins and the production custom skin, and then used
zmprov mcf -zimbraInstalledSkin <skinname>
to redeploy the custom skin.
At this point, the COSs using the custom production skin showed the skin in the list of themes (they had not after the upgrade) in the admin UI, and as before the upgrade, that custom skin was the only skin selected and authorized for that COS. Problem solved.
Postfix Header Checks
We are trying to reduce the amount of DSN backscatter sent to users on this system, generated by legitimate email servers responding to spam received with sender envelopes forged with the email addresses of users on this system.
A thread here in the forums describes a procedure to add two lines to /opt/zimbra/conf/postfix_header_checks.in comprising
to the end of this file.
/^Content-Type: multipart\/report; report-type=delivery-status\;/ DISCARD No Third-Party DSNs
/^Content-Type: message\/delivery-status; / DISCARD No Third-Party DSNs
What we saw when implementing this change is that the Zimbra scripts are apparently running postmap against this file, which as I understand from Postfix is unnecessary and generated the following errors (which we ignored):
It would be nice to know that we can indeed safely ignore these errors; the header checks are definitely working.
postmap: warning: /opt/zimbra/conf/postfix_header_checks.H21781, line 5: record is in "key: value" format; is this an alias file?
postmap: warning: /opt/zimbra/conf/postfix_header_checks.H21781, line 6: record is in "key: value" format; is this an alias file?
postmap: warning: /opt/zimbra/conf/postfix_header_checks.H21781.db: duplicate entry: "/^content-type:"
Postfix Localconfig.xml Changes Not Sticking
The lawyers want us to change the Postfix greet string, which we did under 5.0.4 by running:
and then restarting the mailbox.
zmlocalconfig -e postfix_smtpd_banner="\$myhostname NO UCE ESMTP"
This, and several other Postfix variables we added to localconfig.xml did not survive the upgrade. We had to redo this procedure to reenable the desired Postfix changes. The good news is, once added to localconfig.xml, the changes survive ZCS restarts.
The challenge is that we have now seen that some changes to localconfig.xml "stick" between version upgrades and some do not, so we had to recheck all of them to be sure.
Specifically, the additions below stuck between versions, though the helo change above did not.
postfix_smtpd_error_sleep_time = 3s
postfix_smtpd_hard_error_limit = 4
postfix_smtpd_soft_error_limit = 2
Briefcase Feature Becomes Unenabled - Sort Of
While running ./install.sh we noticed the following scroll by:
Previously, we had enabled the Briefcase feature on an account-by-account basis after our 4.5.11 > 5.0.4 upgrade via the Admin UI.
After the 5.0.5 upgrade, the Briefcase tab on the users' UI who had the Briefcase enabled was there, but clicking the tab just displayed a perpetual loading... in the Briefcase display area.
We haven't fixed this one yet.
In the Admin UI, both the Tasks and Briefcase items are checked in the Features tab for the COS to which these user accounts are subjected.
But, in the Admin UI on the Features tab for each individual account, though both Tasks and Briefcase are enabled, both have a Reset to COS value button, which doesn't make sense.
Not sure if we should open a bug report or a support ticket on this one; anyone else see anything else like this?
ZCS Fails To Restart After Server Reboot
This is not a new one for us; ZCS has never restarted cleanly after a server reboot. Also, it looks like snmp takes a while to start up as well, so the zmcontrol script report the startup as failed even though the Admin UI shows snmp is running.
Here's what we saw five minutes after the reboot:
zimbra@ourserver:~> zmcontrol status
zmamavisdctl is not running
zmamavisdctl is not running
zmclamdctl is not running
zmmailboxdctl is not running
postfix is not running
saslauthd is not running
zmsaslauthdctl is not running
swatch is not running
zmapachectl is not running
zimbra@ourserver:~> zmcontrol stop
zimbra@ourserver:~> zmcontrol start
This zimlet survived both the upgrade from 4.5.11 to 5.0.4 and the 5.0.4 to 5.0.5 upgrade, but the following code we used to have to run under 4.5.11 after each ZCS upgrade now fails. We are waiting to hear from a SF.com user today as to whether the zimlet is working properly without this code completing successfully:
Other Post-Upgrade Manual Changes
zimbra@ourserver:~> zmprov modifyCOS sfusers +zimbraProxyAllowedDomains '*.salesforce.com' *+zimbraProxyAllowedDomains '*.sforce.com'
ERROR: account.INVALID_ATTR_NAME (invalid attr name: [LDAP: error code 17 - ??+zimbraProxyAllowedDomains: AttributeDescription contains inappropriate characters])
All other post-upgrade manual changes (e.g. changes to local.cf) we have historically made were as-expected here.
Hope this info helps others,
All the best,