Migration SE3 vers SE4
La problématique de la migration vers un SE4
Lors de la journée du 19 janvier 2019, nous avons abordé la problématique de la migration d’un SE3 vers un SE4.
Franck nous a montré les grandes lignes d’une telle migration avec 2 cas possibles. Dans les 2 cas, le SE3 passe de Wheezy à Jessie puis de Jessie à Stretch.
Beaucoup de choses changent entre SE3 et SE4 dans la gestion du réseau (pour quelques détails à ce sujet, voir l’article concernant l’installation d’un SE4 que nous avons aussi abordée lors de cette journée). Ce n’est donc pas une opération simple. Il faut très bien la préparer en ayant un se3 à jour et dont une sauvegarde a été effectuée.
Le SE3 initial pour les démos de migration
La machine ayant servi pour les tests est une machine virtuelle sur laquelle se trouve un SE3 cloné à partir d’un SE3 en production. Sur cette machine, on a activé la branche testing des dépôts SE3 (dans le fichier /etc/apt/sources.list.d/sambaedu.list).
Préalable indispensable
Dans les 2 cas, il est impératif de cloner le SE3 ou de le virtualiser avant de lancer la migration pour parer à tout problème éventuel.
À ce propos, une solution prometteuse est la virtualisation du SE3, solution proposée par Laurent. Cette méthode simple et efficace permet de migrer en toute sérénité mais demande cependant de disposer d’un second serveur avec une quantité de RAM suffisante.
Pour des détails sur cette partie, voir la partie dédiée à cette problématique de la sauvegarde.
Lancement de la migration
On lance la commande suivante pour mettre en place le nécessaire à la migration :
On obtient ensuite le menu gérant les différentes options de migration avec la commande suivante :
On a alors 2 cas principaux :
- Le serveur SE3 ne dispose que de peu de RAM et on ne dispose pas d’un second serveur. Dans ce cas, le serveur se4ad sera installé dans un conteneur du serveur Se3 avant que ce dernier ne soit lui-même migré en se4fs (on a donc une seule machine qui héberge les deux serveurs) → option 2 puis option 3
- soit le se4ad comme le se4fs sont virtualisés ou sont sur des machines séparées → option 1
Cette solution est celle préconisée lorsqu’elle est possible.
Quelques remarques
Insistons : avec l’option 3 du script, le SE3 passe de Wheezy à Jessie puis de Jessie à Stretch pour devenir le serveur se4fs. Il n’y a pas de retour en arrière possible ; il est donc impératif de sauvegarder le SE3 avant de lancer la migration pour parer à tout problème éventuel et pouvoir revenir à la situation d’un SE3 fonctionnel. Voir ci-dessus le préalable indispensable !
Pour la démonstration effectuée lors de cette journée, on est parti d’une copie d’un SE3 qui a « vécu  » et qui donc a posé des problèmes, notamment avec le paquet se3-pla. Un correctif est en cours de développement afin de palier le problème ainsi détecté.
Pour les petits serveurs disposant de peu de RAM, ce qui est souvent le cas en collège, et si on ne peut avoir une 2e machine, on lancera l’option 2 (création AD sur conteneur), puis option 3 (transformation du se3 en se4fs).
Pour les plus grosses structures (Lycée, cité scolaire …), et aussi si on peut avoir une 2e machine pour les plus petites structures, on lancera l’option 1 qui permet la création des deux preseed utiles pour installer les deux serveurs se4ad et se4fs comme cela est préciser ci-dessous.
Garder son SE3 et installer SE4
L’option 1 génère 2 fichiers preseed (installation automatique) comme on l’a dit ci-dessus : un pour installer le serveur se4ad sur une 2e machine et l’autre pour installer le serveur se4fs sur une 3e machine en utilisant le mode pxe, et donc le serveur tftp du SE3, au démarrage de ces deux machines.
Ainsi, si on dispose de 2 machines en plus du SE3, inutile d’utiliser les options 1 et 3 du script : on se retrouve au final avec le SE3 initial et les 2 machines se4ad et se4fs. Une fois le SE4 fonctionnel et les données migrées, on arrêtera le SE3 définitivement.
On obtient donc une situation similaire à la fin de l’installation depuis 0.
Le nom de domaine
Un point important est le nom du domaine pleinement qualifié (FQHN) dont un sous-domaine (préfixe) est le domaine netbios : la documentation devra bien expliquer comment choisir ces noms et les précautions à prendre.
En particulier, le nom de domaine samba ("sambaedu3" la plupart du temps car proposé par défaut lors de l’installation d’un se3) devra être conservé afin de migrer automatiquement les clients-windows sans avoir à les réintégrer au nouveau domaine.