Migration of zcs-9....
Clear all

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

6 Posts
3 Users
Joined: 3 years ago
Posts: 16
Topic starter  

Hi there,

I'm trying to perform a migration according article https://community.zextras.com/migrate-zimbra-from-one-server-to-another-server-method-3/

I'm stuck with step "Stop all Zimbra services." I perform this on the new server after rsyncing all of /opt/zimbra

When I "Stop all Zimbra services." I get error "Socket.c: loadable library and perl binaries are mismatched (got handshake key 0xde00080, needed 0xcd00080)"

Whatever zmcontrol I use, I get the same error. Am I missing something here?


When I ignore the aboven and go on with step "Step-4 Fix all permissions." and after that "Now again install Zimbra with the platform override option." I get message "Error: Unable to create a successful TLS connection to the ldap masters. Fix cert configuration prior to upgrading."


Does anyone know how to get arround this? Is there a way to fix certificates? Regenerate certificates maybe?


Help would be greatly appreciated!


Thanks in advance,

Joost Brenters

Jim Dunphy
Joined: 6 years ago
Posts: 22

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



Joined: 3 years ago
Posts: 16
Topic starter  

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:

Starting ldap...Done.

/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.




This post was modified 7 months ago by joob77

Jim Dunphy
Joined: 6 years ago
Posts: 22

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 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.



This post was modified 7 months ago by Jim Dunphy

Joined: 3 years ago
Posts: 16
Topic starter  

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.




Joined: 7 months ago
Posts: 2

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.