EnvoleMigration23 » Historique » Version 9
Version 8 (Gaston TJEBBES, 28/07/2010 16:57) → Version 9/40 (Gaston TJEBBES, 28/07/2010 17:23)
h1. Migration vers la Eole2.3
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. En vrac :
* Renommer toutes les variables qui se nomme posh... en envole...; envole...
* 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); sauvegarder)
h2. Les variables à gérer
h3. Variables communes
* Url de redirection par défaut web_default (fournit par eole-web)
* Nom de domaine web_domain (fournit par eole-web ou eole-appli-web ?)
* Adresse du serveur ftp web_ftp (par application webshare/ajaxplorer) ??
h3. Les applications
* Activation des applications web_<appli> (chaque application fournit le sien)
h2. Les paquets
h3. Séparation
Les applications gibii, gepi et spip-eva doivent être déporté de conf-scribe
h3. Le principe
Un maximum de manipulation doivent doit être effectuées effectuée 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 eole-monappli fournit l'ensemble des dictionnaires, templates, scripts de manipulation util pour qu'il soit tiré dans l'application monappli (est installé sur le conteneur (nomdelappli-apps); master)
* Renommer éventuellement les variables (eole-nomdelappli);
* Revoir les chemins vers les fichiers .sql qui sont templatisés (cf étape 4).
h2. Étape 2 : les templates
A part cas particulier (renommage de variable, ftp, adresse du ldap ...), les templates n'ont pas à être modifiés.
h2. Étape 3: monappli-pkg la division fournit l'ensemble des paquets
Il faut désormais deux paquets dépendances utilisées pour une application :
* eole-nomdelappli contient les templates, les dictionnaires, scripts de configuration et s'installe installer monappli dans le container master;
* nomdelappli-apps contient l'application elle-même et s'installe dans le container web.
Il faut modifier On va donc avoir :
* debian/compat et mettre 5 au lieu de 4;
eole-appliweb
* 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. appliweb-pkg
NB 1 les dépendances :
* eole-monappli doit avoir eolebase-minimal dans ses deps, éventuellement eole-sso, eole-mysql eole-envole
* monappli-apps doit avoir web-pkg dans ses dépendances envole-pkg
NB 2 DESTDIR dans le makefile : eole-posh
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 posh-pkg ou posh_apps si un seul Makefile :-)) méta paquet n'est pas nécessaire
eole-ajaxplorer
Ex :
<pre>
EOLE_GIBII_DESTDIR=$(DESTDIR)/eole-gibii
GIBII_APPS_DESTDIR=$(DESTDIR)/gibii-apps
</pre>
ajaxplorer-apps
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
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
h3. 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
h3. Impact des modifications :
Les fichiers de configuration de génération et d'updates doivent être mis au goût du jour (chemin vers les .ini, .py pour la gestion sql (génération/mdp/update) ne bougent pas.
Les fichiers sql)
Le Makefile doit tenir compte des modifications. (ça doit .sql pourraient être placés dans une structure à peu près tout en attendant la modification de eole-mysql.
h3. Variables communes part:
* Url de redirection par défaut web_default (fournit par eole-web) /etc/eole/mysql/nomdelappli/gen/
et
* Nom de domaine web_domain (fournit par eole-web ou eole-appli-web ?)
* Adresse du serveur ftp web_ftp (par application webshare/ajaxplorer) ?? /etc/eole/mysql/nomdelappli/updates/
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. En vrac :
* Renommer toutes les variables qui se nomme posh... en envole...; envole...
* 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); sauvegarder)
h2. Les variables à gérer
h3. Variables communes
* Url de redirection par défaut web_default (fournit par eole-web)
* Nom de domaine web_domain (fournit par eole-web ou eole-appli-web ?)
* Adresse du serveur ftp web_ftp (par application webshare/ajaxplorer) ??
h3. Les applications
* Activation des applications web_<appli> (chaque application fournit le sien)
h2. Les paquets
h3. Séparation
Les applications gibii, gepi et spip-eva doivent être déporté de conf-scribe
h3. Le principe
Un maximum de manipulation doivent doit être effectuées effectuée 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 eole-monappli fournit l'ensemble des dictionnaires, templates, scripts de manipulation util pour qu'il soit tiré dans l'application monappli (est installé sur le conteneur (nomdelappli-apps); master)
* Renommer éventuellement les variables (eole-nomdelappli);
* Revoir les chemins vers les fichiers .sql qui sont templatisés (cf étape 4).
h2. Étape 2 : les templates
A part cas particulier (renommage de variable, ftp, adresse du ldap ...), les templates n'ont pas à être modifiés.
h2. Étape 3: monappli-pkg la division fournit l'ensemble des paquets
Il faut désormais deux paquets dépendances utilisées pour une application :
* eole-nomdelappli contient les templates, les dictionnaires, scripts de configuration et s'installe installer monappli dans le container master;
* nomdelappli-apps contient l'application elle-même et s'installe dans le container web.
Il faut modifier On va donc avoir :
* debian/compat et mettre 5 au lieu de 4;
eole-appliweb
* 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. appliweb-pkg
NB 1 les dépendances :
* eole-monappli doit avoir eolebase-minimal dans ses deps, éventuellement eole-sso, eole-mysql eole-envole
* monappli-apps doit avoir web-pkg dans ses dépendances envole-pkg
NB 2 DESTDIR dans le makefile : eole-posh
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 posh-pkg ou posh_apps si un seul Makefile :-)) méta paquet n'est pas nécessaire
eole-ajaxplorer
Ex :
<pre>
EOLE_GIBII_DESTDIR=$(DESTDIR)/eole-gibii
GIBII_APPS_DESTDIR=$(DESTDIR)/gibii-apps
</pre>
ajaxplorer-apps
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
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
h3. 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
h3. Impact des modifications :
Les fichiers de configuration de génération et d'updates doivent être mis au goût du jour (chemin vers les .ini, .py pour la gestion sql (génération/mdp/update) ne bougent pas.
Les fichiers sql)
Le Makefile doit tenir compte des modifications. (ça doit .sql pourraient être placés dans une structure à peu près tout en attendant la modification de eole-mysql.
h3. Variables communes part:
* Url de redirection par défaut web_default (fournit par eole-web) /etc/eole/mysql/nomdelappli/gen/
et
* Nom de domaine web_domain (fournit par eole-web ou eole-appli-web ?)
* Adresse du serveur ftp web_ftp (par application webshare/ajaxplorer) ?? /etc/eole/mysql/nomdelappli/updates/