Cet article suppose que votre serveur est déjà converti en VM (P2V), si ce n’est pas encore le cas, consultez la série : Conversion P2V (physical-to-virtual) d’un serveur Online Dedibox ou dédié OVH sous Debian 9 avec VMware ESXI 6/7 et pfSense
Configuration
- Source : Plesk Obsidian (18)
- Debian Stretch (9) avec l’IP du server dédié + 1 IP failover
- Destination : le même serveur converti en P2V avec 1 IP LAN et 1 IP WAN
Au démarrage du tutoriel, l’IP WAN (destination) est une nouvelle IP failover affectée à Plesk.
Le but est de pouvoir le serveur converti sans mettre le serveur dédié initial (source) en maintenance. Une fois que tout sera testé, nous ré-affecterons l’IP failover initiale comme IP WAN de la destination.
Identifier les problèmes
Lancez la console virtuelle ESXi et vous verrez apparaître toutes les erreurs du système au démarrage. Pour les retrouver, se connecter en root et lancer :
journalctl -b
Nous allons ci-dessous les résoudre dans l’ordre.
Problèmes avec MariaDB / Mysql
Étant donné que Plesk a besoin de sa propre BDD pour fonctionner, il faut rétablir MariaDB en premier.
journalctl -b
(...)
mars 10 05:14:07 debian9 nginx[605]: nginx: [emerg] bind() to ip_serveur_physique:443 failed (99: Cannot assign requested address)
mars 10 05:14:07 debian9 nginx[605]: nginx: configuration file /etc/nginx/nginx.conf test failed
mars 10 05:14:07 debian9 systemd[1]: nginx.service: Control process exited, code=exited status=1
mars 10 05:14:07 debian9 systemd[1]: Failed to start Startup script for nginx service.
mars 10 05:14:07 debian9 systemd[1]: nginx.service: Unit entered failed state.
mars 10 05:14:07 debian9 systemd[1]: nginx.service: Failed with result 'exit-code'.
(...)
mars 10 05:14:09 debian9 systemd[1]: mariadb.service: Main process exited, code=killed, status=6/ABRT
mars 10 05:14:09 debian9 systemd[1]: Failed to start MariaDB 10.1.48 database server.
mars 10 05:14:09 debian9 systemd[1]: mariadb.service: Unit entered failed state.
(...)
mars 10 05:14:09 debian9 monit[498]: Job for mariadb.service failed because a fatal signal was delivered to the control process.
mars 10 05:14:09 debian9 monit[498]: See "systemctl status mariadb.service" and "journalctl -xe" for details.
mars 10 05:14:09 debian9 systemd[1]: Started Plesk Panel.
(...)
mars 10 05:14:11 debian9 systemd[1]: plesk-web-socket.service: Main process exited, code=exited, status=1/FAILURE
mars 10 05:14:11 debian9 systemd[1]: plesk-web-socket.service: Unit entered failed state.
mars 10 05:14:11 debian9 systemd[1]: plesk-web-socket.service: Failed with result 'exit-code'.
mars 10 05:14:11 debian9 php[1463]: [2022-03-10 05:14:11.445] 1463:62297b136ca48 ERR [panel] DB query failed: SQLSTATE[HY000] [2002] No such file or directory
mars 10 05:14:11 debian9 systemd[1]: plesk-ext-monitoring-hcd.service: Main process exited, code=exited, status=1/FAILURE
mars 10 05:14:11 debian9 systemd[1]: Failed to start Hardware changes detector for the Plesk Monitoring.
mars 10 05:14:11 debian9 systemd[1]: plesk-ext-monitoring-hcd.service: Unit entered failed state.
mars 10 05:14:11 debian9 systemd[1]: plesk-ext-monitoring-hcd.service: Failed with result 'exit-code'.
(...)
mars 10 05:14:11 debian9 wdcollect[613]: Locale is activated for sending e-mail messages.
mars 10 05:14:11 debian9 wdcollect[613]: Locale is activated for sending e-mail messages.
mars 10 05:14:11 debian9 wdcollect[613]: Server started.
mars 10 05:14:11 debian9 wdcollect[613]: Server started.
mars 10 05:14:11 debian9 wdcollect[613]: Failed to connect to database server during the startup. New attempts will be made.
mars 10 05:14:11 debian9 wdcollect[613]: Failed to connect to database server during the startup. New attempts will be made.
mars 10 05:14:12 debian9 wdcollect[613]: Failed to connect to database server during the startup. New attempts will be made.
mars 10 05:14:12 debian9 wdcollect[613]: Failed to connect to database server during the startup. New attempts will be made.
Puis :
systemctl status mariadb.service
Status: "InnoDB: Fatal: Trying to access page number 4294573311 in space 0 space name ./ibdata1, which is outside the tablespace bounds. Byte offset 0, len 16384 i/o type 10.Please check that the configuration matches the InnoDB system tablespace location (ibdata files)"
Ça pue.
On suit l’article de la KB Plesk : How to fix InnoDB corruption cases for the MySQL databases on Plesk for Linux?
Mais les solution gentilles ne marchent pas, il faut passer à une solution radicale : effacer tous les ibdata et réimporter le dernier backup !
service mysql stop && service plesk-web-socket stop
# on fait un backup des fichiers corrompus, au cas où...
cp -a /var/lib/mysql /root/mysql_backup
ls -l /var/lib/mysql/mysql/*.ibd
# on efface tout
rm -rf `ls -d /var/lib/mysql/* | grep -v "/var/lib/mysql/mysql"`
# le sgbd redémarre à blanc
service mysqld restart
service mysqld status
# on termine l'installation
mysql_secure_installation
chown -R mysql:mysql /var/lib/mysql
service mysqld status
# on met une conf permissive :
locate my.cnf
nano /etc/mysql/my.cnf
[mysqld]
skip-grant-tables
service mysqld restart
Ensuite on doit restaurer la base de Plesk en priorité :
cd /var/lib/psa/dumps
ls
zcat mysql.daily.dump.0.gz | plesk db
# bizarrement il reste quelques fichiers de la précédente installation :
mv /var/lib/mysql/mysql/gtid_slave_pos.frm /var/lib/mysql/mysql/gtid_slave_pos_BAK.frm
mv /var/lib/mysql/mysql/gtid_slave_pos.ibd /var/lib/mysql/mysql/gtid_slave_pos_BAK.ibd
mv /var/lib/mysql/mysql/innodb_index_stats.ibd /var/lib/mysql/mysql/innodb_index_stats_BAK.ibd
mv /var/lib/mysql/mysql/innodb_table_stats.ibd /var/lib/mysql/mysql/innodb_table_stats_BAK.ibd
zcat mysql.daily.dump.0.gz | plesk db
# on remet une conf propre :
nano /etc/mysql/my.cnf
[mysqld]
#skip-grant-tables
service mysqld restart
service mysqld status
Puis, on restaure les bases des sites : How to back up all MySQL databases via a command-line interface in Plesk for Linux
Sur le serveur source (physique), on crée les dumps des bases :
mkdir /root/mysql_dumps_all
cd /root && /usr/sbin/plesk db -e "show databases" | grep -v -E "^Database|information_schema|performance_schema|phpmyadmin" > dblist.txt
cat /root/dblist.txt | while read i; do /usr/sbin/plesk db dump "$i" > /root/mysql_dumps_all/"$i".sql; done
ls -lh /root/mysql_dumps_all
Sur la destination (VM), on copie et on importe :
rsync -avz root@ip_serveur_physique:/root/mysql_dumps_all /root/mysql_dumps_all/
rsync -avz root@ip_serveur_physique:/root/dblist.txt /root/
rm /root/mysql_dumps_all/psa.sql
for i in `cat /root/dblist.txt`; do MYSQL_PWD=`cat /etc/psa/.psa.shadow` mysql -u admin < /root/mysql_dumps_all/"
$i".sql; done
Une fois cela fait, rebootez la VM : vous devriez trouver beaucoup moins d’erreur dans la journal.
Changer les adresses IP
Rappel : dans cet environnement, le serveur physique (source) possède 2 adresses IPv4 : celle attribuée par l’hébergeur au serveur physique, et l’adresse IP failover supplémentaire que j’avais assignée à Plesk.
journalctl -b
(...)
mars 10 05:14:10 debian9 systemd[1]: Started Postfix Mail Transport Agent.
mars 10 05:14:10 debian9 postfix/qmgr[2005]: E59118E40703: from=<root@debian9>, size=786, nrcpt=1 (queue active)
mars 10 05:14:10 debian9 postfix/qmgr[2005]: E4DDC8E406FC: from=<root@debian9>, size=897, nrcpt=1 (queue active)
mars 10 05:14:10 debian9 postfix/qmgr[2005]: 709568E40705: from=<root@debian9>, size=898, nrcpt=1 (queue active)
mars 10 05:14:10 debian9 postfix/qmgr[2005]: 2F56F8E406F7: from=<root@debian9>, size=938, nrcpt=1 (queue active)
mars 10 05:14:10 debian9 postfix/qmgr[2005]: 469A28E406F9: from=<root@debian9>, size=897, nrcpt=1 (queue active)
mars 10 05:14:10 debian9 postfix/qmgr[2005]: 0521B8E406FB: from=<root@debian9>, size=898, nrcpt=1 (queue active)
mars 10 05:14:10 debian9 postfix/qmgr[2005]: 3057F8E406FD: from=<root@debian9>, size=1245, nrcpt=1 (queue active)
mars 10 05:14:10 debian9 postfix/qmgr[2005]: 68D3D8E4070B: from=<root@debian9>, size=1245, nrcpt=1 (queue active)
mars 10 05:14:10 debian9 postfix/smtp[2008]: warning: smtp_connect_addr: bind ip_failover: Cannot assign requested address
mars 10 05:14:10 debian9 postfix/smtp[2012]: warning: smtp_connect_addr: bind ip_failover: Cannot assign requested address
mars 10 05:14:10 debian9 postfix/smtp[2011]: warning: smtp_connect_addr: bind ip_failover: Cannot assign requested address
mars 10 05:14:10 debian9 postfix/smtp[2013]: warning: smtp_connect_addr: bind ip_failover: Cannot assign requested address
mars 10 05:14:10 debian9 postfix/smtp[2010]: warning: smtp_connect_addr: bind ip_failover: Cannot assign requested address
(...)
On voit donc que Postfix se plaint d’un problème d’assignation d’adresse.
Doc : gestion des adresses IP avec ipmanage
Si vous n’avez pas suivi l’étape de restauration MariaDB, vous ne pourrez pas continuer :
root@debian9:~# plesk bin ipmanage --ip_list
DB query failed: SQLSTATE[HY000] [2002] No such file or directory
exit status 1
Sinon :
root@debian9:/var/lib/psa/dumps# plesk bin ipmanage --ip_list
State Type IP Clients Hosting PublicIP
2 E eno1:ip_serveur_physique/255.255.255.0 0 0
2 S eno1:ip_failover/255.255.255.255 0 46 ip_failover
2 E eno2:10.90.211.75/255.255.255.192 0 0
On efface les anciennes IP :
plesk bin ipmanage --remove ip_serveur_physique
plesk bin ipmanage --remove 10.90.211.75
plesk bin ipmanage -u 192.168.1.103 -public_ip nouvelle_ip_failover
plesk bin ipmanage -u 192.168.1.103 -type shared
Et on réaffecte la nouvelle IP aux sites : To change IP for multiple subscriptions
cat /root/subscr.txt | while read i; do plesk bin subscription -u $i -ip 192.168.1.103 -mail-service-ip 192.168.1.103 ; done
plesk bin ipmanage --reread
reboot
Accès à l’admin de Plesk
nano /etc/hosts
nouvelle_ip_failover debian9
reboot
Après ça, vous retrouvez votre interface d’admin sur https://nouvelle_ip_failover:8443/admin/home/
Réglage de Postfix
Ce service s’est montré particulièrement capricieux à reconfigurer.
How to change the hostname and SMTP banner in Postfix on a Plesk server
nano /etc/postfix/main.cf
smtp_bind_address = ip_failover
smtp_bind_address = nouvelle_ip_failover
service postfix restart
nano /etc/hosts
nouvelle_ip_failover debian9 debian9
reboot
Puis How to change the IP address for outgoing emails in Plesk for Linux with Postfix mail server ce qui semble faire un peu doublon mais je n’ai pas eu le chox.
reboot
MAIS ça n’est pas suffisant : Unable to remove IP address
On sort l’artillerie lourde :
plesk db
select * from dns_recs where val='ip_failover' or displayVal='ip_failover';
UPDATE dns_recs SET displayVal = 'nouvelle_ip_failover' WHERE displayVal = 'ip_failover';
UPDATE dns_recs SET val = 'nouvelle_ip_failover' WHERE val = 'ip_failover';
delete from IP_Addresses where ip_address='ip_failover';
reboot
Cette fois, c’est la bonne.
Transférer la licence Plesk vers la VM
How to transfer Plesk key from one server to another?
Il faut récupérer une licence d’essai et l’installer sur l’ancien serveur.
Elle sera valable 15 jours.
Créer une page de maintenance qui marche pour tous les sites du serveur source
On installe une VM Debian 11 (je l’ai mise sur l’ESXi du serveur de destination, mais elle aurait pu être sur le serveur source) avec une configuration rapide :
Configuration du réseau
nano /etc/network/interfaces
auto ens192
iface ens192 inet static
address 192.168.1.111
netmask 255.255.0.0
gateway 192.168.1.1
/etc/init.d/networking restart
On mappe cette machine temporairement à une IP publique (cf. Ajouter des IP publiques supplémentaires à pfSense). Ceci pour vérifier que la page de maintenance répond correctement, et pouvoir vérifier que Certbot arrive à générer des certificats Let’s Encrypt à travers pfSense.
J’ai choisi de rester simple en forwardant tout le trafic destiné à l’IP publique directement vers la VM Debian 11, sans utiliser Squid ni HA Proxy dans pfSense. Par précaution, le trafic sur le port SSH est restreint aux IP de confiance.
Apache
Je préfère installer celui compilé par Ondřej Surý tout de suite, au cas où j’aurais besoin de son fameux PHP-FPM plus tard.
apt install apt-transport-https ca-certificates curl software-properties-common gnupg
curl -fsSL https://packages.sury.org/php/apt.gpg | apt-key add -
add-apt-repository "deb https://packages.sury.org/php/ $(lsb_release -cs) main" # celui-la n'est pas utilisé mais c'est en prévision pour + tard
add-apt-repository "deb https://packages.sury.org/apache2/ $(lsb_release -cs) main"
apt-get update
apt install apache2
locale-gen fr_FR.UTF-8
dpkg-reconfigure locales
a2enmod rewrite
service apache2 restart
Vhost de maintenance
Vu l’enjeu on ne va pas se compliquer la vie, juste utiliser le vhost par défaut (000). Par contre en vue de l’ajout de certificats SSL, on doit quand même le modifier pour ajouter des domaines :
nano /etc/apache2/sites-available/000-default.conf
ServerName domaine1.fr
ServerAlias domaine2.com
(...)
Certificats SSL avec Certbot et Let’s Encrypt
La doc : Cerbot
apt install snapd
snap install core
snap install --classic certbot
ln -s /snap/bin/certbot /usr/bin/certbot
Et on génère les certificats :
certbot install --cert-name domaine1.fr
certbot certonly --webroot -w /var/www/html -d domaine2.com
Modèle de page de maintenance à placer dans /var/www/html
: https://github.com/italic/maintenance
En cas de maintenance « en masse », il peut être préférable de transférer les certificats existants vers la machine de maintenance, via rsync.
Failed to parse metadata
C’est une erreur qui peut apparaître dans le Gestionnaire de sauvegardes.
Pour la résoudre : Internal error: Failed to parse metadata, File aps_php.php
wget https://support.plesk.com/hc/en-us/article_attachments/360010105354/restore-cache
mv restore-cache restore-cache.sh; chmod +x restore-cache.sh
./restore-cache.sh