Dynacase Control

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 :

  • contrôle de la présences des services (postgresl, php, etc…), modules php et autres logiciels attendus sur le serveur
  • possibilité d'utiliser plusieurs dépôts Dynacase (stable, test, dev)
  • gestion des modules Dynacase : modules installés, mise à jours possibles, modules disponibles, suppressions de modules
  • gestion des dépendances entre modules lors de l'installation
  • paramétrage et modification des paramétrages des modules

Dynacase-control permet donc de réaliser simplement une première installation de Dynacase-platform.

Pré-requis

  • Pré-Requis logiciels

    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.

    Navigateurs supportés

    La version Dynacase 3.0 est fonctionnelle avec les navigateurs suivants :

    • Internet Explorer 8
    • Firefox 3 (>3.5)
    • Chrome branche stable

    Apache

    version validée : 2.2

    Modules
    • php5_module
    • env_module
    • expires_module
    • dir_module
    • auth_basic_module
    • authn_file_module
    • authz_host_module
    • setenvif_module
    • rewrite_module

    PostgreSQL

    PHP

    Modules PHP utilisé

    Les modules notés (core) sont normalement inclus de manière statique dans PHP.

    • Core (core)
    • SimpleXML
    • calendar
    • ctype
    • date (core)
    • fileinfo
    • gd
    • gettext
    • iconv
    • imap
    • json
    • ldap
    • mbstring
    • pcntl
    • pcre
    • pgsql
    • posix
    • pspell
    • session (core)
    • sockets
    • standard (core)
    • xml
    • zip

    PEAR

    • XML/RSS.php
    • Net/SMTP.php
    • Mail/mime.php
    • Crypt/CHAP.php (optionnel)

    Commande *nix

    • rm
    • file
    • mkdir
    • tar
    • zip >= 3.0
    • unzip >= 6.0
    • convert
    • recode
    • php
    • ldapdelete (optional)
    • psql
    • pg_dump
    • msgcat
    01/02/2010 13:46 · Claverie Marc

Installation

  • Installation de Dynacase-control

    A cette étape, l'installation de Dynacase Control doit être réalisée par l'administrateur de votre serveur

    Pré-requis

    • Dynacase-control nécessite un serveur HTTP Apache 2.x avec PHP 5 (mod_php) et les modules : php xml, php zip, php json

    Il est nécessaire que le répertoire dans lequel sera installé Dynacase ait une directive ”AllowOverride All” positionné au niveau de la configuration Apache.

    • Si le paramètre ”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'.

    Installation

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

    Troubleshooting/FAQ

    PHP class 'DOMDocument' not found.

    Installer `php-dom' et/ou `php-xml'.

    PHP class 'ZipArchive' not found.

    Installer `php-zip'.

    PHP function 'json_encode' not found.

    Installer `php-json'.

    PHP function 'json_decode' not found.

    Voir Message ”PHP function 'json_encode' not found.”.

    02/04/2010 12:08
  • Création d'un contexte

    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 :

    • le répertoire racine du contexte : ce répertoire contient l'ensemble des modules et autres données installées
    • la base de données Dynacase (demandée par le module obligatoire dynacase-platform)

    Ces éléments sont à préparer par un administrateur système ayant les accès super-utilisateur (root) sur le serveur.

    Préparation du répertoire racine

    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.

    Création de la base de données

    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:

    Création du service Postgresql pour accèder à la base de données

    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
    

    Sous Debian (Lenny), la commande 'pg_config' est fournie par le paquet 'postgresql-server-dev-8.3' ; sous Ubuntu server 8.10 LTS, le package 'libpq-dev' est suffisant.

    # 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=# 
    

    Création du contexte

    Pour créer un contexte, il faut cliquer sur le lien “Create Context” et renseigner les champs indiqués.

    • Name : Nom du contexte
    • Root : Chemin relatif ou absolue ou seront installés les fichiers
    • Description : Commentaire sur le contexte
    • Repositories : Sélectionner la version de Dynacase à installer
    • Url : Url de l'installation de Dynacase
    02/04/2010 12:08
  • Première installation de Dynacase-platform avec Dynacase-control

    Installation du module de base

    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.

    Paramètres obligatoires

    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 :

    • client name : Nom de l'organisme/la société qui apparaîtra dans le login général de dynacase
    • database postgresql service name: : Nom du service PostgreSQL créé pour accéder à la base de données
    • authenticate default mode : html par défaut pour une authentification basée sur un formulaire Web
    • apache system user : Utilisateur sous lequel tourne apache (ex : www-data sous Debian)
    • temporary folder : répertoire utiliser pour stocker des données temporaires

    Vérifications de pré-installation

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

    Résolution des principales dépendances

    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 PATHaptitude install zip
    Checking if the command 'dot' is in the PATHaptitude install graphviz
    Checking if the command 'dot' is in the PATHaptitude install imagemagick
    Checking if the command 'html2ps' is in the PATHaptitude install html2ps
    Checking if the command 'php' is in the PATHaptitude install php5-cli
    Warning : Checking if the command 'ldapdelete' is in the PATH
    Checking if the command 'msgcat' is in the PATHaptitude 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
    Debian Lenny

    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
    
    Ubuntu 8.04 LTS
      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
    Ubuntu 10.04 LTS
      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

    Fin de l'installation et connexion à Dynacase-platform

    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 :

    Le mot de passe par défaut pour se connecter est “admin / anakeen”

    02/04/2010 12:08
  • Dépôts

    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

    02/04/2010 12:08
  • La mise à jour automatique est en cours de réalisation. Une très prochaine version de Dynacase-control intègrera cette fonctionnalité.

    Mise à jour de l'installeur Dynacase-control

    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.

    Mise à jour des modules Dynacase

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

    02/04/2010 12:08
  •  

