Project:Omega.org

Note : Dans son article précédent, Serveur Apache sous Mac OS X : Partie 1, Kevin Hemenway vous a montré comment faire tourner facilement un serveur de pages web à partir de votre ordinateur Mac OS X. Dans cet article, il explore le monde des accès CGI. Pour tirer profit au maximum de ce que Kevin vous offre ici, vous aurez besoin de connaître un peu l’application Terminal. Si vous n’avez pas exploré cette application, je vous recommande de lire notre article, Le Terminal de Mac OS X : Partie 1. Une fois que vous serez à l’aise avec la ligne de commande, vous pourrez revenir ici et en savoir plus sur Apache.

En apprendre un peu plus sur Apache

Après le travail que nous avons fait dans le précédent article, nous avons maintenant une URL plus sympathique, mais toujours un site assez ennuyeux. Nous avons besoin de fonctionnalités pour impressionner le patron et pour les avoir nous devons commencer à jouer avec le Terminal. Nous allons supposer que vous savez comment éditer et sauvegarder des fichiers via la ligne de commande, ou par un éditeur natif du shell (comme vi ou emacs) ou via un éditeur GUI comme BBEDIT ou TextEdit. Nos exemples ci-dessous seront basés sur BBEDIT 6.5 et son utilitaire shell.

Avant que nous n’ajoutions les fonctionnalités supplémentaires, nous devons savoir où se trouve le fichier de configuration d’Apache. Pour le découvrir, nous interrogerons le serveur Apache lui-même, avec la ligne de commande suivante :

httpd -V

Cela va provoquer l’apparition d’un écran d’information spécifique à votre installation d’Apache (cela marche avec n’importe quelle installation d’Apache — pour le Mac, Linux, ou Windows). Sur une machine OS X 10.1.1, nous découvrons que nous employons Apache 1.3.20 (dans la mise à jour 10.1.2, Apache a été mis à niveau en 1.3.22) :

Server version: Apache/1.3.20 (Darwin)

Nous découvrons aussi où se trouve le fichier de configuration :

-D SERVER_CONFIG_FILE=”/etc/httpd/httpd.conf”

Et nous découvrons aussi deux informations utiles :

-D DEFAULT_XFERLOG=”/var/log/httpd/access_log”
-D DEFAULT_ERRORLOG=”/var/log/httpd/error_log”

Ce sont les fichiers log d’Apache — chaque demande et chaque message d’erreur seront inscrits dans ces logs. Vous les trouverez follement utiles pour la mise au point, et aussi pour vous assurer que nos prochaines fonctionnalités fonctionnent correctement.

Etude des accès CGI

Il est temps maintenant de jouer avec la fonctionnalité la plus commune disponible sur un serveur de web : CGI. Sans devenir excessivement ésotérique, CGI nous permet d’installer des milliers de scripts différents qui peuvent être accédés par un navigateur web normal. Les scripts CGI sont souvent écrits en Perl (aussi installé par défaut) et peuvent permettre aux utilisateurs d’avoir accès aux bases de données, utiliser des écrans interactifs, bavarder (chat) , etc.

Apache est livré avec deux scripts simples qui peuvent vérifier que CGI est configuré correctement. Avant que nous ne les testions, voyons ce que nous pouvons apprendre du fichier de configuration d’Apache. Pour commencer, ouvrez votre fichier config dans votre éditeur de texte préféré (l’exemple ci-dessous suppose l’utilisation de BBEDIT 6.5) :

bbedit /etc/httpd/httpd.conf

Si vous ne disposez pas de l’utilitaire shell de BBEdit, utilisez alors TextEdit de la manière suivante :

sudo open -a TextEdit /etc/httpd/httpd.conf

Avertissement : le fichier de configuration d’Apache est assez grand, mais aussi bien documenté. Lisez l’avertissement mis en introduction avec attention : “ne lisez pas simplement les instructions … sans comprendre ce qu’elles font. Elles sont ici seulement en tant que allusions ou rappels. Si vous n’êtes pas certains, consultez les docs en ligne. Vous avez été avertis.” Pour votre information, ces docs en ligne sont disponibles sur Le site web d’Apache.

La façon la plus rapide d’apprendre le fichier de configuration d’Apache est de chercher la particularité que vous voulez activer. Dans notre cas, nous commencerons par chercher “CGI”. La première entrée que nous trouvons est :

LoadModule cgi_module libexec/httpd/mod_cgi.so

Suivie bientôt par :

AddModule mod_cgi.c

