Ekumen, d'abord virtualisée sous Xen, a été migrée sur la plateforme de virtualisation HVM afin d'avoir un meilleur contrôle du noyau (version, paramètres de démarrage). Voir la documentation de Gandi pour plus de détails.

• Pas de snapshot
• Utilisation de l'interface Web de gestion du serveur en lieu et place des commandes gandi fournies dans la doc susmentionnée.

1. Ajout du dépôt de paquets de Gandi (http://mirrors.gandi.net/gandi/debian jessie main)

sudo vim /etc/apt/sources.list.d/gandi.list
sudo apt-key adv --keyserver=hkp://pool.sks-keyservers.net --recv-key D8EAC2F4DAFE3FA5
sudo apt-get update
sudo etckeeper commit

2. Installation du fichier /etc/default/gandi avant le paquet gandi-hosting-vm2

Pour éviter que l'installation du paquet gandi-hosting-vm2 ne refasse la configuration du serveur, j'ai installé d'abord le fichier de configuration principal :

apt-get download gandi-hosting-vm2
dpkg-deb -x gandi-hosting-vm2_2.6_all.deb gandi-hosting-vm2
sudo cp gandi-hosting-vm2/etc/default/gandi /etc/default

et l'ai modifié comme suit :

CONFIG_MOTD=0
CONFIG_TIMEZONE=0
CONFIG_SYSCTL=0
CONFIG_SSHD=0
CONFIG_CONSOLE=0
CONFIG_HOSTNAME=0
CONFIG_NAMESERVER=0
CONFIG_ALLOW_MOUNT=0
CONFIG_CRON=0
CONFIG_NODHCP=""

Puis installation du paquet :

sudo etckeeper commit
sudo apt-get install gandi-hosting-vm2

3. Modification de fstab et test avec le noyau HVM.

Les noms des disques diffèrent selon les plateformes de virtualisation, et le passage de Xen à HVM implique de modifier le fichier /etc/fstab :

sudo sed -ie 's,xvda1,sda,; s,xvda2,sdb,' /etc/fstab
sudo etckeeper commit

Puis dans l'interface Web de gestion du serveur, spécifier un démarrage sur le noyau HVM fourni par Gandi (3.18-x86_64 (hvm)). On y accède via la page de Modification des options sur le disque sysdisk01, dans le champ Kernel. Toujours depuis l'interface Web, redémarrer le seveur à froid (Arrêter, attendre et rafraîchir la page, Redémarrer).

• uname -r nous dit que la migration est effective
• sudo etckeeper vcs status dit que /etc est propre
• lsblk nous apprend que la racine du système est bien sur sda, mais que le disque sdb est utilisé comme espace d'échange (swap), désactivé sur le champ.

Après un peu de lecture, désactivation d'un service de magie violette (responsable de l'activation du disque de swap) :

sudo systemctl disable gandi-bootstrap.service
sudo etckeeper commit

4. Passage à GRUB et au noyau de Debian Jessie (3.16.0-4-amd64)

Installation des paquets nécessaires (sans oublier que c'est pour déployer AppArmor qu'on fait tout ça) :

sudo apt-get install grub-pc linux-image-amd64 apparmor apparmor-utils apparmor-profiles

Comme la racine du système est sur un disque (et non une partition), et que les disques sont virtuels, et qu'on n'a en fait besoin que du menu de GRUB, j'ai dit à debconf de ne pas installer le chargeur de démarrage GRUB sur un des disques, pour éviter une erreur à l'installation du paquet grub-pc. Puis édition de /etc/default/grub :

GRUB_CMDLINE_LINUX="apparmor=1 security=apparmor"

et reconstruction du menu de démarrage avec sudo update-grub.

Enfin, depuis l'interface Web, passage du Kernel courant à grub, et redémarrage à froid. Après le redémarrage, pour s'assurer qu'on a bien ce qu'on attendait :

sudo aa-status

Problème

En cours de manipulations, je découvre avec stupéfaction qu'ekumen ne redémarre pas correctement (semble avoir un problème de configuration/initialisation de la carte réseau) après un bête sudo reboot, et doit donc être redémarrée systématiquement depuis l'interface Web.

todo: à corriger si possible