Astuces dédiées à l'application VHCS 2 «  

VHCS Astuce : Exécution de scripts CGI dans le répertoire htdocs...

Posted by M. declercq on Jul. 13 2006, page edited by M. declercq on Mar. 22, (popular)  
Tags: vhcs exécution programmes cgi htdocs

I. Le pourquoi de ce tutorial:

Lorsque vous installez l'application VHCS 2 et que vous créez des domaines et sous-domaines via l'interface d'administration de cette application, les scripts (programmes) CGI, si actifs, peuvent êtres exécutés qu'à partir d'un répertoire bien particulier. Il s'agit du répertoire /cgi-bin qui se situe en dehors de l'arborescence Web de l'utilisateur.

Pour exemple, si vous créez le domaine nuxwin.com à partir de l'interface d'administration de l'application VHCS 2, cela créra l'arborescence suivante :

/var/www/virtual/nuxwin.com
/var/www/virtual/nuxwin.com/htdocs
/var/www/virtual/nuxwin.com/cgi-bin
/var/www/virtual/nuxwin.com/logs
/var/www/virtual/nuxwin.com/errors

Remarque concernant l'arborescence Web :

Seul le répertoire htdocs fait parti de l'arborescence Web (Il s'agit du répertoire Web racine).

Comme vous le voyez, nous retrouvons bien notre réperoire /cgi-bin à partir duquel les programmes CGI peuvent être éxécutés, ce dernier se trouvant, comme indiqué précédement, en dehors de l'arborescence Web.

Pour un sous-domaine, vous obtiendrez l'arborescence suivante :

Exemple pour le sous-domaine dev.nuxwin.com :

/var/www/virtual/nuxwin.com/dev
/var/www/virtual/nuxwin.com/dev/htdocs
/var/www/virtual/nuxwin.com/dev/cgi-bin

Là encore, nous retrouvons bien le répertoire /cgi-bin à partir duquel les scripts (programmes) CGI peuvent êtres exécutés.

Ps : La remarque concernant l'arborescence Web s'applique aussi aux sous-domaines.

Ce faisant, dans certains cas, il peux être nécessaire/intéressant d'activer l'exécution des programmes CGI à partir du répertoire htdocs ou autre...

Je vais donc vous rappeler, dans un premier temps, les bases de l'exécution d'un programme CGI.

CONSEIL : Avant de modifier quoi que ce soit sur votre système, lisez tranquillement et entièrement ce tutorial.

II. Définition du terme CGI :

Le terme CGI (Common Gateway Interface) correspond à un shéma fonctionnel permettant à un Serveur Web d'exécuter des programmes écrits dans n'importe quel langage : Perl, C, Shell... étant préciser que PERL reste le langage le plus utilisé puisque ce dernier dispose de nombreuses fonctions très puissantes...

III. La directive ScriptAlias :

La directive ScriptAlias donnes accès à des programmes CGI stockés en dehors de l'arborescence Web. Ainsi, lorsque l'URL du navigateur (côté client) sollicite un tel alias, le Serveur Web Apache comprend qu'il ne s'agit pas d'une requête simple et déclenche alors l'exécution du programme CGI. Le programme doit fournir ses résultats sur sa sortie standart et le Serveur Web Apache se chargera d'envoyer cette réponse au navigateur du client.

Rappel concernant la directive ScriptAlias :

La directive ScriptAlias désigne l'emplacement d'exécution des scripts CGI. Sa syntaxe est de type : ScriptAlias chemin-URL chemin-fichier|chemin-répertoire

Cette directive peut être insérée dans le fichier de configuration du Serveur Web Apache (ex : apache2.conf), et/ou dans les fichiers de configurations des hôtes virtuels (VirtualHost) (ex : vhcs2.conf).

Voici un exemple typique d'utilisation de la directive ScriptAlias dans un VirtualHost généré par les templates Apache de l'application VHCS 2 :

