Migration d'Envole vers la version Eole2.3¶

• Migration d'Envole vers la version Eole2.3
  • Les choses en vrac :
  • Étape 1 : le dictionnaire
  • Étape 2 : les templates
  • Étape 3: la division des paquets
  • Étape 4 : Mysql
    • Fichier de configuration
    • Les fichiers .sql
    • Les fichiers de mots de passe
    • Impact des modifications
    • Mysql en ligne de commande
    • Le passage au container
  • L'arbre des dépendances

Les étapes :

• Mettre les dictionnaires à jour;
• Renommer éventuellement les variables pour revenir à quelque chose de standardisé;
• Séparer les paquets conf des paquets applications (container cible différent);
• Mettre les conf sql au gout du jour.

Les choses en vrac :¶

• Renommer toutes les variables qui se nomme posh... en envole...;
• Revoir les adresses localhost ou 127.0.0.1 (ldap et mysql ne sont plus joignables par ces adresses);
• Avoir une structure de dépendances cohérente (le sso est sur le maître, pas dans le container web ...);
• Le nom de domaine s'appelle désormais web_domain au lieu de posh_url ou envole_url ...;
• Revoir l'utilisation des répertoires de /home discussion entamée avec Manu (il est possible de fournir un template qui indique à bacula les rep à sauvegarder);
• Un maximum de manipulation doivent être effectuées depuis le master (script de configuration / synchro ...), cela évite de demander à un utilisateur de se connecter sur un container.

Étape 1 : le dictionnaire¶

Dans le dictionnaire, il faut :

• Identifier les fichiers qui vont dans le master et ceux qui vont dans le container web (gibii peut être pris en exemple);
• Penser à mettre le package nomdelappli-apps pour qu'il soit tiré dans le conteneur (nomdelappli-apps);
• Renommer éventuellement les variables (scribe_envole_nomdelappli);
• Revoir les chemins vers les fichiers .sql qui sont templatisés (cf étape 4).

Étape 2 : les templates¶

Les modifications à apporter au templates :

• le renommage de variable entraîne logiquement des changements;
• la modification des adresses des services (ldap n'est plus sur le master, ftp non plus)
• Certaines variables ont été renommées :
  • le nom de domaine est fournit par une variable unique : web_domain (fournit par le paquet eole-web)
  • l'url par défaut d'accès est fournit par la variable : web_default (fournit par le paquet eole-web)
  • l'adresse du serveur mysql est fournit par : adresse_ip_mysql (fournit par le paquet eole-mysql)
  • l'adresse du serveur ldap est fournit par : adresse_ip_fichier (fournit par le paquet eole-fichier)

Étape 3: la division des paquets¶

Il faut désormais deux paquets pour une application :

• eole-nomdelappli contient les templates, les dictionnaires, scripts de configuration et s'installe dans le container master;
• nomdelappli-apps contient l'application elle-même et s'installe dans le container web.

Il faut modifier :

• debian/compat et mettre 5 au lieu de 4;
• debian/control pour décrire le paquet source et ses paquets binaires;
• debian/rules pour que DESTDIR ne contienne plus le nom du paquet;
• Makefile pour la séparation des paquets.

NB 1 les dépendances :

• eole-monappli doit avoir eolebase-minimal dans ses deps, éventuellement eole-sso, eole-mysql
• monappli-apps doit avoir web-pkg dans ses dépendances

NB 2 DESTDIR dans le makefile :
Une fois la modification faite dans le fichier debian/rules, le DESTDIR obtenu dans le Makefile doit être concaténé pour former les DESTDIR des deux paquets binaires. (C'est comme cela que l'on fait plusieurs paquets avec un seul Makefile :-))
Ex :

EOLE_GIBII_DESTDIR=$(DESTDIR)/eole-gibii
GIBII_APPS_DESTDIR=$(DESTDIR)/gibii-apps

Étape 4 : Mysql¶

La gestion des bases de données mysql doit être revue (où quand, comment) ?

Un soucis rencontré jusqu'à présent est la difficulté à retrouver les fichiers .sql.
Voici une proposition de nomenclature envisagée pour placer les fichiers.

Fichier de configuration¶

Les fichiers ont la même destination, on peut imaginer une structure comme celle-ci

fichier dans le dépot                        ->    fichier sur le serveur

mysql/conf/gen/monappli.py                   ->   /usr/share/eole/applications/gen/monappli.py
mysql/conf/passwords/monappli.ini            ->   /usr/share/eole/applications/passwords/monappli.ini
mysql/conf/updates/config.py                 ->   /usr/share/eole/applications/updates/.../config.py

Les fichiers .sql¶

mysql/files/gen/fichiers.sql                 ->   /usr/share/eole/mysql/<nomdelappli>/gen/fichiers.sql
mysql/files/updates/fichiers.sql             ->   /usr/share/eole/mysql/<nomdelappli>/updates/fichiers.sql

Les fichiers de mots de passe¶

Les fichiers de mot de passe devront contenir une variable container (web est pris par défaut).
Si vous utilisez des scripts de pre et post update, ceux-ci doivent se trouver dans le container maître.

Impact des modifications¶

• Les dicos contiennent les chemins vers les fichiers .sql
• Les fichiers de configuration de génération et d'updates doivent être mis au goût du jour (chemin vers les fichiers sql);
• le Makefile doit tenir compte des modifications. (ça doit être à peu près tout en attendant la modification de eole-mysql);
• Rajouter la variable container dans les fichiers (.ini) de modification de mot de passe.

Mysql en ligne de commande¶

Pour utiliser la commande mysql dans un script bash, il faut faire comme suit :

# Cette ligne ci permet de charger les adresses/chemins des containers
. /etc/eole/containers.conf
echo "Update matable set ..." |  mysql --defaults-file=$container_path_mysql/etc/mysql/debian.cnf -h$container_ip_mysql 

Donc en ligne de commande, c'est pareil (ou presque)

. /etc/eole/containers.conf
mysql -uroot -ppassword -h$container_ip_mysql

Le passage au container¶

• Les bases de données sont créées avec un grant de l'utilisateur@localhost, cela s'avère bloquant lorsque l'on passe au container.
• Grant utilisateur@ipcontainer est nécessaire.

L'arbre des dépendances¶

Il va falloir réfléchir aux meta paquets :

• envole-pkg;
• envole-extras-pkg.