Installation et configuration du système
sgdebrowser


Table des matières

Introduction

Le système sgdebrowser distribué avec le SGDE comprend un ensemble de composantes permettant :
Les principaux composants du système  sgdebrowser sont :
Le sgdebrowser voit le SGDE comme un catalogue de jeux de données, et ne donne pas directement accès aux données elles-mêmes (ce besoin est comblé par les services web de type weds pouvant être interfacés au SGDE). Les requêtes pouvant être effectuées sont en outre relativement simples. L'interface d'utilisation ne répond guère finalement aux normes contemporaines. Ces limitations reflètent l'âge de ce sous-système, développé à la fin des années 1990.

Le sgdebrowser demeure malgré tout un système utile. Il permet tout d'abord de vérifier facilement et rapidement le bon fonctionnement de la base de données. Surtout, malgré leur simplicité relative, les requêtes qu'il permet d'exécuter couvrent un éventail représentatif des besoins réels qu'un utilisateur peut avoir face un catalogue de donnés scientifiques. Ceci explique que le système soit toujours aujourd'hui en fonction à travers le portail de l'OGSL

Ce document explique comment faire l'installation et la configuration des composantes du SGDE formant le système sgdebrowser. On aura avantage à consulter en parallèle le document sgdebrowser - démonstration . Ce dernier explique la mise en place d'un catalogue de données test, et montre comment interroger ce catalogue  et ainsi vérifier la bonne installation du sytème.

Prérequis

Ce document décrit l'installation du sgdebrowser prioritairement en fonction d'une plateforme linux. La distribution linux utilisée pour ces explications est de type RedHat (RHEL, Fedora, Centos, Mandriva par ex.). Quelques ajustements pourraient devoir être apportés pour l'installation sous d'autres distributions, par exemple au niveau du lancement automatique des composantes sasd et sesd en tant que services système.

La procédure peut être facilement étendue à une plateforme windows. Des indications marquées "Notes windows" indiquent les ajustements nécessaires. La section Installation sous windows est spécifiquement consacrée à ce sujet.

Installation des fichiers

Télécharger la dernière version du paquetage sgdebrowser-version.tar.gz à partir du site du projet edms-sgde. Le nom du fichier sera désigné par $KITNAME, le répertoire où se fait le téléchargement par $KITDIR, et la version par $KITVERSION.

Déterminer :

Faire l'installation et la protection des fichiers en exécutant en tant que root .

% su -
# Variables environnementales servant à paramétriser l'installation.
KITNAME=nom du kit téléchargé (ex: sgdebrowser-lit-1.0a.tar.gz)
KITDIR=répertoire où le kit a été téléchargé
KITVERSION=version téléchargée (ex: 1.0)
SERVER_IN_DIR=répertoire AU-DESSUS du répertoire d'installation, ex: /opt
export SGDESRVUSER=usager unix au nom duquel les services fonctionneront (ex: sgdesrv)
export SGDESRVGROUP=groupe unix (ex: sgdesrv)
# Se placer AU-DESSUS du répertoire d'installation que l'on va créer.
cd $SERVER_IN_DIR
# Déballer le paquetage.
tar xfz $KITDIR/$KITNAME
# Le répertoire 'sgde-$KITVERSION' sera créé. Le désigner par $SERVER_ROOT.
export SERVER_ROOT=$SERVER_IN_DIR/sgde-$KITVERSION
# Protéger les fichiers
chown -R $SGDESRVUSER:$SGDESRVGROUP $SERVER_ROOT
chmod -R o= $SERVER_ROOT  # Aucun accès aux usagers autres

Si on le désire, on peut assigner un nom générique  au répertoire d'installation (par ex.: sgde), soit en renommant le répertoire sgde-version , soit au moyen d'un lien symbolique. Un lien symbolique a l'avantage de préserver la référence à la version couramment installée.

# cd $SERVER_IN_DIR
# ln -s sgde-$KITVERSION sgde   (ou bien: # mv sgde-$KITVERSION sgde)
# export SERVER_ROOT=$SERVER_IN_DIR/sgde

Notes windows.

Décompresser le kit d'installation avec l'utilitaire winzip sous le disque et le répertoire choisis comme valeur de $SERVER_ROOT. Tels que livrés dans le kit d'installation, les fichiers de configuration des services windows sont paramétrisés par défaut en supposant C:/opt/sgde  comme valeur de $SERVER_ROOT. A l'exception de quelques endroits clairement indiqués, le délimiteur "/" utilisé sous unix dans les noms de fichiers peut être utilisé au lieu du "\" windows.

Paramétrisation du fichier de configuration config.xml

