Chapitre 1 Introduction

1.1 Abstract

Ce document décrit les procédures d'installation et de mise à jour de Dynacase Platform, et présente les principales procédures d'exploitation.

1.2 Présentation

L'installation d'un contexte Dynacase nécessite au préalable l'installation de Dynacase Control qui permet de créer et de gérer les contextes Dynacase. Dans un contexte Dynacase vous pouvez installer Dynacase Platform et les modules spécifiques à votre application.

1.3 Historique des modifications

1.3.1 Édition 12

• Dépréciation sous-commande wiff wstart et wiff wstop
• Modification Sauvegarde et restauration vis-à-vis de la mise en mode maintenance du contexte et de la sortie du mode maintenance du contexte
• Modification Sauvegarde et restauration avec Sauvegarde de dynacase-control et Restauration de dynacase-control

1.3.2 Édition 11

• Mise à jour pré-requis PHP {5.4, 5.5, 5.6} et Pg {9.1, 9.2, 9.3, 9.4}
• Restrictions sur le nom d'un paquet webinst et le nom d'un module dans Format des modules webinst
• Ré-initialisation de CORE_TMPDIR et FREEDOM_UPLOADDIR lors de la Restauration d'un contexte
• Ajout Enregistrement de contexte
• Mise à jour Check base documentaire
• Espace disque minimal requis pour Archiver un contexte
• Paramètre WIFF connect-timeout
• Ajout Suppression d'un contexte par l'interface Web

1.3.3 Édition 10

• Mise à jour pré-requis Firefox >= 4.0.1

1.3.4 Édition 9

• Mise à jour pré-requis PHP et PostgreSQL
• Mise à jour post-restore du workflow des opérations des modules webinst
• Précision sur la comparaison des versions de modules webinst
• Précision sur les variables MODULE_VERSION_{TO,FROM} dans les programmes personnalisés

1.3.5 Édition 8

