WEBMESTRE : CONCEPTION DE SITES ET ADMINISTRATION DE SERVEURS WEB

Transcription

1 WEBMESTRE : CONCEPTION DE SITES ET ADMINISTRATION DE SERVEURS WEB Installation et administration d un serveur web Module TP A5 (1/2 valeur) Chapitre 9 Apache et scripts CGI

2 Le plus grand soin a été apporté à la réalisation de ce support pédagogique afin de vous fournir une information complète et fiable. Cependant, le Cnam Champagne-Ardenne n'assume de responsabilités, ni pour son utilisation, ni pour les contrefaçons de brevets ou atteintes aux droits de tierces personnes qui pourraient résulter de cette utilisation. Les exemples ou programmes présents dans cet ouvrage sont fournis pour illustrer les descriptions théoriques. Ils ne sont en aucun cas destinés à une utilisation commerciale ou professionnelle. Le Cnam ne pourra en aucun cas être tenu pour responsable des préjudices ou dommages de quelque nature que ce soit pouvant résulter de l'utilisation de ces exemples ou programmes. Tous les noms de produits ou autres marques cités dans ce support sont des marques déposées par leurs propriétaires respectifs. Ce support pédagogique a été rédigé par Michel Melcior, enseignant vacataire au Cnam Champagne-Ardenne. Copyright Centre d'enseignement A Distance du Cnam Champagne-Ardenne. Tous droits réservés. Toute reproduction, même partielle, par quelque procédé que ce soit, est interdite sans autorisation préalable du Cnam Champagne-Ardenne. Une copie par xérographie, photographie, film, support magnétique ou autre, constitue une contrefaçon passible des peines prévues par la loi, du 11 mars 1957 et du 3 juillet 1995, sur la protection des droits d'auteur.

3 APACHE ET SCRIPTS CGI (COMMON GATEWAY INTERFACE) 1. OBJECTIFS En fin de séance, vous devriez être capable : De gérer les droits d'exécution des scripts CGI sur votre serveur. 2. INTRODUCTION. Les scripts CGI (en Français, interface de passerelle commune) servent bien souvent à traiter des données issues de formulaires placés sur des pages HTML. L'exécution du script CGI se fait côté serveur. Du point de vue d'apache, un script CGI est un programme externe (C, C++, Bash, Perl ) qui sera appelé par le serveur. Un client, via un navigateur web, entre comme requête une url se terminant par un script cgi. Par exemple, le client invoque l'url Apache (avec son identité) va alors exécuter le programme compteur.cgi. Comme le ferait un utilisateur en ligne de commande. Si ce programme est écrit en Perl, une session de l'interpréteur Perl va être démarré et le programme exécuté. S'il est écrit en bash, une session bash va exécuter les commandes. S'il a été compilé (C, C++) il va être directement exécuté. Si l'on prend le cas de Perl, à chaque appel du script une session de l'interpréteur Perl doit être démarrée. Si l'on prend la rapidité comme critère de qualité de service, ce mode de fonctionnement n'est pas celui qui donnera les meilleures performances. C'est pourquoi un module interpréteur du langage Perl, intégré à Apache, existe. Nous reparlerons des modules interpréteurs à la fin de ce cours. 3. LES DIRECTIVES DE CONTROLE DES CGI. La directive ScriptAlias permet déclarer un répertoire particulier destiné à contenir les scripts cgi. Syntaxe : ScriptAlias [url-chemin] [répertoire] Contexte : configuration serveur, hôtes virtuels Module : mod_alias Exemple : ScriptAlias /cgi-bin/ /var/www/cgi-bin/ Mais cette directive ne suffit pas, il faut également donner le droit (Apache) aux scripts présents d'être exécutés dans ce répertoire. On va donc utiliser la classique directive Directory, avec l'option ExecCGI. Par exemple : <Directory /var/www/cgi-bin> AllowOverride None Options ExecCGI Order Allow,Deny Installation et administration d un serveur web 1

