Migration of Single Node 8.8.15 with NG Modules to 10 Daffodil

[gabaker]

In the replies, they say there will be no extended support for 8.

I guess it's time to take another look at Carbonio.

Making us go through the work to do a major upgrade to 9.0 to get the extra year before also having to do another major upgrade to 10 is just silly and a waste of time.

[BradC]

https://blog.zimbra.com/2023/09/extendi ... -zimbra-9/
Now that 9 has been extended to end of 2024

Gotta say that wasn't a surprise.

we need support for 8.8.15 extended also until end of 2024 or until they have a way to get us migrated with the NG modules in use.

Can't see that happening, but I'd love to be wrong. 9 was released 3 years ago and I suppose the expectation is you'd "upgrade" to that, ng-warts and all. On the other hand Zimbra currently has no future LTS specified, so jumping from one LTS to the next is a non-starter (that's where I'd head). Most sane projects (such as the Linux kernel that Zimbra relies on) expressly state "x.x.x" is going to be our next LTS and gives you time to plan a migration while they still support the existing LTS (yes I know the kernel is an outlier as far as support goes). Moving from 8.8.x LTS to... well there's nothing to move to because it's not identified and even if it was there's no supported migration strategy for a proportion of customers.

[Klug]

Now that 9 has been extended to end of 2024, we need support for 8.8.15 extended also until end of 2024 or until they have a way to get us migrated with the NG modules in use.

