Tags : debian, esxi, linux, plesk, vmware

Conversion d’un serveur Plesk physique vers une VM ESXi

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.

Sommaire
  1. 1 Identifier les problèmes
  2. 2 Problèmes avec MariaDB / Mysql
  3. 3 Changer les adresses IP
  4. 4 Accès à l’admin de Plesk
  5. 5 Réglage de Postfix
  6. 6 Transférer la licence Plesk vers la VM
  7. 7 Créer une page de maintenance qui marche pour tous les sites du serveur source
    1. 7.1 Configuration du réseau
    2. 7.2 Apache
    3. 7.3 Vhost de maintenance
    4. 7.4 Certificats SSL avec Certbot et Let’s Encrypt
  8. 8 Failed to parse metadata

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.

Screenshot_2020-04-01_Plesk_Obsidian_18_0_25.png
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

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.