Envole

h1. Migration d'Envole vers la version Eole2.3

{{toc}}

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.

h2. 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.

h2. É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 (envole_nomdelappli);

* Revoir les chemins vers les fichiers .sql qui sont templatisés (cf étape 4).

h2. É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)

** l'adresse du serveur sso est adresse_sso (anciennement cas_domainename) ???

h2. É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;

exemple : $(MAKE) install DESTDIR=$(CURDIR)/debian/monappli devient $(MAKE) install DESTDIR=$(CURDIR)/debian/

* 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 : 

<pre>

EOLE_GIBII_DESTDIR=$(DESTDIR)/eole-gibii

GIBII_APPS_DESTDIR=$(DESTDIR)/gibii-apps

</pre>

h2. É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.

h3. Fichier de configuration

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

<pre>

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

</pre>

h3. Les fichiers .sql 

<pre>

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

</pre>

h3. Les fichiers de mots de passe

Les fichiers de mot de passe devront contenir une variable container.

Si vous utilisez des scripts de pre et post update, ceux-ci doivent se trouver dans le container maître.

h3. 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.

h3. Mysql en ligne de commande

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

<pre>

# 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 

</pre>

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

<pre>

. /etc/eole/containers.conf

mysql -uroot -ppassword -h$container_ip_mysql

</pre>

h3. 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.

h2. L'arbre des dépendances

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

* envole-pkg;

* envole-extras-pkg.

h2. Familles et variables à renommer entre 2.2 et 2.3

h3. eoleSSO

* *full_cas* = 'oui' et *config_sso* = 'oui' => *activer_sso* != 'non' _(valeurs possibles pour activer_sso : ['non', 'local', 'distant'])_

* <file filelist=' *sso* '> => <file filelist=' *ssoclient* '> _(utilisé pour les fichiers clients pam/cas et php/cas)_

* *port_sso* et *cas_port* => *eolesso_port*

* *adresse_sso* et *cas_domainname* => *eolesso_adresse*

h3. eole-web

* <family name=' *Applications web* '> => <family name=' *applications web* '>

* *web_domain* => *web_url*

* *web_default* => *web_redirection*

* *scribe_envole_url* et *scribe_envole* disparaissent et *posh_url* => *web_url*

h3. portail Envole

* *web_envole* et "posh" => *activer_envole*

* *posh_path* => *alias_envole* ( avec le */* compris )

h3. applications

* Les variables d'activation des applies EnvOLE => *activer_<applie>*

h2. Notes concernant la mise à niveau de eole-posh

* TODO : changer le nom du paquet et en profiter pour réinitialiser le numéro de version dans le debian/changelog

* vérifier le logrotate

* problèmes probables de droits d'accès aux bdd (GRANT ...)

* quid de /etc/envole/config.ini ?

* scripts pre/post : commentés dans le Makefile et n'utilisant pas $container_path_web

* service de gestion des profils sur le maître ? => ajouter des .fw + mettre à jour l'adresse côté client

* fichier sudo et problématique décrite dans #824