La version actuelle d'Apache est la 1.3.9. Le site principal d'Apache est sur http://www.apache.org/. Une autre bonne source d'information est Apacheweek sur http://www.apacheweek.com/. La documentation d'Apache est bonne, je ne rentrerai donc pas dans les détails de la configuration d'apache. La documentaion est sur le site web et également incluse dans les sources (au format HTML). Il y a également des fichiers textes inclus dans les sources, mais la version HTML est meilleure. La documentation doit devenir bien meilleure depuis que le Apache Documentation Project a été lancé. Pour l'instant la plupart des documents sont écrits par les développeurs. Sans vouloir discréditer les développeurs, ils sont un peu difficiles à comprendre si vous ne connaissez pas la terminologie.
Apache est inclus dans les distributions Red Hat, Slackware, et OpenLinux. Cependant il se peut que ce ne soit pas la dernière version, ce sont des binaires très fiables. La mauvaise nouvelle est que vous aurez à vivre avec leurs choix de répertoires (qui sont totalement différents les uns des autres et de ceux par défaut d'Apache).
Le source est disponible sur le site web d'Apache à http://www.apache.org/dist/. Les binaires sont également disponibles au même endroit. Vous pouvez aussi obtenir les binaires de sunsite à ftp://sunsite.unc.edu/pub/Linux/apps/www/servers/ et pour la France sur ftp://ftp.lip6.fr/pub/linux/sunsite/apps/www/servers/. Et pour ceux d'entre vous qui utilisent une Red Hat le dernier fichier RPM se trouve généralement dans le répertoire des contributions à ftp://ftp.redhat.com/pub/contrib/i386/.
Si votre serveur doit servir un dessein commercial, il est hautement recommandé que vous obteniez les sources à partir du site web d'Apache et de le compiler vous même. L'autre option est d'utiliser un binaire qui provient d'une distribution majeure, par exemple Slackware, Red Hat, ou OpenLinux. La principale raison en est la sécurité. Un binaire inconnu peut avoir une "sortie cachée" pour les hackers, ou une correction instable peut crasher votre système. Ceci vous donnera également plus de contrôle sur les modules compilés, et vous autorisera à changer les répertoires par défaut. Il n'est pas difficile de compiler Apache, et vous ne serez pas un vrai utilisateur de Linux tant que vous ne compilerez pas vos programmes ;)
Tout d'abord décompactez l'archive dans un répertoire temporaire. Ensuite
placez vous dans le répertoire src. Editez alors le fichier Configuration si
vous désirez ajouter des modules spéciaux. Les modules les plus communément
utilisés sont déjà inclus. Il n'y a pas besoin de changer les règles ou le
makefile pour Linux. Lancez ensuite le script shell Configure
(./Configure). Vérifiez qu'il vous dit que vous utilisez une
plateforme Linux et gcc en tant que compilateur.
Ensuite vous pouvez éditer le fichier httpd.h pour changer les répertoires
par défaut.
L'emplacement du serveur (où sont conservés les fichiers de configuration)
par défaut est /usr/local/etc/httpd/, mais vous pouvez le changer
pour juste /etc/httpd/. Et le répertoire principal du serveur (où
sont conservées les pages HTML) par défaut est
/usr/local/etc/httpd/htdocs/, mais j'apprécie le répertoire
/home/httpd/html (le défaut de Red Hat pour Apache). Si vous devez
utiliser su-exec (voir les options spéciales plus bas) vous pouvez également
désirer changer le répertoire. Le répertoire principal peut également être
changé à partir des fichiers de config. Mais il est également bon de le
compiler, juste au cas où Apache ne puisse pas trouver ou lire les fichiers de
configuration. Tout le reste doit être changé à partir des fichiers de
configuration.
Lancez enfin make pour compiler Apache.
Si vous avez des problèmes au sujet de fichiers d'inclusion manquants, vérifiez les points suivants. Vérifiez que vous avez les entêtes du noyau (fichiers include) installés pour votre version du noyau. Vérifiez également que vous avez ces liens symboliques installés:
/usr/include/linux doit être un lien sur /usr/src/linux/include/linux
/usr/include/asm doit être un lien sur /usr/src/linux/include/asm
/usr/src/linux doit être un lien sur les sources de Linux (ex.linux-2.0.30)
ln -s, celà fonctionnera comme la
commande cp à part qu'il fera un lien ((ln -s SOURCE DESTINATION).
Lorsque make a terminé il doit y avoir un exécutable nommé httpd dans le
répertoire. Il est nécessaire de le déplacer dans un répertoire bin.
/usr/sbin ou /usr/local/sbin seraient de bons choix.
Copiez les sous-répertoires conf, logs, et icons des sources vers
l'emplacement du serveur. Renommez ensuite trois des fichiers du
sous-répertoire conf pour vous débarasser de l'extension -dist
((ex. httpd.conf-dist devient httpd.conf).
Il y a aussi divers programmes de support qui sont inclus avec Apache. Ils
sont dans le répertoire support et doivent être compilés et installés
séparément/
La plupart d'entre eux peuvent être créés en utilisant le makefile de leur
répertoire (ce qui est fait lorsque vous lancez le script principal
Configure). Vous n'avez besoin d'aucun d'entre eux pour utiliser
Apache, mais certains rendent le travail des administrateurs plus simple.
Maintenant vous devez avoir quatre fichiers dans votre sous-répertoire
conf de l'emplacement du serveur. Le fichier httpd.conf met en
place le daemon du serveur (numéro de port, utilisateur, etc). Le
srm.conf spécifie l'arborescence pour les documents principaux, les
actions spéciales, etc. Le access.conf spécifie les conditions de base
pour l'accès. Finalement, le mime.types indique au serveur quel type mime
il doit envoyer au navigateur pour quelle extension.
Les fichiers de configuration sont assez bien documentés (ils sont pleins de commentaires), tant que vous comprenez le langage. Vous devriez les lire attentivement avant de mettre votre serveur en marche. Chaque option de configuration est couvert dans la documentation Apache.
Le fichier mime.types n'est pas réellement un fichier de configuration.
Il est utilisé par le serveur pour traduire les extensions des fichiers en
types mime à envoyer au navigateur. La plupart des types mime communs sont
déjà dans le fichier. La majorité des gens ne devrait pas éditer ce fichier.
Au fil du temps, de plus en plus de types mime seront ajoutés pour supporter
de nouveaux programmes. La meilleure chose à faire sera de prendre un nouveau
fichier mime.types (et peut-être une nouvelle version du serveur) à ce
moment là.
Souvenez vous toujours que lorsque vous changez les fichiers de
configuration vous devez relancer Apache ou lui envoyer le signal SIGHUP
avec kill pour que les changements prennent effet. Vérifiez que vous
envoyez le signal au process parent et non aux process enfants. Le parent a
généralement le chiffre id le plus faible. L'id du process du parent est
également dans le fichier httpd.pid du répertoire log. Si vous envoyez
accidentellement le signal à un des process enfants, le process stoppera et
le parent le relancera.
Je ne vous détaillerai pas la configuration d'Apache. Je me contenterai de parler des problèmes spécifiques, des choix à faire, et des options spéciales.
Je recommande chaudement que tous les utilisateurs parcourent le chapitre sur la sécurité dans la documentation Apache. Elle est également disponible sur le site web d'Apache à http://www.apache.org/docs/mics/security_tips.html.
L'hébergement virtuel existe lorsqu'un seul ordinateur dispose de plus d'un nom de domaine. L'ancienne méthode était d'avoir une adresse IP pour chaque site virtuel. La nouvelle méthode utilise une seule adresse IP, mais celà ne fonctionne pas correctement avec les navigateurs qui ne supportent pas le HTTP 1.1.
Ma recommandation pour les sites commerciaux est de conserver un hébergement virtuel basé sur plusieurs IP jusqu'à ce que la majorité des gens disposent de navigateurs supportant HTTP 1.1 (donnez leur un an ou deux). Ceci vous donne également une impression plus complète d'hébergement virtuel. Alors que les deux méthodes peuvent vous donner des possibilités de courrier virtuel (est ce que quelqu'un peut confirmer?), seul l'hébergement virtuel basé IP peut également vous donner un serveur FTP virtuel.
S'il s'agit d'un club ou d'une page personnelle, vous pouvez envisager l'hébergement virtuel par IP partagée. Ce devrait être moins cher que l'hébergement basé IP et vous économiserez de précieuses addresses IP.
Vous pouvez également mélanger les hébergements virtuels par IP fixes et par IP partagées sur le même serveur. Pour plus d'information sur l'hébergement virtuel voyez Apacheweek sur http://www.apacheweek.com/features/vhost.
Pour cette méthode chaque site virtuel dispose de sa propre adresse IP. En fonction de l'adresse IP à laquelle la requête a été envoyée, Apache et d'autres programmes déterminent quel domaine desservir. C'est un incroyable gaspillage d'adresses IP. Prenez par exemple l'ensemble de serveurs où est conservé mon domaine virtuel. Ils ont plus de 35.000 comptes virtuels, ce qui signifie 35.000 adresses IP. Pourtant je crois qu'aux derniers comptes ils avaient moins de 50 serveurs réels.
La configuration se fait en deux parties. La première consiste à rendre Linux capable de reconnaître plus d'une adresse IP. La seconde est de configurer apache pour servir les sites virtuels.
La première étape pour rendre Linux capable d'accepter plusieurs adresses IP consiste à compiler un nouveau noyau. Ceci fonctionne mieux avec la série des noyaux 2.0 (ou supérieure). Vous devrez inclure le support pour "IP networking" et "IP aliasing". Si vous avez besoin d'aide pour la compilation du noyau voyez le kernel howto, ou sa version française sur http://www.freenix.org/linux/HOWTO/Kernel-HOWTO.html.
Vous devrez ensuite spécifier la configuration de chaque interface au lancement du système. Si vous utilisez la distribution Red Hat, ceci peut être fait à partir du panneau de contrôle. Lancez X-Window en tant que super-utilisateur, vous devriez voir un panneau de contrôle. Double-cliquez sur "network configuration" (configuration réseau). Allez ensuite sur le panneau des interfaces et choisissez votre carte réseau. Ensuite cliquez sur alias en bas de l'écran. Rentrez les informations et cliquez sur "done". Ceci devra être fait pour chaque site virtuel / adresse IP.
Si vous utilisez une autre distribution vous pouvez avoir à le faire
manuellement. Vous pouvez simplement mettre les commandes dans le fichier
rc.local de /etc/rc.d (en réalité vous devriez les mettre avec
toutes celles concernant le réseau). Vous devrez avoir une commande
ifconfig et route pour chaque périphérique. Les adresses en alias
sont constituées à partir du périphérique principal. Par exemple eth0 aurait
les alias eth0:0, eth0:1, eth0:2, etc. Voici un exemple de configuration d'un
alias:
ifconfig eth0:0 192.168.1.57
route add -host 192.168.1.57 dev eth0:0
Vous devrez ensuite configurer votre serveur de noms (DNS) pour desservir ces nouveaux domaines. Et si vous ne possédez pas déjà les noms de domaine, vous devrez contacter l' Internic pour enregistrer les noms de domaines. Voyez le DNS-howto pour plus d'informations sur la configuration de votre DNS.
Pour finir, vous devrez configurer Apache de manière à desservir
correctement le domaine virtuel. Ceci se fait dans le fichier de
configuration httpd.conf près de la fin. Ils vous donnent un exemple
sur la façon de procéder. Toutes les commandes spécifiques au site virtuel
sont placées entre les marqueurs virtualhost. Vous pouvez mettre à peu
près n'importe quelle commande ici.
Généralement vous devrez placer différents répertoires pour le serveur, le
répertoire script, et les fichiers de log. Vous pouvez avoir un nombre
quasi-illimité de sites virtuels en ajoutant d'autres marqueurs
virtualhost.
Dans de rares cas, vous pouvez avoir à lancer des serveurs séparés si une directive est nécessaire pour un site virtuel, mais n'est pas acceptée dans les marqueurs du site virtuel. Ceci se fait en utilisant la directive bindaddress. Chaque serveur aura un nom et des fichiers de configuration différents. Chaque serveur répondra à une seule adresse IP, spécifiée par la directive bindaddress. C'est un gaspillage incroyable de ressources système.
C'est une nouvelle méthode pour l'hébergement virtuel. Elle utilise une adresse IP unique, réservant les adresses IP aux vraies machines (et pas les virtuelles). Dans l'exemple cité plus haut, ces 30.000 sites virtuels utiliseraient seulement 50 adresses IP (une pour chaque machine). Ceci est fait en utilisant le nouveau protocole HTTP 1.1. Le navigateur dit au serveur quel site il désire lorsqu'il envoie la demande. Le problème est que les navigateurs qui ne supportent pas HTTP 1.1 obtiendront la page principale du serveur, qui peut être configurée pour donner la liste des sites virtuels disponibles. Ceci ruine toute l'illusion de l'hébergement virtuel. L'illusion que vous avez votre propre serveur.
La configuration est bien plus simple que pour l'hébergement virtuel basé sur IP. Vous aurez toujours besoin d'obtenir de l'Internic votre domaine et de configurer votre DNS. Cette fois-ci, le DNS pointe sur la même adresse IP que le domaine original. Ensuite Apache se configure comme précédemment. Puisque vous utilisez la même adresse IP dans les marqueurs virtualhost, Apache sait que vous désirez l'hébergement virtuel par IP partagée.
Il y a plusieurs solutions pour les anciens navigateurs. Je vais vous
expliquer la meilleure. Tout d'abord vous devrez créer vos pages principales
comme pour un serveur virtuel (soit basé IP, soit par IP partagée). Ceci libère
la page principale pour un lien listant tous vos sites virtuels. Ensuite vous
devrez créer une sortie cachée pour les anciens navigateurs. On le réalise
en utilisant la directive ServerPath pour chaque site virtuel de la
directive virtualhost. Par exemple en ajoutant ServerPath
/monsite/ à www.monsite.com, les anciens navigateurs pourront accéder
au site par www.monsite.com/monsite/. Ensuite mettez dans la page par défaut
du serveur principal un message qui les incitera poliment à se procurer un
nouveau navigateur, et listera les liens sur toutes les sorties cachées des
sites que vous hébergez sur cette machine. Lorsqu'un ancien navigateur
accèdera au site, l'utilisateur sera renvoyé à la page principale, et aura
un lien sur la page correcte. Les nouveaux navigateurs ne verront jamais la
page principale et iront directement sur les sites virtuels. Vous devez
veiller à n'avoir que des liens relatifs à l'intérieur de chaque site web, car les
pages seront demandées à partir de deux URL différentes (www.monsite.com et
www.monsite.com/monsite/).
J'espère que je ne vous ai pas embrouillé ici, mais ce n'est pas d'une compréhension simple. Après tout, vous devriez peut-être envisager l'hébergement basé IP. Une explication très similaire se trouve sur le site web d'apache à http://www.apache.org/manual/host.html.
Si quelqu'un dispose d'un pointeur sympathique pour l'hébergement par IP partagée, j'aimerais le connaître. Il serait agréable de connaître le pourcentage de navigateurs qui supportent le HTTP 1.1, et d'avoir une liste des navigateurs et des versions qui supportent HTTP 1.1.
Il existe deux méthodes différentes pour donner à vos utilisateurs la
possibilité d'utiliser des scripts CGI. La première est de considérer tout
fichier se terminant par .cgi comme un script CGI. La seconde est de créer
des répertoires de scripts (généralement nommés cgi-bin). Vous pouvez
utiliser les deux méthodes également. Quelle que soit la méthode utilisée vos
scripts doivent être exécutables par n'importe qui (chmod 711). En
donnant à vos utilisateurs l'accès aux scripts, vous créez un gros risque de
sécurité. Faîtes proprement votre travail afin de minimiser les risques
concernant la sécurité.
Je préfère la première méthode, spécialement pour les scripts complexes.
Ceci vous autorisera à mettre les scripts dans n'importe quel répertoire.
J'aime mettre mes scripts au même endroit que les pages web qui s'en
servent. Pour les sites avec beaucoup de scripts, c'est beaucoup mieux que
d'avoir un répertoire plein de scripts. La configuration est simple. Tout
d'abord supprimez le commentaire du marqueur .cgi à la fin du fichier
srm.conf. Ensuite vérifiez que tous vos répertoires ont les marqueurs
option ExecCGI ou All dans le fichier access.conf.
Créer un répertoire de scripts est considéré comme plus sûr.
Pour créer un répertoire de scripts, vous utilisez la directive ScriptAlias
dans le fichier srm.conf. Le premier argument est l'alias, et le second
le répertoire réel. Par exemple ScriptAlias /cgi-bin/
/usr/httpd/cgi-bin/ rend le répertoire /usr/httpd/cgi-bin
capable de contenir des scripts exécutables. Ce répertoire sera utilisé chaque
fois quelqu'un demandera le répertoire /cgi-bin/. Pour des raisons de
sécurité vous devez également changer les propriétés du répertoire pour
Options none, AllowOveride none dans le fichier access.conf
(supprimer simplement les commentaires de l'exemple donné). Egalement ne
placez pas vos répertoires de scripts à l'intérieur de la même arborescence que
les répertoires de pages web. Par exemple, si vous servez les pages à partir de
/home/httpd/html/, ne créez pas le répertoire de scripts en tant
que /home/httpd/html/cgi-bin; mais plutôt
/home/httpd/cgi-bin.
Si vous désirez que vos utilisateurs disposent de leurs propres
répertoires de scripts vous pouvez utiliser plusieurs commandes
ScriptAlias. Les sites virtuels doivent avoir cette commande
ScriptAlias dans leurs directives virtualhost.
Est ce que quelqu'un connaît un moyen simple pour autoriser les utilisateurs
à avoir leur propre répertoire cgi-bin sans utiliser des commandes
individuelles ScriptAlias ?
Il y a deux méthodes différentes pour gérer les répertoires web des
utilisateurs. La première est d'avoir un sous-répertoire dans les
répertoires des utilisateurs (généralement public_html).
La seconde est d'avoir une aborescence entièrement différente pour les
répertoires web.
Pour ces deux méthodes vérifiez les options d'accès aux répertoires dans le
fichier access.conf.
La première méthode est configurée par défaut dans apache. Lorsqu'une
demande pour /~bob/ arrive, Apache regarde dans le répertoire
public_html du répertoire principal de bob. Vous pouvez changer ce répertoire avec la
directive UserDir dans le fichier srm.conf. Ce
répertoire doit être lisible et exécutable par tout le monde.
Cette méthode crée un risque pour la sécurité car le répertoire
principal des utilisateurs doit être exécutable par toute personne afin
qu'Apache puisse y accéder.
La seconde méthode est facile à configurer. Vous devez juste changer la
directive UserDir dans le fichier srm.conf. Il y a
beaucoup de formats différents; vous pouvez voir la documentation d'Apache
pour clarification. Si vous voulez que chaque utilisateur dispose de son propre
répertoire sous /home/httpd/, vous utiliserez UserDir
/home/httpd. Ensuite lorsqu'une demande arrivera pour /~bob/,
Apache la traduira par /home/httpd/bob/. Ou si vous avez un
sous-répertoire dans le répertoire de bob vous pouvez utiliser UserDir
/home/httpd/*/html. Ceci traduira en /home/httpd/bob/html/ et
vous autorisera à avoir aussi un répertoire de script (par exemple
/home/httpd/bob/cgi-bin/).
Il y a deux méthodes pour faire tourner Apache. L'une est d'avoir un démon qui tourne tout le temps (Apache appelle ceci standalone). La seconde est celle du super-serveur inetd.
Le mode démon est de loin supérieur au mode inetd. Apache est configuré pour le mode démon par défaut. La seule raison d'utiliser le mode d'inetd est pour les applications très peu utilisées, comme les tests de scripts en interne, l'intranet d'une petite compagnie, etc. Le mode inetd économisera de la mémoire car apache ne sera chargé que lorsqu'il sera demandé. Seul le démon inetd restera en mémoire.
Si vous n'utilisez pas très souvent apache vous pouvez le conserver en mode démon et le lancer lorsque vous en avez besoin. Ensuite vous le supprimez lorsque vous avez terminé (soyez sûr de bien supprimer le processus parent et non pas un des enfants).
Pour configurer le mode inetd vous devrez éditer quelques fichiers. Tout
d'abord /etc/services, regardez si http est déjà présent. S'il n'y
est pas, alors ajoutez ceci:
http 80/tcp
/etc/inetd.conf et ajouter la ligne pour Apache:
http stream tcp nowait root /usr/sbin/httpd httpd
Si le démon inetd est déjà lancé (inetd), alors vous devez lui envoyer
le signal SIGHUP (par kill; voyez la page de manuel de kill pour plus
d'infos) ou relancer l'ordinateur pour que les changements soient effectifs.
Si vous n'avez pas lancé inetd alors vous pouvez le lancer
manuellement. Vous devez également l'ajouter à vos fichiers d'initialisation
afin qu'il soit chargé au démarrage du système (le fichier rc.local serait
un bon choix).
Les nouveaux outils de publication web supportent cette nouvelle méthode d'envoi des pages web par http (à la place de FTP). Certains de ces produits ne supportent même plus le FTP! Apache supporte cette méthode, mais il manque d'un script pour se charger des requêtes. Ce script pourrait être un gros trou de sécurité, soyez certain de ce que vous faîtes avant de tenter d'en écrire ou d'en installer un.
Si quelqu'un connaît un script qui fonctionne faîtes le moi savoir et j'incluerai l'adresse ici.
Pour plus d'informations voyez l'article d'Apacheweek à http://www.apacheweek.com/features/put.
Il s'agit de l'une de mes options préférées. Elle vous autorise à protéger un répertoire ou un fichier par un mot de passe sans utiliser de script CGI. Elle vous autorise également à interdire ou à autoriser l'accès sur la base de l'adresse IP ou du nom de domaine du client. C'est une spécificité très intéressante pour écarter les crétins de votre messagerie et de vos livres d'or (vous trouvez l'IP ou le nom de domaine dans vos fichiers de log).
Pour permettre l'authentification de l'utilisateur, le répertoire doit avoir
AllowOverrides AuthConfig dans le fichier access.conf. Pour
permettre le contrôle d'accès (par domaine ou adresse IP) AllowOverrides
Limit doit être mis pour ce répertoire.
La configuration du répertoire nécessite de placer un fichier
.htaccess dans le répertoire. Pour l'authentification de l'utilisateur
il est également utilisé avec un .htpasswd et optionnellement un
fichier .htgroup. Ces fichiers peuvent être partagés pour de multiples
fichiers .htaccess si vous le désirez.
Pour des raisons de sécurité je recommande que chacun utilise ces directives dans ses fichier access.conf:
<files ~ "/\.ht">
order deny,allow
deny from all
</files>
Si vous n'êtes pas l'administrateur du système vous pouvez également l'ajouter dans votre fichier .htaccess si AllowOverride Limit est configuré pour votre répertoire. Cette directive interdira à quiconque de regarder dans vos fichiers de contrôle d'accès (.htaccess, .htpasswd, etc).
Il y a de nombreux types de fichiers et d'options qui peuvent être utilisés avec le contrôle d'accès. Toutefois, décrire ces fichiers dépasse le propos de ce document. Pour les informations sur la configuration de l'authentification des utilisateurs voyez l'article d'Apacheweek à http://www.apacheweek.com/features/userauth ou les pages de la NCSA à http://hoohoo.ncsa.uiuc.edu/docs-1.5/tutorials/user.html.
su-exec lance les scripts CGI avec l'identité du propriétaire du script. Normalement, ils sont lancés avec la même identité que le serveur web (généralement nobody). Ceci permet aux utilisateurs de rendre leurs propres fichiers accessibles par les scripts, sans mettre ces fichiers en écriture pour tout le monde (un trou de sécurité). Mais si vous ne faîtes pas attention, vous pouvez avoir un trou encore plus gros en utilisant le code su-exec. Celui-ci effectue des contrôles de sécurité avant d'exécuter les scripts, mais si vous le configurez de manière incorrecte vous aurez un trou de sécurité.
Le code su-exec n'est pas pour les amateurs. Ne l'utilisez pas si vous ne savez pas ce que vous faîtes. Vous pouvez vous retrouver avec un gros problème de sécurité, vos utilisateurs pouvant obtenir des accès super-utilisateurs. Ne modifiez pas le code quelle qu'en soit la raison. Lisez attentivement toute la documentation. Le code su-exec est intentionnellement difficile à configurer afin d'éviter l'utilisation par des amateurs (tout doit être fait à la main, il n'y a pas de script d'installation).
Le code su-exec se trouve dans le répertoire support des sources. Tout
d'abord vous devez éditer le fichier suexec.h pour votre système.
Ensuite vous devez compiler le code su-exec avec cette commande:
gcc suexec.c -o suexec
/usr/local/etc/httpd/sbin/. Ceci peut être
changé en éditant le fichier httpd.h dans les sources d'Apache et en
recompilant Apache. Apache regardera seulement dans ce répertoire, il ne
cherchera pas ailleurs. Le fichier doit être la
propriété du super-utilisateur (chown root suexec) et les
permissions doivent être changées (chmod 4711 suexec).
Enfin relancez Apache, il doit vous donner un message sur la console
indiquant que su-exec est utilisé.
Les scripts CGI doivent être rendus exécutables par tous comme d'habitude.
Ils seront automatiquement lancés par le possesseur du script CGI. Si vous
changez les permissions, les scripts CGI ne fonctionneront pas. Si le
répertoire ou le fichier est en écriture par tous ou par un groupe, le script
ne fonctionnera pas. Il ne faut pas lancer de script possédé par un
utilisateur système (root, bin, etc.). Pour les
autres conditions de sécurité qui doivent être remplies, voyez la documentation
de su-exec. Si vous avez des problèmes voyez le fichier de log de su-exec nommé
cgi.log.
Su-exec ne fonctionne pas si vous lancez Apache par inetd, il fonctionne seulement en mode démon. Ceci sera corrigé dans la prochaine version en ce qu'il n'y aura pas de mode inetd. Si vous aimez jouer avec le code source, vous pouvez éditer le fichier http_main.c. Vous pouvez vous débarrasser de la ligne où Apache annonce qu'il utilise le su-exec wrapper (ce qui est faussement indiqué en tête de chaque message).
Lisez attentivement la documentation d'Apache sur su-exec. Elle est inclue dans les sources et est disponible sur le site web d'Apache à http://www.apache.org/docs/suexec.html.
Apache peut gérer des cartes graphiques du côté du serveur. Ce que l'on
appelle "Imagemaps" sont des images dans des pages web qui envoient les
utilisateurs à divers emplacements, selon l'endroit où ils cliquent.
Pour utiliser les imagemaps vérifiez que le module imagemap est installé
(c'est un des modules par défaut). Ensuite vous devez supprimer le
commentaire de la ligne .map à la fin du fichier srm.conf.
Maintenant, tous les fichiers se terminant en .map seront des fichiers
d'imagemap. Les fichiers imagemap délimitent différentes aires sur l'image
associées chacune à un lien différent. Apache utilise des fichiers d'aires au
format standard NCSA. Voici un exemple utilisant un fichier d'aire dans une
page web:
<a href="/map/mapfile.map">
<img src="picture.gif" ISMAP>
</a>
mapfile.map est le fichier d'aires, et
picture.gif est l'image cliquable.
Il y a de nombreux programmes qui peuvent générer des fichiers d'aires compatibles NCSA ou vous pouvez les créer vous-même. Pour une discussion plus détaillée sur les imagemaps et les fichiers d'aires voyez l'article d'Apacheweek à http://www.apacheweek.com/features/imagemaps.
Les Server Side Includes (SSI) ajoutent un contenu dynamique à des pages web qui sinon seraient statiques. Les clauses d'inclusion sont insérées dans les pages web en tant que commentaires. Le serveur web les exécute ensuite et passe les résultats au serveur web. SSI peut ajouter des en-têtes et des pieds de page aux documents, ajouter la date à laquelle le document a été modifié pour la dernière fois, exécuter une commande système ou un script CGI. avec le tout nouveau eXtended Server Side Includes (XSSI) vous pouvez faire bien plus. XSSI ajoute les variables et les instructions de contrôle (if, else, etc). C'est quasiment comme travailler avec un langage de programmation.
L'analyse syntaxique de tous les fichiers relativement aux commandes SSI utiliserait
beaucoup de ressources système. C'est pourquoi il faut distinguer les fichiers
HTML normaux de ceux qui contiennent les commandes SSI. Ceci se fait
généralement en changeant l'extension des fichiers HTML utilisant SSI.
Habituellement on utilise l'extension .shtml.
Pour utiliser SSI/XSSI, vérifiez tout d'abord que le module des
includes est installé. Editez ensuite srm.conf et supprimez les
commentaires des directives AddType et AddHandler pour les
fichiers .shtml. Enfin, vous devez configurer Options Includes
pour tous les répertoires où vous désirez exécuter des fichiers SSI/XSSI. Ceci
se fait dans le fichier access.conf. Maintenant, tous les fichiers avec
l'extension .shtml seront analysés relativement aux commandes SSI/XSSI.
Un autre moyen de faire fonctionner les inclusions est d'utiliser la directive
XBitHack. Si vous l'activez, il regardera si le fichier est
exécutable par l'utilisateur. Si il l'est et que Options Includes est
autorisé pour le répertoire, alors le fichier sera traité comme un fichier
SSI. Ceci fonctionne seulement pour les fichiers dont le type mime est
text/html (fichiers .html .htm). Ceci n'est pas la meilleure méthode.
Il y a un risque pour la sécurité en autorisant SSI à exécuter des commandes
systèmes et des scripts CGI. Toutefois il est possible de bloquer cette
possibilité avec la directire Option IncludesNOEXEC au lieu de Option
Includes dans le fichier access.conf. Toutes les autres commandes SSI
fonctionneront encore.
Pour plus d'informations voyez la documentation d'Apache mod_includes qui se trouve dans les sources. Elle est également disponible sur le site web à http://www.apache.org/docs/mod/mod_include.html.
Pour une discussion plus détaillée de l'implémentation SSI/XSSI voyez l'article d'Apacheweek à http://www.apacheweek.com/features/ssi.
Pour plus d'informations sur les commandes SSI voyez la documentation de la NCSA à http://hoohoo.ncsa.uiuc.edu/docs/tutorials/includes.html.
Pour plus d'informations sur les commandes XSSI allez sur ftp://pageplus.com/pub/hsf/xssi/xssi-1.1.html.
Les fonctionnalités d'Apache peuvent être étendues quasiment à l'infini avec les modules. Il existe déja beaucoup de modules. Seuls les modules d'intérêt général sont inclus dans Apache. Pour des pointeurs vers les modules existants allez voir le
Apache Module Registry à http://www.zyzzyva.com/module_registry/.
Pour les informations sur la programmation des modules voyez http://www.zyzzyva.com/module_registry/reference/