4 Allow From All </Directory> A présent, la requête aura pour résultat l'exécution du script /var/www/cgi-bin/prog par le serveur. Bien entendu, le fichier prog doit être réellement exécutable (script shell ou Perl, programme compilé), avec les droits UNIX correctement positionnés. Les programmes CGI sont toujours une source potentielle de tracas pour l'administrateur du serveur. S'ils sont mal écrits, ils peuvent devenir des trous de sécurité. C'est pourquoi la majorité des administrateurs de sites utilisent la méthode qui vient d'être décrite pour centraliser tous les scripts dans un seul répertoire. Il est alors plus facile de surveiller ce qui est mis à la disposition des clients du serveur. Toutefois, il est possible de placer également des scripts en dehors du répertoire défini par ScriptAlias. Il faut alors utiliser la directive AddHandler. Elle permet, en fonction de l'extension du fichier, d'associer un gestionnaire spécifique appelé handler qui assurera le traitement de ce fichier. Les handlers peuvent soit être implémentés à l'intérieur du serveur sous forme de module, ou être ajoutés par la directive Action. Les handlers intégrés dans la distribution standard d'apache sont les suivants : send-as-is : Envoie les fichiers avec leurs en-têtes HTTP tels quels. (mod_asis) cgi-script : Traite le fichier comme un script CGI. (mod_cgi) imap-file : Fichier de règles de mapping d'images. (mod_imap) server-info : Obtient les informations de configuration du serveur. (mod_info) server-parsed : Interprète les inclusions dynamiques (Server-Side Includes). (mod_include) server-status : Obtient les informations d'état du serveur. (mod_status) type-map : Active la négociation de contenu. (mod_negotiation) Directive : AddHandler Syntaxe : AddHandler [nom-handler] [extension] [extension]... Contexte : configuration serveur, hôtes virtuels, répertoire,.htaccess Module : mod_mime Compatibilité : AddHandler est disponible à partir de la version 1.1 d'apache Pour activer des scripts CGI écrits dans des fichiers d'extension ".cgi", vous écrirez donc: AddHandler cgi-script cgi Une fois que cette ligne a été écrite dans votre fichier de configuration d'apache, tout fichier dont le nom termine par ".cgi" sera considéré comme un programme CGI. Il sera exécuté si : Il s'agit réellement d'un fichier exécutable dont les droits UNIX sont correctement positionnés. Le répertoire où se trouve ce script a été déclaré dans une directive Directory avec l'option ExecCGI. C'est le module mod_cgi qui sera chargé d'exécuter votre script. Entre autres choses, il met à la disposition de votre de script des variables appelées variables d'environnement. Apache et scripts CGI 2

5 Voici quelques-unes de ces variables, à titre d'exemple : SERVER_NAME REQUEST_METHOD REMOTE_ADDR contient le nom complet (FQDN) du serveur Apache. La méthode utilisée pour la requête par le client. Pour HTTP: "GET", "HEAD", "POST" L'adresse IP du client. REMOTE_USER Si vous avez mis en place un mécanisme d'authentification, le nom de l'utilisateur à l'origine de la requête. HTTP_USER_AGENT Le nom du navigateur du client. Pour plus de détails, il faut consulter les documentations du module mod_cgi. Le déboguage de scripts CGI est traditionnellement laborieux, en grande partie parce qu'il est difficile d'accéder aux sorties standard (stdout et stderr) des scripts qui ne fonctionnent pas correctement. Ces directives, inclues à partir de la version 1.2 d'apache, permettent une trace plus fine des erreurs lorsqu'elles surviennent. Lorsqu'elle est configurée, la fonction de trace d'erreurs CGI trace tout CGI qui ne s'exécute pas correctement. Chaque script CGI qui échoue provoque l'écriture d'un certain nombre de lignes dans le fichier de trace. Les deux premières lignes sont toujours sous le format : %% [temps] ligne-requête %% HTTP-status nom-fichier-script-cgi Dans le cas où le script CGI ne peut pas du tout être exécuté, la trace contiendra deux lignes supplémentaires : %% error message-d'erreur Par contre, si l'erreur résulte de l'envoi par le script de mauvaises en-têtes (souvent dues à un bug interne), les informations suivantes sont enregistrées : %request Tous les champs d'en-tête de requête HTTP reçus, entité POST ou PUT (suivant le cas). %response Tous les champs d'en-tête générés par le script CGI %stdout La sortie standard du CGI %stderr La sortie d'erreur standard du script CGI (Les parties %stdout et %stderr peuvent ne pas apparaître si le script n'a rien généré ni sur la sortie standard, ni sur la sortie d'erreur). Directive : ScriptLog Syntaxe : ScriptLog [nomfichier] Défaut : Aucun Statut : mod_cgi La directive ScriptLog définit le fichier de trace des erreurs CGI. Installation et administration d un serveur web 3

