Système sgdebrowser
manuel technique


Table des matières

Introduction

Ce document présente le système sgdebrowser dans la perspective de son administration par la personne en charge du système.  L'approche est technique, et suppose une bonne familiarité avec les bases de données et les services réseau.

Les principales composantes du système sgdebrowser sont tout d'abord décrites. Les commandes-usager acceptées par les services sasd et sesd sont ensuite présentées, suivi des commandes d'administration des privilèges d'accès. Les commandes de démarrage des services sont finalement expliquées.



Composantes du système

Archive de fichiers

L'archive de fichiers désigne le répertoire où sont contenus les fichiers de données qui seront ultimement sélectionnés par l'utilisateur. Ces fichiers sont de type quelconque.

Base de données

Les méta-données servant à décrire les fichiers de données sont gérées dans une base de données relationnelle, utilisée à la manière d'un catalogue pour permettre la sélection de fichiers selon divers critères. Le SGDE a été développé pour utiliser PostgreSQL comme système de base de données.

Service sesd

Le service sesd implante un protocole de communication permettant à une application client d'acheminer des requêtes au système. Le sesd transige avec la base de données et tient à jour une liste des fichiers répondant aux requêtes.  Une fois la sélection terminée, le sesd contacte le service sasd pour valider l'identifiant de l'utilisateur. La liste de fichiers est validée en fonction des droits d'accès de cet utilisateur, et ensuite envoyée au service sasd qui lui retourne un fichier au format zip contenant ces fichiers, ainsi qu'un fichier descriptif au format texte. Le sesd dépose le fichier sur le serveur web, et achemine un courriel à l'utilisateur lui indiquant comment récupérer les résultats de sa sélection, accompagné du fichier descriptif en pièce jointe.

Le sesd est une application java, dont les codes-source sont distribués sur le site du projet.

Service sasd

Le service sasd a deux fonctions. Il gère tout d'abord le fichier d'utilisateurs autorisés à accéder aux fichiers du SGDE, et valide à partir de ce fichier l'identifiant envoyé par le sesd avant de déclencher une extraction. Il construit ensuite un fichiers d'extractions au format zip contenant les fichiers décrits dans la liste recue du sesd, qu'il retourne au sesd accompagné d'un fichier descriptif au format texte.

Le sasd est une application java, dont les codes-source sont distribués sur le site du projet.

Fichier de configuration

Les services sasd et  sesd sont entièrement paramétrisés au moyen d'un fichier au format XML nommé config.xml. Ce fichier définit par ex. les paramètres de la connexion à la base de données, la localisation du répertoire d'archives, les ports-réseau utilisés, et le contenu des courriels envoyés aux utilisateurs.

Explorateur graphique

Le système sgdebrowser comprend une application appelée l'explorateur sgdebrowser permettant d'interroger le catalogue de fichiers au moyen d'une interface graphique conviviale. L'explorateur constitue la composante client du système, et transige avec la composante serveur en acheminant des commandes au service sesd. L'explorateur est une application java. Pour des raisons techniques, les codes-source ne sont pas disponibles.


Serveur web

Un serveur web est utilisé pour donner accès aux fichiers d'extractions contenant en format compressé zip les fichiers de données répondant aux requêtes de l'utilisateur.

Serveur de courrier

Un serveur de courrier est requis pour acheminer aux utilisateurs les courriels les informant des résultats de leurs requêtes.

Environnement

Les composantes du système sgdebrowser, soit les services sasd et sesd ainsi que l'explorateur graphique, sont écrites en java et donc portables sur toute plateforme dotée d'un JRE. La base de données peut être implantée sur toute machine disposant d'un service PostgreSQL.

