I must say right away that to complete this event, you must fully love BDSM, moreover, not light, but hardcore with hits below the belt. Otherwise, nothing will come of it and everything will stand in the middle of the path.
So let's get it in order.
Initially, we needed to deploy a version of Zimbra identical to the old server, in my case it was Zimbra 6.0.4 for CentOS 5, unfortunately it was the most advanced version of the OS for this software at that time.
Download from here zimbra.
wget https://files2.zimbra.com/downloads/6.0.4_GA/zcs-6.0.4_GA_2038.RHEL5_64.20091214192925.tgz
And unpack:
tar -xvf https://files2.zimbra.com/downloads/6.0.4_GA/zcs-6.0.4_GA_2038.RHEL5_64.20091214192925.tgz
Before you install it, configure CentOS. In version 5, disable Selinux, Postfix / Sendmail (either) and set up turnips for yum.
vi /etc/sysconfig/selinux
There we set the value:
SELINUX=disabled
We stop and turn off the services, so that during the installation and update they do not interfere with us:
service iptables stop chkconfig iptables off service sendmail stop chkconfig sendmail off service postfix stop chkconfig postfix off
We set up turnips for yum. In this file you need to # comment out the lines starting with mirror:
vi /etc/yum.repos.d/CentOS-Base.repo
And edit
'baseurl='
Instead of 5.11, we set our version.
baseurl=http://vault.centos.org/5.11/os/$basearch/
Next, update CentOS
yum update
After we updated the OS, it remains to make only one setting, because zimbra is very jealous of DNS, this is a very important setting and without it the installation process simply won’t work.
vi /etc/hosts
In it we register your ip and the full server name - IP FQNS NS.
Everything is in that order, otherwise again a mistake. In my case, the server was called srvmail (or rather, its mx record).
192.168.0.2 srvmail.domail.local srvmail
Then you can proceed with the installation, go to the directory with the zimbra unpacked in advance, and perform:
./install.sh --platform-override
Flag
"--platform-override"
tells the installer what to install in any case (rewrite the platform forcibly).
Another useful flag is
"-s"
this flag tells the installer that we want to install only executable packages and not configure.
Next, the installer will begin the installation and if everything was done correctly, then there will be no errors. At the end of the installation, check the status of the zimbra service:
zmcontrol status
If all the services are in the
Running
status, then everything is OK, then move on.
Stop our zimbru:
zmcontrol stop
After the zimbra is installed, we need to transfer the database, as well as the configuration file from the old zimbra server to the new one.
We need folders
db data index
located in
/opt/zimbra
as well as file
/opt/zimbra/conf/localconfig.xml
Folder data on the new server can be deleted, or backup.
Since the folders and files during the transfer could change the host (permissions), we need to fix this thing:
chown -R zimbra.zimbra /opt/zimbra /opt/zimbra/libexec/zmfixperms
Also, before a test run, it is necessary to check the sql database for errors, you can do this using the standard utility
mysqlcheck
or using the built-in Zimbro utility
zmdbintegrityreport
Run mysql and run the script:
/opt/zimbra/bin/mysql.server start /opt/zimbra/libexec/zmdbintegrityreport /opt/zimbra/libexec/zmdbintegrityreport -r
The first line checks for errors, and the second checks and immediately tries to be repaired.
If no errors have occurred, then clap your hands and look below, if errors:
mysql.general_log Error : You can't use locks with log tables. mysql.slow_log Error : You can't use locks with log tables.
Then you need to do the following:
cd /opt/zimbra/db/data/mysql ls -al *log.frm mv *log.frm /tmp/ /opt/zimbra/libexec/zmdbintegrityreport
If the latter completes without errors, then stop mysql and move on.
/opt/zimbra/bin/mysql.server stop
Now we need to change the passwords to the ldap base. Run ldap:
ldap start
In the first version with the “r” flag, we change the password for the root user, and in the second line for the zimbra user, we stop ldap again:
zmldappasswd -r newrootpass zmldappasswd newpass ldap stop
If you love BDSM and occultism, then read the following paragraph carefully. If not, feel free to skip.
For fans of BDSM
Now a little throttling)) I understand that you are already quite tired and this dullness is a little annoying, but let me explain something to you. When we transferred the bases (ldap and sql) we also transferred their accesses (users and passwords), when we set a new zimbru, it automatically generated passwords for the bases and they are stored in the file /opt/zimbra/conf/localconfig.xml. And if we tried to just transfer the bases and immediately start the Zimbra services, they would send us nafig and not start, because the passwords would not match. In principle, you can go the other way without copying the settings file, but then you have to compare the settings with the old server to change them on the new one. There is a special zmlocalconfig command for this.
We look at the settings for example ldap:
We use them on the new server:
The most important thing is to change passwords for all ldap and mysql.
With mysql, everything is much more complicated, you need to start the service with the privileges table reset and then apply the password equal to the old zimbra configurations:
find the line there
And change it to
Check if mysql is running, if yes we extinguish it
Next, run the cheekbone on a new
Next, go to mysql without a password (mysql) and set the passwords equal to the old zimbra (!!! you need to run on the old zimbra !!!!!!!!!!)
We write the changes and exit
Next, restart the cheekbone by stopping and starting
Check serviceability
if it goes without errors, then rejoice.
stop mysql
We look at the settings for example ldap:
zmlocalconfig -s | grep ldap
We use them on the new server:
zmlocalconfig -e < >=< >
The most important thing is to change passwords for all ldap and mysql.
With mysql, everything is much more complicated, you need to start the service with the privileges table reset and then apply the password equal to the old zimbra configurations:
vi /opt/zimbra/bin/mysql.server
find the line there
(--ledir=${mysql_directory}/libexec < /dev/null > /dev/null 2>&1 &)
And change it to
(--ledir=${mysql_directory}/libexec < /dev/null > /dev/null 2>&1 --skip-grant-tables &)
Check if mysql is running, if yes we extinguish it
/opt/zimbra/bin/mysql.server stop
Next, run the cheekbone on a new
mysql.server start
Next, go to mysql without a password (mysql) and set the passwords equal to the old zimbra (!!! you need to run on the old zimbra !!!!!!!!!!)
zmlocalconfig -s | grep mysql_root_password zmlocalconfig -s | grep zimbra_mysql_password
mysql> UPDATE mysql.user SET Password=PASSWORD('password') WHERE User='root'; ----> Root user. mysql> UPDATE mysql.user SET Password=PASSWORD('password') WHERE User='zimbra'; ----> Zimbra user
We write the changes and exit
FLUSH PRIVILEGES; exit;
Next, restart the cheekbone by stopping and starting
mysql.server stop mysql.server start
Check serviceability
mysql zimbra
if it goes without errors, then rejoice.
stop mysql
/opt/zimbra/bin/mysql.server stop
Next, we again make sure that the
zimbra, mysql, ldap
services are not running:
ps -aux |grep slapd ps -aux |grep sql zmcontrol status
If something is suddenly running, you need to kill or stop.
Well, the moment has come for your first launch of a new server. We bend the fingers with a cross and do not let go until it is fully launched, if you have a tambourine at hand, be sure to use it:
zmcontrol start
There are 2 options for the development of events:
At startup,
Check the zimbra and root password again. Or at launch ldap was already running and you just
When starting
Well, the option when mailboxd does not start
So you need to generate a new certificate:
Before that, you need to delete the old keystore, otherwise FAIL awaits you:
rm -rf /opt/zimbra/mailboxd/etc/keystone cd /opt/zimbra/bin ./zmcertmgr createca -new ./zmcertmgr createcrt -new -days 1825 ./zmcertmgr deploycrt self ./zmcertmgr deployca
Stop and run zimbra in a new way:
zmcontrol stop zmcontrol start
If you saw SUKES, then jump and enjoy (all services should be in Running status).
You can try to break into the WEB, if it does not load, do not despair. THIS IS NORMAL.
These troubles are eliminated by an upgrade TO THE SAME VERSION !!!
Caution Zimbra services must be started when upgrading, otherwise FAIL!
We go to the folder with the downloaded zimbra and enter:
./install.sh --platform-override
Zimbra will ask a couple of times if we want an update, we say yes and continue. By the way, it will pick up the settings for the system from the localconfig.xml we moved. Think of it as a little hack :-)
After installation, check the status of the mailer:
zmcontrol status
If everything is ok, then you can break onto WEB and go under any user from the old server, the passwords will be the same.
Further, as on the thumb, download the latest 7.x.x.x version, unpack it and again:
./install.sh --platform-override
At this stage, we are ready to grade our OS to the next step.
But first you need to check our database for corruption:
/opt/zimbra/libexec/zmdbintegrityreport
If there are no errors, then go ahead, if the mboxgroup errors
mboxgroup1.appointment error : Table upgrade required. Please do "REPAIR TABLE `appointment`" or dump/reload to fix it! mboxgroup1.data_source_item error : Table upgrade required. Please do "REPAIR TABLE `data_source_item`" or dump/reload to fix it! mboxgroup1.imap_folder error : Table upgrade required. Please do "REPAIR TABLE `imap_folder`" or dump/reload to fix it! mboxgroup1.mail_item error : Table upgrade required. Please do "REPAIR TABLE `mail_item`" or dump/reload to fix it! mboxgroup1.pop3_message ........ error : Table upgrade required. Please do "REPAIR TABLE `volume`" or dump/reload to fix it!
then you need to update the database version:
/opt/zimbra/libexec/scripts/migrate20100913-Mysql51.pl
At this exciting moment, take a tambourine in your right hand and pray ...
After the update, we check the databases again and fix them if necessary:
/opt/zimbra/libexec/zmdbintegrityreport /opt/zimbra/libexec/zmdbintegrityreport -r
If again the general and slow lock error, then see above how to fix it.
Well, the last thing to do before upgrading the OS is:
load zimbra variables:
source /opt/zimbra/bin/zmshutil zmsetvars
backup MYSQL:
/opt/zimbra/mysql/bin/mysqldump --user=root --password=$mysql_root_password --socket=$mysql_socket --all-databases --single-transaction --master-data --flush-logs > {name dump}.sql
If the error returns, then the option below:
/opt/zimbra/mysql/bin/mysqldump --user=root --password=$mysql_root_password --socket=$mysql_socket --all-databases --single-transaction --flush-logs > {name dump}.sql
backup ldap:
/opt/zimbra/libexec/zmslapcat /opt/zimbra/libexec/zmslapcat -c /opt/zimbra/libexec/zmslapcat -a
Next, we again transfer the
db, data, index, localconfig.xml
as well as backups
sql ldap</code> , , scsi
? / , CentOS6.
, .. , :
6 Centos zimbra 7..., , 8.0.8 8.0.0!!!
8.0.8 CentOS7 ----> 8.5.1 ----> 8.6.0 :
zmprov ms <zimbraserverhostname> zimbraReverseProxyMailEnabled TRUE zimbraReverseProxyHttpEnabled TRUE
--->8.7.9 ------> 8.8.9.
.
sql ldap</code> , , scsi
? / , CentOS6.
, .. , :
6 Centos zimbra 7..., , 8.0.8 8.0.0!!!
8.0.8 CentOS7 ----> 8.5.1 ----> 8.6.0 :
zmprov ms <zimbraserverhostname> zimbraReverseProxyMailEnabled TRUE zimbraReverseProxyHttpEnabled TRUE
--->8.7.9 ------> 8.8.9.
.