Les services sesd et sasd du système sgdebrowser sont configurés au moyen du fichier au format XML $SERVER_ROOT/config.xml. Un grand nombre de paramètres peuvent être modifiés dans ce fichier. On devra minimalement apporter des modifications aux endroits marqués par les chaînes CHANGE et CHECK. En outre, les balises ayant rapport au formattage des courriels envoyés aux utilisateurs du sgdebrowser auront sûrement à être
ajustées en fonction des conventions locales.

On consultera les commentaires apparaissant dans le fichier pour plus d'information sur la signification de chaque balise.

La notation <xyz> indique de modifier le contenu encadré par <xyz>...</xyz>. Similairement,  la notation <xyz><abcd> fait référence au contenu <abcd> ... </abcd> inscrit dans <xyz> ... </xyz> .

Chemins d'accès aux fichiers

Certaines balises du fichier de configuration servent à définir des noms de fichiers ou de répertoires. Le nom peut alors être spécifé au moyen d'un chemin d'accès absolu (ex.: <sesd><usersFile>/opt/sgde/sesd/users></usersFile> ... </sesd>), ou relatif (ex.: <sesd><usersFile>sesd/users></usersFile> ... </sesd>). Un chemin d'accès relatif est interprété comme ayant sa racine dans le répertoire parent du fichier de configuration. A moins que l'on ait modifié les fichiers de démarrage, le fichier de configuration est localisé directement sous $SERVER_ROOT. En conséquence, les chemins d'accès relatifs sont normalement compris comme faisant référence au répertoire $SERVER_ROOT.

Note windows.

On s'évitera des difficultés avec la notation du disque dans les chemins d'accès (ex.: C:) si on utilise toujours des chemins relatifs au répertoire $SERVER_ROOT. Il est recommandé de toujours utiliser le "/" dans les répertoires relatifs, plutôt que le "\". En suivant ces recommendations, les exemples fournis s'appliqueront intégralement.

Connexion à la BD

Balise concernée : <database>

Définir :
Par ex. si :
on indiquera :

<database>
    <jdbc>
        <driver>org.postgresql.Driver</driver>
        <url>jdbc:postgresql://bozo:5432/mabd</url>
    </jdbc>
    <user>proprio</user>
    <password>salut</password>
 </database>