L'archive de fichiers doit être vue par le service sasd comme appartenant au système de fichiers de la machine hébergeant le service. Il en va de même avec le service sesd pour le répertoire utilisé sur le serveur web pour la diffusion des fichiers d'extraction. En effet, les deux services accèdent à ces répertoires comme s'il s'agissait d'objets locaux. Rien n'empêche cependant ces répertoires d'être importés d'un service de fichiers accessible sur le réseau (par ex. via NFS ou Samba).

Le service web doit permettre l'accès direct par le sesd au répertoire de diffusion. Le service de courrier utilisé doit supporter le protocole SMTP, et permettre l'accès à partir du sesd.

Les composantes du système sgdebrowser peuvent être réparties en réseau sur plusieurs machines, à la condition que les autorisations appropriées soient correctement configurées au niveau des ports-réseau et des systèmes de fichiers impliqués.

Sécurité

La sécurité du système est assurée à trois niveaux. Le service sasd gère tout d'abord une liste des usagers autorisés à accéder aux fichiers de l'archive du  SGDE. L'accès au service sesd, et donc à la base de données, est ensuite  restreint aux usagers identifiés dans un fichier d'utilisateurs géré par le service. Le sesd valide finalement les droits d'accès de l'utilisateur face à chaque fichier au moyen d'une table de  privilèges contenue dans la base de données.

Commandes au service sesd

Le service sesd offre des commandes permettant :
Les noms de commandes ne sont pas sensibles à la casse, mais les arguments de type textuel le sont.

Définition des critères de recherche

Les critères de recherche servent à appliquer à la base de données une commande SQL "select ... from ....  where ...". Les critères de recherche de différents types définissent dans la commande des expressions jointes par un ET logique. Lorsque plusieurs critères de recherche du même type sont utilisés (par ex. plusieurs rectangles de recherche, plusieurs noms de mission), ils sont joints par un OU logique dans une l'expression correspondante
 
RESET

Effacer la liste de critères précédemment entrés.

Exemple :

reset
ADD SPATIAL lat_haut_gauche lon_haut_gauche lat_bas_droit lon_bas_droit

Définir un rectangle de recherche défini par les latitude et longitude des coins supérieur gauche et inférieur droit. Les coordonnées sont entrées en degrés décimalisés (longitude ouest : < 0).

Exemple :

add spatial 50.5 -63.6 47.0 -62

ADD TEMPORAL date_debut date_fin

Sélectionner les jeux de données dont les dates figurent dans l'intervalle spécifié. Les dates sont entrées dans le format aaaa/mm/jj.

Exemple :

add temporal 2005/05/01 2005/09/25

ADD DEPTH min max

Sélectionner les jeux de données associés à des profondeurs figurant dans l'intervalle spécifié. Les unités sont en mètres, et croissent de la surface vers le bas.

Exemple :

add depth 20.5 100.0

ADD MISSION nom

Sélectionner les jeux de données associés à une mission.

Exemple :

add mission IML0963

ADD AREA zone

Sélectionner les jeux de donnés associés à une zone prédéfinie.

Exemple :

add area IML_BOUEE

ADD TYPE type

Sélectionner les jeux de données d'un certain type.

Exemple :

add type ODF-CTD

ADD KEY mot-clé

Rechercher les jeux de données associés au mot-clé indiqué

Exemple :

add key OXYGENE


Décompte et limites spatio-temporelles

Les commandes SHOW retournent un résultat en format texte.
SHOW COUNT

Afficher le nombre de jeux de données répondant aux critères de recherche courants.

Exemple :

show count

SHOW MAX

Afficher le nombre maximal de jeux de données pouvant être extraits en une seule fois.

Exemple :

show max

SHOW LIMIT DEPTH

Afficher la fourchette de  profondeurs englobant la totalité des  jeux de données de l'archive SGDE (ignorant la sélection courante).

Exemple :

show limit depth

SHOW LIMIT TEMPORAL

Afficher la fourchette de  datess englobant la totalité des  jeux de données de l'archive SGDE (ignorant la sélection courante).

Exemple :

show limit temporal