# httpd [nuxwin.com] dmn entry BEGIN.
<VirtualHost 192.168.0.2:80>
    
    #
    #User vu2001
    #Group vu2001
    #
    
    #
    #SuexecUserGroup vu2001 vu2001
    #

    ServerAdmin     hostmaster@nuxwin.com
    DocumentRoot    /var/www/virtual/nuxwin.com/htdocs
    
    ServerName      nuxwin.com
    ServerAlias     www.nuxwin.com nuxwin.com
    
    ErrorLog        /var/log/apache2/users/nuxwin.com-error.log
    TransferLog     /var/log/apache2/users/nuxwin.com-access.log
    
    CustomLog       /var/log/apache2/nuxwin.com-traf.log traff
    CustomLog       /var/log/apache2/nuxwin.com-combined.log combined
    
    Alias /errors   /var/www/virtual/nuxwin.com/errors/
    
    ErrorDocument 401 /errors/401/index.php
    ErrorDocument 403 /errors/403/index.php
    ErrorDocument 404 /errors/404/index.php
    ErrorDocument 500 /errors/500/index.php

    # httpd dmn entry cgi support BEGIN.
    ScriptAlias /cgi-bin/ /var/www/virtual/nuxwin.com/cgi-bin/
    <Directory /var/www/virtual/nuxwin.com/cgi-bin>
        AllowOverride None
        #Options ExecCGI
        Order allow,deny
        Allow from all
    </Directory>
    # httpd dmn entry cgi support END.
    
    <Directory /var/www/vhcs2/gui>
        php_admin_value open_basedir "/var/www/vhcs2/gui/:/etc/vhcs2/:/proc/:/var/www/virtual/:/tmp/"
    </Directory>

    # httpd dmn entry PHP2 support BEGIN.
    php_admin_value open_basedir "/var/www/virtual/nuxwin.com/:/usr/share/php/:/tmp/"
    # httpd dmn entry PHP2 support END.
    
    <Directory /var/www/virtual/nuxwin.com/htdocs>
        # httpd dmn entry PHP support BEGIN.
        # httpd dmn entry PHP support END.
        Options Indexes Includes FollowSymLinks MultiViews
        AllowOverride All
        Order allow,deny
        Allow from all
    </Directory>
    
</VirtualHost>

Ce qui nous intéresse ici, c'est la directive ScriptAlias :

ScriptAlias /cgi-bin/ /var/www/virtual/nuxwin.com/cgi-bin/

Celle-ci nous indique que le répertoire d'exécution des scripts CGI ou plus communément appelés programmes CGI est /cgi-bin ce dernier étant situé dans le répertoire /var/www/virtual/nuxwin.com.

Ce répertoire se trouve bien en dehors de l'arborescence Web qui, elle, commence dans le répertoire htdocs, le répertoire Web racine (DocumentRoot) de l'hôte virtuel.

Il en résulte que si nous tapons l'url suivante ==> http://nuxwin.com/cgi-bin/script.cgi, cela provoquera l'exécution du programme script.cgi qui se trouve dans le répertoire /var/www/virtual/nuxwin.com/cgi-bin.

Ps : Ne cherchez pas le programme script.cgi sur votre système. Il ne s'agit que d'un exemple...

ATTENTION : Pour que vos programmes CGI puissent être exécutés, il est important que le Serveur Web Apache possède les droits d'exécution sur ces programmes. En général, il suffit qu'un chmod 755 leur soit appliqué.

IV. Handler CGI-SCRIPT :

Un Handler désigne une action associée à un fichier autrement que par son type. Quelques Handlers prédéfinis sont fournis avec le Serveur Web Apache2, notamment, l'Handler cgi-script.

C'est cet Handler qui nous intéresse dans le cadre de ce tutorial.

Si vous éditez votre fichier apache2.conf[code], vous pourrez voir qu'une directive [code]AddHandler pour l'exécution des programmes CGI est déjà présente mais commentée. Il s'agit de l'handler cgi-script évoqué ci-dessus.

Ainsi, grâce à cet Handler, tous les fichiers dont l'extension sera cgi pourront êtres considérés comme des programmes CGI.

Bien entendu, vous pouvez rajouter d'autres extentions de fichier à cet Handler.

Exemple :

AddHandler cgi-script .cgi .pl

Ici, nous avons ajouter l'extension .pl.

Cependant, l'activation de l'Handler cgi-script ne suffit pas pour que vos programmes CGI puissent s'exécuter. Il faut en effet que le répertoire dans lequels il se trouvent dispose de la directive Options suivie de l'argument ExecCGI.

