Configurer son site

Pour que Greenstone puisse fonctionner correctement, il faut mettre en place les droits d'accès à certains fichiers. On trouve aussi un fichier de configuration associé à chaque site Greenstone. La procédure d'installation crée un fichier de configuration générique qui repose sur les choix effectués durant l'installation, mais son contenu peut être adapté à différentes situations. La présente section détaille ces deux questions.

Droits d'accès aux fichiers

La présente section ne concerne par les utilisateurs de Windows 95/98, car leurs systèmes d'exploitation n'identifient pas les propriétaires des fichiers.

Sous Windows NT et 2000 ainsi que sous les systèmes Unix, les scripts CGI ne sont pas exécutés avec des droits d'utilisateurs normaux, car il n'est pas possible d'identifier les utilisateurs sur le web. Ils sont plutôt exécutés au nom de l'utilisateur qui a démarré le serveur web (sur les systèmes de type Windows), ou au nom d'un utilisateur particulier (souvent appelé nobody sur les systèmes Unix). C'est pourquoi tous les fichiers et répertoires contenus dans l'arborescence C:\Program Files\gsdl doivent être lisibles par tous (ou en tout cas lisibles par l'utilisateur des scripts CGI, qui peut être nobody). Pour tester la bonne mise en place des permissions sur les fichiers, exécutez le programme library.exe depuis l'interpréteur de commandes. Si les fichiers se trouvent aux bons endroits mais que les permissions sont incorrectes, il fonctionnera correctement depuis l'interpréteur de commandes. Cette situation est à comparer à l'exécution depuis un navigateur web, où il est alors exécuté avec les droits de l'utilisateur nobody, situation qui devrait échouer en cas de droits incorrects. Un autre test consiste à l'exécuter au nom d'un autre utilisateur après s'être connecté en tant que tel, pour vérifier si les droits d'accès aux fichiers sont spécifiques au compte utilisateur original.

Pour fonctionner depuis un navigateur web, tous les répertoires de Greenstone doivent être lisibles par tous. Le répertoire C:\Program Files\gsdl\etc et son contenu doivent de même être inscriptibles par tous. Il s'agit du répertoire où le programme library inscrira les journaux d'utilisation, d'erreur et d'initialisation, ainsi que diverses bases de données utilisateur. Si vous êtes réticent à rendre ce répertoire inscriptible par tous, mettez en place des permissions de sorte que seuls les fichiers errout.txt, initout.txt, key.db, users.db, history.db, et usage.txt soient inscriptibles par l'utilisateur CGI.

Si les droits d'accès sous le répertoire C:\Program Files\gsdl\etc sont incorrects, vous remarquerez peut-être que l'authentification des utilisateurs et la recherche dans l'historique ne fonctionneront pas, ainsi que l'absence de génération du journal d'utilisation (usage.txt).

Le fichier de configuration gsdlsite.cfg

La procédure d'installation crée un fichier de configuration de Greenstone générique qui repose sur les choix effectués durant l'installation. Dans le cas de notre installation c'est C:\Program Files\gsdl\cgi-bin\gsdlsite.cfg, dont voici le contenu:

# Site configuration file for Greenstone.
# Lines begining with
# are comments.
# This file should be placed in the same directory as your library
# executable file. it should be edited to suit your site.
# points to the GSDLHOME directory
gsdlhome “C:/Program Files/gsdl ”
# this is the http address of GSDLHOME
# if your webservers DocumentRoot is set to $GSDLHOME
# then httpprefix can be commented out
httpprefix /gsdl
# this is the http address of the directory which
# contains the images for the interface.
httpimg /gsdl/images
# should contain the http address of this cgi script. This
# is not needed if the http server sets the environment variable
# SCRIPT_NAME
#gwcgi         /cgi-bin/library
# maxrequests is the most requests a fastcgi process
# will serve before it exits. This can be set to a
# low figure (like 1) while debugging and then set
# to a high figure (like 10000) when everything is
# working well.
#maxrequests 10000

Vous pouvez personnaliser votre installation en éditant ce fichier, mais il est peu probable que vous en éprouviez le besoin.

La ligne gsdlhome pointe tout simplement vers le répertoire C:\Program Files\gsdl.

httpprefix est l'adresse web du répertoire où Greenstone est installé. Nous avons expliqué plus haut comment créer un alias de manière que les URL de la forme http://localhost/gsdl/… soient recherchées dans le répertoire C:\Program Files\gsdl. Placer la ligne httpprefix/gsdl dans le fichier de configuration gsdlsite met en place les mêmes conventions pour le logiciel Greenstone.

httpimg est l'adresse web de C:\Program Files\gsdl\images, répertoire qui contient toutes les images (au format GIF) utilisées par l'interface. Dans toutes les installations standard de Greenstone ce sera httpprefix/images, et vous n'interviendrez pas sur cette ligne.

gwcgi est l'adresse web du programme CGI library. La plupart des serveurs web (dont Apache) n'en ont pas besoin, et cette ligne doit alors rester commentée, donc inactive. N'ôtez le commentaire que si vous êtes sûr de vous, car cela peut poser certains problèmes.

maxrequests n'est utilisé que par les versions de Greenstone qui ont activé l'option «Fast-CGI» lors de la compilation. La distribution binaire standard n'inclut pas cette option, car tous les serveurs web ne sont pas configurés de manière compatible. L'option «Fast-CGI» accélère l'exécution des scripts CGI en gardant l'exécutable principal en mémoire entre deux invocations du logiciel, au lieu de le charger depuis le disque dur à chaque requête d'une page web depuis le logiciel Greenstone. Le compromis à trouver est un équilibre avec la quantité de mémoire utilisée, qui peut augmenter si le programme demeure longtemps en mémoire. Après la génération de maxrequests pages web, le programme CGI rend la main, libérant ainsi toute la mémoire accumulée. Pour répondre à la prochaine requête provoquée par une page web, le programme CGI est alors relu depuis le disque dur, et un nouveau cycle de requêtes de pages démarre. La plupart des installations utilisent le protocole standard CGI, ce qui signifie qu'on peut ignorer sans crainte le paramètre maxrequests.