mod_include offre une méthode de traitement des fichiers avant l'envoi de données au client. Généralement, mod_include est utilisé pour inclure des fichiers dans un document, qui sont à leur tour analysés en tant que HTML avant d'atteindre le client. C'est pourquoi ceci est désigné par l'expression inclusions côté serveur (SSI).

Avec les SSI, des commandes spéciales sont exécutées côté serveur, déclenchées par des commentaires SGML formatés. Ces commandes SGML ont la syntaxe suivante :

<!--#element attribute=value -->
        

Pour obtenir la listes des valeurs element et attribute, consultez la documentation de mod_include à l'adresse http://httpd.apache.org/docs-2.0/mod/mod_include.html.

Pour utiliser mod_include dans SUSE Linux, ajoutez include à APACHE_MODULES dans /etc/sysconfig/apache2 ou utilisez YaST comme indiqué dans Modules.

Astuce

Utilisez la directive XBitHack (http://httpd.apache.org/docs-2.0/mod/mod_include.html#xbithack) pour indiquer à Apache d'analyser les fichiers avec l'octet execute défini pour les directives SSI. Cela signifie que plutôt que de devoir changer l'extension d'un fichier pour indiquer qu'il contient des éléments SSI (.shtml dans l'exemple ci-dessus), vous pouvez utiliser un fichier .html classique et exécuter chmod +x myfile.html.

mod_cgi permet à Apache de fournir le contenu créé par des programmes ou des scripts CGI ("Common Gateway Interface") externes. Il agit en tant qu'instance entre un langage de programmation disponible sur la machine physique et le serveur Web Apache. En théorie, les scripts CGI peuvent être écrits dans n'importe quel langage de programmation. On utilise généralement des langages de type Perl ou C. mod_cgi est la méthode la plus courante pour inclure du contenu dynamique à un site Web.

La programmation CGI est différente de la programmation "classique" en ce que les programmes et les scripts CGI doivent pouvoir générer un type MIME Content-type: text/html pour produire un résultat HTML.

#!/path/to/perl
print "Content-type: text/html\n\n";
print "Hello, World.";

La différence entre les modules spécifiquement liés à un langage de programmation (tels que mod_php5) et mod_cgi tient à la possibilité de combiner mod_cgi avec mod_suexec (voir Section 46.5.2.1, « Exécution de CGI en tant qu'utilisateur différent avec mod_suexec  »). Cette combinaison permet l'exécution des scripts CGI avec un ID d'utilisateur spécifié. Généralement, les scripts utilisant uniquement mod_cgi ou mod_php5 sont exécutés avec l'ID d'utilisateur de l'utilisateur Apache (par défaut dans SUSE Linux: wwwrun). Les modules conçus pour un langage de programmation (tels que mod_php5 ou mod_ruby) incorporent un interpréteur persistant dans Apache pour exécuter les scripts sous l'ID d'utilisateur d'Apache.

En conséquence, les CGI avec mod_suexec contribuent à la clarté d'administration car les processus CGI peuvent être affectés à des utilisateurs individuels plutôt qu'au serveur Web lui-même. En outre, cette combinaison contribue à une meilleure sécurité du système de fichiers : le script hérite uniquement des droits du système de fichiers de l'utilisateur. Dans le cas contraire des modules, le script se voit accorder les autorisations d'accès au fichier de l'utilisateur du serveur Web, ce qui peut se traduire par une visibilité involontaire des données du système de fichiers.

Les CGI se terminent à la fin de la requête d'un client sur le serveur Web. Cela signifie que les CGI ne sont pas persistants et libèrent toutes les ressources occupées à la fin. Ceci est un avantage, en particulier dans le cas d'une programmation erronée. Avec les modules, les effets des erreurs de programmation peuvent s'accumuler, du fait que l'interpréteur est persistant. Ceci peut conduire à l'impossibilité de libérer les ressources, telles que les connexions à la base de données, et nécessiter le rédemarrage d'Apache.

Pour utiliser mod_cgi dans SUSE Linux, ajoutez cgi à APACHE_MODULES dans /etc/sysconfig/apache2 ou utilisez YaST comme indiqué dans Modules. Le répertoire par défaut des CGIs dans SUSE Linux est /srv/www/cgi-bin/.

Si vous modifiez manuellement le fichier de configuration d'Apache, utilisez cet exemple comme guide pour configurer mod_cgi.

# Global Environment
LoadModule cgi_module /path/to/mod_cgi.so

# Main Server and/or Virtual Host and/or
# Directory and/or .htaccess context
AddHandler cgi-script .cgi .pl

# Main Server and/or Virtual Host context
ScriptAlias /cgi-bin/ /srv/www/cgi-bin/

# Alternatively, explicitly allow CGI scripts in a directory
# Main Server and/or Virtual Host context
<Directory /srv/www/some/dir>
   Options +ExecCGI
<Directory> 

Combiné à mod_cgi (Section 46.5.1.2, « Common Gateway Interface : mod_cgi  »), mod_suexec permet l'exécution des scripts CGI en tant qu'utilisateur ou que groupe spécifique. Le programme suEXEC de /usr/sbin/suexec2 est utilisé à cette fin. Il s'agit d'un wrapper appelé par Apache chaque fois qu'un script ou un programme CGI est exécuté. Le wrapper et le programme se voient ensuite affecter l'ID de l'utilisateur et du groupe configuré. L'exécution s'effectue de ce fait en tant que l'utilisateur ou le groupe configuré.

Bien que cette approche réduise de façon considérable les risques de sécurité liés à la génération de scripts CGI par l'utilisateur, elle n'est pas sans susciter des préoccupations importantes :

En cas d'erreurs provoquées par mod_suexec, consultez le fichier journal de suexec dans /var/log/apache2/suexec.log.

Pour utiliser mod_suexec dans SUSE Linux, ajoutez suexec à APACHE_MODULES dans /etc/sysconfig/apache2 ou utilisez YaST comme indiqué dans Modules. N'oubliez pas que mod_cgi est nécessaire pour exécuter suexec.

mod_suexec est très utile lorsqu'il est appliqué dans un environnement d'hôte virtuel, décrit dans Section 46.4, « Hôtes virtuels ». Pour spécifier un certain utilisateur et un certain groupe exécutant des scripts CGI, utilisez la syntaxe suivante dans le fichier contenant les déclarations de l'hôte virtuel (par défaut dans SUSE : /etc/apache2/vhosts.d/*) :

<VirtualHost 192.168.0>
# ...
ScriptAlias /cgi-bin/ /srv/www/vhosts/www.example.com/cgi-bin/
SuexecUserGroup tux users
# ...
</VirtualHost>
            

La syntaxe SuexecUserGroup nom d'utilisateur groupe de cet exemple affecte à tous les scripts résidant dans /srv/www/vhosts/www.example.com/cgi-bin/ l'ID d'utilisateur tux et l'ID de groupe des utilisateurs.

mod_ssl fournit le cryptage renforcé et utilise les protocoles secure sockets layer (SSL) et transport layer security (TLS) pour la communication HTTP entre un client et le serveur Web. À cette fin, le serveur envoie un certificat SSL contenant des informations prouvant l'identité valide du serveur avant la réponse à toute requête vers une adresse URL. Ceci garantit à son tour que le serveur est le seul point terminal correct pour la communication. De plus, le certificat génère une connexion codée entre client et serveur, capable de transporter des informations sans risque d'exposer du contenu sensible en texte brut. L'effet le plus visible de l'utilisation de mod_ssl avec Apache est que les adresses URL portent le préfixe https:// et non http://.

Le port par défaut pour les requêtes SSL et TLS du côté du serveur Web est 443. Il n'y a pas de conflit entre une écoute « normale » Apache sur le port 80 et une écoute Apache de type SSL/TLS sur le port 443. En fait, HTTP et HTTPS peuvent être exécutés avec la même instance Apache. Un hôte virtuel (voir Section 46.4, « Hôtes virtuels ») est généralement utilisé pour envoyer les requêtes vers le port 80 et le port 443 afin de séparer les serveurs virtuels.

Hôtes virtuels à base de nom et SSL

Il n'est pas possible d'exécuter plusieurs hôtes virtuels de type SSL sur un serveur avec une seule adresse IP. Les utilisateurs qui se connectent à ce type de configuration reçoivent un message d'avertissement indiquant que le certificat ne correspond pas au nom du serveur chaque fois qu'ils visitent l'adresse URL. Une adresse IP ou un port séparés sont nécessaires pour chaque domaine SSL afin de réaliser la communication basée sur un certificat SSL valide. Malgré le message d'avertissement, vous obtenez le même niveau de codage que sur n'importe quel site SSL valide. Cela signifie que tant que le message d'avertissement est acceptable, la communication entre le serveur Web et le client est sécurisée. Le concept de la connaissance de l'identité unique du serveur, garantie par un certificat SSL valide, est abandonné.

Pour activer mod_ssl dans SUSE Linux, ajoutez ssl à APACHE_MODULES dans /etc/sysconfig/apache2 ou utilisez YaST comme indiqué dans Modules. En outre, le serveur Web doit être configuré pour écouter le port HTTPS standard 443. Ceci peut s'effectuer manuellement dans /etc/apache2/listen.conf ou dans YaST via l'entrée du menu ‘Écoute’ (voir Sélection du périphérique réseau).

Il est possible de créer un certificat SSL de test en saisissant cd /usr/share/doc/packages/apache2; ./certificate.sh en tant que root. Suivez les instructions à l'écran pour générer le certificat SSL. Les fichiers de certificat résultants résident dans les répertoires /etc/apache2/ssl*.

Un certificat « réel » avec une validité globale peut être obtenu auprès de fournisseurs tels que Thawte (http://www.thawte.com/) ou Verisign (www.verisign.com).

Si vous modifiez manuellement le fichier de configuration d'Apache, utilisez cet exemple comme guide pour configurer mod_ssl.

# Global Environment
# listen on the standard SSL port
Listen 443
# load module only if rcapache2 start-ssl was issued
<IfDefine SSL>
LoadModule ssl_module /path/to/mod_ssl.so
</IfDefine>

# Main Server context
# include global (server-wide) SSL configuration
# that is not specific to any virtual host
# only if ssl_module was loaded
<IfModule mod_ssl.c>
Include /etc/apache2/ssl-global.conf
</IfModule>
            

	Astuce
N'oubliez pas d'ouvrir le pare-feu pour Apache avec SSL sur le port 443. Ceci peut s'effectuer via YaST, dans ‘Sécurté et Utilisateurs’+‘Pare-feu’+‘Services autorisés’. Ajoutez ensuite ‘Serveur HTTPS’ à la liste des ‘Services autorisés’.

mod_perl incorpore un interpréteur Perl persistant dans Apache. Ceci évite la surcharge causée par un mod_cgi qui appelle un exécutable externe sur chaque requête vers un CGI. mod_perl permet en outre le contrôle de nombreux aspects des fonctionnalités Apache avec l'aide du langage de programmation Perl.

Pour utiliser mod_perl dans SUSE Linux, installez le RPM apache2-mod_perl et activez le module soit via YaST (Modules) soit manuellement dans /etc/sysconfig/apache2. Après installation et activation, un fichier de configuration séparé, mod_perl.conf, est placé dans /etc/apache2/conf.d/. De surcroît, le script de démarrage mod_perl est installé en tant que mod_perl-startup.pl. Pour plus d'informations sur l'utilisation du module, consultez la documentation qui se trouve sur le site Web mod_perl (http://perl.apache.org/).

PHP est un langage de programmation courant, destiné à l'origine à être utilisé sur le Web. Il existe en deux versions, PHP4 et PHP5. Alors que PHP4 représente le concept et l'approche classiques de PHP, PHP5 a introduit de nouvelles possibilités de programmation orientées objet ainsi que de nombreuses autres fonctions avancées. mod_php4 et mod_php5 sont disponibles dans SUSE Linux. Ils incorporent l'interpréteur PHP dans Apache en tant que module persistant.

Pour utiliser mod_php4 ou mod_php5 dans SUSE Linux, installez le RPM correspondant (apache2-mod_php4, apache2-mod_php5) et activez le module soit via YaST (Modules) soit manuellement dans /etc/sysconfig/apache2.

Après installation et activation, un fichier de configuration séparé correspondant au module, (php4.conf ou php5.conf), est placé dans /etc/apache2/conf.d/. Le site Web PHP (http://www.php.net) est une excellente ressource pour utiliser Apache avec PHP.

mod_python incorpore l'interpréteur Python dans Apache. Python est un langage de programmation orienté objet avec une syntaxe très claire et lisible. Une fonction inhabituelle mais pratique est que la structure du programme dépend de la mise en retrait du code source plutôt que d'éléments de démarcation classiques tels que begin et end.

Pour utiliser mod_python dans SUSE Linux, installez le RPM apache2-mod_python et activez le module soit via YaST (Modules) soit manuellement dans /etc/sysconfig/apache2. Pour plus d'informations sur l'utilisation du module, consultez la documentation qui se trouve sur le site Web mod_python (http://www.modpython.org/).

mod_ruby incorpore l'interpréteur Ruby dans le serveur Web Apache, pour permettre l'exécution des scripts Ruby CGI en mode natif. Ruby est un langage de programmation orienté objet de haut niveau relativement nouveau qui ressemble à certains aspects de Perl et de Python. Tout comme Python, il a une syntaxe claire et transparente. Par contre, Ruby a adopté des abréviations (telles que $.r pour le numéro de la dernière ligne lue dans le fichier d'entrée) qui sont appréciées de certains programmeurs et que d'autres n'aiment pas. Le concept de base de Ruby ressemble étroitement à celui de Smalltalk.

Pour utiliser mod_ruby dans SUSE Linux, installez le RPM apache2-mod_ruby et activez le module soit via YaST (Modules) soit manuellement dans /etc/sysconfig/apache2. Pour plus d'informations sur l'utilisation du module, consultez la documentation qui se trouve sur le site Web mod_ruby (http://www.modruby.net/en/index.rbx).

mod_dav fournit la fonctionnalité WebDAV (création et gestion de versions distribuées sur le Web) d'Apache. WebDAV est une extension du protocole HTTP qui permet aux utilisateurs de modifier et de gérer des fichiers de façon collaborative sur des serveurs distants. Les fonctionnalités de WebDAV sont similaires à celles de FTP à la différence majeure que HTTP est utilisé comme protocole sous-jacent pour l'accès au serveur. En effet, mod_dav fait d'un serveur Web Apache un système de fichiers distant avancé.

Il est recommandé, sinon nécessaire, de limiter l'accès aux répertoires disponibles via WebDAV. Les précautions minimales consistent à configurer l'authentification HTTP de base pour la ressource WebDAV, ainsi que les clauses Limit à l'intérieur d'une directive Emplacement.

Pour accéder à une ressource WebDAV, un logiciel compatible WebDAV doit se trouver du côté du client. SUSE Linux est accompagné de fonctionnalités WebDAV : Konqueror avec le préfixe webdav:// ou webdavs:// (pour WebDAV sur des connexions SSL) permet de se connecter à un système de fichiers Apache WebDAV.

mod_dav nécessite le module mod_dav_fs, qui fournit l'accès au système de fichiers pour WebDAV. Pour utiliser mod_dav dans SUSE Linux, activez le module soit via YaST (Modules) soit manuellement dans /etc/sysconfig/apache2. Faites de même pour mod_dav_fs. Pour plus d'informations sur l'utilisation du module, consultez la documentation qui se trouve sur le site Web mod_dav (http://httpd.apache.org/docs-2.0/mod/mod_dav.html).

Par défaut, mod_userdir dans SUSE Linux offre le contenu du dossier ~/public_html de chaque utilisateur comme des pages Web publiques. L'URL permettant d'accéder à ces pages est alors http://www.example.com/~nom d'utilisateur/.

	Astuce
mod_userdir dans SUSE Linux interdit l'accès à tous les répertoires du répertoire d'accueil de l'utilisateur root pour des raisons de sécurité. Vous pouvez en outre autoriser spécifiquement certains utilisateurs à posséder des pages d'accueil publiques en utilisant : # Main server context UserDir disabled UserDir enabled tux wilber

Pour utiliser mod_userdir dans SUSE Linux, activez le module soit via YaST (Modules) soit manuellement dans /etc/sysconfig/apache2. Pour plus d'informations sur l'utilisation du module, consultez la documentation qui se trouve sur le site Web mod_userdir (http://httpd.apache.org/docs-2.0/mod/mod_userdir.html).

mod_rewrite est souvent nommé « le couteau de l'armée suisse pour la manipulation des adresses URL. » Il réécrit les adresses URL demandées à la volée selon un ensemble de règles spécifié. Le résultat ressemble généralement à http://www.example.com/2/1/de pour http://www.example.com/display.php?cat=2&article=1&lang=de.

Le Guide de réécriture d'adresse URL explique les avantages et les inconvénients de ce module puissant mais complexe :

« Avec mod_rewrite, soit vous vous suicidez dès la première fois, soit vous en tombez amoureux pour le restant de vos jours du fait de sa puissance. »

Des ensembles RewriteRule peuvent être définis dans tous les contextes de configuration : pour le serveur principal, pour les hôtes virtuels, pour les répertoires et pour les fichiers .htaccess. Un bon point de départ pour la réécriture d'adresses URL avec mod_rewrite est le Guide de réécriture d'adresse URL à l'adresse http://httpd.apache.org/docs-2.0/misc/rewriteguide.html.

Pour utiliser mod_rewrite dans SUSE Linux, activez le module soit via YaST (Modules) soit manuellement dans /etc/sysconfig/apache2.