Sans cela, vous n'arriverez pas à exécuter vos programmes et obtiendrez une simple boîte de dialogue vous proposant de télécharger le fichier.

Bien entendu, pour que les changements soient pris en comptes, il faudra, comme usuellement, que vous demandiez au Serveur Web Apache de relire ses fichiers de configuration.

Pour ce faire, il vous suffira de taper la commande suivante dans un terminal :

sudo /etc/init.d/apache2 force-reload

V. Exemple typique d'utilisation :

Exemple concrêt : (Ne pas suivre cet exemple pour la gestion des domaines avec l'application VHCS 2) :

Dans un premier temps, reprenons notre arborescence liminaire :

/var/www/virtual/nuxwin.com
/var/www/virtual/nuxwin.com/htdocs
/var/www/virtual/nuxwin.com/cgi-bin
/var/www/virtual/nuxwin.com/log
/var/www/virtual/nuxwin.com/errors

Comme nous l'avons vu précédement, il nous serait plus facile de placer nos programmes CGI dans le répertoire cgi-bin prévu à cet effet. Cependant, nous voulons placer nos programmes CGI dans notre répertoire Web racine nommé ===> htdocs.

Nous allons donc placer notre premier programme CGI ==> mon-script.cgi dans le répertoire /htdocs.

Ensuite, nous allons activer l'Handler évoqué ci-dessus en éditant notre fichier de configuration apache2.conf. Je rappelle pour la forme que ce fichier est situé dans le répertoire /etc/apache2.

a. En mode graphique :

sudo gedit /etc/apache2/apache2.conf

b. En mode serveur :

sudo nano /etc/apache2/apache2.conf

Dans ce fichier, nous faisons une recherche sur addHandler cgi-script .cgi.

Une fois que nous avons trouvé la ligne concernée, nous la décommentons (on enlève simplement le signe # qui se trouve juste devant).

Au passage et dans la mesure ou certains des programmes CGI que nous allons employer portent l'extension pl, nous la rajoutons à l'Handler prédéfini.

Nous avons donc :

AddHandler cgi-script .cgi

qui devient :

AddHandler cgi-script .cgi .pl

Ensuite, nous devons rajouter au réperoire Web racine htdocs, si elle n'est déjà pas présente, la directive Options ainsi que l'argument ExecCGI.

Pour ce faire, nous reprenons le fichier de configuration de notre VirtualHost ==> vhcs2.conf, tout du moins, la partie qui nous intéresse :

<Directory /var/www/virtual/nuxwin.com/htdocs>
        Options Indexes Includes FollowSymLinks MultiViews ExecCGI
        AllowOverride All
        Order allow,deny
        Allow from all
    </Directory>

La directive Options étant déjà présente dans notre fichier de configuration vhcs.conf nous rajoutons simplement l'argument ExecCGI pour que nos programmes CGI puissent êtres exécutés.

Enfin, nous relançons notre Serveur Web Apache pour que les modifications soient prises en comptes :

sudo /etc/init.d/apache2 force-reload

Une fois ceci effectué, il nous suffit de taper l'url http://nuxwin.com/mon-script.pl ou encore l'url http://nuxwin.com/mon-script.cgi dans la barre d'adresse d'un navigateur internet pour que ce dernier soit exécuté.

NOTA : Normalement, et comme ci-dessus, nous devons rajouter la directive Options ainsi que l'argument ExecCGI pour que les programmes CGI puissent être exécutés en dehors de l'arborescense Web. Ce faisant, dans notre cas, les programmes CGI se trouvent dans notre arborescence Web ( au sein même de notre répertoire Web racine). N'ayant pas encore essayé sans, je ne suis pas certain que l'inclusion de ces deux "éléments" (directive Options et argument ExecCGI) soit impérative dans ce dernier cas...

MISE EN GARDE : Si vous aviez déjà fait des tentatives d'exécution de programmes CGI placés dans un autre répertoire que celui prévu à cet effet ==> (cgi-bin) avant d'activer cette fonction, je vous recommande de vider le cache de votre navigateur et de le fermer (toutes les pages Web ouvertes) avant de retenter l'exécution.

VI : Solution particulière pour l'application VHCS 2 :

1. Mais pourquoi donc une solution particulière pour l'application VHCS 2 ?

Dans une première approche, nous aurions tendance à vouloir modifier directement le fichier de configuration des sites virtuels soit le fichier vhcs2.conf dans notre cas.

Oui mais :

Avec l'application VHCS 2, la configuration des VirtualHosts est générée par des templates qui sont situés dans le répertoire /etc/vhcs2/apache/parts. La configuration des VirtualHosts générée est stockée dans un fichier qui se nomme vhcs2.conf et ce dernier se situe dans le répertoire ==> /etc/apache2/sites-available.

Nous rencontrons donc un problème majeur :

Si nous modifions directement la configuration d'un VirtualHost en éditant le fichier vhcs2.conf, les modifcations apportées seront automatiquement annulées dès que nous ajouterons un nouveau domaine, un sous-domaine ou encore, un alias de domaine via l'interface d'administration de l'application VHCS 2. En effet, à chaque ajout, la configuration des VirtualHosts sera complétement re-générée ce qui provoquera le remplaçement du fichier vhcs2.conf et par conséquent, l'annulation de nos modifications manuelles.

De la même manière, les modifications appliquées sur un VirtualHost seront annulées si nous re-générons nos fichiers de configuration via des requêtes SQL (cf. regénération des fichiers de configurations pour plus de détail à ce sujet...).

Cette possibilité est donc a écarter...

Dans un deuxième temps, ne pouvant modifier directement le fichier de configuration généré (vhc2.conf) par les templates, nous aurions sûrement tendance à vouloir s'en prendre aux templates eux mêmes. Ce faisant, si nous modifions les templates et que nous re-générions nos fichiers de configuration (c'est obligatoire pour que les changements soient pris en comptes), les modifications apportées seraient effectives pour tous les sites virtuels, autrement dit, pour tous les répertoires htdocs de tous les domaines ou sous-domaines selon le template modifié.

Cette deuxième solution est donc aussi à écarter.

Toutefois il existe une autre solution, celle de la gestion décentralisée des répertoires grâce aux fichiers .htaccess

2. Les fichiers de gestion décentralisée .htaccess

La plupart des utilisateurs pensent que les fichiers .htaccess ne servent qu'à protéger un répertoire. Ceci est une fausse idée car ces fichiers permettent beaucoup plus de choses...

Comme indiqué ci-avant, il est possible de gérer des répertoires autrement qu'en passant par les fichiers de configuration d'Apache. Il suffit simplement de créer un fichier .htaccess à la racine du répertoire que l'on souhaite gérer.

Ceci est particulièrement intéressant lorsqu'un Administrateur Web souhaite décentraliser la gestion des répertoires Web de chaque utilisateur d'un Serveur Web. Cela peut notamment être le cas d'un Serveur Web gérant plusieurs domaines appartenant chacun à différents clients. Toutefois, convient-il de préciser que cela peut aussi être très dangereux en terme de sécurité et c'est pour cela que beaucoup d'hébergeurs, notamment ceux qui proposent des offres d'hébergements gratuit, désactivent cette fonction ou en limitent grandement l'utilisation.

a. Le nom des fichiers de gestion décentralisée vous fait peur ?

A ce stade, il convient d'ors-et-déjà de préciser que les fichiers .htaccess peuvent êtres nommés autrement, ceci grâce à la directive AccessFileName.

Cette directive se trouve dans le fichier de configuration apache2.conf.

Voici à quoi elle ressemble dans le cadre d'une utilisation usuelle :

AccessFileName .htaccess

Pour exemple , si nous voulions que nos fichiers de gestion décentralisée se nomment .drakpper au lieu de .htaccess , il nous suffirait de modifier la ligne évoquée ci-dessus de cette manière :

AccessFileName .drakpper

De même, il faudrait effectuer une deuxième modification :

Nous devrions remplacer ce qui suit :

<Files ~ "^.ht">
    Order allow,deny
    Deny from all
</Files>

Par ceci :

<Files ~ "^.dr">
    Order allow,deny
    Deny from all
</Files>

Et enfin, nous devrions relancer notre Serveur Web Apache pour que les changements soient pris en comptes :

sudo /etc/init.d/apache2 force-reload

b. Et la sécurité alors ?

Comme évoqué au début de ce paragraphe, il est possible de limiter l'utilisation des fichiers de gestion décentralisée. Ceci peut être mis en place grâce à la directive AllowOverride.

Petit rappel concernant la directive AllowsOverride :

Cette directive sert à contrôler l'utilisation des fichiers de gestion décentralisée .htaccess.

Sa syntaxe est de type : AllowOverride All|None|type-de-directive.

Exemple concrêt de syntaxes et leurs significations :

AllowOverride All : Toutes les directives valides sont autorisées dans les fichiers .htaccess

AllowOverride None : Aucune directive n'est autorisée se qui rend les fichiers .htaccess non opérationnels

AllowOverride Options : L'utilisation de la directive Options est possible dans les fichiers .htaccess

Ps : Il existe d'autres arguments disponibles pour la directive AllowOverride, renseignez-vous...

3 : Mise en application pour l'exécution de programmes CGI dans le répertoire /htdocs d'un domaine ou sous-domaine géré par l'application VHCS 2.

Ps : Dans cette exemple, il s'agirat du sous-domaine dev du domaine nuxwin.com ==> dev.nuxwin.com.

Remarque à titre liminaire :

Par défaut (vive la sécurité...), lorsqu'on créer un sous-domaine, via l'interface d'administration de l'application VHCS 2, le fichier vhcs2.conf suivant est généré :

Ps : je ne reporte que la configuration du sous-domaine concerné car, la configuration de tous les hôtes virtuels est stockées dans le même fichier avec l'application VHCS 2.

# httpd [nuxwin.com] dmn group entry BEGIN.

# httpd [dev.nuxwin.com] sub entry BEGIN.
<VirtualHost 192.168.0.2:80>

    #
    #User vu2001
    #Group vu2001
    #
    
    #
    #SuexecUserGroup vu2001 vu2001
    #

    ServerAdmin     root@nuxwin.com
    DocumentRoot    /var/www/virtual/nuxwin.com/dev/htdocs
    
    ServerName      dev.nuxwin.com
    ServerAlias     www.dev.nuxwin.com dev.nuxwin.com *.dev.nuxwin.com
    
    ErrorLog        /var/log/apache2/users/dev.nuxwin.com-error.log
    TransferLog     /var/log/apache2/users/dev.nuxwin.com-access.log
    
    CustomLog       /var/log/apache2/nuxwin.com-traf.log traff
    CustomLog       /var/log/apache2/nuxwin.com-combined.log combined

    Alias /errors /var/www/virtual/nuxwin.com/errors/

    <Directory /var/www/virtual/nuxwin.com/errors/>
        php_admin_value open_basedir "/var/www/virtual/nuxwin.com/errors/"
    </Directory>

    ErrorDocument 401 /errors/401/index.php
    ErrorDocument 403 /errors/403/index.php
    ErrorDocument 404 /errors/404/index.php
    ErrorDocument 500 /errors/500/index.php

    # httpd sub entry cgi support BEGIN.
    ScriptAlias /cgi-bin/ /var/www/virtual/nuxwin.com/dev/cgi-bin/
    <Directory /var/www/virtual/nuxwin.com/dev/cgi-bin>
        AllowOverride None
        #Options ExecCGI
        Order allow,deny
        Allow from all
    </Directory>
    # httpd sub entry cgi support END.

    <Directory /var/www/vhcs2/gui>
        php_admin_value open_basedir "/var/www/vhcs2/gui/:/etc/vhcs2/:/proc/:/var/www/virtual/:/tmp/"
    </Directory>

    # httpd sub entry PHP2 support BEGIN.
    php_admin_value open_basedir "/var/www/virtual/nuxwin.com/dev/:/usr/share/php/:/tmp/"
    # httpd sub entry PHP2 support END.
    
 <Directory /var/www/virtual/nuxwin.com/dev/htdocs>
        # httpd sub entry PHP support BEGIN.
        # httpd sub entry PHP support END.
        Options Indexes Includes FollowSymLinks MultiViews
        AllowOverride All
        Order allow,deny
        Allow from all
    </Directory>
    
</VirtualHost>

Ce qui nous intéresse ici, c'est la dernière strophe.

Comme vous pouvez aisément le constater, la directive AllowsOverride ainsi que l'argument All sont déjà présent. Cela signifie d'une part que les fichiers .htaccess sont opérationnels par défaut et pire (argument All), que toutes les directives disponibles dans ce contexte sont autorisées pour le répertoire /htdocs ainsi que ses sous-répertoires éventuels...

Nous n'aurons donc pas à modifier cette directive bien que cela ne soit pas ce qu'on pourrait appeler le TOP en terme de sécurité... Le même problème se pose lorsqu'on créer un nouveau domaine via l'interface d'administration de l'application VHCS 2...

Nous noterons aussi que la directive Options ainsi que les arguments suivants : Indexes Includes FollowSymLinks MultiViews sont déjà présent dans la configuration du VirtualHost (fichier vhcs2.conf).

Il nous reste donc deux choses à faire pour que l'exécution de programmes CGI soit possible à partir de notre répertoire Web racine /htdocs :

1. La création du fichier .htaccess ;
2. La configuration du fichier .htaccess

1. Création du fichier .htaccess

Nous allons dès à présent créer un fichier .htaccess dans notre répertoire Web racine htdocs.

Pour ce faire, il nous suffit de taper la commande suivante dans un terminal :

a. En mode graphique :

sudo gedit /var/www/virtual/nuxwin.com/dev/htdocs/.htaccess

b. En mode serveur :

sudo nano /var/www/virtual/nuxwin.com/dev/htdocs/.htaccess

2.Configuration du fichier .htaccess

Une fois le fichier .htaccess créé et en cours d'édition, il nous suffit de rajouter l'Handler cgi-script et les bonnes directives et argument pour que nos programmes CGI puissent s'exécuter à partir de notre répertoire Web Racine htdocs[code] : Il nous suffit donc de rajouter ceci dans le fichier .htaccess que nous venons de créer et qui est en cours d'édition :

Options +ExecCGI
AddHandler cgi-script .cgi

Options +ExecCGI
AddHandler cgi-script .cgi .pl

Si vous voulez que les fichiers portant l'extension [code].pl et qui se trouvent dans le répertoire htdocs soient considérés comme des programmes CGI.

Et enfin de sauvegarder le fichier.

Ps : Pensez à appliquer les bonnes permissions sur le fichier .htaccess que vous venez de créer. Evitez d'accorder les permissions d'écriture sur ce fichier. Un chmod 444 est largement suffisant ! De même, il est préférable que ce fichier appartienne au groupe du Serveur Web Apache ==> souvent, il s'agit de www-data.

Ps : Le reload du Serveur Web Apache n'est pas utiles dans le cas d'un fichier de gestion décentralisée car ce dernier est lu à chaque requête.

MISE EN GARDE : Si vous aviez déjà fait des tentatives d'exécution de programmes CGI placés dans un autre répertoire que celui prévu à cet effet ==> (/cgi-bin), avant d'activer cette fonction, je vous recommande de vider le cache de votre navigateur et de le fermer (toutes les pages Web ouvertes) avant de retenter l'exécution.

ATTENTION : Pour que vos programmes CGI puissent être exécutés, il est important que le Serveur Web Apache possède les droits d'exécution sur ces programmes. En général, il suffit qu'un chmod 755 leur soit appliqué.

Précisions :

Ce tutorial à été rédigé dans un souci de clareté pour que tous les utilisateurs puissent comprendre de quoi il s'agit exactement.

La procédure évoquée a été testée avec succès sur un système disposant d'Ubuntu Dapper Drake (6.06 LTS) sur laquelle l'application VHCS version 2.4.7.1 a préalablement été installée, cette dernière étant couplée à Apache/2.0.55 (Ubuntu) PHP/4.4.2-1build1 ainsi qu'au Serveur Mysql 5.0.22

Pour tous renseignements complémentaires ou suggestions concernant ce tutorial, je vous remercie de me contacter directement à cette adresse ==> redaction@nuxwin.com

Add a comment ·  Trackback