Ligne de commande

  • Mode CLI

    Le CLI permet d'administrer le Dynacase-control en ligne de commande.

    Utilisation

    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').

    Commandes

    Lister les contextes existants

    Syntaxe
    list context [--pretty]
    
    Description

    Cette opération permet d'afficher les contextes installés.

    Exemple
    # /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
    

    Manipuler les modules du contexte

    Lister les modules installés

    Syntaxe
    context <context-name> module list installed [--pretty]
    
    Description

    Cette opération affiche les modules installés dans le contexte sélectionné.

    Exemple
    # /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)
    

    Lister tous les modules disponibles à l'installation

    Syntaxe
    context <context-name> module list available [--pretty]
    
    Description

    Cette opération affiche la liste des modules disponibles sur les dépôt de paquets accessibles par HTTP ou FTP.

    Exemple
    # /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)
    

    Lister les modules installés ayant une mise-à-jour de disponible

    Syntaxe
    context <context-name> module list upgrade [--pretty]
    
    Description

    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.

    Exemple
    # /var/www/dynacase-control/wiff context test module list upgrade
    freedom-core (2.14.1-12)
    freedom (2.14.3-18)
    

    Installer un module

    Syntaxe
    context <context-name> module install [options] <localPackagePath>
    context <context-name> module install [options] <moduleName>
    
    Description

    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é.
    Exemple

    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.
    
    

    Upgrader un module

    Syntaxe
    context <context-name> module upgrade [options] <localPackagePath>
    context <context-name> module upgrade [options] <moduleName>
    
    Description

    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.
    Exemple
    # /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.
    
    

    Manipuler les paramètres des modules

    Afficher l'ensemble des paramètres d'un ou des modules

    Syntaxe
    context <context-name> param show [<moduleName>]
    
    Description

    Cette opération permet d'afficher la liste des paramètres des modules installés.

    Exemple
    # /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
    

    Afficher la valeur d'un paramètre d'un module

    Syntaxe
    context <context-name> param get <module-name>:<param-name>
    
    Description

    Cette opération permet d'afficher la valeur d'un paramètre d'un module donné.

    Exemple
    # /var/www/dynacase-control/wiff context test param get foo:bar
    foo:bar = baz
    

    Positionner la valeur d'un paramètre d'un module

    Syntaxe
    context <context-name> param set <module-name>:<param-name> <param-value>
    
    Description

    Cette opération permet de positionner la valeur d'un paramètre d'un module donné.

    Exemple
    # /var/www/dynacase-control/wiff context <context-name> param set foo:bar buzz
    foo:bar = buzz
    

    Exécuter wstop sur un contexte

    Syntaxe
    wstop <context-name>
    
    Description

    Cette opération permet d'exécuter le script historique `wstop' sur un contexte.

    Exemple
    # /var/www/dynacase-control/wiff wstop test
    check update needed (/var/www/test/wcheck)
    

    Exécuter wstart sur un contexte

    Syntaxe
    wstart <context-name>
    
    Description

    Cette opération permet d'exécuter le script historique `wstart' sur un contexte.

    Exemple
    # /var/www/dynacase-control/wiff wstart test
    

    Exécuter whattext sur un contexte

    Syntaxe
    whattext <context-name>
    
    Description

    Cette opération permet d'exécuter le script historique `whattext' sur un contexte.

    Exemple
    # /var/www/dynacase-control/wiff whattext test
    

    Administration système

    Ouvrir un shell sous l'uid Apache

    Syntaxe
    context <context-name> shell
    context <context-name> exec  <command> [<command-options>]]
    
    Description

    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).
    Exemple
    # /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 .
    

    (PROPOSITION) Sauvegarde de Dynacase-control

    Syntaxe
    archive [--to <directory>] [--prefix <prefix>]
    
    Description

    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 :
      • `%d', `%M', etc. comme les éléments de `strftime()' (Voir strftime)
    Exemple

    (PROPOSITION) Sauvegarde d'un contexte

    Syntaxe
    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>]
    
    
    Description

    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 :
      • `%d', `%M', etc. comme les éléments de `strftime()' (Voir strftime)
    Exemple
    01/02/2010 10:41

