Pour répondre à des besoins d'installation et de mise à jour de Dynacase sur diverses plateforme, de manière simple via une interface WEB, Dynacase-control est né.
Dynacase-control rend l'installation et la mise à jour de Dynacase indépendant de la distribution Linux présente sur le serveur.
Dynacase-control en quelques lignes :
Dynacase-control permet donc de réaliser simplement une première installation de Dynacase-platform.
Les informations fournies ci-dessous, le sont à titre indicatif et peuvent varier en fonction de la distribution linux cible (nom des extensions par exemple).
Ces informations sont fournies pour la version stable de dynacase.
Pour les composants requis (apache, postgresql, php, …) la version validée est la version avec laquelle les tests de dynacase sont joués.
La version utilisable est éventuellement indiquée : elle est sensée fonctionner avec dynacase. Toutefois, l'ensemble des fonctionnalités dynacase n'ont pas été validé avec cette version.
Les informations relatives aux composants sont exhaustives (utilisée par certain modules) et nécessaires pour une installation standard faite par défaut.
| stable 3.0 | 3.1 | |
|---|---|---|
| PHP | > 3.0.12 version 5.3 >= 3.0.4 version 5.3 (fonctionne avec une version 5.2 si les composants extui ne sont pas utilisés) < 3.0.4 : version 5.2 | 5.3 |
| PostgreSQL | 8.3 ou 8.41) | 8.4 |
| ExtJS | 3.1 | 3.2 |
Pour voir le détail des paquets aptitude à installer sous Debian, reportez-vous à la page Résolution des principales dépendances.
La version Dynacase 3.0 est fonctionnelle avec les navigateurs suivants :
version validée : 2.2
Les modules notés (core) sont normalement inclus de manière statique dans PHP.
AllowOverride All” positionné au niveau de la configuration Apache.
max_execution_time” de votre installation PHP est trop bas (inférieur à 5 minutes), il sera peut être nécessaire d'augmenter celui-ci dans votre `php.ini'.
Se connecter 'root'. Déplacer vous dans un répertoire accessible via apache (dans votre DocumentRoot décrit dans vos fichiers de configuration apache - par exemple). Dans ce répertoire sera installé Dynacase-control.
# cd /var/www/html
Télécharger l'installer ici http://eec.anakeen.com/public/control/dynacase-control-current.tar.gz :
# wget http://eec.anakeen.com/public/control/dynacase-control-current.tar.gz
Extraire l'archive :
# tar xfz dynacase-control-current.tar.gz
Modifier le propriétaire de l'arborescence crée :
# chown -R apache: dynacase-control-x.y-z/
Remarque : Le user apache dépend de votre distribution (www-data sous Debian)
Créer un raccourci
# ln -s dynacase-control-x.y-z dynacase-control
Se connecter à l'URL Dynacase Control (dépend de son dossier d'installation et de la configuration apache) :
Installer `php-dom' et/ou `php-xml'.
Installer `php-zip'.
Installer `php-json'.
Voir Message ”PHP function 'json_encode' not found.”.
Un contexte regroupe tout ce qui est nécessaire au fonctionnement de Dynacase-platform : bases, modules Dynacase (logiciel), paramètres de configuration, etc…
Un même serveur peut fournir plusieurs contextes Dynacase-platform, chacun des contextes étant totalement autonome en terme de logiciel et de source, vous pouvez donc avoir 2 versions de Dynacase-platform installées simultanément sur votre serveur.
Les différents éléments nécessaires à l'initialisation d'un contexte sont :
Ces éléments sont à préparer par un administrateur système ayant les accès super-utilisateur (root) sur le serveur.
C'est le répertoire dans lequel sera installé l'instance de Dynacase-platform.
Ce répertoire doit être sous le ”DocumentRoot” de votre serveur Apache, et accessible en lecture/écriture par Apache.
Vous pouvez rentrer un chemin absolu ou un chemin relatif. Dans le cas d'un chemin relatif, celui-ci sera relatif au répertoire dans lequel vous aurez installé Dynacase-control.
Si le répertoire renseigné n'existe pas, Dynacase-control essayera de le créer. Pour cela, il faut que l'utilisateur Apache ait le droit d'écriture dans le répertoire parent du répertoire que vous voulez créer.
Si le répertoire existe déjà, Dynacase-control vérifiera qu'il ne contient pas d'installation existante. Dans le cas contraire, une erreur sera retourné et vous devrez sélectionner un autre répertoire.
La base de donnée dédiée à votre contexte Dynacase doit être propriété d'un rôle (au sens postgresql) SUPERUSER sur la base du contexte Dynacase.
Exemple :
[root@server ~]# su postgres [postgres@server ~]# psql postgres=# CREATE ROLE dynacaseowner WITH LOGIN ENCRYPTED PASSWORD 'password' SUPERUSER; postgres=# CREATE DATABASE dynacase OWNER dynacaseowner;
Note:
La configuration de Dynacase est par la suite basée sur le service (au sens postgresql). Exemple :
[root@server ~]# more $PGSYSCONFDIR/pg_service.conf [dynacase] host=localhost port=5432 user=dynacaseowner password=password dbname=dynacase
Le répertoire $PGSYSCONFDIR dans lequel est stocké le fichier pg_service.conf est dépendant de votre distribution et sa valeur peut être trouvée à l'aide de la commande pg_config. Exemple :
[root@server ~]# pg_config --sysconfdir /etc/sysconfig/pgsql/pg_service.conf
# pg_config --sysconfdir /etc/postgresql-common
Pour vérifier que les paramètres associés au service sont correct on pourra essayer de se connecter à la base avec la commande `psql' :
[root@server ~]# PGSERVICE=dynacase psql dynacase=#
Pour créer un contexte, il faut cliquer sur le lien “Create Context” et renseigner les champs indiqués.
Pour installer Dynacase-platform, il faut juste cliquer sur le bouton `Install Selection'. En effet tous les composants de base de Dynacase-platform sont déjà automatiquement sélectionnés. Ceci entrainera l'installation des modules de base de Dynacase-platform et toutes leur dépendances.
Certains modules (ex : Dynacase-platform) nécessite la saisie de paramètres obligatoires qui seront demandés avant l'installation :
Pour freedom-toolbox, il faut donc renseigner les paramètres suivants :
Avant l'installation de chaque module, Dynacase-control vérifie que tout les pré-requis sont installés sur le système.
Un écran apparait indiquant les contrôles effectués. Si un pré-requis est absent, l'installation s'interromp et peut-être ensuite relancée (bouton “retry”) une fois le problème résolu (en général installation d'un paquet) :
Le tableau ci-dessous indique comment résoudre les dépendances pour une installation de base sous Debian Lenny.
| Message | Commandes pour résoudre les dépendances |
|---|---|
| Checking if the PHP function 'pg_connect' exists You might need to install a php-pg package from your distribution in order to have Postgresql support in PHP. | aptitude install php5-pgsql /etc/init.d/apache2 reload |
| Checking if the command 'zip' is in the PATH | aptitude install zip |
| Checking if the command 'dot' is in the PATH | aptitude install graphviz |
| Checking if the command 'dot' is in the PATH | aptitude install imagemagick |
| Checking if the command 'html2ps' is in the PATH | aptitude install html2ps |
| Checking if the command 'php' is in the PATH | aptitude install php5-cli |
| Warning : Checking if the command 'ldapdelete' is in the PATH | |
| Checking if the command 'msgcat' is in the PATH | aptitude install gettext |
| Checking if the PHP function 'imagegd' exists You might need to install a php-gd package from your distribution in order to have GD support in PHP. | aptitude install php5-gd/etc/init.d/apache2 reload |
| Checking if the PHP function 'ldap_connect' exists You might need to install a php-ldap package from your distribution in order to have LDAP support in PHP. | aptitude install php5-ldap /etc/init.d/apache2 reload |
| Warning : Checking if the PHP function 'ncurses_init' exists You might need to install a php-ncurses package from your distribution in order to have ncurses support in PHP. | Rien à faire sous Debian |
| Checking if the PHP function 'pspell_new' exists You might need to install a php-pspell package from your distribution in order to have spelling support in PHP. | aptitude install php5-pspell /etc/init.d/apache2 reload |
| Checking if the class 'Crypt_CHAP' is available in include file 'Crypt/CHAP.php' You might need to run : pear install Crypt_CHAP | aptitude install php-pear pear install Crypt_CHAP /etc/init.d/apache2 reload |
| Checking if the class 'Net_SMTP' is available in include file 'Net/SMTP.php' You might need to run : pear install Net_SMTP | pear install Net_SMTP /etc/init.d/apache2 reload |
| Checking if the class 'Mail_mime' is available in include file 'Mail/mime.php' You might need to run : pear install Mail_Mime | pear install Mail_Mime /etc/init.d/apache2 reload |
| Checking if the Apache module 'mod_expires' is loaded You might need to install and/or activate the Apache mod_expires module. | a2enmod expires/etc/init.d/apache2 restart |
| Checking if the class 'XSLTProcessor' is available in include file '' You might need to install a php-xsl package form your distribution in order to have XSLT support in PHP. | aptitude install php5-xsl /etc/init.d/apache2 reload |
| Checking if the class 'XML_Parser' is available in include file 'XML/Parser.php' You might need to install a php-pear-XML_Parser package from your distribution, or run 'pear install XML_Parser', in roder to have XML_Parser support in PHP. | pear install XML_Parser/etc/init.d/apache2 reload |
| Checking if the class 'XML_RSS' is available in include file 'XML/RSS.php' You might need to install a php-pear-XML_RSS package form your distribution, or run 'pear install XML_RSS', in order to get RSS parsing support in PHP. | aptitude install php-xml-rss/etc/init.d/apache2 reload |
| Checking if the PHP function 'imap_open' exists You might need to install a php-imap package from your distribution in order to get IMAP support in PHP. | aptitude install php5-imap/etc/init.d/apache2 reload |
En résumé et toujours sous Debian Lenny, il faut donc exécuter ces commandes :
# aptitude install zip unzip graphviz imagemagick html2ps php5-cli # aptitude install php-pear gettext php5-pgsql php5-gd php5-xsl # aptitude install php5-ldap php5-pspell # pear install Crypt_CHAP # aptitude install php-net-smtp php-mail-mime # a2enmod expires # /etc/init.d/apache2 restart
apt-get install zip unzip dot graphviz html2ps imagemagick ghostscript gettext php5-gd php5-ldap php5-pspell php-pear php5-xsl php-xml php-xml-rss php5-imap php5-mcrypt /etc/init.d/apache2 restart pear install Crypt_CHAP pear install Net_SMTP pear install Mail_Mime a2enmod expires /etc/init.d/apache2 force-reload ## required by module freedom-dav a2enmod expires /etc/init.d/apache2 force-reload
apt-get install postgresql apache2 php5 zip unzip graphviz html2ps imagemagick ghostscript gettext php5-gd php5-ldap php5-pspell php-pear php5-xsl php-xml-rss php5-imap php5-mcrypt php5-pgsql recode pear install Crypt_CHAP Net_SMTP Mail_Mime XML_Parser a2enmod expires rewrite service apache2 force-reload
Votre installation de Dynacase-platform de base est alors pleinement opérationnelle.
Dynacase-platform sera ensuite disponible à l'adresse indiquée dans votre contexte. Exemple :
Seul les dépôts stables de la version 3.0 sont configurés par défaut.
Si vous avez un compte entreprise EEC, vous pouvez supprimer les dépôts fournis par défaut et ajouter les dépôts correspondants à votre compte EEC.
Pour ajouter un dépot, il suffit de se rendre dans le setup de dynacase-control. Dans ce setup, vous pouvez paramétrer le mode d'accès à internet (utilisation d'un proxy avec ou sans authentification), ajouter autant de dépots que nécessaires : Control > Setup > Repositories
Pour la recherche des mises à jour de dynacase-control, vous pouvez renseigner votre dépôt EEC avec les paramètres “wiff-update-host” et “wiff-update-path” : Control > Setup > Parameters
La mise à jour automatique est en cours de réalisation. Une très prochaine version de Dynacase-control intègrera cette fonctionnalité.
Lorsque Dynacase-control détecte qu'une nouvelle version de l'installeur est disponible, une demande de mise-à-jour apparait :
Cliquer sur le bouton [Yes] pour télécharger et mettre à jour l'installeur, et cliquer sur [No] pour ne pas effectuer la mise-à-jour. La mise-à-jour sera proposée de nouveau au prochain chargement de l'installeur.
Pour les mises à jour en mode console, se reporter à la documentation du CLI DYNACASE-CONTROL.
Lors de la consultation d'un contexte Dynacase, Dynacase-control présente les modules installés et ceux qui disposent d'une version supérieure sur le repository sont précédés de l'icône
:
Dans l'exemple ci-dessus, le modules `dynacase-platform' a une mises-à-jour disponible.
Pour installer les mises-à-jour, il suffit de cocher les modules que vous souhaitez mettre à jour (case à cocher au début de la ligne), et valider ensuite en cliquant sur le bouton [Upgrade Selection].
En cliquant sur la case de la barre de titre, toute les mises à jour faisables seront sélectionnées (comme dans l'exemple).
Le CLI permet d'administrer le Dynacase-control en ligne de commande.
La commande `wiff' permet de manipuler et administrer les contextes Dynacase-platform.
A terme, les opérations actuellement accessibles à travers l'UI Web, seront accessibles en ligne de commande à l'aide de cette commande `wiff'.
La commande `wiff' doit être lancé sous `root'. Pour cela, vous pouvez soit vous logger sous le compte `root' pour exécuter la commande, soit utiliser `sudo pour exécuter celle-ci.
Si vous n'êtes pas `root' sur le serveur, et que les opérations d'administrations s'effectuent avec `sudo' :
$ sudo /var/www/dynacase-control/wiff help Password: ****** [message d'aide]
Si vous avez accès au compte `root' sur le serveur :
# /var/www/dynacase-control/wiff help [message d'aide]
Par la suite, nous utiliserons la notation de ce dernier cas (`# /var/www/dynacase-control/wiff').
list context [--pretty]
Cette opération permet d'afficher les contextes installés.
# /var/www/dynacase-control/wiff list context developpement test production # /var/www/dynacase-control/wiff list context --pretty Name Description ----------------------------------------------------------------------------------- developpement Développement test Test production Production
context <context-name> module list installed [--pretty]
Cette opération affiche les modules installés dans le contexte sélectionné.
# /var/www/dynacase-control/wiff context test module list installed freedom-core (2.14.1-12) freedom-vault (3.10.0-0) freedom-fckeditor (2.6.3-5) freedom-common (0.6.0-0) freedom (2.14.3-18) freedom-webdesk (1.2.0-2)
context <context-name> module list available [--pretty]
Cette opération affiche la liste des modules disponibles sur les dépôt de paquets accessibles par HTTP ou FTP.
# /var/www/dynacase-control/wiff context test module list available freedom-vault (3.10.0-0) freedom-extjs (3.0.0-4) freedom (2.14.3-18) freedom-core (2.14.1-12) [...] freedom-searchsheet (0.2.0-0) freedom-ecm (0.0.4-0) freedom-theme (0.0.1-3) freedom-url (0.0.0-3)
context <context-name> module list upgrade [--pretty]
Cette opération permet d'afficher la liste des modules installés dont une mise-à-jour est disponible sur les dépôts de paquets.
# /var/www/dynacase-control/wiff context test module list upgrade freedom-core (2.14.1-12) freedom (2.14.3-18)
context <context-name> module install [options] <localPackagePath> context <context-name> module install [options] <moduleName>
Cette opération permet d'installer un module contenu dans un paquet local (archive .webinst stocké en local sur le serveur) ou à partir d'un paquet disponible sur un dépôt de paquets distant accessible par HTTP ou FTP.
Les options disponibles sont :
–nopre' permet de ne pas exécuter les processus de `pre-install' déclarés par le paquet.–nopost' permet de ne pas exécuter les processus de `post-install' déclarés par le paquet.–nothing' permet de ne pas exécuter les processus de `pre-install' et de `post-install' déclarés par le paquet.–force' permet de forcer l'installation du paquet même si celui-ci est déjà installé.Installation d'un paquet distant :
# /var/www/dynacase-control/wiff context test module install freedom Will install (or upgrade) the following packages: - freedom-core-2.14.1-12 - freedom-vault-3.10.0-0 - freedom-fckeditor-2.6.3-5 - freedom-common-0.6.0-0 - freedom-2.14.3-18 Proceed to installation ? [Y/n] Y Processing required module 'freedom-core' (2.14.1-12) for install. Downloading module 'freedom-core-2.14.1-12'... [OK] Parameters for module 'freedom-core' ------------------------------------ client_name ? [] Test core_db ? [test] authtype ? [html] apacheuser ? [www-data] _www Doing 'pre-install' of module 'freedom-core'. [...] Doing 'unpack' of module 'freedom-core'. Unpacking module 'freedom-core'... [OK] Doing 'post-install' of module 'freedom-core'. Running 'Initialize system database'... [OK] Running 'Record core application in database'... [OK] Running 'Record users application in database'... [OK] Running 'Record access application in database'... [OK] Running 'Record authent application in database'... [OK] Running 'Record appmng application in database'... [OK] Running 'Generate traduction catalog'... [OK] Running 'Register client name'... [OK] Processing required module 'freedom-vault' (3.10.0-0) for install. Downloading module 'freedom-vault-3.10.0-0'... [OK] Doing 'pre-install' of module 'freedom-vault'. Doing 'unpack' of module 'freedom-vault'. Unpacking module 'freedom-vault'... [OK] Doing 'post-install' of module 'freedom-vault'. Running 'Process programs/record_application VAULT'... [OK] Running 'Process wsh.php --api=vault_init'... [OK] Running 'Process programs/update_catalog'... [OK] Processing required module 'freedom-fckeditor' (2.6.3-5) for install. Downloading module 'freedom-fckeditor-2.6.3-5'... [OK] Doing 'pre-install' of module 'freedom-fckeditor'. Doing 'unpack' of module 'freedom-fckeditor'. Unpacking module 'freedom-fckeditor'... [OK] Doing 'post-install' of module 'freedom-fckeditor'. Processing required module 'freedom-common' (0.6.0-0) for install. Downloading module 'freedom-common-0.6.0-0'... [OK] Doing 'pre-install' of module 'freedom-common'. Doing 'unpack' of module 'freedom-common'. Unpacking module 'freedom-common'... [OK] Doing 'post-install' of module 'freedom-common'. Running 'Process programs/record_application FDC'... [OK] Running 'Process programs/update_catalog'... [OK] Processing required module 'freedom' (2.14.3-18) for install. Downloading module 'freedom-2.14.3-18'... [OK] Doing 'pre-install' of module 'freedom'. Running 'Check php function gd_info'... [OK] Running 'Check php function cal_info'... [OK] Running 'Check php class XSLTProcessor'... [OK] Doing 'unpack' of module 'freedom'. Unpacking module 'freedom'... [OK] Doing 'post-install' of module 'freedom'. Running 'Process programs/app_post FDL I'... [OK] Running 'Process programs/record_application FDL I'... [OK] Running 'Process programs/app_post FDL U'... [OK] Running 'Process programs/app_post USERCARD I'... [OK] Running 'Process programs/record_application USERCARD I'... [OK] Running 'Process programs/app_post USERCARD U'... [OK] Running 'Process programs/record_application GENERIC I'... [OK] Running 'Process programs/record_application ONEFAM I'... [OK] Running 'Process programs/record_application FUSERS I'... [OK] Running 'Process programs/app_post FREEDOM I'... [OK] Running 'Process programs/record_application FREEDOM I'... [OK] Running 'Process programs/app_post FREEDOM U'... [OK] Running 'Process programs/record_application FGSEARCH I'... [OK] Running 'Process wsh.php --api=crontab --cmd=register --file=FREEDOM/freedom.cron'... [OK] Running 'Process programs/update_catalog'... [OK] Done.
Installation d'un paquet local :
# /var/www/dynacase-control/wiff context test module install /tmp/foo-1.2.3-4.webinst Processing required module 'foo' (1.2.3-4) for install. Module 'foo-1.2.3-4' is already downloaded in '/private/tmp/foo-1.2.3-4.webinstkeZbf9'. Doing 'pre-install' of module 'foo'. Running 'Check php class XML_Parser'... [OK] Running 'Check php function imap_open'... [OK] Doing 'unpack' of module 'foo'. Unpacking module 'foo'... [OK] Doing 'post-install' of module 'foo'. Running 'Process programs/app_post FOO I'... [OK] Running 'Process programs/record_application FOO'... [OK] Running 'Process programs/app_post FOO U'... [OK] Running 'Process programs/update_catalog'... [OK] Done.
context <context-name> module upgrade [options] <localPackagePath> context <context-name> module upgrade [options] <moduleName>
Cette opération permet d'upgrader un module à partir d'un paquet local (archive .webinst stocké en local sur le serveur) ou à partir d'un paquet disponible sur un dépôt de paquets distant accessible par HTTP ou FTP.
Les options disponibles sont :
–nopre' permet de ne pas exécuter les processus de `pre-upgrade' déclarés par le paquet.–nopost' permet de ne pas exécuter les processus de `post-upgrade' déclarés par le paquet.–nothing' permet de ne pas exécuter les processus de `pre-upgrade' et de `post-upgrade' déclarés par le paquet.–force' permet de forcer l'upgrade du paquet même si une version supérieure ou égale est déjà installée.# /var/www/dynacase-control/wiff context test module upgrade /tmp/foo-2.0.0-1.webinst Processing required module 'foo' (2.0.0-1) for upgrade. Module 'foo-2.0.0-1' is already downloaded in '/private/tmp/foo-2.0.0-1.webinstwEvSU3'. Doing 'pre-upgrade' of module 'foo'. Running 'Check php class XML_Parser'... [OK] Running 'Check php class XML_RSS'... [OK] Running 'Check php function imap_open'... [OK] Doing 'unpack' of module 'foo'. Unpacking module 'foo'... [OK] Doing 'post-upgrade' of module 'foo'. Running 'Process programs/pre_migration FOO'... [OK] Running 'Process programs/app_post FOO U'... [OK] Running 'Process programs/record_application FOO'... [OK] Running 'Process programs/post_migration FOO'... [OK] Running 'Process programs/update_catalog'... [OK] Done.
context <context-name> param show [<moduleName>]
Cette opération permet d'afficher la liste des paramètres des modules installés.
# /var/www/dynacase-control/wiff context test param show freedom-core:client_name = Test freedom-core:core_db = test freedom-core:authtype = html freedom-core:apacheuser = _www foo:bar = baz foo:bir = biz
# /var/www/dynacase-control/wiff context test param show foo foo:bar = baz foo:bir = biz
context <context-name> param get <module-name>:<param-name>
Cette opération permet d'afficher la valeur d'un paramètre d'un module donné.
# /var/www/dynacase-control/wiff context test param get foo:bar foo:bar = baz
context <context-name> param set <module-name>:<param-name> <param-value>
Cette opération permet de positionner la valeur d'un paramètre d'un module donné.
# /var/www/dynacase-control/wiff context <context-name> param set foo:bar buzz foo:bar = buzz
wstop <context-name>
Cette opération permet d'exécuter le script historique `wstop' sur un contexte.
# /var/www/dynacase-control/wiff wstop test check update needed (/var/www/test/wcheck)
wstart <context-name>
Cette opération permet d'exécuter le script historique `wstart' sur un contexte.
# /var/www/dynacase-control/wiff wstart test
whattext <context-name>
Cette opération permet d'exécuter le script historique `whattext' sur un contexte.
# /var/www/dynacase-control/wiff whattext test
context <context-name> shell context <context-name> exec <command> [<command-options>]]
Cette opération permet d'ouvrir un shell, ou d'exécuter une commande, sous l'uid de l'utilisateur exécutant le serveur Apache afin d'effectuer manuellement des opérations d'administration spécifiques.
Par défaut, si aucune commande n'est spécifié, le shell par défaut définit pour l'utilisateur du serveur Apache est lancé. Si l'utilisateur n'a pas de shell associé, il faudra alors spécifier le chemin du shell qu'on souhaite exécuter avec la variante `exec'.
Lors de l'ouverture du shell, ou de l'exécution de la commande, les variables d'environnement suivantes sont pré-positionnés :
HOME' : le répertoire racine du contexte.wpub' : le répertoire racine du contexte (pour compatibilité scripts post/migr de Freedom).pgservice_core' : le service Postgresql de la base `core' (pour compatibilité scripts post/migr de Freedom).pgservice_freedom' : le service Postgresql de la base `freedom' (pour compatibilité scripts post/migr de Freedom).freedom_context' : vaut toujours ”default” (pour compatibilité scripts post/migr de Freedom).# /var/www/dynacase-control/wiff context test shell /bin/bash wiff(test)~$ id uid=70(_www) gid=70(_www) egid=20(staff) groups=70(_www) wiff(test)~$ pwd /var/www/test wiff(test)~$ ./FOO/FOO_post U [...]
# /var/www/dynacase-control/wiff context test exec /usr/bin/tar -zcf /tmp/archive.tar.gz .
archive [--to <directory>] [--prefix <prefix>]
Cette commande permet de faire une archive de Dynacase-control avec son paramétrage.
Les options disponibles sont :
–to <directory>' permet de spécifier le répertoire dans lequel sera créée l'archive.–prefix <prefix>' permet de spécifier le prefixe du nom de l'archive. Le préfixe peut contenir les éléments variables suivant :context <context-name> archive all [--to <directory>] [--prefix <prefix>] context <context-name> archive pubdir [--to <directory>] [--prefix <prefix>] context <context-name> archive database <database-service-name> [--to <directory>] [--prefix <prefix>] context <context-name> archive vault <vault-path> [--to <directory>] [--prefix <prefix>]
Cette commande permet de sauvegarder tout (`all'), ou une partie (`pubdir', `database' et`vault'), des éléments d'un contexte.
Les options disponibles sont :
–to <directory>' permet de spécifier le répertoire dans lequel seront créées les archives.–prefix <prefix>' permet de spécifier le prefixe du nom de l'archive. Le préfixe peut contenir les éléments variables suivant :
Dans cette page, je vais présenter les éléments constitutifs d'un module Dynacase et mettre en oeuvre ces éléments pour construire un module d'exemple qu'on nommera freedom-foo.
Pour bien suivre cette présentation, il est souhaitable d'avoir bien en tête les notions d'Applications et d'Actions de Dynacase et du fonctionnement général de ceux-ci.
[A détailler]
Vous avez surement déjà manipulé des Applications et des Actions dans Dynacase…
[A détailler]
Dans les exemples ci-dessous, nous allons détailler la construction d'un module freedom-foo qui fournira une Application Dynacase nommé FOO, avec un ensemble d'actions associés.
Le fichier info.xml permet de décrire le module Dynacase en fournissant en particulier la version du module, une description, des dépendances avec d'autres modules Dynacase, un ensemble de paramètres, un descriptif des évolutions (changelog), et un ensemble d'action de pre-install, post-install, etc.
<?xml version="1.0"?> <module name="freedom-foo" version="1.2.3" release="1" [basecomponent="no"]> <description lang="en">Freedom foo</description> [<description lang="fr">Freedom toto</description>] <requires> [<installer version="1.0.0" comp="ge" />] <module name="freedom-bar" /> <module name="freedom-baz" version="1.0.0" comp="ge" /> [...] </requires> <parameters> <param name="foo_dir" label="Directory of FOO" type="text" default="/var/foo" needed="yes" /> <param name="foo_color" label="Color of FOO" type="enum" values="red|green|blue" default="green" needed="no" /> </parameters> <changelog> <version number="1.1.1" date="2009-01-01"> <change title='First change' url='http://dev.dynacase.org/issues/111'> Comment for first change. </change> <change title='Second change'> Comment for second change. </change> <change title='Third change'> </change> </version> <version number="1.1.0" date="2008-12-15"/> </changelog> <pre-install> <check type="syscommand" command="zip" /> <check type="phpfunction" function="pg_connect"> <help>You might need to install a php-pg package.</help> </check> <check type="file" file="/var/foo" predicate="is_dir" /> </pre-install> <post-install> <process command="programs/app_post FOO I" /> <process command="programs/record_application FOO" /> <process command="programs/app_post FOO U" /> <process command="programs/update_catalog" /> </post-install> <post-upgrade> <process command="programs/pre_migration FOO" /> <process command="programs/app_post FOO U" /> <process command="programs/record_application FOO" /> <process command="programs/post_migration FOO" /> <process command="programs/update_catalog" /> </post-upgrade> <post-param> </post-param> </module>
La racine du document info.xml est un tag <module> avec les attributs suivants :
name : le nom du moduleversion : la version du module (sous la forme N.N.N)release : le numéro de release de la versionbasecomponent : yes ou no, permet de spécifier si le module est un module de base, obligatoire a toute installation de Dynacase (optionnel, par défaut la valeur est no)author : l'auteur du module (ex. John Doe john.doe@example.net)(optionnel)licence : licence du module (optionnel)<?xml version="1.0"?> <module name="freedom-foo" version="1.2.3" release="rc1" author="John Doe <john.doe@example.net>" licence="GPLV2"> [...] </module>
Le module peut fournir une description textuelle pour expliciter le rôle du module. On pourra fournir des descriptions localisés en utilisant l'attribut lang.
Exemple :
<description lang="fr">Ce module permet à Dynacase de se connecter à FOO</description> <description lang="en">This module allows Dynacase to connect to FOO</description>
Les dépendances permettent d'exprimer qu'un module requiert d'autres modules Dynacase avec eventuellement une contrainte sur la version de ceux-ci.
Le tag <requires> est composés d'éléments <module> qui ont les attributs suivants :
name : le nom du module Dynacase requisversion : la version que le module requis doit avoircomp : gt ou ge, opérateur de comparaison de version
Le module peut aussi exprimer une contrainte sur la version de l'installeur lui même à l'aide de l'élément <installer>. Dans ce cas, les attributs sont :
version : la version de l'installeur que requiert le modulecomp : gt ou ge, opérateur de comparaison de version Exemple :
<requires> <installer version="1.0" comp="ge" /> <module name="freedom-bar" version="2.0" comp="ge" /> <module name="freedom-baz" version="1.9" comp="gt" /> <requires>
Dans cet exemple, le module requiert un installeur avec une version >= 1.0, le module freedom-bar en version >= 2.0 et le module freedom-baz en version > 1.9.
Le changelog permet d'indiquer les évolutions produites en rapport avec les versions du module. Ces informations sont contenues dans une balise <changelog> contenant des <version>.
Les éléments <version> ont les attributs suivants :
number : le numero de versiondate : la date de publication de la version
Les éléments <version> contiennent des éléments <change> qui décrivent chaque changement effectué. Les éléments <change> ont les attributs suivants :
title : l'intitulé du changementurl : une url en rapport avec le changement (dans l'interface dynacase-control, les chaines de forme issues/111/ sont reconnues et donnent comme texte du lien affiché 'issues 111' ; sinon un texte par défaut est utilisé)
La valeur de l'élément <change> constitue une description.
Exemple :
<changelog> <version number="1.1.1" date="2009-01-01"> <change title='First change' url='http://dev.dynacase.org/issues/111'> Comment for first change. </change> <change title='Second change'> Comment for second change. </change> <change title='Third change'> </change> </version> <version number="1.1.0" date="2008-12-15"/> </changelog>
Un module peut demander lors de son installation (ou upgrade) l'entrée de certains paramètres.
Les paramètres nécessaires au module sont renseignés avec un élément <parameters> contenant des éléments <param>.
Les élements <param> ont les attributs suivants :
name : le nom du paramètrelabel : le label textuel pour présenter le paramètretype : text ou enum, permet de spécifier le type de donnée attendudefault : la valeur par défaut présenté à l'utilisateur lors de la saisie des paramètres.needed : yes ou no, permet de spécifier si la saisie du paramètre est obligatoire ou optionnelle.values : lorsque type=“enum”, l'attribut values permet de spécifier une list de choix finis à partir de laquelle l'utilisateur selectionnera une valeur Exemple :
<parameters> <param name="foo_dir" label="Directory of FOO" type="text" default="/var/foo" needed="yes" /> <param name="foo_color" label="Color of FOO" type="enum" values="red|green|blue" default="green" needed="no" /> </parameters>
Lors de l'installation, upgrade ou suppression d'un module, un ensemble d'actions peuvent être effectués avant (pre) et après (post) l'opération suivant l'ordre suivant :
Chaque phase (pre-install, post-install, etc.) spécifie un ensemble de check ou process qui sont exécutés et qui retournent un status d'échec ou de réussite.
Une phase est validé lorsque tous ses sous-éléments check ou process ont retournés un statut de réussite.
Si une phase n'est pas validé, alors l'installation, ou l'upgrade, alors il est présenté à l'utilisateur les messages d'erreurs rencontrés, et celui-ci peut rejouer la phase après avoir eventuellement corrigé le problème, ou bien il peut choisir d'ignorer les messages d'erreurs et poursuivre l'install/ugprade.
Les éléments de pre-install s'exécutent avant l'installation des fichiers du module sur le système de fichier.
Les actions possible peuvent être des éléments <check>.
Chaque élément <check> peut fournir un élément <help> qui sera présenté à l'utilisateur lorsque l'action échoue.
Exemple :
<pre-install> <check type="phpfunction" function="pspell_new"> <help>Il faut peut-être installer php5-pspell avec apspell et aspell-fr</help> </check> <check type="syscommand" command="convert" /> </pre-install>
Les actions de pre-install serviront généralement à vérifier la présence de certains éléments et bloquer l'installation si ces éléments ne sont pas présents/corrects.
Les éléments de post-install s'exécutent après l'installation des fichiers du module sur le système de fichier.
Les actions possible peuvent être des éléments <process>.
Chaque élément <process> peut fournir un élément <label> qui sera présenté à l'utilisateur lorsque l'action sera exécuté.
Exemple :
<post-install> <process command="programs/record_application FOO"> <label lang="en">Record FOO application in database</label> </process> <process command="programs/update_catalog"> <label lang="en">Generate localization catalog</label> </process> </post-install>
Les actions de post-install serviront généralement à configurer le module qui viens d'être isntallé. Une erreur dans la phase de post-install laissera les fichiers installés en place, mais le paquet sera marqué en erreur de post-install dans l'interface.
Les éléments de pre-upgrade s'exécutent avant l'installation des nouveaux fichiers du module sur le système de fichier.
Les actions possible peuvent être des éléments <check>.
Chaque élément <check> peut fournir un élément <help> qui sera présenté à l'utilisateur lorsque l'action échoue.
Exemple :
<pre-upgrade> <check type="phpfunction" function="pspell_new"> <help>Il faut peut-être installer php5-pspell avec apspell et aspell-fr</help> </check> <check type="syscommand" command="convert" /> </pre-upgrade>
Les actions de pre-upgrade serviront généralement à vérifier la présence de certains éléments et bloquer l'upgrade si ces éléments ne sont pas présents/corrects.
Les éléments de post-upgrade s'exécutent après l'installation des nouveaux fichiers du module sur le système de fichier.
Les actions possible peuvent être des éléments <process>.
Chaque élément <process> peut fournir un élément <label> qui sera présenté à l'utilisateur lorsque l'action sera exécuté.
Exemple :
<post-upgrade> <process command="programs/pre_migration FOO"> <label lang="en">Pre-migration scripts</label> </process> <process command="programs/record_application FOO"> <label lang="en">Update application record in database</label> </process> <process command="programs/post_migration FOO"> <label lang="en">Post-migration scripts</label> </process> <process command="programs/update_catalog"> <label lang="en">Re-generate localization catalog</label> </process> </post-install>
Les actions de post-upgrade serviront généralement à configurer le module qui viens d'être isntallé, lancer les scripts de migration, etc. Une erreur dans la phase de post-upgrade laissera les fichiers installés en place, mais le paquet sera marqué en erreur de post-upgrade dans l'interface.
Les éléments check permettent d'executer des actions pour vérifier la présence de certains éléments.
Le check de type phpfunction permet de vérifier la présence d'une fonction PHP.
Le nom de la fonction testé est spécifié avec l'attribut function.
Exemple :
<check type="phpfunction" function="pg_connect" />
Le check de type syscommand permet de vérifier la présence d'une commande disponible sur le système.
Le nom de la command testé est spécifié avec l'attribut command
Exemple :
<check type="syscommand" command="convert" />
Le check de type phpclass permet de vérifier la présence d'une classe objet PHP.
Le nom de la classe PHP est fournis avec les attributs suivants :
include : le nom du fichier pour inclure la définition de la classeclass : le nom de la classeExemple :
<check type="phpclass" include="Net/SMTP.php" class="Net_SMTP" />
LE check de type apachemodule permet de vérifier qu'un module Apache particulier est activé et chargé par celui-ci.
Le nom du module est spécifié par l'attribut module.
Exemple :
<check type="apachemodule" module="mod_expires" />
Les éléments process servent à exécuter les actions permettant d'effectuer les opérations nécessaires au fonctionnement du module suite à son installation.
Prototype :
programs/app_post <APPNAME> I|UUtilisable dans les phases :
post-installpost-upgradeConditions d'utilisation :
post-install, le programme doit être exécuté avec le programme record_applicationpost-upgrade, le programme doit être exécuté après pre_migration et avant le programme record_application
Le programme app_post permet de lancer un script _post pour initialiser une application Dynacase.
Les arguments sont :
I | U : Le nom de la phase d'initialisation a exécuter (I pour install, U pour upgrade)Exemple :
<post-install> <process command="programs/post_app WEBDESK I" /> [...] </post-install> <post-upgrade> [...] <process command="programs/post_app WEBDESK U" /> [...] </post-upgrade>
Prototype :
programs/record_application <APPNAME>Utilisable dans les phases :
post-installpost-upgradeConditions d'utilisation :
app_post
Le programme record_application est utilisé pour enregistrer, ou mettre à jour, la définition de l'application en base de données.
La ligne de commande est spécifié par l'attribut command.
record_application prend en argument le nom de l'application à enregistrer.
Exemple :
<process command="programs/record_application FOO" />
Prototype :
programs/update_catalogUtilisable dans les phases :
post-installpost-upgradeConditions d'utilisation :
Le programme update_catalog est utilisé pour ré-générer le catalogue des messages de localisation.
Exemple :
<process command="programs/update_catalog" />
Prototype :
programs/pre_migrationUtilisable dans les phases :
post-upgradeConditions d'utilisation :
app_post
Le programme pre_migration est utilisé pour exécuter les scripts de pre-migration d'un module lors de sa mise-à-jour.
Exemple :
<process command="programs/pre_migration" />
Prototype :
programs/post_migrationUtilisable dans les phases :
post-upgradeConditions d'utilisation :
record_application, et avant le update_catalog
Le programme post_migration est utilisé pour exécuter les scripts de post-migration d'un module lors de sa mise-à-jour.
Exemple :
<process command="programs/post_migration" />
Prototype :
./wsh.phpUtilisable dans les phases :
post-installpost-upgradeConditions d'utilisation :
Le programme ./wsh.php est utilisé pour exécuter des méthodes sur des classes documentaires et exécuter des API Dynacase.
Exemple :
<process command="./wsh.php --api=freedom_refresh --method=postModify --famid=FOO" />
Vous avez la possibilité d'écrire vos propres programmes de post-install, post-upgrade, etc. afin d'effectuer des opérations spécifiques à votre module.
Ces programmes seront généralement développés soit en shell Bash soit en PHP. Ils seront disponible après la phase de décompression de votre paquet, dans le répertoire que vous aurez spécifié à l'empaquetage.
Le programme est exécuté dans le répertoire racine de l'installeur DYNACASE-CONTROL, et les variables d'environnement suivantes sont accessible depuis le script :
$CWD) dans lequel sera exécuté votre programmes)Exemple :
#!/bin/bash set -e # -- Récupérer la valeur du paramètre `foo_dir' spécifié par l'utilisateur PARAM_FOO_DIR=`"$WIFF_ROOT"/wiff --getValue=foo_dir` # -- Créer le répertoire s'il n'existe pas if [ ! -d "$PARAM_FOO_DIR" ]; mkdir "$PARAM_FOO_DIR" fi # -- Ajouter le nom de ce répertoire dans le fichier # -- `foo_dir.list' dans le sous-répertoire de mon module `FOO' echo "$PARAM_FOO_DIR" >> "$WIFF_CONTEXT_ROOT"/FOO/foo_dir.list
Note : Le programme PHP a aussi accès aux variables d'environnement, comme le script Bash, mais le chemin d'include doit être construit en fonction de vos besoins.
Exemple :
#!/usr/bin/env php <?php $WIFF_ROOT=getenv('WIFF_ROOT'); if( $WIFF_ROOT === false ) { print "WIFF_ROOT environment variable is not set!"; exit( 1 ); } $WIFF_CONTEXT_ROOT=getenv('WIFF_CONTEXT_ROOT'); if( $WIFF_CONTEXT_ROOT === false ) { print "WIFF_CONTEXT_ROOT environment variable is not set!"; exit( 1 ); } # -- Si je dois accéder aux fichier d'include de Dynacase # -- j'ajoute les répertoire d'include de Dynacase # -- dans mon include_path PHP set_include_path( get_include_path().PATH_SEPARATOR."$WIFF_ROOT/include".PATH_SEPARATOR$WIFF_CONTEXT_ROOT ); set_include_path(join(PATH_SEPARATOR, array( get_include_path(), "$WIFF_ROOT/include", "$WIFF_CONTEXT_ROOT" ))); # -- A présent, je peux inclure les librairies de l'installeur require("lib/Lib.Cli.php"); # -- ... et les librairies Dynacase require("WHAT/Lib.Common.php"); $param_foo_dir = wiff_getParamValue('foo_dir'); if( ! is_dir($param_foo_dir) ) { $ret = mkdir($param_foo_dir); if( $ret === false ) { print sprintf("Error: could not create directory '%s'!", $param_foo_dir); exit( 1 ); } } ?> [A compléter]
Pour fabriquer votre fichier webinst il faut disposer d'un fichier configure.in d'un fichier Makefile.in comme ceux-ci.
Le configure.in
# Autoconf script for libphp
#
#
AC_REVISION($Id: configure.in $)
dnl
dnl Process this file with autoconf to produce a configure script.
dnl
AC_PREREQ(2.13)
AC_INIT(./Makefile.in)
AC_SUBST(VERSION)
VERSION=`cat VERSION`
AC_SUBST(RELEASE)
RELEASE=`cat RELEASE`
AC_SUBST(PACKAGE)
PACKAGE=freedom-myapplication
AC_SUBST(APPNAME)
APPNAME=MYAPP
ac_default_prefix=/usr/share/what
AC_SUBST(PUBRULE)
PUBRULE=
AC_ARG_WITH(pubrule, [ --with-pubrule=dir Path to PubRule], PUBRULE=$withval)
if test "x$PUBRULE" != "x"; then
PUBRULEDIR=$PUBRULE
else
if test "x$PUBRULEDIR" == "x"; then
AC_CHECK_FILE($HOME/anakeen/devtools/PubRule, PUBRULEDIR=$HOME/anakeen/devtools/)
if test "x$PUBRULEDIR" = "x"; then
PUBRULEDIR=`pwd`
fi
fi
fi
AC_CHECK_FILE($PUBRULEDIR/PubRule, PUBRULE=$PUBRULEDIR)
if test "x$PUBRULE" = "x"; then
AC_MSG_ERROR([Could not find PubRule])
fi
AC_MSG_NOTICE([PubRule located at $PUBRULE])
AC_OUTPUT(Makefile info.xml )
Le Makefile :
# ============================================
# $Id: Makefile.in $
# ============================================
PACKAGE = @PACKAGE@
VERSION = @VERSION@
RELEASE = @RELEASE@
utildir=@PUBRULE@
pubdir = @prefix@
appname = offline
srcdir = @srcdir@
SUBDIR= Action
TOP_MODULES =
TAR = gtar
GZIP_ENV = --best
export targetdir PACKAGE
pages_not_xml = info.xml
include $(utildir)/PubRule
DISTFILES += $(SUBDIR) \
RELEASE VERSION
le makefile inclut le fichier Pubrule. Il contient un ensemble de règles pour publier le code et fabriquer les paquets.
Vous devez inclure ce fichier dans le répertoire de vos sources. Ensuite vous tapez :
autoconf ./configure make webinst
cela va générer le fichier webinst correspondant à votre module.
Cette page décrit comment installer ou mettre à jour un module Dynacase à partir d'un paquet Dynacase-control sans disposer d'un dépôt.
Cette fonction est disponible à partir de la version 0.2.2-6 de Dynacase-control.
L'empaquetage au format Dynacase-control d'un module Dynacase est décrit ici : Construction de modules pour Dynacase.
Vous disposez donc d'un paquet Dynacase-control monpaquet-x.y.webinst.
Rendez-vous sur l'interface Dynacase-control et positionnez vous dans le contexte pour lequel vous souhaitez importer le paquet.
En haut de la zone présentant la liste des paquets installés, le bouton 'Import module' est disponible.
Cliquez dessus, votre navigateur vous demande alors de choisir un fichier. Sélectionnez le paquet Dynacase-control correspondant au module à installer.
Le serveur analyse le contenu du paquet. Une fenêtre vous permet de préciser si vous souhaitez faire une installation ou une mise à jour. Suite à votre choix, l'installation ou la mise à jour se déroule comme pour celle d'un paquet issu d'un dépôt.
Les éventuelles dépendances nécessaires pour le module à installer ou mettre à jour sont contrôlées par rapport aux modules installés et ceux disponibles sur les dépôts nommés.
$ wiff mkrepoidx /var/www/my-dynacase-repo $ cat /var/www/my-dyncase-repo/content.xml
Si la machine sur laquelle est installé Dynacase n'a pas accès à Internet, vous pouvez créer un miroir local HTTP/FTP du dépôt de paquets en ligne.
$ mkdir /var/www/mirror $ cd /var/www/mirror $ wget --mirror --no-parent http://eec.anakeen.com/public/ $ wget --mirror --no-parent -X '/third-party/*/bak' ftp://ftp.dynacase.org/third-party
Configurer ensuite votre serveur Web pour servir ce répertoire `mirror', et modifier les paramètres par défaut du dépôt ”freedom” pour pointer sur ce nouveau dépôt.
http]localhost]/mirror/eec.ankaeen.com/public/platform]
Ajuster ensuite les paramètres `wiff-update-host' et `wiff-update-path' de l'installeur Dynacase-control pour chercher les mises-à-jour de l'installeur sur ce nouveau dépôt :
# vi /var/www/dynacase-control/conf/params.xml
[...]
<param name="wiff-update-host" value="http://localhost/"/>
<param name="wiff-update-path" value="mirror/eec.anakeen.com/public/control/"/>
[...]