• Ajout Journal des messages d'erreurs
• Ajout commande CLI pour Créer un nouveau contexte
• Ajout commande CLI pour Manipuler les propriétés d'un contexte
• Ajout commande CLI pour Modifier les dépôts de paquets utilisés par un contexte
• Ajout commande CLI pour Supprimer un contexte
• Ajout commande CLI pour Gérer la liste des dépôts de paquets de dynacase-control
• Ajout commande CLI pour Gérer les paramètres de dynacase-control
• Ajout commande CLI pour Enregistrer dynacase-control avec son compte EEC
• Ajout commande CLI pour Enregistrer un contexte avec son compte EEC
• Modification Format des modules webinst pour la validation XML (Voir Changements par rapport à l'ancien format)

1.3.6 Édition 7

• précision des versions des modules PEAR supportés
• versions PHP, PostgreSQL et du navigateur IE
• ajout chapitre Ajustement des références à la machine

1.3.7 Édition 6

• précision des versions des modules PEAR supportés

Chapitre 2 Prérequis

Ce chapitre identifie l'ensemble des prérequis pour l'installation et l'utilisation de Dynacase Platform.

Seuls les prérequis pour les modules standards sont listés.

2.1 Nouveautés 3.2

2.1.1 php-intl

Installer le module php Intl (php5-intl habituellement) et penser à relancer le service apache.

Ce module est utilisé pour l'internationalisation.

2.1.2 Implémentation libc de Iconv

La fonction iconv doit être fournie par PHP compilé avec GLIBC.

Pour vérifier cela :

$ iconv --version
iconv (Ubuntu EGLIBC 2.11.1-0ubuntu7.8) 2.11.1  
...
$ php -r 'var_dump(ICONV_IMPL); var_dump(iconv("UTF-8", "ASCII//TRANSLIT", "\xc3\xa9t\xc3\xa8"));'  
string(5) "glibc"
string(3) "ete"

2.1.3 Locales fr_FR et en_US

Les locales fr_FR.UTF-8 et en_US.UTF-8 (ainsi que les dictionnaires aspell de langue fr et en) doivent être installés et disponibles sur le serveur.

2.1.4 Apache mod_headers

Installer et activer le module Apache mod_headers.

2.2 Poste client

Les navigateurs supportés sont :

• Internet Explorer 8, 9 10 et 11 Updated
• Firefox branche stable Updated
• Chrome branche stable

3.2 R17 IE 8, 9, 10 et 11 / Chrome stable / Firefox stable

3.2 R11 IE 8, 9, 10 et 11 / Chrome stable / Firefox >= 4.0.1

3.2 R10 IE 8 et 9 / Chrome stable / Firefox > 3.6

2.3 Serveur

2.3.1 GNU/Linux

Dynacase fonctionne sur un système GNU/Linux (Debian, Ubuntu, RedHat, etc.).

2.3.1.1 Commandes système

Dynacase requiert les commandes système suivantes :

• rm
• file
• mkdir
• tar
• gzip
• zip (commande zip avec support de l'option -Z store de info-zip >= 3.0. En cas de problème avec la commande zip, utiliser la version fournie par Info-ZIP)
• unzip (En cas de problème avec la commande unzip, utiliser la version fournie par Info-ZIP)
• dot (fourni par Graphviz)
• convert (fourni par ImageMagick)
• recode
• html2ps
• ps2pdf (fourni par Ghostscript)
• php (PHP en ligne de commande. Voir les prérequis php)
• psql (Voir les prérequis postgresql)
• pg_dump (Voir les prérequis postgresql
• msgcat (fourni par gettext)
• ldapdelete (fourni par OpenLDAP) (optionnel)
• patch (fourni par patch)

2.3.1.2 Locales

Dynacase requiert que les locales systèmes fr_FR.UTF-8 et en_US.UTF-8 soient actives et correctement configurées sur le système.

Dynacase requiert aussi que les dictionnaires de langue fr et en de la librairie aspell soient installés et accessibles pour l'extension pspell de PHP.

2.3.2 PHP

18 Fév 2019 5.6 / 7.0 / 7.1 / 7.2

3.2 R17 5.6 / 7.0 / 7.1

3.2 R15 5.6 / 7.0 (Les versions 5.4 et 5.5 restent compatibles mais ne sont pas supportés. Les éventuels problèmes dus à ces versions obsolètes de PHP ne sont pas supportés par Anakeen.)

3.2 R14 5.4.4 / 5.5 / 5.6

3.2 R12 5.4.4 / 5.5

3.2 R11 5.4.4 / 5.5

3.2 R11 5.3

La version 5.3 n'est plus compatible à compter de la release 3.2 R12.

2.3.2.1 Zend Server

Pour les distributions Linux qui ne fournissent pas la version PHP nécessaire, Zend Server fournit différentes versions de PHP pour les distributions Linux.

2.3.2.2 Extensions PHP

Les extensions notées (core) sont normalement incluses de manière statique dans PHP.

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

2.3.2.3 Composants PEAR

3.2 R15 Aucune dépendance sur les composants PEAR n'est requise.

3.2 R14 modules Webdesk et Webdesk Services :

XML_Parser (1.3.2) / XML_RSS (1.0.2)

3.2 R10module Core :

XML_Parser (1.3.2) / XML_RSS (1.0.2) / Net_SMTP (1.6.0) / Mail_Mime (1.8.0) / Crypt_CHAP (optionnel)

2.3.2.4 Paramétrage PHP

Certains paramètres de PHP doivent être modifiés afin que Dynacase Platform fonctionne au mieux et en fonction de votre utilisation. Ces valeurs préconisées doivent être revues en fonction de votre configuration réelle et de vos applications.

2.3.2.4.1 Paramètres INI

date.timezone

Ce paramètre permet de spécifier le fuseau horaire utilisé par les fonctions de manipulation de date.

date.timezone = 'Europe/Paris'

max_execution_time

Ce paramètre permet de spécifier le temps maximal (en seconde) de traitement d'une requête par PHP. Par défaut ce paramètre est à “30”.

max_execution_time = 300 ; 5 min.

max_file_uploads

Ce paramètre permet de spécifier le nombre maximum de fichiers qui seront pris en compte par PHP lors de la soumission d'un formulaire contenant des fichiers.

Cette valeur doit être en cohérence avec le nombre maximum de fichier pouvant être soumis lors de l'enregistrement d'un document.

Si ce n'est pas le cas, l'enregistrement du document est refusé à l'utilisateur et le message d'erreur suivant est présenté à l'utilisateur : "Trop de fichiers dans le formulaire. Veuillez contacter votre administrateur système pour augmenter max_file_uploads dans php.ini. Le maximum est de %s".

Par défaut ce paramètre est à “20”.

max_file_uploads = 100

max_input_vars

Ce paramètre permet de spécifier le nombre maximum de variables de formulaires prises en compte par PHP lors de la soumission des formulaires.

Si vous avez beaucoup d'attributs sur vos familles et que la valeur déclarée de ce paramètre est trop basse, le message d'erreur suivant est présenté à l'utilisateur lors de la soumission des formulaire d'édition de documents : "Variables d'entrée dépassées %s. Veuillez contacter votre administrateur système pour augmenter max_input_vars dans php.ini.".

Par défaut ce paramètre est à "1000".

max_input_vars = 1000

error_reporting

Ce paramètre permet de spécifier le niveau de reporting des notices/warnings/erreurs/etc. Il est nécessaire de ne pas afficher les messages de notices (E_NOTICE), de dépréciation (E_DEPRECATED) et de suggestion (E_STRICT) de PHP lors de l'utilisation de Dynacase Platform en production.

error_reporting = E_ALL & ~E_NOTICE & ~E_DEPRECATED & ~E_STRICT

display_errors

Ce paramètre permet d'activer ou non l'affichage des erreurs PHP dans les réponses émises au client. En production, il est recommandé de désactiver le display_errors (les messages d'erreur/warning/suggestion de PHP seront alors consultables sur le serveur dans le fichier spécifié par le paramètre INI error_log).

Par défaut ce paramètre est à On.

display_errors = Off

2.3.2.5 htaccess

Les paramètres suivants sont définis dans le fichire .htaccess à la racine du contexte. Ils doivent êre redéfinis dans ce fichier, et doivent être repositionnés après chaque mise à jour de Dynacase.

post_max_size

Ce paramètre permet de spécifier la taille maximale d'une requête de type POST.

Par défaut ce paramètre est à "80M" (80 Mo).

post_max_size = "128M"

upload_max_filesize

Ce paramètre permet de spécifier la taille maximale d'un fichier téléversé. Si un fichier d'une taille supérieure est envoyé par le navigateur, il ne sera pas pris en compte par PHP.

Par défaut ce paramètre est à "80M" (80 Mo).

upload_max_filesize = "20M"

2.4 PostgreSQL

18 Fév 2019 9.1 / 9.2 / 9.3 / 9.4 / 9.5 / 9.6 / 10

3.2 R17 9.1 / 9.2 / 9.3 / 9.4 / 9.5 / 9.6

3.2 R15 9.1 / 9.2 / 9.3 / 9.4 / 9.5 (Les versions 9.1 / 9.2 / 9.3 restent compatibles. Néanmoins, les versions recommandées par Anakeen sont les dernières versions de Postgresql 9.4 et 9.5.)

3.2 R14 9.1 / 9.2 / 9.3 / 9.4

3.2 R12 9.1 / 9.2 / 9.3

3.2 R11 9.1 / 9.2 / 9.3

3.2 R11 8.4

La version 8.4 n'est plus compatible à compter de la release 3.2 R12

Les différentes optimisations, en particulier sur le calcul des droits ne sont effectives qu'avec la version 9.1 de PostgreSQL.

Dynacase utilise le fichier de service Postgresql (pg_service.conf) pour la définition des paramètres de connexion à la base de données :

• http://www.postgresql.org/docs/9.4/static/libpq-pgservice.html

Pour identifier l'emplacement du fichier pg_service.conf sur votre distribution Linux, vous pouvez utiliser la commande suivante :

# pg_config --sysconfdir

2.5 HTTPD Apache

Dynacase Platform nécessite le serveur HTTPD Apache en version 2.2 et 2.4.

Le répertoire dans lequel sera installé Dynacase doit avoir un AllowOverride All afin que les .htaccess livrée par Dynacase soient bien pris en compte par Apache :

• http://httpd.apache.org/docs/2.2/mod/core.html#allowoverride

L'utilisation avec Apache 2.4 requiert l'utilisation du module mod_access_compat :

• https://httpd.apache.org/docs/2.4/fr/mod/mod_access_compat.html

2.5.1 Modules Apache

Les modules Apache suivants sont requis :

• php5_module (Voir les prérequis php)
• env_module
• expires_module
• dir_module
• auth_basic_module
• authn_file_module
• authz_host_module
• setenvif_module
• rewrite_module
• headers_module

Si vous utilisez Apache 2.4, les modules suivants sont requis en plus des modules ci-dessus :

• mod_access_compat

Chapitre 3 Installation de Dynacase Control

Dynacase Control est l'outil qui permet d'installer et de gérer des contextes Dynacase.

3.1 Téléchargement

Dynacase Control est téléchargeable ici : http://dynacase.anakeen.com/control/dynacase-control-current.tar.gz.

Vous pouvez vous reporter à l'annexe Vérification de l'intégrité des éléments téléchargés pour plus d'explication sur le contrôle de l'intégrité des données téléchargées.

3.2 Installation

L'installation s'effectue sous le compte root.
L'archive "tar.gz" récupérée doit être décompressée dans un répertoire servi par Apache, par exemple dans le DocumentRoot de la configuration Apache.

root@server: cd /var/www      # Debian/Ubuntu  
root@server: cd /var/www/html # RedHat/CentOS

Télécharger l'archive de Dynacase Control:

wget http://dynacase.anakeen.com/control/dynacase-control-current.tar.gz

Extraire l'archive et renommer le répertoire :

tar zxf dynacase-control-current.tar.gz
mv dynacase-control-*-* dynacase-control  

Modifier le propriétaire du répertoire de Dynacase Control pour être celui de l'utilisateur faisant tourner Apache.

chown -R www-data: dynacase-control # Debian/Ubuntu
chown -R apache: dynacase-control   # RedHat/Centos

3.3 Première connexion

L'url de connexion dépend de votre configuration Apache. Si Dynacase Control a été installé dans votre Document Root, l'URL de connexion est : http://localhost/dynacase-control/

Lors de la première connexion à Dynacase Control, vous devez saisir un login et un mot de passe afin de contrôler l'accès à l'interface de Dynacase Control.

Figure 1. définition du login d'accès à Dynacase Control

Dynacase Control vous demande si vous souhaitez enregistrer ce dernier avec votre compte EEC.
Cet enregistrement vous permet de déclarer l'installation de Dynacase conformément à votre contrat EEC.

Figure 2. enregistrement EEC

Si vous n'avez pas de compte EEC, cliquez sur le bouton '[Register later…]'

Si vous n'enregistrez pas Dynacase Control lors de cette première connexion, vous aurez toujours la possibilité de le faire depuis l'interface Control.

3.4 Dynacase Control

3.4.1 Setup

Figure 3. interface Dynacase Control

L'interface Control > Setup permet de configurer Dynacase Control. Vous pouvez, depuis cet écran:

• Mettre à jour Dynacase Control lorsqu'une nouvelle version est détectée
• Changer le mot de passe de connexion à Dynacase Control : “Dynacase Control Information > Password”
• Enregistrer son Dynacase Control avec son compte EEC : “Dynacase Control Information > Registration > Register”
• control 1.5 (Dés)Activer le journal local des erreurs de Dynacase Control : “Local log > Local log On/Off”
• Ajouter/Supprimer/Modifier des dépôt de paquets : ”Repositories”
• Modifier les paramètres de Dynacase Control : ”Parameters”
• Voir les paramètres de PHP : “PHP Info”

Figure 4. interface setup Dynacase Control

3.4.1.1 Mise à jour de Dynacase Control

Lors de la connexion à l'interface Dynacase Control, celui-ci vérifie si une nouvelle version est disponible. Si c'est le cas, alors une popup propose de télécharger et d'appliquer la mise à jour :

Figure 5. mise à jour de Dynacase Control

Si vous refusez la mise à jour, il est alors possible d'appliquer ultérieurement la mise à jour en allant dans la section Setup > Dynacase Control Information, en cliquant sur le bouton [Update].

3.4.1.1.1 Configuration des mises-à-jour de Dynacase Control

Vous pouvez configurer l'hôte sur lequel Dynacase Control effectuera les recherches et téléchargements de mises-à-jour (c'est particulièrement utile lors de l'installation sur une machine n'ayant pas accès à internet). Par défaut, la configuration pointe sur le dépôt officiel Anakeen de Dynacase Control.

3.4.1.2 Enregistrement de Dynacase Control

L'enregistrement permet d'associer une instance de Dynacase Control avec votre contrat EEC. Cet enregistrement va automatiquement envoyer sur les serveurs de Dynacase certaines informations de configuration de votre serveur, permettant de simplifier les éventuelles interventions ultérieures de support. Enfin, l'enregistrement avec votre compte EEC va également ajouter automatiquement à Dynacase Control la liste des dépôts de paquets privés associés à votre contrat.

3.4.1.3 Dépôts de paquets

La section Repositories permet d'ajouter, supprimer et éditer des dépôts de paquets qui pourront être utilisés pour créer un contexte Dynacase.

Lorsque vous souhaitez installer une version donnée de Dynacase, il vous faut ajouter de dépôt correspondant.

Figure 6. Édition de dépôt

Lors de l'édition d'un dépôt, vous avez à renseigner les champs suivants:

3.4.1.3.1 Dépôts pré-configurées

Par défaut, le dépôt de la version communautaire de Dynacase Platform est pré-configuré :

• Repository : Dynacase
• Protocol : https
• Host : dynacase.anakeen.com
• Path : stable/

3.5 Utilisation d'un proxy

Si vos accès aux dépôts Dynacase Platform nécessitent l'utilisation d'un proxy HTTP, vous pouvez définir celui-ci avec les paramètres suivants :

3.6 Délai de connexion

Le paramètre connect-timeout (par défaut à 3) permet de spécifier le temps d'attente maximum pour l'établissement d'une connexion HTTP (e.g. connexion à un dépôt de paquet pour vérifier son statut ou lister son contenu).

• Si la valeur est positionnée à 0 (zéro), alors le temps d'attente maximum sera le temps d'attente maximum par défaut de la librairie cURL (soit 300 secondes).
• Si vous avez déclaré de nombreux dépôts de paquets inaccessibles, cela peut entrainer des ralentissements et des blocages transitoires dans l'interface. Dans ces cas là, il est préférable de supprimer les dépôts inaccessibles et éviter ainsi de devoir attendre l'expiration du délais de connexion à chaque accès à ces dépôts par dynacase-control.

3.7 Journal des messages d'erreurs

control 1.5

Les messages d'erreurs émis par dynacase-control sont enregistrés de la manière suivante :

• Le message est systématiquement envoyé au gestionnaire syslog local avec le tag dynacase-control et la "facility" déclarée par le paramètre syslog-facility (LOG_USER par défaut).

• Si le paramètre Local log > Local log On/Off est activé (dans la section Setup), le message est aussi envoyé dans le fichier log/wiff.log et consultable avec le bouton Local log > View de la section Setup.

3.7.1 Paramétrage syslog

3.7.1.1 syslog-facility

La "facility" des messages émis par syslog est paramétrable par le paramètre syslog-facility qui peut prendre les valeurs suivantes :

LOG_AUTH, LOG_AUTHPRIV, LOG_CRON, LOG_DAEMON, LOG_KERN, LOG_LOCAL0, LOG_LOCAL1, LOG_LOCAL2, LOG_LOCAL3, LOG_LOCAL4, LOG_LOCAL5, LOG_LOCAL6, LOG_LOCAL7, LOG_LPR, LOG_MAIL, LOG_NEWS, LOG_SYSLOG, LOG_USER, LOG_UUCP.

La valeur du paramètre n'est pas modifiable par l'interface Web Pour modifier sa valeur il faut éditer le fichier conf/params.xml et changer la propriété value du paramètre syslog-facility.

Exemple pour logger avec la "facility" LOG_LOCAL0 :

<param name="syslog-facility" mode="hidden" value="LOG_LOCAL0" />

Si la valeur de syslog-facility est vide, alors la "facility" LOG_USER est utilisée.

Si la valeur de syslog-facility n'est pas une "facility" valide, alors la "facility" LOG_USER est utilisée et un message d'erreur est émis indiquant que la "facility" spécifiée est invalide (Invalid syslog-facility 'XXX'. Using default facility.).

Chapitre 4 Installation d'un contexte

L'installation de Dynacase Platform et de ses modules est réalisée en créant un contexte Dynacase Control.

Un contexte regroupe l'ensemble des éléments nécessaires au fonctionnement d'une application Dynacase Platform : code des différents modules (installés ou générés), données et paramètres de configuration.

4.1 Création d'un contexte

L'item Create Context de l'interface Dynacase Control ouvre la fenêtre de création d'un nouveau contexte.

Figure 7. création d'un contexte

Vous êtes invité à saisir les paramètres du contexte :

Lorsque le contexte est créé, celui-ci apparaît dans la rubrique Context de l'interface de Dynacase Control.

Vous pouvez vous reporter à l'annexe Vérification de l'intégrité des éléments téléchargés pour plus d'explication sur le contrôle de l'intégrité des données téléchargées.

4.2 Sélection des modules

En sélectionnant le contexte créé, son détail et la liste des modules disponibles sont affichés.

Figure 8. détail d'un contexte

Vous pouvez maintenant sélectionner les modules que vous souhaitez installer parmi ceux proposés à la rubrique Available.

Les modules pré-sélectionnés (comme Dynacase Core) sont obligatoires.

En cliquant sur le bouton [Install Selection] , le processus d'installation commence. Dynacase Control vérifie les dépendances des paquets sélectionnés, et propose la liste des paquets qui seront installés.

Figure 9. contrôle des dépendances

Si vous êtes d'accord avec la liste proposée, vous pouvez valider cette liste et poursuivre l'installation.

4.3 Processus d'installation

Chacun des modules sélectionnés pour l'installation va suivre ce même processus d'installation :

• demande de licence
• demande des paramètres du module
• exécution des processus de pre-installation
• exécution des processus d'installation
• exécution des processus de post-installation

Figure 10. process d'installation

Le panneau principal détaille l'exécution des processus de pré-installation, installation et post-installation.

La liste des modules à installer est présentée dans la liste “Module List”. Les modules installés avec succès sont marqués par une pastille verte.

Les téléchargements des modules sont lancés.

4.3.1 Licence

Si nécessaire, il vous est demandé d'accepter les contrats de licence affichés.

Figure 11. contrat de licence

4.3.2 Paramètres

Les modules peuvent nécessiter des paramètres pour leur installation ou leur fonctionnement.

Figure 12. paramètres du module

L'installation de Dynacase Core (exemple ci-dessus) requiert les paramètres suivants :

4.3.3 Fin de l'installation

À la fin de l'installation, les modules installés sont présentés dans la section “Installed”.

Figure 13. fin de l'installation

Chapitre 5 Gestion des contextes

5.1 Description d'un contexte

Lors de la sélection d'un contexte, les sections suivantes sont présentées :

Informations

Les caractéristiques du contexte

Installed

la liste des modules installés

Available

la liste des modules disponibles

5.1.1 Informations

La section “Informations” présente les informations et la configuration générale du contexte.

de plus, les actions suivates sont disponibles au travers des boutons :

Modify Context

Permet de modifier la description du contexte et la liste des dépôts utilisés par ce dernier.

Import Module

Permet d'installer un module format .webinst sans passer par les dépôts de paquets (voir les annexes pour la description des fichiers webinst). Lors de l'utilisation de ce menu, il vous sera demandé d'uploader le fichier webinst, puis de choisir entre les scénarios d'installation et de mise à jour du module.
Cette action ne devrait pas être utilisée en dehors des phases de développement.

Create Archive

Permet d'archiver le contexte (voir la gestion des archives)

Delete context

Permet de supprimer le contexte et ses éléments associés (base de donnée, vault, etc.)

5.1.2 Installed

Cette section présente la liste des modules qui sont installés dans le contexte. Lorsqu'un module a une mise-à-jour de disponible sur les dépôts de paquets, une icone apparaît en début de ligne d'un module et la nouvelle version disponible est présentée dans la colonne Available Version. Pour mettre à jour le module, il faut alors cocher la ligne du module et cliquer sur le bouton [Upgrade Selection].

5.1.3 Available

La section “Available” présente la liste des modules disponibles sur les dépôts de paquets. Vous pouvez cocher les modules que vous souhaitez installer dans le contexte, et lancer l'installation en cliquant sur le bouton [Install Selection].

5.2 Archivage et restauration de contexte

Une archive de contexte contient tous les éléments d'un contexte (base de donnée, fichiers, etc.) Ces archives peuvent permettre la restauration d'un contexte sur une autre machine.

Attention : Cette fonctionnalité ne doit pas se substituer à une sauvegarde réguière de vos données. c'est une commodité de développement (voir Les procédures d'exploitation).

5.2.1 Archivage

Lors de l'utilisation du bouton [archivage], un assistant s'ouvre pour vous permettre de créer une archive.

Figure 14. Archivage

Il vous demande les éléments suivants :

Le fichier généré sera une archive avec l'extension .fcz et stocké dans le sous-répertoire archived-contexts de dynacase-control. Cette archive contiendra :

• Les fichiers du contexte.
• Un dump de la base de données.
• Les fichiers des vaults (si demandé).

5.2.2 Restauration

Les archives .fcz présentes dans le sous-répertoire archived-contexts de dynacase-control sont présentés dans la section "Archives" de l'interface de dynacase-control, sous la liste "Context".

Pour restaurer une archive il faut cliquer sur le bouton [Create Context] et remplir les informations demandées :

Notes :

• Ces répertoires doivent être créés manuellement et être accessibles en écriture à l'utilisateur Apache.
• 3.2 R14 Lors de la restauration d'une archive de contexte, si la valeur de CORE_TMPDIR, ou FREEDOM_UPLOADDIR, référence un répertoire à l'extérieur du répertoire du contexte, alors sa valeur est réinitialisée à sa valeur initiale (i.e. ./var/tmp).

5.3 Suppression d'un contexte

Un contexte peut être supprimé via Informations > Delete context. Une demande de confirmation est alors affichée afin de confirmer ou non l'exécution de l'opération.

La suppression d'un contexte comporte deux phases :

• La suppression "physique" des éléments du contexte.
• La suppression "logique" pour supprimer le contexte de la liste des contextes gérés par dynacase-control.

La suppression "physique" d'un contexte supprime dans l'ordre les éléments suivants :

• L'enregistrement de la crontab FREEDOM/freedom.conf.
• Le contenu des vaults du contexte.
• Le contenu de la base de données du contexte.
• Le contenu du répertoire racine du contexte.

Si la suppression d'un de ces éléments retourne une erreur, l'opération de suppression se poursuit avec les éléments suivants, et à la fin de l'opération un récapitulatif des erreurs rencontrés est affiché.

À la fin de l'opération de suppression "physique" (qu'il y ait eu des erreurs ou non), le contexte est alors supprimé "logiquement" de la liste des contextes gérés par dynacase-control.

5.4 Enregistrement de contexte

La procédure d'enregistrement d'un contexte peut vous être demandée dans le cadre du support EEC.

• Les informations collectées sont consultables sur le contexte dans Informations > Registration > Show configuration.

Figure 15. Informations d'enregistrement du contexte

• Ces informations peuvent être téléchargés sous la forme d'une archive Zip sur le contexte dans Informations > Registration > Download configuration.

Les informations collectées sont :

• Informations générales :
  • date de collecte des informations ;
  • nombre de comptes utilisateur du contexte ;
  • version de dynacase-control ;
  • version de PHP ;
  • version de PostgreSQL.
• Liste des modules installés avec leur version.
• Informations système :
  • informations système (uname -a) du serveur ;
  • capacité mémoire du serveur ;
  • nombre de processeurs du serveur ;
  • caractéristiques des processeurs du serveur.

Chapitre 6 Procédures d'exploitation

6.1 Sauvegarde et restauration

La sauvegarde se différencie de l'archivage par le fait que la sauvegarde est une opération effectuée par le service d'exploitation système, et qu'il peut s'intégrer plus facilement dans les procédures mises en place par le service informatique.

Ce chapitre va donc présenter quels sont les éléments de Dynacase à sauvegarder sur un serveur afin de pouvoir remonter ces éléments en cas de perte totale de ce serveur.

6.1.1 Éléments à sauvegarder

Les éléments à sauvegarder sont les suivants :

• Le répertoire de dynacase-control : il contient les méta-données des contextes ainsi que le code permettant de gérer l'installation et la mise à jour des contextes Dynacase.
• Pour chaque contextes Dynacase :
  • Le répertoire applicatif du contexte : il contient le code PHP des applications et des familles de documents.
  • La base de données : elle contient les documents et le paramétrage Dynacase.
  • Le ou les vaults : ils contiennent les fichiers insérés dans les documents Dynacase.

6.1.2 Sauvegarde

La sauvegarde se déroulera selon les étapes suivantes:

1. Sauvegarde de dynacase-control
2. Mise en mode maintenance du contexte
3. Sauvegarde de la base de données
4. Sauvegarde du répertoire applicatif du contexte
5. Sauvegarde du vault
6. Sortie du mode maintenance du contexte

6.1.2.1 Sauvegarde de dynacase-control

La sauvegarde de dynacase-control permet de sauvegarder les "méta-données" du contexte (la liste des modules installés dans ce contexte avec leur version).

tar zcf /backup/dynacase-control.tar.gz /var/www/dynacase-control

Si vous avez des archives de contextes et que vous ne souhaitez pas les sauvegarder ou bien vous souhaitez réduire le temps ou la taille de la sauvegarde de dynacase-control, vous pouvez alors exclure ces archives en ne sauvegardant pas les fichiers contenus dans le sous-répertoire archived-contexts :

tar zcf /backup/dynacase-control.tar.gz --exclude archived-contexts/\* /var/www/dynacase-control

Note :

• La sauvegarde de dynacase-control sauvegarde les méta-données de tous les contextes gérés par ce dynacase-control.

6.1.2.2 Mise en mode maintenance du contexte

Afin d'assurer l'intégrité des données, l'accès au contexte sera bloqué afin que les utilisateurs ne puissent pas modifier les données durant le déroulement de la sauvegarde.

Pour cela il faudra lancer le script ./wstop dans le contexte Dynacase qu'on sauvegarde :

/var/www/dynacase-control/wiff context <nomDuContexte> exec ./wstop

6.1.2.3 Sauvegarde de la base de données

La sauvegarde de la base de données s'effectue par un dump complet à l'aide de la commande pg_dump :

PGSERVICE=dynacase pg_dump | gzip > /backup/dynacase.pg_dump.gz

6.1.2.4 Sauvegarde du répertoire applicatif du contexte

Le répertoire du contexte contient des fichiers et des répertoires qui peuvent être sauvegardés de manière standard avec des outils comme tar :

tar zcf /backup/dynacase.context.tar.gz /var/www/dynacase

Afin de réduire la durée de sauvegarde vous pouvez exclure les éléments générés dynamiquement.

Ces éléments sont :

• le répertoire var/cache : sous-répertoire contenant des fichiers de cache.
• le répertoire var/session : sous-répertoire contenant les sessions.
• le répertoire var/tmp : sous-répertoire par défaut des fichiers temporaires.
• le répertoire var/upload : sous-répertoire de stockage des archives importées.

Vous pouvez aussi effectuer une sauvegarde incrémentale des fichiers du répertoire du contexte.

6.1.2.5 Sauvegarde du vault

Si vous avez conservé le vault dans son emplacement par défaut (par défaut dans le sous-répertoire vaultfs à la racine du contexte), alors le vault sera inclut dans la sauvegarde du répertoire applicatif du contexte ci-dessus.

Si vous avez déplacé le vault dans un répertoire distinct (ou que vous l'avez exclu de la sauvegarde du contexte ci-dessus), alors il vous faudra le sauvegarder de manière distincte.

Le vault, comme le répertoire du contexte, peut être sauvegardé avec des outils standards comme tar :

tar zcf /backup/dynacase.vault.tar.gz /data/vault

Une sauvegarde incrémentale est aussi possible pour ce répertoire.

6.1.2.6 Sortie du mode maintenance du contexte

Une fois les éléments sauvegardés, l'accès au contexte peut-être réouvert à l'aide du script wstart -m :

/var/www/dynacase-control/wiff wstart <nomDuContexte>

6.1.3 Restauration

L'ordre de restauration des éléments s'effectue de manière inverse à leur sauvegarde :

1. Restauration du vault
2. Restauration du répertoire applicatif du contexte
3. Restauration de la base de données
4. Sortie du mode maintenance du contexte
5. Restauration de dynacase-control

6.1.3.1 Restauration du vault

Restauration des fichiers précédemment archivés :

tar -C / -zxf /backup/dynacase.vault.tar.gz

6.1.3.2 Restauration du répertoire applicatif du contexte

Restauration des fichiers du contexte :

tar -C / -zxf /backup/dynacase.context.tar.gz

6.1.3.3 Restauration de la base de données

Re-créer la base de données avec les paramètres PostgreSQL adéquats :

• standard_conforming_strings positionné à off
• DateStyle positionné à ISO, DMY

ALTER DATABASE dynacase SET standard_conforming_strings = off;
ALTER DATABASE dynacase SET DateStyle = 'ISO, DMY';

Restaurer le dump de la base :

gzip -dc /backup/dynacase.pg_dump.gz | PGSERVICE=dynacase psql

Note : Pour accélerer le chargement des données, vous pouvez consulter la section Bulk data loading pour un exemple de paramétrage de Postgresql.

6.1.3.4 Ré-enregistrement des crontabs

Réenregistrer la crontab de Dynacase :

/var/www/dynacase-control/wiff context <nomDuContexte> exec ./wsh.php --api=crontab --cmd=register --file=FREEDOM/freedom.cron

Si votre application possède ses propres crontab, il faudra alors réenregistrer ses crontabs :

/var/www/dynacase-control/wiff context <nomDuContexte> exec ./wsh.php --api=crontab --cmd=register --file=MON_APP/ma_crontab.cron

6.1.3.5 Sortie du mode maintenance du contexte

Comme la sauvegarde a été effectué en mode maintenance (wstop), il faut à la fin réouvrir l'accès avec ./wstart -m :

/var/www/dynacase-control/wiff context <nomDuContexte> exec ./wstart -m

6.1.3.6 Restauration de dynacase-control

tar -C / -zxf /backup/dynacase-control.tar.gz

6.1.4 Ajustement des références à la machine Nouveau

Si la restauration s'effectue sur une machine différente de celle sauvegardée, c'est-à-dire que les chemins d'accès aux fichiers ou que le service de base de données sont différents, il faudra alors modifier les éléments restaurés pour refléter ces changements.

Les éléments qui référencent des chemins ou service de base de données dépendant de la machine sont décrits ci-dessous.

6.1.4.1 Chemin racine du contexte

Le chemin d'accès à la racine du contexte est référencé dans les fichiers suivants :

• 3.2 R15 Si le contexte utilise dynacase-core >= 3.2.21 :

supervisor/.htaccess

Modifier la directive AuthUserFile "/path/to/context/supervisor/.htpasswd" avec la nouvelle racine du contexte.

.htaccess

Modifier la directive php_value session.save_path "/path/to/context/var/session" avec la nouvelle racine du contexte.

• 3.2 R14 Si le contexte utilise dynacase-core < 3.2.21 :

supervisor/.htaccess

Modifier la directive AuthUserFile "/path/to/context/supervisor/.htpasswd" avec la nouvelle racine du contexte.

.htaccess

Modifier la directive php_value session.save_path "/path/to/context/var/session" avec la nouvelle racine du contexte.

WHAT/Lib.Prefix.php

Modifier la variable $pubdir = '/path/to/context'; avec la nouvelle racine du contexte.

Paramv CORE_PUBDIR

Modifier la valeur du paramv CORE_PUBDIR avec la nouvelle racine du contexte.

UPDATE paramv SET val ='/path/to/context' WHERE name = 'CORE_PUBDIR'

6.1.4.2 Chemin d'accès au vault

Le chemin d'accès à la racine du vault est référencé en base de données :

Table vaultdiskfsstorage, colonne r_path

Modifier le chemin r_path de la table vaultdiskfsstorage avec le nouvel emplacement du vault.

UPDATE vaultdiskfsstorage SET r_path = '/new/path/to/vaultfs' WHERE r_path = '/old/path/to/vaultfs';

6.1.4.3 Service de la base de donnée

Le nom du service de la base de donnée est référencée dans les fichiers suivants :

• 3.2 R15 Si le contexte utilise dynacase-core >= 3.2.21 :

config/dbaccess.php

Modifier les variables $pgservice_core = 'pgServiceName'; et $pgservice_freedom = 'pgServiceName'; avec le nouveau nom du service de base de données.

• 3.2 R14 Si le contexte utilise dynacase-core < 3.2.21 :

config/dbaccess.php

Modifier les variables $pgservice_core = 'pgServiceName'; et $pgservice_freedom = 'pgServiceName'; avec le nouveau nom du service de base de données.

Le nom du service de base de données est aussi référencée dans la base de données elle même :

Paramv CORE_DB, FREEDOM_DB et WEBDAV_DB

Modifier la valeur des paramv CORE_DB, FREEDOM_DB et WEBDAV_DB avec le nouveau nom du service de base de données.

UPDATE paramv SET val = 'service=''' || 'newPgServiceName' || '''' WHERE name IN ('CORE_DB', 'FREEDOM_DB', 'WEBDAV_DB');  

6.1.4.4 Nom d'hôte et URL

Le nom d'hôte de la machine peut être référencé dans la base de données :

Paramv CORE_URLINDEX

Si ce paramètre est renseigné, modifier la valeur avec la nouvelle URL.

UPDATE paramv SET val = 'http://newURL/xxx' WHERE name = 'CORE_URLINDEX';

Paramv CORE_OPENURL

Si ce paramètre est renseigné, modifier la valeur avec la nouvelle URL.

UPDATE paramv SET val = 'http://newOpenURL/xxx' WHERE name = 'CORE_OPENURL';

Paramv TE_INDEXURL

Si ce paramètre est renseigné, modifier la valeur avec la nouvelle URL.

UPDATE paramv SET val = 'http://newTeCallbackURL/xxx' WHERE name = 'TE_INDEXURL';

6.2 Check base documentaire

Une liste de vérification de problèmes pouvant se produire sur une installation Dynacase est disponible dans le sous-répertoire supervisor/ du contexte et accessible par l'URL : http://<nomDuServeur>/supervisor/, rubrique DB consistency.

L'interface présente alors une liste de vérification avec un statut :

•   (vert) si aucune erreur ou incohérence n'a été detecté ;
•   (rouge) ou   (orange) si des erreurs ou des incohérences ont été detectés.

Liste des vérifications :

main connection db

Vérifie que Postgresql est bien lancé.

dateStyle

Indique le dateStyle utilisé par la base courante.

unreferenced user in group

Vérifie les inconsistances de la table groups vis à vis des utilisateurs. La table groups contient les liens entre les utilisateurs et les groupes, dans certains cas des utilisateurs supprimés peuvent persister dans cette table.

Solution : Supprimer les références erronées

DELETE FROM groups WHERE iduser NOT IN (SELECT id FROM users);

user as group

Par exemple user as group1 users detected as group 25. Peut arriver par un import SQL qui écraserait les utilisateurs. Peut aussi provenir de groupes supprimés qui n'existe plus dans la table users.

Solution : Soit mettre les utilisateurs comme groupe (mettre l'attribut isgroup à Y dans la table users) ou supprimer la référence dans la table groups, puis rafraîchir la table users :

dynacase=# BEGIN;
dynacase=# DELETE FROM groups WHERE idgroup NOT IN (SELECT id FROM users WHERE isgroup='Y');
DELETE 110
dynacase=# COMMIT;
COMMIT

puis :

/var/www/dynacase-control/wiff context <nomDuContexte> exec ./wsh --api=freedom_groups

unreference actions

peut arriver lors de la suppression d'applications.

Solution : Appliquer le fichier SQL /var/www/dynacase/WHAT/what_clean.sql sur la base principale.

unreference parameters

peut arriver lors de la suppression d'applications

Solution : Appliquer le fichier SQL /var/www/dynacase/WHAT/what_clean.sql sur la base principale.

unreference acl

peut arriver lors de la suppression d'applications

Solution : Appliquer le fichier SQL /var/www/dynacase/WHAT/what_clean.sql sur la base principale.

unreference permission

peut arriver lors de la suppression d'applications

Solution : Appliquer le fichier SQL /var/www/dynacase/WHAT/what_clean.sql sur la base principale.

double doc id

Plusieurs documents ont le même identifiant numérique. Peut arriver lors d'importation avec des identificateurs fixe ou lors d'importation avec des familles inexistantes.

Exemple :

1 double id detected  
Array  
(  
    [1178] => 2  
)

Solution : Supprimer l'un des doublons (ou les deux)

Obtenir la liste des identifiants posant problème :

dynacase=# SELECT id,COUNT(*) FROM doc GROUP BY id HAVING COUNT(*) > 1;
  id  | COUNT
------+-------
 1178 |     2

Obtenir le détail des enregistrements posant problème :

dynacase=# SELECT id, title, fromid, locked FROM doc WHERE id = 1178;
  id  |      title      | fromid | locked
------+-----------------+--------+--------
 1178 | Fiche de suivi  |      0 |      0
 1178 | Dossier EI auto |   1169 |      0

Suppression de l'enregistrement incorrect :

dynacase=# DELETE FROM doc WHERE id = 1178 AND fromid = 0;
DELETE 1

double doc name

plusieurs documents ont le même identifiant logique (propriété name)

Solution : Supprimer l'un des doublons (ou les deux)

family inheritance

L'héritage déclaré par la famille ne correspond pas à celle défini dans postgresql. Peut arriver si on change l'héritage d'une famille ou si une famille est créée avant sa famille père.

Exemple :

Family [44232]: fromid = 0, pg inherit=  
Family [44237]: fromid = 0, pg inherit=  
Family [44241]: fromid = 0, pg inherit=  
…  

Solution : restaurer l'héritage

Identifier les enregistrement posant problème :

dynacase=# SELECT id, title, fromid, locked, doctype FROM doc WHERE fromid = 0 AND doctype IS NULL;
  id   | title | fromid | locked | doctype
-------+-------+--------+--------+---------
 44232 |       |      0 |      0 |
 44237 |       |      0 |      0 |
 44241 |       |      0 |      0 |
…

Supprimer les enregistrements :

dynacase=# DELETE FROM doc WHERE fromid = 0 AND doctype IS NULL;
DELETE 14

Ou supprimer la table correspondante et lancer :

# /var/www/dynacase-control/wiff context <nomDuContexte> exec ./wsh --api=fdl_adoc --docid=<N°famille>

multiple alive revision

Plusieurs révisions sont vivantes pour un même document. Cela peut arriver sur d'ancienne version (< 2.14) lorsque deux tentatives de révisions simultanées sont créés ou si par programmation on force des restauration.

Exemple :

2 multiple alive  
Array (  
    [73780] => jean-raymond.durand@example.net  
    [85480] => Restauration groupe test  
)

Solution : utiliser l'API fixMultipleAliveRevision

Obtenir le détail des enregistrements posant problème :

dynacase=# SELECT id, title FROM docread WHERE id IN (SELECT m AS id FROM (SELECT MIN(id) AS m, initid, COUNT(initid) AS c FROM docread WHERE locked != -1 AND doctype != 'T' GROUP BY docread.initid) AS z WHERE z.c > 1);
  id   |                        title
-------+-----------------------------------------------------
 73780 | jean-raymond.durand@example.net
 85480 | Restauration groupe test
(2 lignes)

API fixMultipleAliveRevision :

# /var/www/dynacase-control/wiff context <nomDuContexte> exec ./wsh.php --api=fixMultipleAliveRevision
Fixing mutiple alive revision for (initid='35198', id='85480')
Fixing mutiple alive revision for (initid='56405', id='73780')

attribute type

Vérifie la cohérence entre le type Dynacase d'un attribut et le type SQL de la colonne associée à cet attribut.

attribute orphan

Vérifie la cohérence entre la liste des attributs logiques Dynacase déclarés pour une famille et les colonnes physiques de la table docXXX pour cette famille.

Cette vérification détecte donc les colonnes de la table docXXX d'une famille qui ne correspondent pas, ou plus, à un attribut de cette famille (table docattr).

Solution : appliquer les requêtes SQL données en résultat pour supprimer les colonnes physiques des tables docXXX des familles ayant cette incohérence.

cleanContext cron job execution

Vérifie que la crontab de Dynacase est correctement exécutée en vérifiant qu'il n'existe pas de documents temporaires plus vieux de 1 jour. La présence de documents temporaires plus vieux de 1 jour peut indiquer que la crontab n'est soit pas bien enregistrée, soit que le mécanisme cron général est défaillant.

Solution : vérifier les points indiquer dans le résultat de la vérification.

missing documents in docread

Vérifie s'il y a des documents dans la table doc qui ne sont pas présents dans la table de "cache" docread.

Solution : mettre à jour les documents pour qu'ils soient insérés dans la table de "cache" docread.

dynacase=# UPDATE doc SET id = id WHERE id < 1e9 AND NOT EXISTS (SELECT 1 FROM docread WHERE docread.id = doc.id);

spurious documents in docread

Vérifie s'il y a des documents dans la table de "cache" docread qui n'existent plus dans la table doc.

Solution : supprimer les documents qui n'existent plus dans la table de "cache" docread.

dynacase=# DELETE FROM docread WHERE id < 1e9 AND NOT EXISTS (SELECT 1 FROM doc WHERE docread.id = doc.id);

missing family name

Vérifie s'il existe des familles dont le nom logique n'existe pas dans la table docfam ou qui est mal référencé dans les tables docname et docread.

Exemple :

• 1 unnamed family in docfam:
{17087}

Solution :

Mettre à jour le nom de la famille :

dynacase=# UPDATE docfam SET name = 'NOM_DE_LA_FAMILLE' WHERE id = <id-famille-sans-nom>;

Puis, lancer un cleanContext :

$ ./wsh.php --api=cleanContext

Si dynacase-workspace est installé, les vérifications additionnelles suivantes sont faites :

connection db webdav

Vérifie la disponibilité de la table webdav (si le module WORKSPACE est installé)

Si dynacase-networkuser est installé, les vérifications additionnelles suivantes sont faites :

connection USER LDAP

Vérifie le lien avec le LDAP (si le module NETWORKUSER est installé)

6.3 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 --level=1 --no-parent "http://dynacase.anakeen.com/control/?F=0"                                    # dynacase-control
$ wget --mirror --level=1 --no-parent --http-user=${EEC_USERNAME} --http-password=${EEC_PASSWD} "${EEC_REPO_URL}/?F=0" # Votre dépôt EEC Dynacase
$ wget --mirror --level=1 --no-parent "http://ftp.dynacase.org/third-party/?F=0"                                      # third-party elements

Les paquets du dépôt EEC font référence à des éléments additionnels téléchargés sur http://ftp.dynacase.org (dépôt third-party elements). Pour pouvoir être installés depuis le miroir il faut donc modifier ces paquets pour y inscrire la nouvelle racine pour le téléchargement de ces éléments additionnels.

Pour cela, dynacase-control fournit l'outils sedwebinst.php dans le sous-répertoire utils du répertoire d'installation de dynacase-control.

Cet outils prend 3 arguments qui sont :

1. l'URL à modifier ;
2. la nouvelle URL d'accès aux éléments de third-party sur votre miroir ;
3. et enfin le répertoire d'accès au dépôt des paquets de Dynacase qui contient les fichiers webinst.

$ php /var/www/dynacase-control/utils/sedwebinst.php \
    http://ftp.dynacase.org/third-party \
    http://localhost/mirror/ftp.dynacase.org/third-party \
    /var/www/mirror/eec.anakeen.com/$EEC_USERNAME/

Configurer ensuite votre serveur Web pour servir ce répertoire mirror, et configurer un dépôt pointant sur ce répertoire (voir la gestion des dépôts).

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 (voir la configuration des mises-à-jour de Dynacase Control).

6.4 Exploitation des logs

Les logs de Dynacase sont gérés au moyen de syslog.

Dynacase logue par défaut tous ses messages avec la facilité LOG_LOCAL6, à l'exception des erreurs d'authentification, qui sont journalisées avec la facilité LOG_AUTH (à moins que vous ayiez changé cette valeur au moyen du paramètre applicatif AUTH_LOGFACILITY).

Le formatage des logs suit la règle suivante: [<code>] Dynacase <application> <fonction> <message>, avec :

code

Le code de log, correspondant à la priorité :

• D pour la priorité DEBUG
• O pour les appels de fonction deprecated (priorité INFO)
• I pour la priorité INFO
• W pour la priorité WARNING
• E pour la priorité ERROR
• F pour la priorité ALERT

application

l'application, si définie, sous la forme :application

fonction

la fonction, si définie, sous la forme :fonction

Après chaque exécution de procédures automatiques (cron), des logs sont enregistrés dans le syslog. Ils contiennent le titre et l'id du processus exécuté, ainsi que le statut de l'exécution (0 en cas de succès) et le temps d'exécution de la procédure:

Aug 30 10:18:15 pc-de-test [I] Dynacase:CORE:WELCOME: []  Default Master [1] - : Process FDL IMPCARD [3355] executed in 1.005 seconds

Le même système est en place à chaque exécution de timer (minuteur).

L'api dynacaseDbCleaner produit, elle aussi, des logs. Ces logs sont de la forme:

Aug 27 09:25:55 ubuntu1004server dynacaseDbCleaner(CORE_CLIENT): DELETE 0
Aug 27 09:25:55 ubuntu1004server dynacaseDbCleaner(CORE_CLIENT): Temps : 3,868 ms

Chaque commande sql lancée par le dynacasDbCleaner est enregistrée. Le nom du client (paramétré à la configuration) est affiché à la place de CORE_CLIENT.

6.5 Suppression dépôts de paquets freedom-ecm.org

Les premières versions de Freedom et Dynacase étaient hébergés sur des serveurs du domaine freedom-ecm.org.

Suite au changement de nom, ce domaine n'est plus valide et vous ne devez plus utiliser de dépôts de paquets qui font référence à ce domaine.

Pour supprimer les références à ces anciens dépôts de paquets, vous pouvez soit les supprimer manuellement, soit utiliser le script utils/remove_freedom_ecm_repos.php fourni avec les dernières versions de dynacase-control pour supprimer automatiquement ces dépôts.

Le script fonctionne en mode notification (pour vous informer de la présence de dépôts invalides) ou en mode suppression (pour supprimer les dépôts invalides rencontrés).

Mode notification (mode par défaut) :

# cd /var/www/dynacase-control
# php utils/remove_freedom_ecm_repos.php
* Inspecting repository list...
Found invalid repository 'invalid1' with host 'ftp.freedom-ecm.org'.
Found invalid repository 'invalid2' with host 'ftp.freedom-ecm.org'.

Re-run with '--remove' argument to remove the invalid repositories.

Mode suppression (option --remove) :

# cd /var/www/dynacase-control
# php utils/remove_freedom_ecm_repos.php --remove
* Inspecting repository list...
Found invalid repository 'invalid1' with host 'ftp.freedom-ecm.org'.
Found invalid repository 'invalid2' with host 'ftp.freedom-ecm.org'.
* Deactivating repository 'invalid1' on context 'c1'.
Done.
* Deactivating repository 'invalid1' on context 'c2'.
Done.
* Deactivating repository 'invalid2' on context 'c2'.
Done.
* Deleting repository 'invalid1'.
Done.
* Deleting repository 'invalid2'.
Done.

6.6 Répertoires de fichiers de cache et de fichiers temporaires

Les répertoires de cache et de fichiers temporaires sont localisés dans le sous-répertoire var du contexte Dynacase.

Le sous-répertoire var contient les répertoires suivants :

cache/file/

cache de fichiers générés par les applications Dynacase ;

cache/image/

cache d'images redimensionnées dynamiquement par Dynacase ;

session/

fichiers de session PHP ;

tmp/

fichiers temporaires (valeur par défaut ./var/tmp du paramètre applicatif CORE CORE_TMPDIR et FREEDOM_UPLOADDIR) ;

upload/

répertoire de stockage pour la fonction d'import d'archives.

Chapitre 7 Tuning PostgreSQL

Dans le cadre de son utilisation avec Dynacase, une couche d’abstraction logicielle Dynacase sur PostgreSQL permet d’optimiser son utilisation. Les éventuels tuning de la base PostgreSQL dépendent entièrement du modèle documentaire mis en œuvre par Dynacase. Ils sont réalisés ou préconisés si nécessaire lors de la mise en œuvre de la solution par un expert Anakeen.

7.1 Configuration de PostgreSQL

La plupart des distributions livrent PostgreSQL avec une configuration basique, passe-partout, qui n'est pas forcement adaptée au volume et au nombre de transactions que peut générer Dynacase. Voici quelques éléments de configuration pour une machine type avec 2 Go à 3 Go de RAM.

7.1.1 shared_buffers

Le paramètre shared_buffers permet de spécifier la taille de la mémoire partagée allouée par Postgresql. Il est à noter que ce paramètre PostgreSQL dépend d'un paramètre du kernel qui indique la valeur maximale de mémoire partagée disponible pour les processus. Il faudra donc au préalable augmenter la valeur de ce paramètre au niveau du noyau, pour ensuite augmenter la valeur dans PostgreSQL.
Sous Linux, la taille de la mémoire partagée maximale autorisée est définie par le paramètre sysctl kernel.shmmax :

# sysctl kernel.shmmax kernel.shmmax = 33554432

On voit dans ce cas que la valeur est de 32 Mo Sur une machine dédiée à PostgreSQL avec 2 à 3 Go de RAM on alloue entre 1 et 2 Go de mémoire partagée utilisable par les process :

 # sysctl -w kernel.shmmax=2147483648 kernel.shmmax = 2147483648

Pour rendre ce paramètre persistant au redémarrage, on enregistre celui-ci dans le fichier /etc/sysctl.conf.

Une fois le shmmax configuré sur le kernel, on définit le paramètres PostgreSQL shared_buffers.

# vi /var/lib/pgsql/data/postgresql.conf
[…]
shared_buffers = 1024MB
[…]

La prise en compte de ce paramètre est effective après re-démarrage de PostgreSQL :

# /etc/rc.d/init.d/postgresql restart

Si Postgresql ne redémarre pas, vérifier que la valeur de shared_buffers est bien inférieure à la valeur de kernel.shmmax.

7.1.2 effective_cache_size

Le paramètre effective_cache_size indique à PostgreSQL la mémoire restante une fois que PostgreSQL et tous les autres process du serveur tournent en fonctionnement normal. Cet espace "libre" est utilisé par le noyau pour gérer ses buffers et son cache. Cet espace est visualisable sous Linux avec la commande free sous la forme des valeurs de buffers et cached :

# free
             total       used       free    shared    buffers     cached
Mem:       3095688    1932116    1163572         0      62524    1433776
-/+ buffers/cache:     435816    2659872
Swap:      1044208      89816     954392

Dans le cas ci-dessus, on peut donc indiquer à PostgreSQL une valeur de effective_cache_size de 1400 Mo :

# vi /var/lib/pgsql/data/postgresql.conf
[…]
effective_cache_size = 1400MB
[…]

7.1.3 work_mem

Le paramètre work_mem spécifie la quantité de mémoire que peut utiliser un process PostgreSQL pour effectuer des tris. Une valeur plus grande lui permettra de pouvoir manipuler plus de données en mémoire vive (plutôt que d'avoir recours à des fichiers temporaires qui sont plus lents).
Ce paramètre doit être calibré en fonction du nombre maximum de connexions concurrentes déclaré par le paramètre max_connections. La mémoire allouée pour ces opérations étant alors égale à max_connections * work_mem.

# vi /var/lib/pgsql/data/postgresql.conf
[…]
max_connections = 64
[…]
work_mem = 16Mb
[…]

Dans l'exemple ci-dessus, l'utilisation mémoire pourra monter à 64 * 16 Mo = 1 Go.

7.1.4 maintenance_work_mem

Le paramètre maintenance_work_mem spécifie la quantité de mémoire que peuvent utiliser les commandes/process PostgreSQL de VACUUM, création d'index et altération de table. Une valeur plus grande lui permettra de pouvoir manipuler plus de données en mémoire vive, et accélèrera le temps de traitement sur les VACUUM (freedom_clean) par exemple.

vi /var/lib/pgsql/data/postgresql.conf
[…]
maintenance_work_mem = 128Mb
[…]

7.1.5 WAL : Write Ahead Log

Le mécanisme de WAL (Write Ahead Log) est le mécanisme utilisé par Postgresql pour gérer les modifications des données de la base et assurer l'intégrité de la base de données en cas de crash du serveur.

Lorsqu'une donnée est modifiée, l'opération est d'abord enregistrée dans un fichier WAL sur le disque. Ensuite, de manière asynchrone, les opérations contenues dans les fichiers WAL sont écrites de manière définitive sur la base de données.

Suite à un crash, au redémarrage, le serveur Postgresql rejouera alors les opérations des fichiers WAL qui ne sont pas encore inscrites en base pour mettre à niveau la base de données.

7.1.5.1 wal_buffers

Le paramètre wal_buffers spécifie la taille d'un fichier de journal d'écriture "WAL" (Write-Ahead-Log).

Par défaut, la taille d'un WAL est de 64KB. Une petite valeur entraînera des écritures de petits fichiers WAL plus fréquentes, et une grande valeur entraînera des écritures de fichiers WAL de plus gros volume mais avec une fréquence moindre.

Il est admis qu'une valeur de 16MB est une bonne valeur pour un serveur de production :

wal_buffers = 16MB

7.1.6 checkpoint_segments, checkpoint_timeout et checkpoint_completion_target

Le paramètre checkpoint_segments spécifie le nombre de fichiers WAL qui sont conservés, en rotation, sur le disque.

Une grand nombre de checkpoint_segments réduit le nombre d'écritures sur la base de données, mais en cas de crash du serveur, cela fera un plus gros volume de données à rejouer lors du redémarrage du serveur pour qu'il remette sa base à niveau avec les derniers fichiers checkpoints.

Le paramètre checkpoint_timeout spécifie le temps maximal qu'un fichier WAL peut rester sur le disque avant d'être inscrit de manière définitive dans la base de données.

Le paramètre checkpoint_completion_target permet quand à lui de spécifier la périodicité d'écriture des fichiers WAL sur la base de données. Il permet de répartir les écritures des fichiers WAL au cours du temps et d'éviter d'avoir des pics d'écritures lorsque les fichiers WAL atteignent leur limite de temps au même moment.

Une estimation du nombre de fichiers WAL stockés sur le disque est donné par la formule suivante :

number of WAL files = ( 2 + checkpoint_completion_target ) * checkpoint_segments + 1

Les valeurs suivantes sont admises comme étant un bon compromis entre la réduction du nombre d'écritures sur la base et le temps de reprise en cas de crash.

checkpoint_segments = 32
checkpoint_timeout = 5min
checkpoint_completion_target = 0.9

Le volume occupé par les fichiers WAL sera alors approximativement de 1.5GB.

7.1.7 Bulk data loading

Dans le cas de la restauration d'une base de donnée, ou du chargement massif de données, ces paramètres de WAL peuvent être augmentés afin de réduire le nombre d'opérations d'écritures sur la base de donnée, moyennant une utilisation d'un plus grand volume par les fichiers WAL.

checkpoint_segments = 300
checkpoint_timeout = 3000
autovacuum = off

Attention : Ces paramètres ne doivent pas être utilisés en production, mais seulement temporairement pour la durée de l'opération de chargement/restauration des données.

7.1.8 Conclusion

Ces paramètres permettent donc de donner une plus grande liberté de mouvement à PostgreSQL comparés à ceux livrés par défaut. Les valeurs données ci-dessus sont des exemples qu'il faudra bien sûr adapter/moduler en fonction de la machine et de son utilisation dans le temps.

7.1.9 Liens utiles

Postgresql Tuning

7.1.10 Dépannage/troubleshoot

7.1.10.1 Voir les requêtes en cours d'exécution

Pour voir les requêtes en cours d'exécution, Postgresql dispose de la table pg_stat_activity :

postgres=# SELECT * FROM pg_stat_activity;
 datid  | datname  | procpid | usesysid | usename  | application_name | client_addr | client_port | backend_start                 | xact_start                    | query_start                   | waiting | current_query
--------+----------+---------+----------+----------+------------------+-------------+-------------+-------------------------------+-------------------------------+-------------------------------+---------+---------------------------------
 11874  | postgres | 40516   |    10    | postgres | psql90           |             | -1          | 2011-01-17 11:49:52.022024+01 | 2011-01-17 11:53:43.766623+01 | 2011-01-17 11:53:43.766623+01 | f       | SELECT * FROM pg_stat_activity;
 207531 | 3.0.16   | 40570   | 16391    | freedom  |                  | ::1         | 57914       | 2011-01-17 11:50:28.902947+01 |                               | 2011-01-17 11:51:30.213533+01 | f       | VACUUM FULL ANALYSE;
(2 ROWS)

Cette table présente le détail des requêtes en cours d'exécution :

current_query

La requête en cours d'exécution

procpid

le pid du process qui execute cette requête

backend_start

l'heure de reception de la requête

query_start

l'heure de début de traitement de la requête

waiting

le caractère « waiting » d'une requête si elle est bloqué ou en attente de libération d'une ressource par une autre requête.

La visualisation du champ current_query nécessite le paramètre track_activities = on (par défaut à on). Si ce paramètre n'était pas actif, vous pouvez le définir dans postgresql.conf et recharger la conf à chaud :

Modification de la configuration :

# vi /path/to/postgresql.conf
…
track_activities = on
…

rechargement de la configuration :

SELECT pg_reload_conf();
SHOW track_activities;

7.1.10.1.1 Journaliser les requêtes longues

Lorsque l'observation de longues requêtes par pg_stat_activity n'est pas possible (parce que le problème n'est pas reproductible ou observable à une heure précise de la journée par exemple), on peut indiquer à Postgresql de logger les requêtes qui mettent plus N secondes à s'exécuter. La durée est paramétrable via le paramètre log_min_duration_statement (par défaut '-1' : désactive le log). Vous pouvez soit le définir en global dans postgresql.conf, soit par base de données (via un ALTER DATABASE) :

Configuration globale commune à toutes les bases (ex. 5 minutes) :

vi /path/to/postgresql.conf
…
log_min_duration = 5min
…

rechargement de la configuration :

SELECT pg_reload_conf();

Paramétrage sur une base spécifique

ALTER DATABASE dynacase SET log_min_duration_statement = '5min';

Les logs apparaissent alors dans postgresql.log sous la forme :

2011-01-11 17:15:01 CET LOG: duration: 2.291 ms statement: SELECT * from paramv where type='G' or (type='A' and appid=1);

7.1.10.2 Connexion sécurisée (SSL)

• Configuration client : SSL Support (http://www.postgresql.org/docs/8.4/interactive/libpq-ssl.html)
• Configuration serveur : Secure TCP/IP Connections with SSL (http://www.postgresql.org/docs/8.4/interactive/ssl-tcp.html)

Utilisation de la directive 'sslmode=require' dans pg_service.conf pour forcer la connexion du client par SSL :

[dynacase]
host=pg.example.net
port=5432
user=dynacase
password=secret
dbname=dynacase
sslmode=require

7.2 Performances avec PHP

7.2.1 Impact du mode SSL

L'utilisation du SSL entraîne une surcharge lors de l'établissement d'une connection TCP sur PostgreSQL.

Exemple de surcharge pour l'initiation d'une connexion par TCP sur un serveur PostgreSQL en écoute sur l'interface locale de la machine (127.0.0.1) :

.                           .--------------------------------.
                            | Temps pg_connect sur 127.0.0.1 |
,---------------------------+--------------------------------|
| sslmode=disable           | + 0  ms                        |
| sslmode=require (default) | + 15 ms                        |
'------------------------------------------------------------'
(Mesuré avec 1 x CPU Intel Core 2 Duo CPU T8300 @ 2.40GHz)

L'utilisation du SSL entraîne aussi une surcharge de traitement pour l'envoi du résultat au client. Cette surcharge de traitement est proportionnelle au volume de données à envoyer et donc à chiffrer.

Exemple de surcharge pour le transfert des N premiers éléments d'une table conmposée d'une colonne de type integer (requête SELECT * FROM foo LIMIT <N>) :

.             .------------------------.
              | Temps requête avec SSL |
,-------------+------------------------|
| LIMIT 10    | + 0,0551 ms            |
| LIMIT 100   | + 0,0729 ms            |
| LIMIT 1000  | + 0,401  ms            |
| LIMIT 10000 | + 6,863  ms            |
`--------------------------------------'
(Mesuré avec 1 x CPU Intel Core 2 Duo CPU T8300 @ 2.40GHz)

Conclusion :

Si le réseau entre le serveur Dynacase et la base de données est « sûr », et si le niveau de sécurité souhaité le permet, il peut être avantageux en terme de performance de désactiver le support SSL.

Chapitre 8 Tuning Apache2

8.1 MaxClients (et max_connections PostgreSQL)

La principale directive du mode MPM-Prefork de Apache est la directive MaxClients qui permet de configurer le nombre maximum de clients connectés et servis simultanément.

La valeur de ce paramètre dépend donc du nombre souhaité de clients servis en concurrent, mais aussi de la capacité du serveur : trop de processus Apache concurrents risquent d'entrainer une surcharge mémoire et forcer le système à utiliser son swap ce qui dégradera les temps de traitement.

L'utilisation mémoire depend de l'application qui est exécutée et doit donc être mesurée par l'exécution d'un scénario type par exemple.

Pour Journaliser l'utilisation mémoire de vos requêtes PHP vous pouvez insérer le log de la variable %{mod_php_memory_usage}n dans le LogFormat de votre fichier access_log.

Exemple :

LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\" %{mod_php_memory_usage}n" combined

Important :

• La directive MaxClients doit être ajustée conjointement avec la directive max_connections de PostgreSQL. Dynacase effectuant généralement une connexion par requête HTTP, on doit donc avoir un max_connections PostgreSQL supérieur au MaxClients Apache sous peine de voir des requêtes mises en erreur.

Référence :

• apache prefork

8.2 KeepAlive

La directive keepAlive permet de réduire le nombre de connexions TCP initiés par les clients HTTP, et donc de réduire l'utilisation CPU de l'OS et du serveur Apache.

Le client pourra ainsi effectuer N requêtes (l'une à la suite de l'autre) sur cette même connexion TCP sans devoir faire N nouvelles connexions TCP pour chacune des requêtes.

Exemple :

KeepAlive On

Référence :

• apache keepalive

8.3 HostnameLookups et Logs

Outre le fait de servir des requêtes, le serveur Apache journalise des informations dans les fichiers access.log et error.log.

Lors de l'écriture d'entrées dans ces fichiers, le serveur Apache peut résoudre les adresses IP des clients connectés et inscrire leur nom DNS à la place de leur adresse IP.

Ces résolutions DNS prennent généralement du temps et il est donc recommandé de désactiver cette fonctionnalité :

HostnameLookups Off

Le fait que ces fichiers access.log et error.log soient stockés par défaut localement sur le serveur Web peut entrainer une surcharge sur la machine : un nombre important de requêtes entrainera un nombre important d'opérations d'écritures de messages dans ces fichiers.

Il peut donc être bénéfique de déplacer ces fichiers de logs sur des disques distinct afin de minimiser les E/S sur le disque des fichiers servis par le serveur Apache. L'écriture de ces logs peut aussi être déportée sur un serveur tiers via le protocole syslog.

Référence :

• apache hostname lookup
• apache log

Chapitre 9 Dynacase Control en mode CLI

Le mode CLI de dynacase-control permet d'administrer les contextes Dynacase en ligne de commande.

9.1 Utilisation

La commande wiff permet de manipuler et administrer les contextes Dynacase. Les opérations actuellement accessibles à travers l'UI Web, seront accessibles en ligne de commande à l'aide de cette commande wiff. Cette commande doit être lancée sous root. Pour cela, vous pouvez soit vous logger sous le compte root, soit utiliser sudo pour l'exécuter (Dans ce cas, vous pouvez également autoriser la commande wiff sans mot de passe en éditant le fichier sudoers).

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]

Le CLI utilise un verrou afin de se prémunir contre l'exécution concurrente de plusieurs opérations de modification (voir détails Opérations verrouillées ci-dessous).

9.2 Commandes

9.2.1 Lister les contextes existants

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

Syntaxe :

list context [--pretty]

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

9.2.2 Créer un nouveau contexte

control 1.5

Cette opération permet de créer un nouveau contexte.

Syntaxe :

create context <context-name> <context-root>

Exemple :

# /var/www/dynacase-control/wiff create context test /var/www/test

9.2.3 Manipuler les propriétés d'un contexte

control 1.5

Les propriétés d'un contexte sont :

url

L'URL affichée sur le contexte.

description

La description affichée sur le contexte.

9.2.3.1 Voir la liste des propriétés d'un contexte

control 1.5

Cette opération permet de voir la liste des propriétés avec leur valeur.

Syntaxe :

context <context-name> property show

Exemple :

# /var/www/dynacase-control/wiff context test property show
url = /test/admin.php
description = Contexte de test.

9.2.3.2 Récupérer la valeur d'une propriété d'un contexte

control 1.5

Cette opération permet de voir la valeur d'un propriété.

Syntaxe :

context <context-name> property get <property-name>

Exemple :

# /var/www/dynacase-control/wiff test property get url
url = /test/admin.php

9.2.3.3 Modifier les propriétés d'un contexte

control 1.5

Cette opération permet de modifier les propriétés d'un contexte.

Syntaxe :

context <context-name> property set <property-name> <property-value>

Exemple :

# /var/www/dynacase-control/wiff context test property set url http://www.example.net/test/
# /var/www/dynacase-control/wiff context test property set description "Ceci n'est pas un contexte de test."

9.2.4 Modifier les dépôts de paquets utilisés par un contexte

control 1.5

Cette opération permet de voir/modifier la liste des dépôts de paquets utilisés par un contexte.

Les dépôts de paquets utilisables par un contexte doivent être déclarés au préalable dans dynacase-control (voir Gérer la liste des dépôts de paquets de dynacase-control ci-dessous).

9.2.4.1 Voir les dépôts actifs sur un contexte

control 1.5

Syntaxe :

context <context-name> repository list

Exemple :

# /var/www/dynacase-control/wiff context test repository list
dynacase
acme

9.2.4.2 Activer un dépôt sur un contexte

control 1.5

Syntaxe :

context <context-name> repository enable <repo-name>

Exemple :

# /var/www/dynacase-control/wiff context test repository enable foo

9.2.4.3 Désactiver un dépôt sur un contexte

control 1.5

Syntaxe :

context <context-name> repository disable <repo-name>

Exemple :

# /var/www/dynacase-control/wiff context test repository disable foo

9.2.4.4 Désactiver tous les dépôts sur un contexte

control 1.5

Syntaxe :

context <context-name> repository disable --all

Exemple :

# /var/www/dynacase-control/wiff context test repository disable --all

9.2.5 Supprimer un contexte

control 1.5

Syntaxe :

delete context [options] <context-name>

Les options disponibles sont :

• --nopre permet de ne pas exécuter les processus de 'pre-delete' déclarés par les paquets.
• --force permet de ne pas tenir compte des statuts d'échec des processus de 'pre-delete'.

Exemple :

# /var/www/dynacase-control/wiff delete context --force test

9.2.6 Manipuler les modules du contexte

9.2.6.1 Lister les modules installés

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

Syntaxe :

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

Exemple :

# var/www/dynacase-control/wiff context test module list installed
dynacase-fckeditor (2.6.3-7)
dynacase-webdesk (1.2.2-1)
dynacase-extjs (3.1.1-8)
dynacase-core (3.2.5-1)
dynacase-extui (0.6.4-1)
dynacase-workspace (0.6.1-1)
dynacase-ecm (0.3.0-1)

9.2.6.2 Lister les modules disponibles

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

Syntaxe :

context <context-name> module list available [--pretty]` 

Exemple :

# /var/www/dynacase-control/wiff context test module list available
dynacase-extjs (3.1.1-8)
dynacase-core (3.2.5-1)
dynacase-fckeditor (2.6.3-7)
dynacase-freeevent (2.6.0-0)
dynacase-webdesk (1.2.2-1)
[...]
dynacase-apisamples (0.1.3-1)
dynacase-familysamples (0.1.0-2)
dynacase-cas (0.0.2-1)
dynacase-theme (0.0.1-4)
dynacase-url (0.0.0-3)

9.2.6.3 Lister les modules avec mise à jour proposée

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.

Syntaxe :

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

Exemple :

# /var/www/dynacase-control/wiff context test module list upgrade
dynacase-core (3.2.6-1)

9.2.6.4 Installer un module

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.

Syntaxe :

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

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 dynacase-core
Will (i)nstall, (u)pgrade, or (r)eplace the following modules:
- dynacase-core-3.2.5-1.20130221.090413 (i)
- dynacase-jquery-installer-1.7.2-1.20120730.134605 (i)
- dynacase-jquery-ui-installer-1.8.21-2.20120817.154930 (i)
- dynacase-json2-1.0.0-0.20130214.114647 (i)
- dynacase-datajs-3.2.5-0.20130220.144720 (i)
- dynacase-jquery-dataTables-installer-1.9.1-0.20120622.121419 (i)
- dynacase-ckeditor-installer-4.0.1-0.20130213.174659 (i)
Proceed with installation ? [Y/n]
 
Processing module 'dynacase-core' (3.2.5-1.20130221.090413) for install.
Downloading module 'dynacase-core-3.2.5-1.20130221.090413'... [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.
[...]
Done.

Notes :

• control 1.5 À partir de la version 1.5 de dynacase-control, le format XML des modules est vérifié et un avertissement est affiché si le format n'est pas conforme. Voir Format des modules webinst et Changements par rapport à l'ancien format pour les changements à apporter à vos fichier info.xml de description de module.

9.2.6.5 Upgrader un module

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.

Syntaxe :

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

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-install' 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.
[...]
Done.

Notes :

• control 1.5 À partir de la version 1.5 de dynacase-control, le format XML des modules est vérifié et un avertissement est affiché si le format n'est pas conforme. Voir Format des modules webinst et Changements par rapport à l'ancien format pour les changements à apporter à vos fichier info.xml de description de module.

9.2.7 Archives de contextes

9.2.7.1 Archiver un contexte

control 1.5

Syntaxe :

context <context-name> archive <archive-name> [--without-vault] [--description=<description>]

Les options disponibles sont :

• --without-vault permet de ne pas inclure l'archivage du vault dans l'archive du contexte.
• --description=<description> permet de saisir le champ de description de l'archive.

Exemple :

# /var/www/dynacase-control/wiff context dev archive test
test-1f84e69f127a5fb3f2d920c35beb12f2f2a6c4d5

Note :

• L'archivage d'un contexte peut nécessiter jusqu'à deux fois la taille des éléments à archiver. Une estimation de l'espace disque minimal nécessaire peut être obtenue avec la formule suivante :

  s1 := taille( dump de la base de données )
  s2 := taille( contenu du répertoire racine du contexte )
  s3 := taille( contenu des vaults )
   
  espace_libre_necessaire := ( s1 + s2 + s3 ) * 2

9.2.7.2 Lister les archives

control 1.5

Syntaxe :

list archive

Exemple :

# /var/www/dynacase-control/wiff list archive
test-1f84e69f127a5fb3f2d920c35beb12f2f2a6c4d5
pre-prod-838ac13e91d439d5c3a8bed86ea8adfee800c949

9.2.7.3 Voir les informations d'une archive

control 1.5

Syntaxe :

archive <archive-id> info

Exemple :

# /var/www/dynacase-control/wiff archive test-1f84e69f127a5fb3f2d920c35beb12f2f2a6c4d5 info
Archive 'test-1f84e69f127a5fb3f2d920c35beb12f2f2a6c4d5'
-------------------------------------------------------
 
id          = test-1f84e69f127a5fb3f2d920c35beb12f2f2a6c4d5
date        = 2014-12-15 09:03:04
name        = test
size        = 42.121 Mo
vault       = Yes
description = dev@2014-12-15T09:03:04
 
Installed modules:
- dynacase-core (3.2.17-1)
[...]

9.2.7.4 Restaurer l'archive d'un contexte

control 1.5

Syntaxe :

archive <archive-id> restore <context-name> <context-root> <pg-service-name> <vault-root>
                               [--remove-profiles --user-login=<login> --user-password=<password>]
                               [--clean-tmp-directory=<'yes'|'no'>]

Les options disponibles sont :

• --remove-profiles permet de donner tous les privilèges sur tous les documents à un nouvel utilisateur lors de la restauration du contexte (à utiliser en conjonction avec --user-login et --user-password).
• --user-login et --user-password permet de spécifier le login et le mot de passe du nouvel utilisateur auquel sont donnés tous les privilèges sur tous les documents.
• --clean-tmp-directory=<'yes'|'no'> permet de supprimer si les fichiers temporaires de la restauration sont effacés (yes ou comportement par défaut) ou s'il sont conservés (no).

Exemple :

# /var/www/dynacase-control/wiff archive test-1f84e69f127a5fb3f2d920c35beb12f2f2a6c4d5 restore test2 /var/www/test2 db-test-2 /var/www/test2/vaultfs
Context 'test2' successfully created from archive 'test-1f84e69f127a5fb3f2d920c35beb12f2f2a6c4d5'.

9.2.8 Supprimer une archive de contexte

Syntaxe :

delete <archive-id>

Exemple :

# /var/www/dynacase-control/wiff delete archive test-1f84e69f127a5fb3f2d920c35beb12f2f2a6c4d5

9.2.9 Manipuler les paramètres des modules

9.2.9.1 Afficher la liste des paramètres d'un module

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

Syntaxe :

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

Exemple :

# /var/www/dynacase-control/wiff context test param show
dynacase-core:client_name = Test
dynacase-core:core_db = test
dynacase-core:authtype = html
dynacase-core:lcdate = iso : standard format 8601
dynacase-core:core_tmpdir = ./var/tmp
dynacase-core:core_admin_passwd =
dynacase-core:mod_deflate = yes
foo:bar = baz
foo:bir = biz
 
# /var/www/dynacase-control/wiff context test param show foo
foo:bar = baz
foo:bir = biz

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

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

Syntaxe :

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

Exemple :

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

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

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

Syntaxe :

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

Exemple :

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

9.2.10 Gérer la liste des dépôts de paquets de dynacase-control

control 1.5

Cette opération permet de gérer la liste de dépôts de paquets connus par dynacase-control.

9.2.10.1 Afficher la liste des dépôts de paquets

control 1.5

Syntaxe :

repository list

Exemple :

# /var/www/dynacase-control/wiff repository list
dynacase    http://dynacase.anakeen.com/3.2/webinst/
local    http://localhost/repo/

9.2.10.2 Ajouter un dépôt de paquets

control 1.5

Syntaxe :

repository add <repo-name> <repo-url> [<repo-username> [<repo-password>]]

Exemple :

# /var/www/dynacase-control/wiff repository add foo "http://example.net/foo/"
# /var/www/dynacase-control/wiff repository add acme "http://example.net/acme/" "john.doe" "s3cr3t"

Notes :

• Le nom du dépôt ne peut contenir que des caractères alpha-numériques non accentués et le symbole _ (underscore). REGEX pour la validation du nom du dépôt : /^[a-zA-Z0-9_]+$/.

9.2.10.3 Supprimer un dépôt de paquets

control 1.5

Syntaxe :

repository delete <repo-name>

Exemple :

# /var/www/dynacase-control/wiff repository delete foo

Notes :

• La suppression d'un dépôt de dynacase-control ne désactive pas son utilisation par un contexte. Voir Désactiver un dépôt sur un contexte.

9.2.10.4 Supprimer tous les dépôts de paquets

control 1.5

Syntaxe :

repository delete --all

Exemple :

# /var/www/dynacase-control/wiff repository delete --all

Notes :

• La suppression d'un dépôt de dynacase-control ne désactive pas son utilisation par un contexte. Voir Désactiver un dépôt sur un contexte.

9.2.11 Gérer les paramètres de dynacase-control

control 1.5

Cette opération permet de voir/modifier les paramètres de dynacase-control.

9.2.11.1 Liste des paramètres de dynacase-control

wiff-update-host

Base de l'URL de recherche des mises à jour de dynacase-control.

wiff-update-path

Chemin pour la recherche des mises à jour de dynacase-control.

wiff-update-file

Nom du fichier de la dernière version de dynacase-control.

wiff-update-login (optionnel)

Nom d'utilisateur pour la recherche des mises à jour (si authentification HTTP Basic requise).

wiff-update-password (optionnel)

Mot de passe pour la recherche des mises à jour (si authentification HTTP Basic requise).

use-proxy (optionnel)

Active l'utilisation d'un proxy HTTP pour les requêtes HTTP/FTP émises par dynacase-control.

Valeurs : yes ou no.

proxy-host (optionnel)

Nom d'hôte du proxy HTTP à utiliser si use-proxy est activé.

Ex. proxy.example.net

proxy-port (optionnel)

Port du proxy HTTP à utiliser si use-proxy est activé.

Ex. : 3128

proxy-username (optionnel)

Nom d'utilisateur pour la connexion au proxy HTTP proxy-host.

proxy-password (optionnel)

Mot de passe pour la connexion au proxy HTTP proxy-host.

auto-configuration-sender-interval

Intervalle (en nombre de jours) pour la soumission des information des contextes avec send_configuration lorsque ceux-ci sont enregistrés avec le compte EEC.

Valeurs : entier de 1 à 31.

local-log control 1.5

Active la journalisation des messages d'erreurs dans le fichier log/wiff.log.

Valeurs : yes ou no.

syslog-facility control 1.5

Facility syslog utilisée par les messages d'erreurs émis par dynacase-control.

Voir Paramétrage syslog.

9.2.11.2 Voir les paramètres de dynacase-control

control 1.5

Syntaxe :

param show

Exemple :

# /var/www/dynacase-control/wiff param show
wiff-update-host = http://dynacase.anakeen.com/ (visible)
wiff-update-path = /control/ (visible)
wiff-update-file = dynacase-control-current.tar.gz (visible)
wiff-update-login =  (visible)
wiff-update-password =  (visible)
use-proxy = no (visible)
proxy-host =  (visible)
proxy-port =  (visible)
proxy-username =  (visible)
proxy-password =  (visible)
auto-configuration-sender-interval = 30 (visible)
local-log = yes (hidden)
syslog-facility = LOG_USER (hidden)

9.2.11.3 Récupérer la valeur d'un paramètre de dynacase-control

control 1.5

Syntaxe :

param get <param-name>

Exemple :

# /var/www/dynacase-control/wiff param get local-log
local-log = yes

9.2.11.4 Modifier la valeur d'un paramètre de dynacase-control

control 1.5

Syntaxe :

param set <param-name> <param-value> ['hidden']

Exemple :

# /var/www/dynacase-control/wiff param set local-log no

Notes :

• La visibilité hidden permet de masquer la présentation du paramètre dans l'interface Web.

9.2.12 Enregistrer dynacase-control avec son compte EEC

control 1.5

Cette opération permet d'enregistrer dynacase-control avec son compte EEC.

9.2.12.1 Voir le status d'enregistrement

Syntaxe :

register

Exemple :

# /var/www/dynacase-control/wiff register
Not registered.

9.2.12.2 Enregistrer dynacase-control avec son compte EEC

control 1.5

Syntaxe :

register <eec-username> <eec-password>

Exemple :

# /var/www/dynacase-control/wiff register "john.doe" "s3cr3t"
Successfully registered dynacase-control.
 
# /var/www/dynacase-control/wiff register
Registered with EEC username 'john.doe'.

9.2.13 Enregistrer un contexte avec son compte EEC

control 1.5

Cette opération permet d'enregistrer un contexte avec son compte EEC.

Syntaxe :

context <context-name> register

Exemple :

# /var/www/dynacase-control/wiff context test register

Notes :

• L'enregistrement d'un contexte avec son compte EEC nécessite au préalable que dynacase-control ait été enregistré avec un compte EEC. Voir Enregistrer dynacase-control avec son compte EEC.

9.2.14 Envoi de la configuration au compte EEC

Cette opération permet d'envoyer la configuration de tous les contextes enregistrés avec le compte EEC.

Syntaxe :

send_configuration

Exemple :

# /var/www/dynacase-control/wiff send_configuration

9.2.15 Passer un contexte en mode maintenance

Le mode maintenance d'un contexte permet de bloquer l'accès des utilisateurs au contexte, et de désactiver l'exécution des crons, afin d'effectuer des opérations pour lesquelles il est nécessaire que les données ne soient pas modifiés.

dynacase-control 1.5.2

Cette opération permet d'exécuter le script historique 'wstop' sur un contexte. Dans ce mode, seul l'utilisateur master default a accès au contexte.

Syntaxe :

wstop <context-name>

Exemple :

# /var/www/dynacase-control/wiff wstop test

dynacase-control 1.5.3

Cette opération est dépréciée et doit être remplacée par le lancement de la commande ./wstop dans le contexte à l'aide de l'opération WIFF exec.

Exemple :

# /var/www/dynacase-control/wiff context test exec ./wstop

Voir :

• ./wstop

9.2.16 Sortir un contexte du mode maintenance

La sortie du mode maintenance d'un contexte permet de rétablir l'accès des utilisateurs, et l'exécution des crons, lorsque l'opération de maintenance est terminée.

dynacase-control 1.5.2

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

Syntaxe :

wstart <context-name>

Exemple :

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

dynacase-control 1.5.3

Cette opération est dépréciée et doit être remplacée par le lancement de la commande ./wstart -m dans le contexte à l'aide de l'opération WIFF exec.

Exemple :

# /var/www/dynacase-control/wiff context test exec ./wstart -m

Voir :

• ./wstart

9.2.17 Réinitialiser les catalogues de langue

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

Syntaxe :

whattext <context-name>

Exemple :

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

9.2.18 Ouvrir un shell sous l'uid Apache

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.

Syntaxe :

context <context-name> shell

context <context-name> exec  <command> [<command-options>]

Par défaut, si aucune commande n'est spécifiée, 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 Dynacase).
• pgservice_core : le service Postgresql de la base 'core' (pour compatibilité scripts post/migr de Dynacase).
• pgservice_freedom : le service Postgresql de la base 'freedom' (pour compatibilité scripts post/migr de Dynacase).
• freedom_context : vaut toujours ”default” (pour compatibilité scripts post/migr de Dynacase).

Exemple :

# /var/www/dynacase-control/wiff context test shell /bin/bash
$ id
uid=70(_www) gid=70(_www) egid=20(staff) groups=70(_www)
$ pwd
/var/www/test
$ ./FOO/FOO_post U
[...]
# /var/www/dynacase-control/wiff context test exec /usr/bin/tar -zcf /tmp/archive.tar.gz .

9.3 Opérations verrouillées

control 1.5

Les opérations suivantes sont soumises à l'obtention du verrou exclusif :

• Créer un nouveau contexte
• Installer un module
• Upgrader un module
• Activer un dépôt sur un contexte
• Désactiver un dépôt sur un contexte
• Désactiver tous les dépôts sur un contexte
• Positionner la valeur d'un paramètre d'un module
• Modifier la valeur d'un paramètre de dynacase-control
• Ajouter un dépôt de paquets
• Supprimer un dépôt de paquets
• Supprimer tous les dépôts de paquets
• Voir le status d'enregistrement
• Enregistrer dynacase-control avec son compte EEC
• Enregistrer un contexte avec son compte EEC
• Restaurer l'archive d'un contexte
• Archiver un contexte
• Supprimer une archive de contexte

Le verrou est implémenté avec un appel système flock sur le fichier conf/contexts.xml.lock.

Si le CLI ne peut obtenir un verrou exclusif, alors il se termine avec un exit code 100 et affiche le message Error locking Dynacase-Control: Already locked by process with pid 'xxx' si le verrou est pris par un autre CLI, ou Error locking Dynacase-Control: xxx pour une erreur générale (e.g. problème dans l'accès au fichier conf/contexts.xml.lock).

Chapitre 10 FreeDAV/WebDAV

10.1 Présentation de l'application DAV

Le protocole WebDAV permet aux utilisateurs d'éditer et de sauver les fichiers inclus dans les documents directement depuis leur traitement de texte, tableurs et autres logiciels d'édition de fichiers.

L'application DAV de Dynacase gère deux serveurs WebDAV :

• un serveur authentifié par login et mot de passe, pour une utilisation classique au travers de client WebDAV tel que l'explorateur de fichier Microsoft Windows ;
• un serveur authentifié par identifiant de sessions pour être utilisé à travers l'interface Web d'échange de fichiers.

Lors de la modification de fichiers par l'interface Web, l'éditeur de fichier utilise le serveur WebDAV authentifié par numéro de session. L'adresse de ce serveur WebDAV doit être précisé dans le paramètre applicatif FREEDAV_SERVEUR.

L'adresse du deuxième serveur doit être renseigné dans le paramètre WEBDAV_SERVEUR (accessible depuis le menu administration/paramètres de configuration/paramètres applicatif/dav).

Ces deux serveurs doivent avoir deux noms distincts du nom de la machine pour l'accès à l'interface web. Ces deux noms désignent la même machine (alias DNS) que le serveur WEB. Le serveur Web Apache doit être configuré pour avoir deux hôtes virtuels (Apache VirtualHost) correspondant aux deux serveurs DAV.

10.2 Configuration des postes client éditer et sauver en ligne

10.2.1 Windows

Le navigateur Web ne peut pas nativement exécuter un autre programme. Pour autoriser votre navigateur à ouvrir les éditeurs vous devez installer deux fichiers sur votre poste client opendav.reg et opendav.vbs :

• https://eec.anakeen.com/public/dav/windows/opendav.reg
• https://eec.anakeen.com/public/dav/windows/opendav.vbs

Pour enregistrer le protocole pour le navigateur, il faut double-cliquer sur l'icône du fichier opendav.reg que vous avez téléchargé. Ensuite il faut enregistrer le fichier opendav.vbs dans le répertoire C:\WINDOWS\.

Après cette manipulation à partir de votre navigateur Internet Explorer ou Firefox, vous pouvez éditer et enregistrer les fichiers comme s'ils étaient sur votre disque dur.

Lorsque vous cliquez sur le lien Ouvrir dans un éditeur, une interface vous demande de choisir le programme capable de lire le fichier. Pour enregistrer le fichier sur le serveur, une fois les modifications effectuées, il suffit d'utiliser le menu enregistrer de l'éditeur comme d'habitude

Notes :

• Une mise à jour du client WebDAV/WebFolders de Windows est disponible, et corrige apparemment plusieurs problèmes comme la gestion des caractères accentués : http://support.microsoft.com/kb/907306
• Si votre accès Internet se fait via un proxy, il peut être nécessaire de modifier la configuration de votre poste.

10.2.2 Linux

Dans Firefox, entrez l'URL : about:config

Ajouter les options suivantes :

• [bouton droit > Nouvelle > Valeur booléenne]
• nom : network.protocol-handler.external.asdav
• valeur : true
• [bouton droit > Nouvelle > Chaîne de caractère]
• nom : network.protocol-handler.app.asdav
• valeur : dynacase-opendav.sh

Pour Firefox > 3.5, il faut aussi lancer deux commande à l'aide de gconftool-2 :

gconftool-2 -s /desktop/gnome/url-handlers/asdav/command '/path/to/app %s' --type String
gconftool-2 -s /desktop/gnome/url-handlers/asdav/enabled --type Boolean true

Créer le fichier de commande dynacase-opendav.sh suivant dans un répertoire accessible par le PATH système (/usr/local/bin/dynacase-opendav.sh par ex.) :

#!/bin/bash
np=$(echo "$1" | sed "s/asdav:/http:/")
ooffice "$np"

Rendre le script exécutable :

chmod +x /usr/local/bin/dynacase-opendav.sh

Il reçoit en argument l'URL du fichier à éditer. Cette URL est une ressource asdav: qui doit être transformée en http: et être fournie à l'exécutable Open Office.

Si la configuration n'est pas correcte, vous allez rencontrer ce message :

Si tout fonctionne correctement, vous allez avoir cette fenêtre :

10.2.3 Mac OS X

Télécharger et installer l'application Asdav.app :

• https://eec.anakeen.com/public/dav/macosx/Dynacase%20Asdav.dmg

L'application Asdav.app permet d'ouvrir les URLs asdav: de Dynacase avec OpenOffice, et donc d'éditer en ligne tous les types de fichiers supportés par celui-ci.

Asdav.app utilisera en premier OpenOffice.org.app, et si celui-ci n'est pas disponible il utilisera NeoOffice.org.app.

Note pour les utilisateurs sous Mac OS X Tiger (10.4) :

OpenOffice.org.app 3.0.0 comporte un petit bug qui le rend inutilisable lorsqu'il est lancé par Asdav.app (c.f. http://www.openoffice.org/issues/show_bug.cgi?id=93731).

Pour contourner ce problème, il faut éditer le fichier /Applications/OpenOffice.org.app/Contents/Info.plist et changer la valeur de la clef CFBundleExecutable par soffice.bin :

<key>CFBundleExecutable</key>
<string>soffice.bin</string>
[...]

Note : ce problème doit être à présent résolu à partir de OpenOffice.org 3.0.1

10.3 Configuration serveur web apache

L'utilisation de la fonction DAV nécessite la création de deux configurations Apache à base de VirtualHosts. Comme cette conf n'est pas accessible et réalisable par dynacase-control, vous devrez insérer les configurations données ci-dessous dans la configuration de votre serveur Apache.

10.3.1 Pré-requis

Ce module nécessite en pré-requis l'activation du module rewrite :

# a2enmod rewrite
# /etc/init.d/apache2 restart

10.3.2 Base de données webdav

L'utilisation du protocole dav utilise un schéma dav dédié dans la base données générale.

Les tables dav.locks, dav.properties et dav.sessions sont automatiquement crées lors de l'installation de dynacase-core.

10.3.3 VirtualHosts Apache pour l'accès aux fonctions WebDAV

Pour utiliser les fonctions d'édition et de montage WebDAV, vous devez mettre en place deux VirtualHosts Apache.

Pour cela, il vous faut déclarer deux noms DNS additionnels qui pointeront vers votre serveur Dynacase.

Exemple :

Soit un contexte dynacase installé dans le répertoire /var/www/ged, et accessible par l'enregistrement DNS ged.example.net.

Vous pouvez créer deux enregistrements DNS ged-freedav.example.net et ged-webdav.example.net qui pointeront vers ged.example.net.

ged-freedav IN CNAME ged.example.net.
ged-webdav  IN CNAME ged.example.net.

Dans ce cas, les configurations associées seront :

• Configuration pour l'accès FreeDAV (édition en ligne) :

Fichier de configuration /etc/apache2/sites-available/default-freedav

<VirtualHost *:80>
    ServerName ged-freedav.example.net
 
    DocumentRoot /var/www/ged/freedav
 
    <Directory /var/www/ged/freedav/>
            Order allow,deny
            Allow from All
 
            DirectoryIndex index.php
 
            Options FollowSymLinks
            AllowOverride All
    </Directory>
 
    ErrorLog /var/log/apache2/freedav.error.log
</VirtualHost>

Activer la configuration

# a2ensite ged-freedav
# /etc/init.d/apache2 restart

• Configuration pour l'accès WebDAV (montage comme système de fichier) :

Fichier de configuration /etc/apache2/sites-available/ged-webdav

<VirtualHost *:80>
    ServerName ged-webdav.example.net
 
    DocumentRoot /var/www/ged/webdav
 
    <Directory /var/www/ged/webdav/>
            Order allow,deny
            Allow from All
 
            DirectoryIndex index.php
 
            Options FollowSymLinks
            AllowOverride All
    </Directory>
 
    ErrorLog /var/log/apache2/webdav.error.log
</VirtualHost>

Activer la configuration

# a2ensite ged-webdav
# /etc/init.d/apache2 restart

Remarque : Il est possible de vérifier avec votre navigateur que les deux VirtualHost fonctionnent correctement :

• http://ged-freedav.example.net : Doit afficher une page blanche ;
• http://ged-webdav.example.net : Doit demander un mot de passe et afficher “WebDAV Server: HTML view is not implemented yet”.

10.4 Paramétrage de l'application dav

L'application dav comporte quatre paramètres accessibles via :

• menu “Administration”
• onglet “Paramètres applicatifs”
• section “Dav”

FREEDAV_SERVEUR

adresse du serveur webdav pour freedav. Alias de nom de la machine serveur. Le virtual host associé ne doit pas être authentifié.

WEBDAV_SERVEUR

adresse du serveur webdav pour le serveur authentifié. Alias de nom de la machine serveur. Le virtual host associé doit être authentifié.

WEBDAV_DB

3.2 R15 coordonnées d'accès à la base de données webdav. Doit être égale aux coordonnées de la base principale - automatiquement renseignée lors de l'installation.

WEBDAV_ROOTID

Identifiant du dossier racine pour l'accès authentifié. Identifiant du document dossier pour la racine du webdav authentifié. Lors d'un usage combiné avec WORKSPACE, la référence désigne un document recherche simple qui recherche l'ensemble des espaces de travail.

WEBDAV_FOLDERMAXITEM

Nombre maximum d'éléments (dossier/fichier) visibles dans un dossier. Cette limite permet d'éviter d'afficher trop d'éléments pouvant provoquer un ralentissement du client.

10.5 Test de débogage du dav

En cas de problème dans la mise en place de l'application dav, il est possible d'effectuer différents tests pour identifier la source du problème.

10.5.1 Test avec cadaver

Le client WebDAV cadavere n ligne de commande disponible sous Linux permet de vérifier que la connexion au serveur webdav et au serveur freedav fonctionne correctement :

$ cadaver ged-freedav
dav:/>

$ cadaver ged-webdav
Authentication required for  on server `ged-webdav':
Username: admin
Password: ******
dav:/> ls
Listing collection `/': succeeded.
Coll:   import                                 0  sep 17 16:25
Coll:   la poubelle                            0  sep 17 16:25
Coll:   les cycles                             0  sep 17 16:25
Coll:   les familles                           0  sep 17 16:25
Coll:   les maisons                            0  sep 17 16:25
Coll:   les profils                            0  sep 17 16:25
dav:/>

En cas de problèmes, regarder les éventuels messages d'erreur le error_log PHP ou Apache.

10.6 Troubleshoot de l'application dav

10.6.1 Delocker un document

Situation : Le document a été chargé en édition avec OpenOffice.org, et ce dernier s'est terminé anormalement en laissant le document locké au niveau WebDAV.

Solution : Identifier l'URL du document (ex. asdav:/ /freedav.example.net/freedav/vid-12765-4870-3a0404dfe29f7c88bb58ac8a6943559d/Foo.odt), et supprimer le lock du document dans la table locks :

# PGSERVICE=dynacase psql \
-c "DELETE FROM dav.locks WHERE path = '/freedav/vid-12765-4870-3a0404dfe29f7c88bb58ac8a6943559d/Foo.odt'"

10.6.2 Lenteur d'ouverture des fichiers

Il arrive sur certains postes en Windows XP d'avoir des lenteurs d'accès aux documents : les temps d'accès constatés sont d'environ 30 secondes.

Ces problèmes sont inhérents à Windows, il existe 2 solutions possibles pour pallier à ces lenteurs :

10.6.2.1 1. Solution pour intranet (modification du serveur dynacase)

L'installation du service Samba (sur le serveur Dynacase) semble réduire dans certains cas le temps d'attente du poste Windows pour l'accès aux ressources WebDAV.

10.6.2.2 2. Solution pour tous les cas (modification de chaque poste client)

Dans certains cas, le changement d'ordre des "Fournisseurs de réseau" peut réduire le temps d'attente du poste Windows pour l'accès aux ressources WebDAV.

Pour cela, allez dans le panneau de configuration puis dans Connexions réseau / Avancé / Paramètres avancés :

Dans l'onglet “Ordre des fournisseurs”, vous placez “Web Client Network” en tête de liste :

Explication : lorsque vous cherchez à accéder à un serveur dav, le fournisseur réseau du dav devient prioritaire sur les autres services réseau, ce qui évite les problématiques de timeouts.

Par contre cela peut potentiellement engendrer d'autres lenteurs pour accéder à d'autres ressources réseau (serveur de fichier, active directory, …).

Cette solution est à appliquer au cas par cas.