Vous verrez un certain nombre de ces lignes dans le fichier config d’Apache. Si vous n’avez jamais travaillé avec un programme à module d’extension, vous reconnaîtrez facilement leur but — ces lignes chargent des fonctionnalités différentes dans le serveur web Apache. Apache appelle ces “modules” et vous verrez que beaucoup de noms de module commencent par mod _, comme mod_perl et mod_php. Les lignes qui sont en commentaires (c’est-à-dire les lignes qui commencent par le caractère #) sont inactives.

Parce que nos lignes CGI sont déjà activées, nous continuerons à scruter :

ScriptAlias /cgi-bin/ “/Library/WebServer/CGI-Executables/”
<Directory “/Library/WebServer/CGI-Executables”>
AllowOverride None
Options None
Order allow,deny
Allow from all
</Directory>

La directive ScriptAlias nous permet de diriger une URL vers un emplacement de notre disque dur. Dans ce cas, Apache dirige http://127.0.0.1/cgi-bin/ vers le dossier /Library/WebServer/CGI-Executables/. Si vous examinez ce dossier maintenant, vous verrez les deux scripts CGI que j’ai mentionnés auparavant : printenv et essai-cgi. Le <Directory> n’est pas si important pour l’instant, donc nous continuerons d’examiner le fichier de config :

* AddHandler cgi-script .cgi

Là est votre première importante décision concernant votre installation d’Apache. Quand un répertoire donné a été “ScriptAliasé” (comme notre répertoire CGI-Executables, ci-dessus), les fichiers de ce répertoire sont toujours considérés comme des scripts CGI. Si les fichiers ont été sortiss de ce répertoire (disons, vers notre répertoire DocumentRoot), ils seraient considérés alors comme des fichiers texte normaux.

En rendant ces lignes actives (suppression du “#”), vous dites à Apache d’exécuter n’importe quel fichier qui se termine par .cgi. Cela peut arriver à partir de n’importe quel répertoire et pour n’importe quel utilisateur, ceci est rarement conseillé d’un point de vue sécurité.

Dans une installation par défaut d’Apache sur Mac OS X, les scripts CGI sont seulement permis dans le répertoire /Library/Webserver/CGI-Executables/. En activant la ligne ci-dessus (en enlevant le “#”) cela permet aux scripts CGI d’être exécutés à partir de n’importe quel répertoire utilisateur, comme /Users/morbus/Sites. Dans notre cas, parce que nous n’employons pas les répertoires Utilisateur (parce qu’ils créent de bien laides URL pour notre intranet), nous allons laisser cette ligne en commentaire.

Si les accès CGI sont déjà actifs, nous devrions être capables d’atteindre http://127.0.0.1/cgi-bin/test-cgi et voir un heureux résultat, vrai ? Si vous êtes allés à cette URL, cependant, vous avez été probablement accueilli par un message beaucoup moins agréable : “FORBIDDEN”. Apache crie : “Vous n’avez pas la permission d’accéder à /cgi-bin/test-cgi”.

Hein ? Pourquoi cela n’a t’il pas marché ? Il est temps maintenant de voir combien les logs d’Apache peuvent s’avérer utiles. Si vous vous rappelez les résultats de la commande httpd-V ci-dessus, le fichier d’accès d’Apache est placé dans le répertoire /var/log/httpd/access_log. Regardons les dernières lignes de ce fichier, que nous pouvons facilement atteindre avec cette commande : tail /var/log/httpd/access_log

Vous verrez que les dernières lignes ressemblent à celles-ci :

127.0.0.1 - - [19/Nov/2001:21:59:46-0500]
“GET /cgi-bin/test-cgi HTTP/1.1″ 403 292

Rapidement, cette ligne montre où la demande d’accès est intervenue (127.0.0.1), le moment où le fichier a été demandé, le protocole employé (HTTP/1.1), le code retour (403) et la taille de la réponse (292 octets). Ceci est très bien, mais ne nous dit pas ce qui a mal tourné. Pour cela, nous allons parcourir notre fichier log :

tail /var/log/httpd/error_log

Et nous voyons :

[Mon Nov 19 21:59:46 2001] [error] [client 127.0.0.1]
file permissions deny server execution:
/Library/WebServer/CGI-Executables/test-cgi

Bingo ! Cela nous dit exactement ce qui s’est mal passé — les autorisations du fichier étaient incorrectes. Pour qu’Apache puisse exécuter un script CGI, le script en question doit avoir des autorisations d’exécution. Pour donner au fichier essai-cgi les autorisations correctes, nous tapons :

cd /Library/WebServer/CGI-Executables
chmod 755 test-cgi

Après avoir effectué ce que nous avons vu au-dessus, rechargez l’URL et vous devriez être chaleureusement salués par plein d’informations environnementales. (Pour en savoir plus sur les autorisations, l’utilitaire chmod et l’environnement du serveur, consulter votre moteur de recherche préféré, votre serviteur, ou la librairie d’O'Reilly).

Avec les bases de CGI maintenant apprises, vous pouvez maintenant installer des applications CGI pour compléter votre intranet. Vous avez besoin d’un gestionnaire de contenus pour que les développeurs tiennent tout le monde informé de leurs avancées et de leurs discussions ? Essayez Movable Type.

Activation des inclusions côté serveur

Les inclusions côté serveur, mieux connues sous le nom SSI, vous permettent d’inclure le contenu d’autres fichiers ou de scripts dans la page actuellement générée par le serveur. C’est Apache qui s’en charge avant que la page ne soit montrée à l’utilisateur — ils ne sauront jamais ce que vous avez inclus.

Généralement, les SSI sont employés pour inclure des en-têtes, des pieds de page et des fonctions du genre “Quoi de neuf ?” sur un site entier. Quand vous devez changer la couleur de fond de votre site, par exemple, vous pouvez changer le fichier d’en-tête seulement et la couleur sera immédiatement changée là où vous aurez inclus le fichier.

Par défaut, les SSI, ne sont pas activés. Pour les réactiver, nous allons employer le même “recherche de fonctionnalité” qu’auparavant. Ouvrez votre fichier de configuration Apache et recherchez “server side“. Notre unique résultat sera le suivant :

# To use server-parsed HTML files
#
# AddType text/html .shtml
# AddHandler server-parsed .shtml

Par chance, c’est exactement que nous cherchions. Ces deux simples lignes d’ajout nous en disent beaucoup. Elles établissent un modèle basé sur ce que nous savions déjà avec les CGI. Si vous vous rappelez ce que nous avons vu sur les CGI, nous aurions pu activer la fonctionnalité de CGI pour des fichiers finissant par .cgi — autrement dit, n’importe quel fichier que vous auriez créé avec l’extension .cgi (que ce soit un programme CGI ou pas), serait traité comme un script exécutable.

De même, ces lignes nous disent que nous pouvons activer les inclusions côté serveur pour des fichiers finissant par .shtml. Même Si le fait d’employer en réalité cette fonctionnalité SSI dans ces fichiers n’importe pas — ils seraient toujours traités comme ils l’ont été jusqu’à présent.

Ceci est important. Vous devez vous dire “si les SSI sont si bien faits, pourquoi pas s’en servir pour des noms de fichier en .html ?” En fin de compte, c’est une question de vitesse. Si vous avez 3,000 fichiers .html et que seulement 1,000 d’entre eux exploitent les SSI, Apache cherchera toujours des instructions SSI dans les 2000 autres. C’est une perte de ressources. D’accord, le traitement des SSI ne nécessite que peu de ressources, mais si vous êtes touchés 50,000 fois par seconde, il se peut que l’addition soit lourde. Ce n’est pas trop inquiétant pour notre intranet, mais il est bon de le savoir pour votre futur projet Apache.

Pour le moment, oter les commentaires des lignes AddType et AddHandler. Cela activera les SSI. Oui, mais où ? Quand nous avons fait connaissance avec les CGI, nous avons vu une configuration indiquant que nos CGIs résidaient dans /Library/Webserver/CGI-Executables/ — nous devons maintenant dire à Apache où nous voulons mettre en place notre fonctionnalité SSI.

C’est parce que nous construisons un intranet, qui va vivre dans /Library/Webserver/Documents, que nous voulons que notre fonctionnalité SSI y soit activée. Allez au début de votre fichier de configuration Apache et recherchez “/Library/Webserver/Documents/“. Le deuxième résultat de cette recherche ressemble à cela (nous avons enlevé les lignes de commentaires dans cet exemple) :

<Directory “/Library/WebServer/Documents”>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>

Vous remarquerez que cela ressemble à l’entrée <Directory> que nous avons vue quand nous examinions les CGI. Comme auparavant, nous allons en sauter le principal (nous prêterons attention à ces lignes un peu plus tard dans notre série). Pour le moment, ajoutez juste le mot Includes à la ligne Options. Options est une directive Apache qui peut activer ou désactiver des fonctionnalités différentes pour le <Directory> et tous les sous-répertoires inclus. Les sous-répertoires peuvent ignorer la configuration de leur parent.

Parce que nous avons fait des changements au fichier de configuration d’Apache, nous devons maintenant relancer Apache. La façon la plus simple est d’aller dans le tableau de bord “Partage“. De la même manière que nous avons activé les préférences de partage dans la première partie de cette série, nous pouvons arrêter et démarrer pour que nos changements soient pris en compte. Faites cela maintenant.

Pour tester que nos SSI fonctionnent correctement, renommez votre fichier index.html en index.shtml (parce que .shtml est la seule extension que nous avons autorisée pour les SSI) et éditez le de façon à ce qu’il corresponde de correspondre à l’extrait ci-dessous :

<html>
<body>
<h1>Gleefully Served By Mac OS X</h1>
<pre><!–#include virtual=”/cgi-bin/test-cgi”–>
</pre>
</body>
</html>

Là, nous avons inclu le script CGI de test dans le contenu de notre page principale. Quand vous chargez http://127.0.0.1/ dans votre navigateur, vous voyez apparaître le message “Gleefully Served”, en même temps que l’affichage du script CGI lui-même. Nous aurions pu aussi facilement créer une page web statique (disons, “navigation.html“) et l’inclure dans notre page à la place.

SSI est configuré et fonctionne, mais que pouvez-vous faire avec cela ? Et si votre département marketing voulait créer une galerie d’images avec les annonces les plus récentes ? C’est assez facile en se référant à l’article Galerie d’Images SSI, aussi écrit par votre serviteur.

Dans mon article suivant, je vous montrerai comment activer PHP. En attendant, bonne chance avec CGI.

Textes originaux en anglais sur O’Reilly : Apache Web Server par Kevin Hemenway

Thierry Serveurs Web apache, Mac OS X, réseau, serveur web