Consultation des tables de la base de données par l'explorateur graphique

Les commandes GET ont été développées pour les besoins de l'explorateur graphique, qui les utilise pour initialiser les éléments de son interface. Les résultats sont retournés dans un format interne compréhensible seulement par l'explorateur. Ces commandes ne devraient donc pas être utilisées lors d'une connexion directe au sesd avec telnet.

GET MISSION

Obtenir les données nécessaires à l'initialisation de l'onglet 'Missions".

GET AREA

Obtenir les données nécessaires à l'initialisation de l'onglet "Areas".

GET TYPE

Obtenir les données nécessaires à l'initialisation de l'onglet "Data types".

GET KEY

Obtenir les données nécessaires à l'initialisation de l'onglet "Keywords".

Exécution de l'extraction

EXTRACT usager mot-de-passe courriel

Lancer le processus d'extraction sur la base des critères de recherche courants. L'usager doit être inscrit dans la liste d'usagers SGDE géré par le service sasd. L'obtention d'un fichier dont le droit d'accès est autre que PUBLIC est conditionnel à l'appartenance de l'usager au groupe correspondant à ce droit. Un courriel sera envoyé à l'adresse indiquée informant l'usager du résultat de ses recherches, accompagné en pièce jointe d'un fichier présentant le sommaire des fichiers sélectionnés.

Exemple :

extract hector iliade nom@domaine

Fin de session

EXIT

Terminer la connexion avec le service sesd.

Exemple :

exit


Commandes au service sasd

Ajout d'un fichier à la liste d'extractions

ADD prm1 prm2 ... prm16

Après avoir déterminé que l'utilisateur peut obtenir un fichier particulier, le service sesd envoie au service sasd une commande ADD . Les paramètres de la commande permettent au sasd de localiser le fichier dans le répertoire d'archive, et de composer l'entrée du fichier dans le tableau résumant les résultats de la recherche et qui sera joint au courriel retourné à l'utilisateur. Ces paramètres sont :