IMPORTANT. On devra s'assurer que le service de base de données PostgreSQL autorise les connexions en provenance de la machine hébergeant le service sesd. Cela se fait au moyen d'une directive du fichier pg_hba.conf (situé par ex. sous /var/lib/pgsql/data sur la machine hébergeant le service PostgreSQL, dans le cas d'un système linux).

Service sesd

Balise concernée : <sesd>

Vérifier :
Par ex., si :
on indiquera :

<sesd>
    <port>40000</port>
    <usersFile>sesd/users</usersFile>
    <log>
        <file>logs/sesd-%Y-%M.log</file>
        <SQL>false</SQL>
        <exec>true</exec>
        <read>false</read>
    </log>
    <mde>25</mde>
</sesd>


Service sasd

Balise concernée : <sasd>

Vérifier :
Par ex., si :
on indiquera :

<sasd>
    <port>40001</port>
    <host>localhost</host>
    <usersFile>sasd/users</usersFile>
    <log>
        <file>logs/sasd-%Y-%M.log</file>
        <SQL>false>
        <exec>true</exec>
        <read>false</read>
    </log>
</sasd>


Répertoire d'archives (fichiers de données du SGDE)

Balise concernée : <archives>

Ajuster :
Par ex., si :
on indiquera :

<archives>
    <datadir>/data/archives-sgde/prod</datadir>
    <extrdir>/data/tempo</extrdir>
    <extrurl>http://bozo/sgde-extractions</extrurl>
</archives>

NOTE. Comme dans cet exemple on fait référence à des répertoires autres que ceux crées par la procédure d'installation normale, il va de soi que ces répertoires devront être créés et correctement sécurisés.

Courriels

Balise concernée : <mail>

Modifier :
Par ex., si :
on indiquera :

<mail>
    <smtpServer>monserveur.com</smtpServer>
    <from>admin.sgde@sgde.com</from>
    <msg>
      <subject>Données SGDE / SGDE data</subject>
       ...
    </msg>
</mail>

NOTE. On devra s'assurer que le serveur smtp autorise les connexions à partir de la machine hébergeant le sesd.

On comprendra plus facilement la signification des diverses sections de la balise <mail> en regardant un exemple de courriel pouvant  être envoyé par le sgdebrowser. Il est alors facile de mettre en correspondance chaque section du message avec une section de la balise <mail>.

Pièce jointe (fichier détail)

Balise concernée : <detail>

Ajuster :
On comprendra plus facilement la signification des diverses sections de la balise <detail> en se référant à un exemple de pièce jointe pouvant  être envoyé par le sgdebrowser. Il est alors facile de mettre en correspondance chaque section du message avec une section de la balise <detail>.

Filtres

Balise concernée : <filter>

La balise <filter> permet à l'administrateur du système sgdebrowser de forcer l'application de certaines conditions à toutes les requêtes faites sur la base de données.
Aucun filtre n'est appliqué par défaut.

Par exemple, si l'on désire interdire l'accès aux jeux de données dont le nom débute par le préfixe BRUTE, ou dont la taille est > 250K, on pourrait définir :

<filter>
    <typ_jd>typ_jd not like 'BRUTE%´</typ_jd>
    <jeu_donnees>vol_jd between 0 and 250</jeu_donnees>
</filter>

Configurations relatives au répertoire d'extraction

Notes windows

Aucun équivalent ne peut être donné pour windows.

Serveur web

Les fichiers extraits des archives SGDE à la suite d'une sélection  avec le sgdebrowser sont regroupés et compressés dans un fichier au format zip dans le répertoire dit d'extraction (défaut : $SERVER_ROOT/extractions). Les fichiers y sont nommés de facon
à garantir leur unicité pour chaque requête.

Le fichier zip n'est pas envoyé a l'utilisateur. Ce dernier doit le  téléchargé en utilisant un URL contenu dans le message qui lui est
envoyé pour l'informer des résultats de sa requête. Un serveur web doit donc être correctement configuré permettre ce téléchargement.

Les instructions suivantes (privilège root requis) montrent une facon de faire, en supposant que :
<archives>
    <datadir>archives</datadir>
    <extrdir>extractions</extrdir>
    <extrurl>http://nom-de-machine/sgde-extractions</extrurl>
</archives>

Créer sur nom-de-machine le fichier /etc/httpd/conf.d/sgde.conf contenant les directives suivantes (on pourrait aussi ajouter ces directives directement au fichier de configuration principal d'Apache : /etc/httpd/conf/httpd.conf) :

# Mise en correspondance du repertoire web avec le
# repertoire physique ou sont generes les fichiers d'extration.
Alias /sgde-extractions /opt/sgde/extractions

# Protection du repertoire web pour eviter le furetage.
# Pour telecharger un fichier, le client web doit connaitre
# son nom exact, tel que transmis dans le courrielqui lui a
# ete envoye suite a une extraction.
<Location /sgde-extractions>
   Options -Indexes MultiViews
   Order allow,deny
   Allow from all
</Location>

Redémarrer le service httpd :

# service httpd graceful

On notera qu'étant donné les droits d'accès restreints pouvant être associés à certains fichiers des archives SGDE, il est important d'interdire le furetage dans le répertoire web associé au répertoire d'extractions, i.e. de faire lister le contenu du répertoire. Il est aussi important de protéger le répertoire d'extractions sur la machine physique, par ex. en donnant les droits de lecture/écriture au seul usager
$SGDESRVUSER au nom duquel s'execute le service sesd , en limitant le groupe $SGDESRVGROUP à la lecture seule, et en interdisant tout accès aux autres usagers.

IMPORTANT. L'usager au nom duquel s'exécute le serveur web (ex.: apache) doit être membre du groupe $SGDESRVGROUP, sinon les fichiers d'extraction ne pourront être téléchargés.

# chown -R $SGDESRVUSER:SGDESRVGROUP $SERVER_ROOT/extractions
# chmod -R 0750 /opt/sgde/extractions
# usermod -a -G $SGDESRVGROUP apache

  Redémarrer le service httpd :

# service httpd graceful

Temps maximal de rétention des fichiers du répertoire

Le temps durant lequel un fichier demeure disponible dans le répertoire d'extractions relève de la politique de gestion locale. Ce délai devrait être indiqué dans le texte des courriels envoyés aux utilisateurs.

Il est important de nettoyer régulierement ce répertoire pour éviter d'engorger l'espace-disque du système.  Les fichiers plus vieux que le temps prescrit peuvent être éliminés au moyen d'une tâche planifiée régulièrement exécutée au nom de l'usager $SGDESRVUSER. Le fichier $SERVER_ROOT/sesd/bin/linux/sgde_cleanup donne un exemple d'une telle tâche, exécutée à la minute 0 de chaque heure pour détruire les fichiers vieux de plus d'un jour.

# cat $SERVER_ROOT/sesd/bin/linux/sgde_cleanup
00 * * * * find /opt/sgde/extractions/* -mtime +1 -exec rm -f {} \; 1> /dev/null 2>&1

 Pour activer cette tâche récurrente, faire :

# crontab -u $SGDESRVUSER $SERVER_ROOT/sesd/bin/linux/sgde_cleanup

Services sasd et sesd

Notes windows

La configuration et l'installation sous windows des composantes sasd et sesd à titre de services demande une procédure particulière. Consulter la section Installation sous windows .

Fichiers de configuration

Cette section est spécifique à linux.

NOTE: dans les fichiers de configuration des deux services:

Les instructions qui suivent demandent d'être exécutées avec le privilège root.

Editer les fichiers de configuration du service sesd dans $SERVER_ROOT/sesd/bin/linux :
Editer les fichiers de configuration du service sasd dans $SERVER_ROOT/sasd/bin/linux :
Les composants du sgdebrowser ont été testés avec succès sur des versions 1.4 ou supérieures des machines virtuelles java.

Par exemple, si :
on aurait :

# cd $SERVER_ROOT/sasd/bin/linux
# cat sasd
...
export SERVER_ROOT=/opt/sgde-1.0
...
# cat sasd.conf
...
export LOGIN=sgdeadmin
export JRE=/usr/lib/jvm/jre-1.4.2-gcj
...
# cd $SERVER_ROOT/sesd/bin/linux
# cat sesd
...
export SERVER_ROOT=/opt/sgde-1.0
...
# cat sesd.conf
...
export LOGIN=sgdeadmin
export JRE=/usr/lib/jvm/jre-1.4.2-gcj
...

Démarrage des services

Cette section est spécifique à linux.

Installer les services sesd et sasd à titre de service système, de facon à ce qu'ils soient automatiquement lancés au démarrage de la machine.

# cd /etc/init.d
# ln -s $SERVER_ROOT/sasd/bin/linux/sasd
# ln -s $SERVER_ROOT/sesd/bin/linux/sesd

Démarrer manuellement une première fois les services sasd et sesd .

# service sasd start
# service sesd start

Vérifier que les services sont actifs. La commande "service nom status"  devrait retourner "running" :

# service sasd status
sasd (pid 23071) is running...
# service sesd status
sesd (pid 23123) is running...

Vérifier également qu'un fichier-journal a été créé pour chaque service dans $SERVER_ROOT/logs, et que chaque fichier contient une  entrée "Started" associée à l'heure à laquelle le service correspondant a été démarré.

# ls $SERVER_ROOT/logs
sasd-2010-07.log  sesd-2010-07.log
# cat $SERVER_ROOT/logs/sasd-2010-07.log
2010/07/22 12:47:17 Started
# cat $SERVER_ROOT/logs/sesd-2010-07.log
2010/07/22 12:47:20 Started

Le format du nom des fichiers-journaux est déterminé par les balises <sasd><log> et <sesd><log> du fichier $SERVER_ROOT/config.xml .
Ainsi, on a par défaut pour le service sasd :

<sasd>
...
    <log>sasd-%Y-%M.log</log>
...
</sasd>

Cette définition fait en sorte qu'un nouveau fichier-journal nommé sasd-aaaa-mm.log est démarré pour le service sasd à chaque changement d'année (%Y) et de mois (%M).

Arrêt / redémarrage des services

Cette section est spécifique à linux.

Les services sasd et sesd  peuvent être arrêtés / redémarrés en donnant l'argument stop / restart à la commande service :

# service sasd status
sasd (pid 23071) is running ...
# service sasd restart
# service sasd status
sasd (pid 23346) is running ...
# service sasd stop
# service sasd status
sasd is stopped

Fichier d'utilisateurs sasd (usagers SGDE)

Pour pouvoir effectuer une requête avec le sgdebrowser, il est nécessaire d'être un usager SGDE. La liste des usagers SGDE est contenue dans un fichier géré par le service sasd, conservé dans $SERVER_ROOT/sasd/users. Un usager SGDE est défini simplement au moyen d'un nom d'utilisateur et d'un mot de passe.

IMPORTANT. Le fichier d'usagers sasd est conservé en format encrypté, et il est impossible de décrypter l'information originale en clair une fois l'encryption effectuée. Il est donc primordial pour l'administrateur du SGDE de préserver les données initiales (nom et mot de passe) utilisées lors de sa création des comptes-usager.

Ce fichier peut être initialisé automatiquement à l'aide du script create-sasd-users et d'un fichier d'identifiants. Ce script requiert toutefois de disposer sur la machine des paquetages tcl et expect. L'initialisation peut aussi se faire manuellement en se connectant directement au service (voir plus bas).

Scripts de création / modification du fichier


Le script d'initailisation automatique est lancé en faisant :

$ $SERVER_ROOT/tools/create-sasd-users admin pass port passfile

où les arguments sont :

 admin  
nom de l'administrateur sasd; on aura a utiliser ce nom si on désire se connecter manuellement au service avec telnet
 pass
mot de passe du compte admin
 port
port réseau du service sasd; doit correspondre à la valeur indiquee dans la balise <sasd><port> du fichier $SERVER_ROOT/config.xml(défaut: 30102)
passfile
fichier contenant les noms et mots de passe des usagers SGDE, à raison d'un usager par ligne dans le format "nom motpasse".

  L'execution du script produira la sortie suivante :

added user: nom
added user: nom
added user: nom
...


IMPORTANT. Si on désire exécuter à nouveau le script, il est obligatoire au préalable :
en exécutant :

# rm -f $SERVER_ROOT/sasd/users
# service sasd restart

$SERVER_ROOT/tools contient une variante du script create-sasd-users, appelée modif-sasd-users. L'appel est similaire. La différence entre les deux versions est que modif-sasd-users ne réinitialise pas la totalité du fichier d'usagers. Les entrées dans passfile sont ajoutées à l'actuel fichier d'usagers dans le cas de nouveaux identifiants. Dans le cas d'identifiants déjà existants, leur mot de passe est modifié. Il n'est pas nécessaire de redémarrer le service après l'exécution de modif-sasd-users.

Mise-à-jour manuelle du fichier

Il est aussi possible d'initialiser le fichier d'usagers en se connectant manuellement au service sasd par telnet. On utilisera cette méthode si le script create-sasd-users ne peut être exécuté (par ex. si tcl ou expect sont non disponibles sur la machine).

Les commandes suivantes reproduisent les actions effectuées automatiquement par le script. On suppose que le fichier d'usagers est inexistant au départ. Sinon, on devra tout d'abord le détruire et redémarrer le service en faisant :

# rm -f $SERVER_ROOT/sasd/users
# service sasd restart

Le service commence par demander de définir le compte d'administration. On est alors connecté en tant qu'administrateur. La commande set mode administrator active les privilèges d'administrateur (inactifs par défaut). Une commande add user nom pass est ensuite entrée pour définir chaque usager. La commande show users retourne la liste des usagers courants. La commande exit termine la connexion au service.

$ telnet localhost 30102
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
Sgdo Archival Server 1.0.3 (2010-04-09)
New administrator login:admin
New administrator password:...
10:OK
>set mode administrator
10:OK
>add user nom pass 255.255.255.255
10:OK
>add user nom pass 255.255.255.255
10:OK
>add user nom pass 255.255.255.255
10:OK
etc ...
>show users
nom:255.255.255.255
nom:127.0.0.1
nom:255.255.255.255
etc...   
>exit

L'ajout ou la modification d'un identifiant sasd en mode manuel se fait de manière similaire. Comme le fichier d'usagers existe déjà, le service ne commencera par demander de créer un compte administrateur. Il demandera simplement de s'identifier. On entrera alors les nom et mot de passe de l'administrateur (définis lors de l'initialisation du fichier). On entrera ensuite une commande "set mode administrator" pour activer les privilèges d'administration (inactifs par défaut), suivie des commandes "add user ..." appropriées.

Par exemple, pour ajouter un nouvel identifiant ou modifier un identifiant existant on ferait :

$ telnet localhost 30102
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
Sgdo Archival Server 1.0.3 (2010-04-09)
login: admin
password:...
10:OK
>set mode administrator
10:OK
>add user nom pass 255.255.255.255
10:OK
>exit

Fichier d'utilisateurs sesd

L'exécution du service sesd demande elle aussi une liste d'utilisateurs, conservée en format encrypté dans le fichier $SERVER_ROOT/sesd/users. Cette liste est généralement plus courte, puisque le service est généralement appelé par la seule application sgdebrowser. Il est rare en pratique qu'un usager ordinaire doive interagir directement avec le service.

IMPORTANT. L'application sgdebrowser force l'utilisation de "SgdeExtractorBrowser" comme nom d'usager, et "sgdo" comme mot de passe. Cet identifiant devra donc toujours figurer dans la liste d'usagers.

Les mêmes précautions s'appliquent quant à la préservation de la version en langage clair des données encryptées dans le fichier.

L'initialisation ou la modification du fichier d'usagers sesd se fait selon une méthode identique à celle utilisée pour le service sasd. On se référera à cette section du document pour plus d'informations. On se rappellera toutefois que le port par défaut du service sesd est le 30203.

Scripts de création / modification du fichier

tcl et expect sont requis.

$ $SERVER_ROOT/tools/create-sesd-users admin pass port passfile
$ $SERVER_ROOT/tools/modif-sesd-users admin pass port passfile

IMPORTANT. Si on désire exécuter à nouveau le script create-sesd-users, il est obligatoire au préalable :
en exécutant :

#rm -f $SERVER_ROOT/sesd/users
# service sesd restart

Mise-à-jour manuelle du fichier


$ telnet localhost 30203
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
SGDO Extractor Server 1.3.1 (2010-04-09)
New administrator login:admin
New administrator password:...
10:OK
>set mode administrator
10:OK
>add user SgdoExtractorBrowser sgdo 255.255.255.255
10:OK
>show users
SgdoExtractorBrowser:255.255.255.255
admin:127.0.0.1
>exit

$ telnet localhost 30203
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
SGDO Extractor Server 1.3.1 (2010-04-09)
login: admin
password: ...
10:OK
>set mode administrator
10:OK
add user user pass 255.255.255.255
10:OK
>exit

Fichier journal

Les services sasd et sesd tiennent à jour un journal d'exécution (log) où sont consignées les principales actions effectuées. Le nom du fichier journal, de même que le type d'actions enregistrées, sont paramétrisés au moyen d'une section <log> à l'intérieur des balises <sasd> et <sesd> du fichier de configuration. Cette section est définie de facon identique pour les deux services, et comporte les paramètres suivants.
La paramétrisation par défaut est logs/sasd-%Y-%M.log pour le service sasd, et logs/sesd-%Y-%M.log pour le service sesd. Les fichiers-journaux seront ainsi crées dans le répertoire $SERVER_ROOT/logs, porteront le nom du service (sasd / sesd) comme préfixe, et comme suffixe l'année et le mois dans le format -aaaa-mm.log. Un nouveau fichier-journal sera initialisé au début de chaque mois. Au fil du temps, les fichiers suivants seront créés sous $SERVER_ROOT/logs :

... sasd-2010-01.log ... sasd-2010-08.log sasd-2010-09.log ...
... sesd-2010-01.log ... sesd-2010-08.log sesd-2010-09.log ...

Si on changeait le nom du fichier journal du service sasd pour logs/%Y%M%D-sasd.log, un nouveau fichier-journal serait initialisé à chaque jour. On verrait apparaître dans $SERVER_ROOT/logs :

... 20100731-sasd.log  20100801-sasd.log  20100802-sasd.log  ...

IMPORTANT. Si on change le répertoire où les fichiers sont générés, il faudra s'assurer que l'usager $SGDESRVUSER y a accès en écriture. Il est important de bien sécuriser ce répertoire, puisque les fichiers-journaux peuvent contenir des informations sensibles.
Les sorties résultant du  paramètre <exec> peuvent différer de celles du paramètre <read> : 

Installation sous Windows

Il existe deux facons de lancer sasd et sesd en tant que servies sous windows.  

Démarrage manuel


La première est de lancer manuellement chaque service dans une fenêtre DOS au moyen des scripts .bat contenus sous :

$SERVER_ROOT\sasd\bin\win\sasd_start.bat
$SERVER_ROOT\sesd\bin\win\sesd_start.bat

S'assurer d'abord que la valeur de la variable SERVER_ROOT est bien définie dans ces scripts. Apporter les modifications appropriées selon le répertoire d'installation choisi.

...
set SERVER_ROOT=C:\opt\sgde
...

Exécuter ensuite chacun des deux scripts. L'endroit à partir duquel l'exécution est lancée peut être quelconque.

Par exemple, dans le cas du service sasd , double cliquer dans l'explorateur windows sur l'icône sasd_start.bat :



La fenêtre DOS suivante apparaîtra :



On pourra ensuite tester la connexion en ouvrant une autre fenêtre DOS et en entrant (machine locale, port par défaut 30102 assigné au sasd dans le fichier de configuration config.xml):



La fenêtre DOS affichera :



On pourra maintenant entrer des commandes au sasd, tel qu'indiqué plus haut ainsi que dans le manuel d'utilisation.
Pour terminier le service, taper un <ctrl-C> dans la fenêtre DOS.

Ce mode de démarrage des services a le désavantage d'être plutôt fragile, puisqu'il exige de devoir conserver ouvertes en tout temps les fenêtres DOS auxquelles sont rattachées les services, et qu'il ne survit pas à un redémarrage de la machine.

Démarrage à titre de services windows

Il est plus simple de transformer le sasd et sesd en véritables services windows sous le contrôle du gestionnaire de services (services.msc).  De cette facon, les services pourront être arrêtés et redémarrés facilement au moyen du gestionnaire, et pourront être lancés automatiquement au démarrage de la machine.

Une application java peut être convertie en service windows à l'aide de l'excellent outil Java Service Wrapper de Tanuki Software, disponible en license libre. Suite à l'installation on retrouvera les fichiers nécessaires sous les répertoires :

$SERVER_ROOT\sasd\bin\win\svc-wrapper
$SERVER_ROOT\sesd\bin\win\svc-wrapper

Dans chacun de ces répertoires se trouve un fichier conf\wrapper.conf servant à la configuration du service windows. Tels que livrés dans le paquetage, ces deux fichiers utilisent C:\opt\sgde comme racine de l'installation. Si l'installation s'est faite sous un autre répertoire, éditer les fichiers et remplacer toutes les occurences de C:/opt/sgde par le chemin approprié (NOTE: dans ces fichiers, le délimiteur "/" est utilisé plutôt que le "\" dans les chemins d'accès). 

...
wrapper.java.classpath.2=C:/opt/sgde/lib/activation-1.1.jar
wrapper.java.classpath.3=C:/opt/sgde/lib/commons-collections-3.2.1.jar
...
wrapper.java.classpath.9=C:/opt/sgde/lib/sgde-servers-1.0.jar
...
wrapper.app.parameter.2=C:/opt/sgde/config.xml
...

On installera une première fois les services windows en exécutant le fichier bin\install.bat situé dans chacun des répertoires. L'exécution peut être lancée de n'importe-où, dans une fenêtre DOS ou en double-cliquant sur l'icône du fichier dans l'explorateur windows. L'avantage de l'exécution dans une fenêtre DOS est de pouvoir visualiser immédiatement les messages confirmant l'installation du service.



Un journal d'exécution logs\wrapper.log est produit dans le répertoire de chaque service. On y verra par ex. suite à l'installation du service sasd :

...
STATUS | wrapper  | 2010/08/11 11:19:58 | SGDE sasd service installed.

En ouvrant le gestionnaire de services, on verra les services apparaître dans la fenêtre Services sous les noms SGDE sasd et SGDE sesd :



Suite à leur installation, les services devront être démarrés explicitement une première fois au moyen du menu Action > Démarrer . La fenêtre Services affichera :



Le type de démarrage des deux services étant "Automatique", ils seront automatiquement relancés au prochain démarrage de la machine, et n'auront plus à être démarrés manuellement.

Suirte au démarrage, des informations seront ajoutées aux journaux d'exécution logs\wrapper.log. Dans le cas par ex. du service sasd :

STATUS | wrapper  | 2010/08/11 11:26:43 | --> Wrapper Started as Service
STATUS | wrapper  | 2010/08/11 11:26:43 | Java Service Wrapper Community Edition 32-bit 3.4.1
STATUS | wrapper  | 2010/08/11 11:26:43 |   Copyright (C) 1999-2010 Tanuki Software, Ltd.  All Rights Reserved.
STATUS | wrapper  | 2010/08/11 11:26:43 |     http://wrapper.tanukisoftware.org
STATUS | wrapper  | 2010/08/11 11:26:43 |
STATUS | wrapper  | 2010/08/11 11:26:43 | Launching a JVM...
INFO   | wrapper  | 2010/08/11 11:26:43 | Command : "C:\WINDOWS\system32\java.exe" -Djava.library.path="../lib" -classpath "../lib/wrapper.jar;C:/opt/sgde/lib/activation-1.1.jar;C:/opt/sgde/lib/commons-collections-3.2.1.jar;C:/opt/sgde/lib/commons-configuration-1.6.jar;C:/opt/sgde/lib/commons-lang-2.5.jar;C:/opt/sgde/lib/commons-logging-1.1.1.jar;C:/opt/sgde/lib/mail-1.4.2.jar;C:/opt/sgde/lib/postgresql-8.4-701.jdbc3.jar;C:/opt/sgde/lib/sgde-servers-1.0.jar" -Dwrapper.key="cyS449ZnkjiA7h5t" -Dwrapper.port=32000 -Dwrapper.jvm.port.min=31000 -Dwrapper.jvm.port.max=31999 -Dwrapper.pid=924 -Dwrapper.version="3.4.1" -Dwrapper.native_library="wrapper" -Dwrapper.service="TRUE" -Dwrapper.cpu.timeout="10" -Dwrapper.jvmid=1 org.tanukisoftware.wrapper.WrapperSimpleApp osl.sgdo.server.SgdoArchivalServer C:/opt/sgde/config.xml
INFO   | jvm 1    | 2010/08/11 11:26:44 | WrapperManager: Initializing...

On pourra maintenant entrer des commandes au service tel qu'indiqué dans le manuel d'utilisation, avec une connexion telnet ou en démarrant l'explorateur graphique.  Voici un exemple de connexion telnet au service sesd (machine locale, port par défaut 30203 assigné au service sesd  dans le fichier de configuration config.xml).





Utiliser le menu Action > Redémarrer du gestionnaire de services pour redémarrer un service, et Action > Arrêter pour l'arrêter. Les services sasd et sesd ne peuvent cependant être interrompus.

Pour désinstaller les services windows, exécuter le script svc-wrapper\bin\uninstall.bat disponible dans le répertoire win de chaque service. Ce script peut être exécuté de n'importe-où. Lorsqu'exécuté dans une fenêtre DOS, on obtiendra :



Le journal d'exécution documente l'arrêt et la désinstallation. Dans le cas du service sasd il contiendra par ex. :

...
STATUS | wrapper  | 2010/08/11 11:39:19 | Service is running.  Stopping it...
STATUS | wrapper  | 2010/08/11 11:39:20 | <-- Wrapper Stopped
STATUS | wrapper  | 2010/08/11 11:39:22 | SGDE sasd service stopped.
STATUS | wrapper  | 2010/08/11 11:39:22 | SGDE sasd service removed.

NOTE. Si on doit modifier le fichier conf\wrapper.conf, il est nécessaire de désinstaller au préalable le service en exécutant le script bin\uninstall.bat.

Explorateur graphique sgdebrowser

Introduction

L'explorateur sgdebrowser est une application autonome permettant de sélectionner des fichiers de données dans le SGDE au moyen d'un interface graphique, et d'acheminer les résultats par courriel à l'utilisateur.

L'explorateur constitue la portion client d'un système de type client-serveur où le service sesd joue le rôle de serveur.
L'explorateur sgdebrowser peut être installé sur une machine différente de celle hébergeant les services sesd et sasd. Il suffit que le port de communication assigné au service sasd soit accessible à partir de la machine hébergeant l'explorateur. Etant écrit en java, l'explorateur peut  s'exécuter sur linux ou windows.

L'application fut développée à l'Institut Maurice-Lamontagne au début des années 2000 pour la première version du système (alors appelé SGDO / ODMS). L'approche de développement utilisée à l'époque a malheureusement mal vieilli, et empêche de faire évoluer l'application en lui apportant l'entretien et les améliorations qu'elle mériterait. Malgré sa désuétude relative, l'explorateur conserve toutefois son utilité pour effectuer des requêtes simples sur la base de données SGDE et le dépôt de fichiers associé. L'application a aussi son intérêt en ce qu'elle permet de vérifier rapidement le bon fonctionnement  du SGDE. Pour ces raisons, il a été décidé de distribuer l'application, mais en version exécutable seulement, les codes source ne pouvant maheureusement être distribués sous license libre.

Installation

Suivre les étapes suivantes pour installer l'application.

Copier dans un répertoire à accès public de la machine cible les fichiers suivants du répertoire $SERVER_ROOT/sgde-clients du paquetage d'installation, soit :
Editer le fichier sgdebrowser (Linux) ou sgdebrowser.bat (Windows) et y ajuster les définitions suivantes.
 Exemples.

Sous linux

Si :
on obtiendrait :

demeter$ ls /usr/local/bin/sgdebrowser
sgdebrowser sgdebrowser.jar
demeter$ cat /usr/local/bin/sgdebrowser/sgdebrowser
CLASSPATH=/usr/local/bin/sgdebrowser/sgdebrowser.jar
HOST=demeter
PORT=30203
(...)

On devra s'assurer que les fichiers sont accessibles et bien protégés :

# chmod a+rx /usr/local/bin/sgdebrowser
# chmod a+r /usr/local/bin/sgdebrowser/*
# chmod a+x /usr/local/bin/sgdebrowser/sgdebrowser

On informera les utilisateurs de placer le répertoire d'installation dans leur PATH d'exécution. Par exemple, un usager du shell bash pourrait ajouter à son fichier ~/.bashrc :

export PATH=/usr/local/bin/sgdebrowser:$PATH

Sous windows

Si :
on obtiendrait :

C:\> dir sgdebrowser
... sgdebrowser.bat
... sgdebrowser.jar
C:\> type sgdebrowser\sgdebrowser.bat
set CLASSPATH=C:\sgdebrowser\sgdebrowser.jar
set HOST=lauimldaisss01
set PORT=40000
(...)

Pour placer le répertoire d'installation sur le PATH d'exécution, accéder au dialogue de définition des variables d'environnement.

Sous XP, suivre: 
Démarrer > Panneau de configuration > Système > Avancé > Variables d'environnement

Sous Windows 7 , suivre :
Démarrer >Panneau de configuration >Système et sécurité >Système > Paramètres système avancés > Variables d'environnement.

Editer le contenu de la variable PATH en utilisant le caractère ';' comme séparateur de répertoires. Par ex.:
C:\Program Files;C:\sgdebrowser

Exécution

Avant de pouvoir lancer l'explorateur une première fois, on doit s'assurer des conditions suivantes.
Le paquetage d'installation du sgdebrowser contient un jeu de données test qui pourront être chargées dans le système, permettant de faire l'essai de l'explorateur. Consulter à ce sujet le document  sgdebrowser - démonstration.

Pour lancer l'explorateur sgdebrowser :
$ sgdebrowser
On verra d'abord apparaître une fenêtre montrant le progrès du chargement de l'application en mémoire :



Un blocage à cette étape, suivi de l'affichage de la fenêtre d'erreur suivante, s'explique vraisemblablement par un problème de communication réseau. On devra dans ce cas revoir les prérequis indiqués ci-haut.



La fenêtre du sgdebrowser devrait apparaître ensuite.



NOTE. Les noms SGDO / ODMS réfèrent à la première version du système. L'application est toutefois compatible avec la nouvelle version SGDE / EDMS.

La langue du poste utilisé détermine la langue de l'application, soit l'anglais dans l'exemple ci-haut. Le menu Aide/Help décrit comment accéder aux diverses fonctionnalités.

On trouvera dans le document sgdebrowser - démonstration des exemples d'utilisation de l'explorateur sgdebbrowser à partir de données test.