Migration of zcs-9.0.0_ZEXTRAS_20221203.UBUNTU18_64.20221216110428 to zcs-9.0.0_ZEXTRAS_20221203.UBUNTU20_64.20221216110431

Not clear what you are doing but this is fairly common when someone attempts rsync to a different os version.  Here is what causes this every time.

* install.sh -s (install software only) so now /opt/zimbra is populated

* mv /opt/zimbra /opt/zimbra-

* rsync old server onto /opt/zimbra

Wait... did you just blow away the version of perl's compiled modules that you installed in step 1 because now you have a mix-match of a different  OS versions of those perl .so modules in /opt/zimbra.  Yep.  Those compiled modules have to match the perl they were compiled against. 

solution is simple enough... run install.sh -s one more time after your rsync or re-install the perl components from you current OS.

Hope this makes sense.  Pretty good reference here. 

Ref: https://forums.zimbra.org/viewtopic.php?p=301880#p301880

HTH,

Jim

Hi Jim,

Thanks for your reply.

It helped quite a bit. But the thing is, I'm trying to migrate from ubuntu 18.02 to 20.02, with new hostname and new ip-address.

So that's a bit different. But running the ./install -s for the second time, after rsyncing /opt/zimbra brings me further in the process. But now I'm stuck with ldap that doesn't start.

This is what I did:

1]  ./install.sh -s

2]  /opt/zimbra → rm-rf *