# Description Exemple
1 Répertoire d'archive (relativement à la racine indiquée dans le fichier de configuration par la balise <archives><datadir>) ODF_CTD
2 Nom du fichier dans le répertoire d'archive iml001.dat
3 Nom logique du fichier (nom sous lequel le fichier doit être transmis à l'usager) CTD_2009063_104_1_DN.ODF
4 Latitude de la première donnée 49.4833
5 Longitude de la première donnée -58.7141
6 Latitude de la dernière donnée 49.484
7 Longitude de la dernière donnée -58.7141
8 Date de la première donnée 2009/11/11
9 Date de la dernière donnée 2009/11/11
10 Profondeur minimale 2.98
11 Profondeur maximale 119.83
12 Nom de mission IML0963
13 Type de fichier ODF-CTD
14 Propriétaire USAG1
15 Droit d'accès PUBLIC
16 Etat du fichier Archive

Obtention du contenu de la liste d'extractions

GET fichierdescriptif

Le service sesd envoie cette commande pour obtenir le flux de données représentant l'ensemble des fichiers identifiés par les précédentes commandes ADD, auquel est joint le fichier descriptif composé à partir des paramètres passés aux commandes ADD. Le flux est compressé en format zip. Le résultat est retourné en binaire, compréhensible seulement par le service sesd. Cette commande ne doit pas être exécutée dans une session telnet.

Exemple :

get detail3245.txt

Fin de session

EXIT

Terminer la connexion avec le service sesd.

Exemple :

exit


Administration des privilèges d'accès

Chacun des services sasd et sesd a recours à un fichier d'utilisateurs pour authentifier les utilisateurs. Le fichier d'utilisateurs du sasd est le plus important, puisqu'il correcpond à la liste des usagers autorisés à obtenir des fichiers de l'archive SGDE : il est aussi appelé fichier des usagers SGDE. Le fichier d'utilisateurs du sesd est par contre beaucoup moins important, puisqu'en pratique seul l'explorateur graphique sgdebrowser a avantage à se connecter au service sesd.

Les fichiers d'utilisateurs sont conservés à l'endroit indiqué dans le fichier de configuration config.xml au moyen des balises <sasd><usersFile> et <sesd><usersFile>. Ces fichiers sont encryptés, et ne peuvent être traduits en clair. Il est donc important de conserver une version sécurisée de leur contenu en format textuel lisible.

La gestion des utilisateurs des deux services se fait de manière identique. Les exemples de cette section sont relatives aux utilisateurs du sesd, mais peuvent être transposés au sasd sans changement.

La gestion des comptes utilisateurs se fait à l'aide d'un ensemble de commandes réservées aux usagers dotés du privilège d'administrateur. L'exécution de ces commandes n'est possible qu'en établissant une connexion directe au service par telnet.

Le premier compte à créer est celui de l'administrateur principal. L'appel au service en l'absence d'un usager associé au rôle d'administrateur provoquera la demande des noms et mot de passe de cet administrateur.

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:secret
10:OK


Activation du privilège d'administrateur


SET MODE ADMINISTRATOR
SET MODE USER

Pour pouvoir être exécutées, toutes les commandes de gestion des comptes utilisateurs requièrent que la connexion au service ait été faite avec un compte doté du privilège administrateur. Ce privilège n'est pas activé par défaut, et ceci vaut aussi pour l'administrateur principal.  C'est ce qu'on constate dans l'exemple suivant :

% 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:secret
10:OK
>add user xyz pass 255.255.255.255
101:Syntax error

Pour pouvoir exercer le privilège administrateur, la commande SET MODE ADMINISTRATOR doit être entrée. On désactivera au besoin le privilège avec la commande SET MODE USER.

En poursuivant l'exemple précédent :

>set mode administrator
10:OK
>add user xyz pass 255.255.255.255
10:OK

Ajout d'un usager

ADD USER usager mottdepasse nnn.nnn.nnn.nnn

Définir un usager et son mot de passe. Le 3e argument représente un masque réseau IP 32 bits permettant de limiter les machines à partir desquelles l'utilisateur peut se connecter au service. Les connexions au sasd se font toujours normalement à partir de la machine hébergeant le sesd, ce qui fait que le masque-réseau associé à un usager sasd doit obligatoirement autoriser une connexion par cette machine. Il est recommandé en pratique d'utiliser le masque-réseau 255.255.255.255 pour les usagers non provilégiés, afin d'autoriser une connexion à partir de n'importe quelle origine.

Les seuls comptes pour lesquels un masque-réseau est important sont ceux associés au privilège d'administrateur. Par mesure de sécurité, le masque 127.0.0.1 devrait alors être utilisé, de manière à ce que toute connexion au service avec ce compte doive obligatoirement se faire à partir de la machine hébergeant le service.

Exemple :

>add user andre secret 255.255.255.255
10:OK
>add user puissant tressecret 127.0.0.1

Autres commandes

ADD ADMINISTRATOR user

Conférer le privilège d'administrateur à un usager

REMOVE ADMINISTRATOR user

Retire le privilège d'administrateur à un usager

REMOVE USER user

Supprimer un utilisateur.

CHANGE PASSWORD user

Assigner un nouveau mot de passe à un utilisateur.

CHANGE SUBNETMASK usager nnn.nnn.nnn.nnn

Modifier le masque-réseau d'un utilisateur.

SHOW USER user
SHOW USERS

Afficher l'information sur un usager. La 2e forme de la commande affiche l'information sur tous les usagers.

Exemple :

>show user hector
hector:255.255.255.255
10:OK
>show users
SgdoExtractorBrowser:255.255.255.255
admin:127.0.0.1
hector:255.255.255.255
ulysse:255.255.255.255
10:OK

SHOW ADMINISTRATORS

Afficher la liste de tous les utilisaters doté du privilège d'administrateur.


Démarrage des services sasd et sesd

Sous linux

Les services sont demarrés par l'intermédiaire de scripts conservés dans les répertoires :

Chaque répertoire contient un script portant le nom du service (sasd ou sesd), accompagné d'un fichier daemon qui définit les fonctions du service (start, stop, restart, status), et d'un fichier .conf définissant les variables d'environnement essentielles au bon lancement du service.

Les services peuvent être contrôlés en exécutant les scripts sasd et sesd. Ces derniers acceptent en argument l'une des valeurs suivantes :

start   pour démarrer le service
stop     pour arrêter le service
restart pour redémarrer le service
status  pour connaître le statut courant du service

Un lien logique vers chacun des scripts sasd et sesd peut être défini dans le répertoire /etc/init.d . De cette facon, les services peuvent être facilement contrôlés à l'aide de la commande système service. Ils seront aussi automatiquement démarrés par une commande start au démarrage de la machine.

# service sasd start
# service sasd status
sasd (pid 20763) is running...
# service sasd stop
# service sasd stop
# service sasd status
sasd is stopped

Sous windows

On peut lancer les services de deux facons :
Méthode de lancement

Indépendamment des particularités propres à la plateforme utilisée, le lancement des services se résume pour l'essentiel à lister les bibliothèques au format JAR du répertoire $SERVER_ROOT/lib sur le chemin de recherche (CLASSPATH) de la machine virtuelle java, et à exécuter la méthode main() de la classe appropriée.

Sous linux, le lancement du service sasd se fait en exécutant :

# cd $SERVER_ROOT
# LIB=$SERVER_ROOT/lib
# CLASSPATH=$LIB/activation-1.1.jar:$LIB/common-collections-3.2.1.jar:...
# java -server -cp $CLASSPATH osl.sgdo.server.SgdoArchivalServer $SERVER_ROOT/config.xml

La variable CLASSPATH énumére chacune des librairies au format JAR contenues sous $SERVER_ROOT/lib . Le service est lancé en exécutant la méthode main() de la classe SgdoArchivalServer du paquet osl.sgdo.server. La méthode recoit en argument le nom du fichier de configuration ($SERVER_ROOT/config.xml).

Dans le cas du service sesd :

cd $SERVER_ROOT
# LIB=$SERVER_ROOT/lib
# CLASSPATH=$LIB/activation-1.1.jar:$LIB/common-collections-3.2.1.jar:...
# java -server -cp $CLASSPATH osl.sgdo.server.SgdoExtractorServer $SERVER_ROOT/config.xml

La procédure est identique. Seule change la classe de la méthode main(), qui pour le sesd est la classe SgdoExtractorServer du paquet osl.sgdo.server.

La facon de faire est facile à transposer sous windows. Par exemple, pour le sasd :

cd %SERVER_ROOT%
set LIB=%SERVER_ROOT%/lib
set CLASSPATH=%LIB%/activation-1.1.jar;%LIB%/common-collections-3.2.1.jar;...
java -cp %CLASSPATH% osl.sgdo.server.SgdoArvhivalServer %SERVER_ROOT%/config.xml

Le fichier de configuration config.xml

Les composantes serveur du sgdebrowser sont configurées au moyen du fichier au format XML $SERVER_ROOT/config.xml. Le fichier livré dans le paquetage d'installation est reproduit ci-après. Les commentaires expliquent la signification de chaque balise. Les mentions CHANGE indiquent les valeurs devant obligatoirement être modifiées, et la mention CHECK les valeurs par défaut qui doivent être validées en fonction du contexte de l'installation.

<!--
  Les services sesd et sasd du SGDE sont configures au moyen du fichier
  $SERVER_ROOT/config.xml. On devra veiller a ce que
  les parametres identifies de la maniere suivante soient
  correctement definis.
    -Le texte CHANGE identifie dans le contenu des balises les portions
     devant etre obligatoirement modifiees.
    -Le commentaire CHECK identifie les balises dont la
     valeur par defaut peut devoir etre modifiee en fonction des
     contraintes locales
    -Les balises ayant rapport au formattage des courriels envoyes
     aux utilisateurs du sgdebrowser auront probablement a etre
     ajustees en fonction des conventions locales.

  Les balises utilisees pour designer un nom de fichier ou de repertoire peuvent
  utiliser un chemin d'acces absolu ou relatif. Une chemin d'acces relatif est
  interprete comme ayant pour racine le repertoire parent du fichier de
  configuration, normalement $SERVER_ROOT.

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

-->
<SgdeServerConfig>

  <database>
    <jdbc>
      <!-- driver : pilote de base de donnees -->
      <driver>org.postgresql.Driver</driver>
      <!-- url : paramètres de connexion a la bd PostgreSQL
           syntaxe :
               jdbc:postgresql://hostname:port/database -->
      <url>jdbc:postgresql://CHANGE:5432/CHANGE</url> <!-- CHECK port utilise par le service PostgreSQL -->
    </jdbc>
    <!-- user:      nom d'usager
         password:  mot de passe pour etablir la connexion -->
    <user>CHANGE</user>
    <password>CHANGE</password>
  </database>

  <sesd>
        <!--  port:  numero du port reseau associe au service 'sesd';
                     si on desire utiliser l'application 'sgdebrowser',
                     ce numero doit correspondre au numero de port
                     indique dans le fichier de demarrage de l'application
                            -->
    <port>30203</port> <!-- CHECK disponibilite du port -->
    <!--  usersFile: Fichier (encrypte) des usagers autorises a
                     acceder au service sesd.
                     Le chemin d'acces peut etre relatif ou absolu (voir ci-haut).  -->
    <usersFile>sesd/users</usersFile>
    <log>
            <!-- file : Repertoire et nom des fichiers de rapport.
                    Un nouveau fichier sera genere au debut de chaque mois
                    portant le nom 'sesd-aaaa-mm.log,
                    par ex.: sesd-2010-05.log
                    Utiliser "%D" pour debuter un nouveau fichier chaque jour.
                    Le chemin d'acces peut etre relatif ou absolu (voir ci-haut).
             SQL  : true pour ecrire dans le journal les commandes SQL
                    appliquees sur la bd
             exec : true pour ecrire dans le journal les commandes
                    executees par le service sesd
             read : true pour ecrire dans le journal les commandes
                    recues par le sesd (ATTENTION: peut contenir
                    de l'information sensible)

                    Toute autre valeur que 'true' est consideree 'false'.
                   -->
        <file>logs/sesd-%Y-%M.log</file>
        <SQL>false</SQL>
        <exec>true</exec>
        <read>false</read>
    </log>
    <!-- mde: Nombre maximal de fichiers de donnees pouvant etre
              obtenus dans un meme demande d'extraction -->
    <mde>50</mde> <!-- CHECK limite max sur le nombre de jeux de donnees par extraction -->
  </sesd>

  <sasd>
    <!-- port: numero du port reseau associe au service 'sasd' -->
    <port>30102</port> <!-- CHECK disponibilite du port -->
        <!-- host: machine sur laquelle fonctionne le service 'sasd'.
             ATTENTION.
             Le service 'sasd' peut fonctionner sur une
             machine differente de celle ou fonctionne le service 'sesd'.
             Toutefois, les caracteres accentues contenus dans le fichier
             'detail*.txt' risquent alors d'etre corrompus.
              -->
    <host>localhost</host>
    <!--  usersFile: Fichier (encrypte) des usagers autorises a
                     acceder au servie sasd. Ce fichier est aussi
                     appele "fichier des usagers SGDE".
                     Le chemin d'acces peut etre relatif ou absolu (voir ci-haut). -->
    <usersFile>sasd/users</usersFile>
   <log>
            <!-- file : Repertoire et nom des fichiers de rapport.
                    Un nouveau fichier sera genere au debut de chaque mois
                    portant le nom 'sasd-aaaa-mm.log,
                    par ex.: sasd-2010-05.log
                    Utiliser "%D" pour debuter un nouveau fichier chaque jour.
                    Le chemin d'acces peut etre relatif ou absolu (voir ci-haut).
             SQL  : true pour ecrire dans le journal les commandes SQL
                    appliquees sur la bd
             exec : true pour ecrire dans le journal les commandes
                    executees par le service sasd
             read : true pour ecrire dans le journal les commandes
                    recues par le sasd (ATTENTION: peut contenir
                    de l'information sensible)

                    Toute autre valeur que 'true' est consideree 'false'.
                   -->
        <file>logs/sasd-%Y-%M.log</file>
        <SQL>false</SQL>
        <exec>true</exec>
        <read>false</read>
    </log>
  </sasd>

  <archives>
    <!--  datadir: repertoire contenant les fichiers de donnees
                   (archives de donnees)
                   Le chemin d'acces peut etre relatif ou absolu (voir ci-haut). -->
    <datadir>archives</datadir> <!-- CHECK on pourrait utiliser un repertoire dev, prod, test, etc -->
    <!-- extrdir: repertoire ou sont generes les fichiers compresses
                  contenant le resultat des extractions.
                  Ce repertoire doit etre associe a l'URL specifie
                  par la balise 'extrurl', par ex. au moyen d'un
                  alias dans la configuration du serveur apache.
                  Le chemin d'acces peut etre relatif ou absolu (voir ci-haut). -->
    <extrdir>extractions</extrdir>  <!-- CHECK on pourrait utiliser un répertoire destine aux fichiers temporaires -->
    <!-- extrurl: URL menant au repertoire specifie par la balise
                  'extrdir'. Cet URL doit etre convenablement protege
                  pour y interdire le furetage. -->
    <extrurl>http://CHANGE</extrurl> <!-- ex.: http://bozo/sgde-extractions -->
  </archives>

  <filter>
    <!-- typ_jd: Les requetes impliquant la colonne 'typ_jd' des tables
                 'jeu_donnees' et 'typ_jd' ne rapporteront que les
                 lignes satisfaisant l'expression SQL. Ceci permet de
                 limiter l'acces a certains types de donnees.
                 Si cette balise est omise, aucune restriction ne sera
                 imposee. L'extracteur 'sesd' verra a encadrer
                 l'expression par des parentheses.
                 Ex.: Si on definit ainsi la balise :
                        <typ_jd>typ_jd = 'ODF_CTD' or typ_jd = 'ODF_XBT'</typ_jd>
                      toutes les selections faites sur les tables 'typ_jd' et
                      'jeu_donnees' prendront la forme :
                        SELECT ... WHERE ... AND (typ_jd='ODF_CTD' OR typ_jd='ODF_XBT');
                                                             -->
    <!-- Filtre utilise a l'IML pour interdire l'acces aux donnees brutes -->
    <!--
    <typ_jd>typ_jd NOT LIKE 'BRUTE%'</typ_jd>
    -->

    <!-- jeu_donnees : Les requetes sur la table 'jeu_donnees' doivent satisfaire l'expression
                       SQL. L'expression ne doit faire reference qu'aux seules colonnes de
                       la table 'jeu_donnees'.
                       L'extracteur 'sesd' verra a encadrer l'expression par des parentheses.
                                                             -->
    <!-- Refuser l'acces aux jeux de donnees de plus de 250K.
         L'operateur 'between' est utilise pour contourner le probleme
         pose par les caracteres '<' et '>' dans une balise XML -->
    <!--
    <jeu_donnees>vol_jd between 0 and 250</jeu_donnees>
    -->

  </filter>

  <detail>
    <!-- CHECK Verifier references au contexte local : adresses, etc -->
    <!-- La balise 'detail' permet de parametriser le contenu du fichier
         'detail*.txt' inclus dans le courriel donnant acces aux resultats
         d'une extration. Le fichier est forme de la suite de sections suivantes,
         chacune decrite par sa propre balise.
            intro:     introduction
            notes:     notes explicatives
            colHeader: entetes de colonnes
         Suivent les descriptions des fichiers de donnees retournes,
         un fichier par ligne.
         Voir cet exemple
                                 -->
    <intro>
bla bla la
    </intro>
    <notes>
bla bla bla
    </notes>
    <colHeader>
Fichier                             Coordonnée (début)  Coordonnée (fin)  Date (début)  Date (fin)  Prof. (min) Prof. (max) Mission       Type       Propriétaire    Accès     Statut
File                                Coordinate (start)  Coordinate (end)  Date (start)  Date (end)  Depth (min) Depth (max) Mission       Type       Owner           Access    Status
                                       (lat., long.)      (lat., long.)   (AAAA/MM/JJ) (AAAA/MM/JJ)     (m)         (m)     
                                                                          (YYYY/MM/DD) (YYYY/MM/DD)
----------------------------------- ------------------ ------------------ ------------ ------------ ----------- ----------- ------------- ---------- --------------- --------- ---------

    </colHeader>
  </detail>

  <mail>
    <!-- CHECK Ajuster au contexte local. Voir en particulier les balises
         <signatureSect> et <quotingSect> .
     -->
    <!-- smtpServer:  serveur SMTP pour l'acheminement des courriels-->
    <smtpServer>CHANGE</smtpServer>
    <!-- from:  adresse courriel de l'envoyeur -->
    <from>CHANGE</from>
    <!-- msg: La balise 'msg' permet de parametriser le contenu du message
              achemine a l'utilisateur pour lui donner acces aux
              resultats d'une extraction.
              Le message est compose des sections suivantes, chacune decrite
              par sa propre balise.
                subject:       objet du message
                topLine:       lignes d'introduction precedant les criteres de recherche
                spatialSect:   entete des criteres de recherche spatiaux
                temporalSect:  entete des criteres de recherches temporels
                depthSect:     entete des criteres de recherche sur la profondeur
                missionSect:   entete des criteres de recherche sur le smissions
                areaSect:      entete des criteres de recherche sur les zones
                datatypeSect:  entete des criteres de recherche sur le type de donnees
                keywordSect:   entete des criteres de recherche sur les mots-cle
                detailSect:    explications relatives a l'acces aux fichiers de resultats
                quotingSect:   notes sur la facon de citer les resultats
                noDataSect:    texte écrit si aucune donnée n'a pu être retournée
                signatureSect: signature du message

               Voir cet exemple.
                                                              -->
    <msg>
      <subject>Extracteur SGDE / EDMS Extractor</subject>
      <topLine>
Résultats de l'extraction SGDE / EDMS Extraction Results

Critères de recherche utilisés / Search criteria used :
      </topLine>
      <spatialSect>Références spatiales / Spatial references :</spatialSect>
      <temporalSect>Références temporelles / Temporal references :</temporalSect>
      <depthSect>Profondeurs (m) / Depths (m) :</depthSect>
      <missionSect>Missions :</missionSect>
      <areaSect>Zones / Areas :</areaSect>
      <datatypeSect>Types de jeux de données / Data types :</datatypeSect>
      <keywordSect>Mots-clés : Keywords :</keywordSect>

      <detailSect>
bla bla bla
      </detailSect>

      <quotingSect>
bla bla bla
      </quotingSect>

      <noDataSect>
bla bla bla
      </noDataSect>

      <signatureSect>
bla bla bla
      </signatureSect>

    </msg>
  </mail>

</SgdeServerConfig>