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.
Themes Challenges
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).
We used
Code:
zmprov mcf -zimbraInstalledSkin <skinname>
to remove all of the test skins and the production custom skin, and then used
Code:
zmskindeploy /tmp/<prod_skin_name>
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
Code:
/^Content-Type: multipart\/report; report-type=delivery-status\;/ DISCARD No Third-Party DSNs
/^Content-Type: message\/delivery-status; / DISCARD No Third-Party DSNs
to the end of this file.
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):
Code:
zmmtactl reload
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:"
It would be nice to know that we can indeed safely ignore these errors; the header checks are definitely working.
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:
Code:
zmlocalconfig -e postfix_smtpd_banner="\$myhostname NO UCE ESMTP"
and then restarting the mailbox.
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.
Code:
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:
Code:
zimbraFeatureBriefcasesEnabled=FALSE
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:
Code:
zimbra@ourserver:~> zmcontrol status
Host ourserver.reliablenetworks.com
antispam Stopped
zmamavisdctl is not running
antivirus Stopped
zmamavisdctl is not running
zmclamdctl is not running
ldap Running
logger Running
mailbox Stopped
zmmailboxdctl is not running
mta Stopped
postfix is not running
saslauthd is not running
zmsaslauthdctl is not running
snmp Stopped
swatch is not running
spell Stopped
zmapachectl is not running
stats Stopped
zimbra@ourserver:~> zmcontrol stop
Host ourserver.reliablenetworks.com
Stopping stats...Done
Stopping mta...Done
Stopping spell...Done
Stopping snmp...Done
Stopping archiving...Done
Stopping antivirus...Done
Stopping antispam...Done
Stopping imapproxy...Done
Stopping mailbox...Done
Stopping logger...Done
Stopping ldap...Done
zimbra@ourserver:~> zmcontrol start
Host ourserver.reliablenetworks.com
Starting ldap...Done.
Starting logger...Done.
Starting mailbox...Done.
Starting antispam...Done.
Starting antivirus...Done.
Starting snmp...FAILED
Starting spell...Done.
Starting mta...Done.
Starting stats...Done.
zimbra@ourserver:~> SalesForce.com Zimlet
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:
Code:
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])
zimbra@ourserver:~>
Other Post-Upgrade Manual Changes
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,
Mark
Zimbra :: Bugzilla
Zimbra :: Wiki
5.0.4 > 5.0.5 
but I have never had any really issues yet 
(apart from user error 
)
you got me 
Linear Mode