3]  (on old server) rsync --progress -avzrlHS -e ssh /opt/zimbra/* root@:/opt/zimbra/

4]  (back to new server) /opt/zimbra/libexec/zmfixperms -extended -v

5]  ./install.sh -s

6]  edit /opt/zimbra/.saveconfig/config.save to rename every reference to the old server name

7]  cp /opt/zimbra/.saveconfig/config.save /opt/zimbra/.saveconfig/config.new

8]  ./install.sh --force-upgrade /opt/zimbra/config.new

9]  followed the instructions to export/import ldap data

10]as zimbra user -> zmcontrol start

Then it says:

Host
Starting ldap...Done.

Failed.
/opt/zimbra/libexec/zmslapd: line 23: /opt/zimbra/common/libexec/slapd: No such file or directory
/opt/zimbra/libexec/zmslapd: line 23: /opt/zimbra/common/libexec/slapd: No such file or directory
/opt/zimbra/libexec/zmslapd: line 23: /opt/zimbra/common/libexec/slapd: No such file or directory
/opt/zimbra/libexec/zmslapd: line 23: /opt/zimbra/common/libexec/slapd: No such file or directory
/opt/zimbra/libexec/zmslapd: line 23: /opt/zimbra/common/libexec/slapd: No such file or directory
/opt/zimbra/libexec/zmslapd: line 23: /opt/zimbra/common/libexec/slapd: No such file or directory
/opt/zimbra/libexec/zmslapd: line 23: /opt/zimbra/common/libexec/slapd: No such file or directory
Failed to start slapd. Attempting debug start to determine error.

don't know where to go from here...

Hope there is some help left.

Thanks!

Joost

Hi Joost,

A couple of suggestions for your steps.

1. Step 4 and 5.  install.sh -s will do that fixperms
2. Step 0... put the old zmhostname name in /etc/hosts with the new ip address
3. After Step 5, put ldap in it's place.  I tar the ldap data file with the sparse option and exclude  data.mdb (ldap) when I rsync
4. So After install.sh -s for the second time, I would extract ldap in place via the tar image
5. I would then run install.sh - this will fix almost everything and should leave you with a running machine

So for me, I do:

• /etc/hosts - new ip but old name (zmhostname)
• install.sh -s
• get /opt/zimbra into place from old machine
• install.sh -s
• drop ldap into place - tar or zimbra's practice using ldap commands
• install.sh 

I don't do fixperms as that is called by install.sh. That last option is pretty good at fixing and doing everything required to bring it back.

I will also go to the trouble of running a local dns server with the zmhostname that has an entry for this new machine so the illusion is complete... zmhostname would have the ip address from this new machine in /etc/hosts and if it attempted to use /etc/resolv.conf via 127.0.0.1 for a lookup.  I think that named (BIND9) step is probably extra but that is what I do. This is only for the installation and afterwords, I use a different configuration for named. I do not run Zimbra's dns resolver.

At this point, you should have a running zimbra but MUA's like thunderbird or outlook can't send email yet and your hostname is incorrect. Web interfaces should all work.  Last step is to then fix it so the MUA's can send by updating ZimbraMtaMyNetworks and either waiting for zmconfigd or updating amavisd.conf, sauser.cf, opendkim-localnets.conf ... basically anywhere the old ip exists. As far as hostname, it can be different unless you are talking about zmhostname but not enough information at this point to help. ldap can be configured to use the hosts ip address or name.  Here it uses the name of the host which is why /etc/hosts has to have that name in it.

tip: modify your desktop's /etc/hosts for this new machine so you can test the new machine with your browser and verify what you expect before cut over.

I use 8.8.15 but this should apply to version 9.

HTH,

Jim

Hi Jim,

Still didn't have the time to try it after your last post. I will give this a go in about two weeks time. Thank you for your help so far!

If I understand correctly these are the steps:

1. setup a servers with new IP but the same zmhostname as original server

2. install.sh -s

3. /opt/zimbra → rm-rf *

4. (on old server)

rsync --progress --delete --archive --verbose --hard-links --exclude=zimbra/data/ldap/mdb/db/data.mdb --exclude zimbra/data/ldap/accesslog/db/data.mdb --exclude zimbra/data/ldap/config/db/data.mdb /opt/zimbra newserver.domain.tld:/opt/

5. ./install.sh -s

6. delete /opt/zimbra/data/ldap/mdb/db/data.mdb on new server if present

7. export/import ldap data (export on old server: tar cvzpfs data.mdb.tar.gz data.mdb) (import on new server: tar xvf data.mdb.tar.gz)

8. ./install.sh --skip-activation-check

Actually, I have to combine your help of that with articles:

- https://forums.zimbra.org/viewtopic.php?t=71750

- https://forums.zimbra.org/viewtopic.php?p=301880#p301880

Again, thanks! And I will report back in a few weeks.

Greetz,

Joost

To migrate from zcs-9.0.0_ZEXTRAS_20221203.UBUNTU18_64.20221216110428 to zcs-9.0.0_ZEXTRAS_20221203.UBUNTU20_64.20221216110431, you can follow these general steps:

1. Backup: Before starting the migration process, it is crucial to create a backup of your existing zcs-9.0.0_ZEXTRAS_20221203.UBUNTU18_64.20221216110428 installation. This ensures that you have a copy of your data in case anything goes wrong during the migration.

2. Prepare the New Server: Set up a new server with the appropriate version, zcs-9.0.0_ZEXTRAS_20221203.UBUNTU20_64.20221216110431, installed on Ubuntu 20.04 64-bit. Make sure the server meets the system requirements for the new version.

3. Install Zimbra and Zextras: Install Zimbra Collaboration Suite (ZCS) 9.0.0 on the new server following the installation instructions provided by Zimbra. Once ZCS is installed, proceed to install the Zextras Suite, ensuring that you use the version compatible with ZCS 9.0.0.

4. Configuration and Network Setup: Configure the necessary network settings, such as IP addresses, DNS, and firewall rules, to ensure proper connectivity between the new server and other network resources.

5. Migration of Data: Transfer the data from the old zcs-9.0.0_ZEXTRAS_20221203.UBUNTU18_64.20221216110428 server to the new zcs-9.0.0_ZEXTRAS_20221203.UBUNTU20_64.20221216110431 server. This involves migrating user accounts, mailboxes, calendars, contacts, and any other relevant data. Zimbra provides several tools and utilities for data migration, such as Zimbra Migration Tools (ZMT) or Zimbra's native migration features.

6. Testing and Verification: After the migration is complete, thoroughly test the functionality of the new server and ensure that all data has been migrated successfully. Verify that email delivery, calendar syncing, contact management, and other essential features are working as expected.

7. Update DNS and MX Records: Update your DNS and MX records to point to the new server, directing incoming emails and other services to the zcs-9.0.0_ZEXTRAS_20221203.UBUNTU20_64.20221216110431 installation.

8. User Communication: Inform your users about the migration and any necessary changes, such as new server addresses, updated login credentials, or modifications to email client settings.

9. Decommission the Old Server: Once you have confirmed the successful migration and ensured that all data and services are functioning correctly on the new server, decommission the old zcs-9.0.0_ZEXTRAS_20221203.UBUNTU18_64.20221216110428 server. This involves properly shutting down and removing the old server from your environment.

It is crucial to consult the official Zimbra documentation and follow their recommended migration procedures for a seamless and successful migration. Additionally, consider performing the migration in a controlled test environment before executing it in a production environment to minimize potential disruptions.