Migration vers EOLE 2.6

Depuis la page d'accueil, un lien suivi de la migration affiche une page avec les informations suivantes pour chacune des version d'EOLE utilisée sur les serveurs :

• la liste des serveurs à migrer sans donnée spécifique à la migration ;
• la liste des serveurs préparés (dans l'application Zéphir) pour la migration.

Le bouton sélectionner comme groupe permet de créer un groupe contenant tous les serveurs de la liste.

La première tâche à prendre en compte pour préparer la migration est l'adaptation des variantes dans la nouvelle version. Suivant la version, deux cas sont possibles :

• adaptations nécessaires : pour les modules dont la configuration n'est pas directement compatible, les variantes du nouveau module doivent être créées manuellement dans l'application (il est toujours possible d'utiliser la fonction de copie de variante, sans garantie sur la compatibilité des fichiers transférés)

• pour les modules compatibles d'une version à l'autre (versions mineures successives), un bouton Import des données X est présent au niveau du menu des modules (par exemple, Import des données 2.4.1 pour la distribution 2.4.2).

  

  Cette fonction va effectuer les actions suivantes :

  • Les dictionnaires locaux de la version X sont recopiés si ils n'existent pas ;
  • les variante n'existant pas (test sur le libellé) sont copiées et définies comme équivalentes (voir ci-dessous) ;
  • les valeurs par défaut des modules X sont recopiées sur tous les modules ou aucune n'est définie.

  En cas de lancement successif de cette fonction, seuls les dictionnaires / variantes et fichiers de valeurs non présents dans la nouvelle version sont pris en compte. Cela évite d'écraser d'éventuelles adaptations faites entre-temps sur les nouvelles variantes. Cela implique qu'en cas d'ajout d'un fichier dans une variante X-1 déjà copiée, il faudra faire manuellement l'ajout dans la version X de la variante.

Zéphir propose une notion d'équivalence de variantes entre deux versions successives de la distribution EOLE. Lorsque deux variantes sont définies comme équivalentes, Zéphir sera capable de choisir automatiquement la variante à attribuer au serveur lors de la procédure Upgrade-Auto (et Maj-Release à partir de la version 2.5.0).

Les équivalences entre variantes peuvent être définies de deux façons :

• automatiquement, lorsque des variantes sont importées d'une version à l'autre de la distribution (voir ci-dessus). Dans ce cas, il est également possible de redéfinir manuellement ces équivalences.

• manuellement, en se rendant sur la page des variantes d'un module. Si la fonction est gérée pour cette version de la distribution, il sera possible de définir des équivalences pour chaque variante et chaque version de destination possible.

  

Le serveur Zéphir permet de préparer à l'avance la configuration des serveurs à migrer. Cette fonction est disponible en cas de changement de version de la librairie Creole (nécessite d'adapter les dictionnaires personnalisés des variantes ou des serveurs), ou lorsque les fichiers de configuration sont trop différents pour être adaptés automatiquement d'une version à l'autre.

• sur la page d'état d'un serveur à migrer (amon-2.3 par exemple), cliquer sur le lien générer les données de migration ;

• dans la liste choisir la variante à utiliser lors de la migration du serveur et cliquer sur Générer la configuration ;

• pour les modules 2.4 et supérieurs, la saisie de configuration passe par l'interface de configuration du module qui a été intégrée au serveur Zéphir, le formulaire interne a été abandonné ;

• une fois tous les onglets renseignés, cliquez sur Fichier puis Enregistrer la configuration. Quitter l'interface de configuration du module. Un fichier migration.eol est alors enregistré dans le répertoire de données du serveur ainsi qu'un fichier variante_migration indiquant la variante sélectionnée.

Une fois la configuration enregistrée, vous pouvez choisir de modifier la configuration de migration ou de la re-générer en partant des valeurs par défaut (si vous voulez utiliser une autre variante par exemple). Les liens correspondants sont à coté du voyant migration en haut de la page d'état.

Cette étape de génération de configuration concerne seulement le fichier de configuration config.eol du serveur. Pour migrer les données applicatives (données de l'EAD, données des utilisateurs, ...), il faut passer par les scripts fournis pour sauvegarder/restaurer les données.

Si vous ne voulez pas passer par ces procédures, ou si vous avez des fichiers divers spécifiques à reprendre sur certains serveurs (hors variante) , il est possible de définir une liste de fichiers à conserver sur Zéphir d'une version à l'autre (voir chapitre suivant).

Lors de la migration d'un serveur dans l'application, les fichiers divers ne sont pas repris automatiquement, aux exceptions suivantes près :

• les fichiers définis par défaut pour chaque module (configuration EAD, options de filtrage sur le serveur Amon et partages personnalisés sur les serveurs Horus / Scribe) sont remontés depuis le serveur migré en fin de procédure. Ce sont les scripts de migration (migrationXX.sh ou Upgrade-Auto) qui se chargent de les restaurer sur la machine ;
• certains fichiers seront repris tels quels dans le répertoire du serveur sur le serveur Zéphir : configurations VPN sur sphynx / fichiers de réplication LDAP sur le module Seshat.

Pour d'autre cas (fichiers spécifiques à un serveur ou définis dans le fichier fichiers_acad d'une variante), il est possible de spécifier une liste de fichiers à remettre en place dans le répertoire fichiers_zephir du serveur après migration. Vous pouvez indiquer au serveur Zéphir la façon de les traiter en créant un fichier /usr/share/zephir/migration_perso.py. Les fichiers définis seront envoyés au serveur migré (avant la remontée des fichiers par défaut). Les données sont décrites sous la forme suivante :

La structure migration_perso décrit les fichiers à recopier dans le répertoire fichiers_divers après bascule sur la nouvelle version.

Le libellé complet du module de destination (nom-version) doit être spécifié, les fichiers pouvant ne plus être au même emplacement d'une version à l'autre de la distribution :

• files: source, destination, et booléen indiquant si le fichier doit être traduit de l'iso en utf-8 ;
• rights : fichier copié, options pour chmod / chown (par exemple, -R pour récursif), utilisateur, groupe, droits ;
• exclude : fichiers à exclure lors de la copie (utile si copie des répertoires entiers).

Les permissions définies dans la section rights sont automatiquement retranscrites dans le fichier droits_zephir du serveur (elles peuvent ensuite être modifiées / supprimées dans l'application web Zéphir si besoin). le chemin des fichiers source et destination sont donnés par rapport au répertoire fichiers_zephir du serveur sur le serveur Zéphir ( pour référence : /var/lib/zephir/conf/<id_etab>/<id_serveur>/fichiers_zephir/)

• destinations_perso permet de renseigner la destination du fichier sur le serveur client. Cette liste de fichiers sera ajoutée dans le fichier fichiers_zephir du serveur (équivalent de la case fichier de destination dans la gestion des fichiers divers de l'application web Zéphir).

Il est possible de passer par l'API (XMLRPC) de l'application Zéphir pour générer en mode batch les configurations de migration. En particulier, dans le cas où les serveurs à migrer possèdent des variables supplémentaires définies dans des variantes.

Un squelette de script a été mis à disposition sur le serveur Zéphir pour aider à la migration vers EOLE 2.4 (/usr/share/zephir/utils/gen_migration_sample.py).

Le fonctionnement est le suivant :

• le script lit un fichier CSV indiquant les numéros de serveurs à préparer et le numéro de variante à leur appliquer une fois migrés ;
• pour chaque serveur, Il génère une configuration équivalente à celle obtenue via la fonction générer les données de migration dans l'application web Zéphir ;
• il passe ensuite dans une fonction update_conf, qui reçoit en paramètre la configuration actuelle du serveur, la configuration de migration générée et la variante de destination.

C'est cette fonction qu'il convient d'adapter pour remplir les informations manquantes dans la configuration de migration (voir les commentaires et exemples dans le script pour plus de détails).