9 is still using the NG modules, the upgrade from 8.8.15 is not that complicated (it's a standard major version upgrade, versus the upgrade from 9 to 10).
We should be able (next patch?) to disable the ModernUI so we don't get customers issues with it.

Upgrading to 9 with support till end of 2024 seems quite a good move to me.
Either you want to upgrade to 10 in the end or move to something else...

[JDunphy]

Rehearsing a 8.8.15 P43 upgrade to version 9 single server upgrade in-place. Hoping that Zimbra eventually with another year in development will make going to Version 10 fairly painless. Upgrade appeared to work with little changes to my custom configs on my system. I don't use Zimbra-connect, zimbra-archiving, zimbra-drive, zimbra-dns-cache, and anything beta so pretty plain network upgrade. Network NG modules took an extra step but they are working it would appear with one extra update and corresponding zmcontrol restart cycle.
What didn't work is that I am at P34 and not P36 according to zmcontrol -v?

Code: Select all

# su - zimbra
$ zmcontrol -v
Release 9.0.0_GA_3954.RHEL8_64_20200629045300 RHEL8_64 NETWORK edition, Patch 9.0.0_P34.
% exit
# yum clean metadata
# check-update
# yum update
Last metadata expiration check: 0:11:33 ago on Mon 18 Sep 2023 01:48:40 PM PDT.
Dependencies resolved.
Nothing to do.
Complete!
# cat /etc/yum.repos.d/zimbra.repo
[zimbra-90-oss]
name=Zimbra New RPM Repository
baseurl=https://repo.zimbra.com/rpm/90/rhel8
gpgcheck=1
enabled=1
[zimbra-90-network]
name=Zimbra New RPM Repository
baseurl=https://repo.zimbra.com/rpm/90-ne/rhel8
gpgcheck=1
enabled=1

Investigating.

Code: Select all

# dnf repoquery --whatprovides '*zmmailboxdmgr*'
Last metadata expiration check: 0:10:17 ago on Mon 18 Sep 2023 02:08:21 PM PDT.
zimbra-patch-0:9.0.0.1655029483.p25-2.r8.x86_64
zimbra-patch-0:9.0.0.1655187100.p25-2.r8.x86_64
zimbra-patch-0:9.0.0.1655455547.p25-2.r8.x86_64
zimbra-patch-0:9.0.0.1655472168.p25-2.r8.x86_64
zimbra-patch-0:9.0.0.1658845137.p26-2.r8.x86_64
zimbra-patch-0:9.0.0.1664354709.p27-2.r8.x86_64
zimbra-patch-0:9.0.0.1667906330.p28-2.r8.x86_64
zimbra-patch-0:9.0.0.1669440287.p29-2.r8.x86_64
zimbra-patch-0:9.0.0.1676464095.p30-2.r8.x86_64
zimbra-patch-0:9.0.0.1680535380.p32-2.r8.x86_64
zimbra-patch-0:9.0.0.1684843181.p33-2.r8.x86_64
zimbra-patch-0:9.0.0.1688906705.p34-2.r8.x86_64
zimbra-patch-0:9.0.0.1692275170.p35-2.r8.x86_64
zimbra-patch-0:9.0.0.1694187731.p36-2.r8.x86_64

# dnf install zimbra-patch-0:9.0.0.1694187731.p36-2.r8.x86_64
Last metadata expiration check: 0:11:48 ago on Mon 18 Sep 2023 02:08:21 PM PDT.
Package zimbra-patch-9.0.0.1694187731.p36-2.r8.x86_64 is already installed.
Dependencies resolved.
Nothing to do.
Complete!

Is this the expected behavior for upgrading 8.8.15 to 9.0 Network?

Very odd.

Code: Select all

% dnf reinstall zimbra-patch-0:9.0.0.1694187731.p36-2.r8.x86_64
Last metadata expiration check: 0:05:58 ago on Mon 18 Sep 2023 02:30:44 PM PDT.
Dependencies resolved.
=========================================================================================================================================================================
 Package                              Architecture                   Version                                             Repository                                 Size
=========================================================================================================================================================================
Reinstalling:
 zimbra-patch                         x86_64                         9.0.0.1694187731.p36-2.r8                           zimbra-90-network                         106 M

Transaction Summary
=========================================================================================================================================================================

Total download size: 106 M
Installed size: 234 M
Is this ok [y/N]: y
Downloading Packages:
zimbra-patch-9.0.0.1694187731.p36-2.r8.x86_64.rpm                                                                                         66 MB/s | 106 MB     00:01    
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total                                                                                                                                     66 MB/s | 106 MB     00:01     
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
...
$ zmcontrol -v
Release 9.0.0_GA_3954.RHEL8_64_20200629045300 RHEL8_64 NETWORK edition, Patch 9.0.0_P36.

Doesn't leave one with a lot of trust with the update process. It's going to take me some time to trust version 9 with this first impression.

Jim

[gabaker]

Jim,
Thanks for posting your results on the in-place upgrade from 8.8.15 to 9. This is the route that I am going to go as well since there is no good documented way to go directly to 10.
Nice to hear that it was relatively painless, except for the Patch number. Interestingly, I had the same happen when going to P42 on the 8.8.15 branch. After patch process was complete, my version still is showing P41. In the thread about P42, I noticed others experiencing the same issue. However, the necessary patching was done (installer simply removed some offending files) but it seems that the patcher is a bit dodgy with updating the patch level reported. I'm unaware of the mechanics of that, but it is nice to see that a reinstall of the patch on your 9 system got it sorted. I will see if my 8.8.15 reports the proper patch level after I install P43 (yet to be done)

When I get to doing my upgrade to 9, I will try to post results as well.

Cheers

[ghen]

The 8.8.15 P41 and P42 patches, as well as 9.0.0 P35 and P36, contain no rebuilt binaries, only removing certain JSP files + a small client-side XSS fix.
It's the server-side binaries that report the version number, so in this case it's unchanged, since the server binaries didn't change.
Usually patches contain more changes and bump the server-side version as well, but in this case it exceptionally didn't happen, as stated by Zimbra.

Thanks for reporting your successful upgrade from 8.8.15 to 9.0.0, we are planning the same while waiting for Zimbra 10.1 next year, for RHEL 9 support.

[dbayer]

Thank you Jim for posting your upgrade Experience. Couple of questions.

1. Can you link to any documentation you followed?
2. Does 9 default to using the classic interface, or do you have to configure it to do so?

Thanks,
Daniel

[JDunphy]

Hi Daniel,

My login went to the classic theme. The initial login screen has a new look however. There is also a pull down menu where they can choose classic. I just checked a few user accounts because of your question and they have their existing themes. I also checked the default CoS and it's our normal default theme.

We use a corporate logo on our login screen and then a slightly different logo after they authenticate so they are trained if they don't see the expected logo to contact me as they could have been phished. I should also mention there is a bug from my perspective... the database or html will point to your links but the filesystem will not contain those logo's for some upgrades. We have patch scripts that fix that on any upgrade but that is something to be aware of. One of the upgrades got me years ago... their browser kept it cached for 2-3 days and then wham, my phone started ringing days later when they arrived after a long weekend and the logo's were missing. My testing failed to uncover that browser caching was pulling those logo's locally. Yikes.

A few comments. The zimbra image I am using is what I have been kicking around since version 5. With the exception of moving from 32bit to 64bit OS years and years ago which was more manual, the process for this single server for me has always been in place upgrade with install.sh

My process for this initial rehearsal was:

Take snapshot of working production server which for me was using one of my backups so I could test my disaster recovery. I am also using this time to test moving from one data center to another so throwing a few things in this rehearsal. Fire it up, change some entries for the new ip in /etc/hosts, update the ip for the host and update my local dns server and make sure /etc/resolv.conf points to it. Reboot server, verify zimbra came up clean and on to the upgrade. On my desktop, I create an entry for /etc/hosts and use one of the SAN's from my certificate for this zimbra instance. That is what I will use with my local browser to test the environment.

Next I take an OS snapshot of this 8.8.15P43 working server because I will probably do this a few times I suspect and want to go back.

Then it was time.

Code: Select all

% wget 'https://files.zimbra.com/downloads/9.0.0_GA/zcs-NETWORK-9.0.0_GA_3954.RHEL8_64.20200629045300.tgz'
% tar xvf zcs-NETWORK-9.0.0_GA_3954.RHEL8_64.20200629045300.tgz
# cd zcs-NETWORK-9.0.0_GA_3954.RHEL8_64.20200629045300
# ./install.sh

Answer the questions about what modules I want installed, and it worked other than the curious patch display problem. I then went through my patch scripts that I apply after every upgrade or patch to see what needs to be changed and most things remained unchanged to my surprise. Felt very much like one of our uneventful patches to 8.8.15 and it was surprisingly quick.

When I logged in with my browser, no issues at all and admin and my user accounts have 2FA enabled and that worked perfectly too.

Read a few messages, looked around the admin interfaces, checked the logs and shutdown the instance.

I needed some more practice time with Backup NG so thought I would test some delete/restore scenarios today as it's been a while and I have forgot everything. Still waiting on the restore as it been running all day.

So long message to say... install.sh

Jim

[dbayer]

Hi Jim,

Thank you for that detailed explanation. That is very helpful.

It's been a while since I've done a restore as well. So like you, I might take advantage of the upgrade and do a practice run.

Good luck with the rest of your testing.

Thanks,
Daniel

[L. Mark Stone]

We use a corporate logo on our login screen and then a slightly different logo after they authenticate so they are trained if they don't see the expected logo to contact me as they could have been phished. I should also mention there is a bug from my perspective... the database or html will point to your links but the filesystem will not contain those logo's for some upgrades. We have patch scripts that fix that on any upgrade but that is something to be aware of. One of the upgrades got me years ago... their browser kept it cached for 2-3 days and then wham, my phone started ringing days later when they arrived after a long weekend and the logo's were missing. My testing failed to uncover that browser caching was pulling those logo's locally. Yikes.

Hi Jim,

To avoid this issue we put the app banner and login logos on an S3 bucket that is open to the public. You can also use any https web server you like.

The locations of those files, both globally and on a per-domain basis, are stored in LDAP. You can indeed input a proper URL instead of a file system location in those attributes.

Doing so means you eliminate the above problem.

Code: Select all

zimbra@mail:~$ zmprov gacf | grep zimbraSkinLogo | grep Banner
zimbraSkinLogoAppBanner: https://s3.amazonaws.com/public.xxx.yyy/AppBanner.png
zimbraSkinLogoLoginBanner: https://s3.amazonaws.com/public.xxx.yyy/LoginBanner.png
zimbra@mail:~$ 

Hope that helps,
Mark