6 Attention, si aucune directive ScriptLog n'est définie, les erreurs ne sont pas tracées. Par contre, si vous invoquez cette directive, toute erreur CGI est enregistrée dans le fichier défini par l'argument nomfichier. Ce fichier peut être défini par son chemin d'accès absolu, ou relativement à la racine ServerRoot. Cette trace sera ouverte au nom de l'utilisateur qui est utilisé par le processus fils Apache comme identité pour être exécuté. C'est-à-dire, l'utilisateur spécifié par la directive User principale. Ceci suppose que le répertoire dans lequel se situe cette trace ait les droits d'écriture définis pour cet utilisateur, à moins que le fichier de trace correspondant n'ait été créé manuellement et rendu inscriptible pour cet utilisateur. Si vous placez la trace de scripts dans votre répertoire principal des traces, ne changez pas les permissions sur ce répertoire pour attribuer des droits d'écriture à l'utilisateur qui est utilisé par le processus fils Apache comme identité. Notez que la trace des scripts doit rester essentiellement un outil de déboguage lors de l'écriture de scripts CGI, et n'est pas sensée être laissée active en permanence sur des serveurs en opération. Elle n'est ni optimisée en vitesse ni en efficacité, et peut provoquer des problèmes relatifs à la sécurité si elle est utilisée à un autre usage que ce pour quoi elle a été instaurée. 4. TRAVAIL PERSONNEL. Lors de la séance précédente, vous aviez déclaré /home/virtuweb comme racine des documents de votre serveur virtuel "virtuweb". Nous allons maintenant créer le répertoire /home/cgi-bin et utiliser ce répertoire pour stocker les scripts cgi du serveur. 1. Créez le répertoire /home/virtu/cgi-bin et configurez votre serveur pour que ce répertoire devienne le répertoire des scripts cgi. 2. Vous allez recopier le script Perl suivant dans ce répertoire. Appelez ce script essai1. Pensez à lui donner des droits d'exécution (chmod +x essai1). #!/usr/bin/perl w use CGI qw(:standard); print header, start_html("essai1"), h1("hello world"); 3. Essayez votre script qui devrait être disponible à l'url : nom de serveur]/cgi-bin/essai1. Vous devriez voir apparaître une page html avec le titre "essai1" contenant le texte "hello world" en gros caractères. Vous allez vite remarquer que le dépannage d'un script CGI peut devenir pénible... Je vous conseille, si c'est possible, d'exécuter au préalable et sans Apache vos scripts. Par exemple, placez vous dans le répertoire contenant le programme essai1. Puis entrez :./essai1 Perl attend des paramètres en mode offline, il suffit de terminer avec la séquence CTRL+D. Si le résultat est concluant (code HTML), il a des chances de fonctionner sous Apache. 4. Vous pouvez maintenant essayer ce script que vous appellerez essai2. Apache et scripts CGI 4

7 #!/usr/bin/perl w use CGI qw(:standard); my $pre=param("prenom"); if ($pre) { print header, start_html("essai2"), h1("bonjour $pre"); } else { print header, start_html("essai2"), h1("vous avez oublié d'ajouter?prenom=.. à l'url"); }; Ce programme attend une URL du type : Où l'on passe le paramètre prenom au script (généralement par un formulaire HTML). Vous pouvez tester ce script et créer la page HTML avec le formulaire adapté. 5. LES MODULES INTERPRETEURS INTEGRES A APACHE. Le principal défaut de la méthode d'appel des scripts nécessitant un interpréteur que nous venons de voir est une certaine lenteur. Ceci est dû à la durée de chargement de l'interpréteur pour chaque appel de script. C'est pourquoi des modules interpréteurs (PHP, ASP, Perl ) ont été écrits pour Apache. Ils ne sont chargés qu'une fois et l'exécution des scripts est accélérée. L'exécution d'un script (PHP, Perl) par un module interpréteur n'est pas soumise aux mêmes conditions que l'exécution d'un script par un interpréteur externe à Apache. Pour PHP, c'est l'extension du fichier de script qui détermine l'appel du module. Par exemple, les fichiers.php et.php3 seront traités par le module php : Addtype application/x-httpd-php.php Addtype application/x-httpd-php.php3 Pour Perl, il faut définir un emplacement où les scripts Perl doivent se trouver. Par exemple : <IfModule mod_perl.c> Alias /perl/ /home/perl/ <Location /perl> SetHandler perl-script PerlHandler Apache::Registry Options +ExecCGI </Location> </IfModule> Si le module mod_perl est installé, alors les scripts Perl placés dans /home/perl seront exécutés par mod_perl. Les scripts seront accessibles à l'url : du script]. Installation et administration d un serveur web 5

8 6. RESUME. Le tableau ci-dessous (à compléter par vos soins) résume les notions abordées dans cette séance. Directive Apache Fonction ScriptAlias ExecCGI AddHandler ScriptLog 7. ELEMENTS DE CORRECTION. NameVirtualHost <VirtualHost > ServerAdmin DocumentRoot /home/virtuweb ScriptAlias /cgi-bin /home/virtu/cgi-bin ScriptLog logs/ virtu-error-cgi ServerName virtuweb ErrorLog logs/ virtu-error_log CustomLog logs/ virtu-access_log common </VirtualHost> <Directory /home/virtu/cgi-bin> Options ExecCGI Order allow,deny Allow from all </Directory> Apache et scripts CGI 6