Dépôts et paquets

  • Construction de modules pour Dynacase

    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]

    Présentation

    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.

    Les fichiers nécessaires

    Fichier ''FOO.app''

    Fichier ''FOO_init.php''

    Fichier ''info.xml''

    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.

    Exemple de fichier de info.xml

    <?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>

    Description d'un module

    Préambule Module

    La racine du document info.xml est un tag <module> avec les attributs suivants :

    • name : le nom du module
    • version : la version du module (sous la forme N.N.N)
    • release : le numéro de release de la version
    • basecomponent : 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>

    Description

    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>

    Dépendances

    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 requis
    • version : la version que le module requis doit avoir
    • comp : 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 module
    • comp : 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.

    Changelog

    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 version
    • date : 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 changement
    • url : 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>

    Paramètres

    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ètre
    • label : le label textuel pour présenter le paramètre
    • type : text ou enum, permet de spécifier le type de donnée attendu
    • default : 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>

    Pre/post install/upgrade/etc.

    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.

    pre-install

    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.

    post-install

    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.

    pre-upgrade

    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.

    post-upgrade

    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.

    pre-remove

    post-remove

    Les checks

    Les éléments check permettent d'executer des actions pour vérifier la présence de certains éléments.

    phpfunction

    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" />

    syscommand

    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" />

    phpclass

    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 classe
    • class : le nom de la classe

    Exemple :

      <check type="phpclass" include="Net/SMTP.php" class="Net_SMTP" />

    apachemodule

    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 process

    Les éléments process servent à exécuter les actions permettant d'effectuer les opérations nécessaires au fonctionnement du module suite à son installation.

    programs/app_post

    Prototype :

    • programs/app_post <APPNAME> I|U

    Utilisable dans les phases :

    • post-install
    • post-upgrade

    Conditions d'utilisation :

    • Dans la phase post-install, le programme doit être exécuté avec le programme record_application
    • Dans la phase post-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 :

    • Le nom de l'application (le script exécuté sera alors <APPNAME>_post)
    • 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>

    programs/record_application

    Prototype :

    • programs/record_application <APPNAME>

    Utilisable dans les phases :

    • post-install
    • post-upgrade

    Conditions d'utilisation :

    • Le programme doit être exécuté après le programme 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" />

    programs/update_catalog

    Prototype :

    • programs/update_catalog

    Utilisable dans les phases :

    • post-install
    • post-upgrade

    Conditions d'utilisation :

    • Le programme doit être exécuté à la fin de la phase

    Le programme update_catalog est utilisé pour ré-générer le catalogue des messages de localisation.

    Exemple :

      <process command="programs/update_catalog" />

    programs/pre_migation

    Prototype :

    • programs/pre_migration

    Utilisable dans les phases :

    • post-upgrade

    Conditions d'utilisation :

    • Le programme doit être exécuté au début de la phase, avant le programme 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" />

    programs/post_migation

    Prototype :

    • programs/post_migration

    Utilisable dans les phases :

    • post-upgrade

    Conditions d'utilisation :

    • Le programme doit être exécuté après le programme 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" />

    ./wsh.php

    Prototype :

    • ./wsh.php

    Utilisable dans les phases :

    • post-install
    • post-upgrade

    Conditions d'utilisation :

    • Le programme peut être utilisé à n'importe quel moment en fonction des besoins

    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" />

    Programmes personnalisés

    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 :

    • WIFF_ROOT : Le chemin du répertoire ou est installé DYNACASE-CONTROL (c'est donc aussi le répertoire courant ($CWD) dans lequel sera exécuté votre programmes)
    • WIFF_CONTEXT_ROOT : Le chemin du répertoire du contexte sur lequel est effectué l'opération.
    • WIFF_CONTEXT_NAME : Le nom du contexte sur lequel est effectué l'opération.
    Ecrire un programme personnalisé en shell Bash

    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
    Ecrire un programme personnalisé en PHP

    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]

    Générer le fichier .webinst

    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.

    01/02/2010 10:39
  • Préambule

    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.

    Installation d'un paquet

    Rendez-vous sur l'interface Dynacase-control et positionnez vous dans le contexte pour lequel vous souhaitez importer le paquet.

    bouton d'import de 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.

    01/02/2010 10:39
  • Créer son propre dépôt de paquets

    • Mettre ses paquets `.webinst' dans un répertoire accessible par HTTP ou FTP (ex. `/var/www/my-dynacase-repo')
    • Générer l'index `content.xml' de ce répertoire à l'aide de la commande wiff CLI :
    $ wiff mkrepoidx /var/www/my-dynacase-repo
    $ cat /var/www/my-dyncase-repo/content.xml
    
    14/10/2010 12:09 · Jérôme Augé
  • Miroir local des paquets

    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.

    • Dynacase-Control > Setup
    • Repositories > “freedom” > Modify
      • Protocol : [http]
      • Host : [localhost]
      • Path : [/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/"/>
    [...]
    
    01/02/2010 10:43
1) nous préconisons la 8.4 (dernière stable), le fonctionnement est identique avec les 2 versions
freedom_3/install/wiff-complet.txt · Dernière modification: 04/10/2010 08:59 par marc