Apache
Apache est un serveur Web open source. Il est utilisé par plus de sites Web que tous les autres serveurs Web commerciaux réunis.
Apache 1.3 et les versions ultérieures peuvent charger et décharger dynamiquement des modules de configuration sans recompilation. L'intérêt de cette possibilité est d'ajouter dans les modules de configuration initiale des modules complémentaires spécifiques, comme par exemple un interpréteur Perl, un préprocesseur PHP ou encore le module de sécurisation SSL. De la sorte, le serveur Apache dispose de tous les modules dont il a besoin et d'aucun autre en plus.
La seule exigence du serveur Apache est la ram. Idéalement, un serveur Web ne devrait jamais devoir utiliser la mémoire virtuelle (swap). La RAM doit donc être suffisante pour supporter le niveau de trafic prévisionnel du serveur.
Sur Red Hat Linux, Apache nécessite les fichiers suivants :
Apacheconf-0.8-4
Apache-devel-1.3.20-8
Apache-1.3.20-8
Apache-manual-1.3.20-8 (ou versions ultérieures, en fonction de votre version d’OS).
Disposer d'un serveur Web Apache fonctionnel est relativement simple. Il faut :
1. S'assurer que les fichiers nécessaires à Apache sont installés. La fonction chkconfig permettra de vérifier que les fichiers sont effectivement lancés.
2.
Il faut que la machine ait un nom d'hôte valide. Cette
vérification se fera à la fois dans le fichier host et
dans httpd.conf (voir plus loin).
3. Démarrer le serveur Web :
/etc/init.d/httpd
start
4. Pour vérifier si le serveur fonctionne, il suffit d'ouvrir une page Mozilla, et de taper l'adresse : http ://127.0.0.1 ou http ://localhost. Une page test en anglais doit alors apparaître. S'il n'apparaît pas, vérifiez votre configuration avec les points précédents.
Il existait autrefois trois fichiers de configuration d'Apache. Httpd.conf, srm.conf, et access.conf. Aujourd'hui, une configuration complète se fait avec httpd.conf seulement.
Parcourons ce fichier :
La première section contient des commentaires sur la version du fichier : elle se repère par le caractère # placé au début de chaque ligne.
La section suivante s'appelle section 1 : global environment. Elle comprend les instructions de configuration générale du serveur.
On peut choisir Servertype standalone ou inetd. On choisira l'option inetd si l'emploi du serveur Web reste occasionnelle. Dans ce cas le démon xinetd se chargera de gérer chacune des nouvelles requêtes. Mais cette formule implique le lancement d'un nouveau démon à chaque requête et résulte en un temps de réponse plus long du serveur. Standalone est l'option par défaut pour un serveur Web d'utilisation courante.
Ce répertoire contient le fichier de configuration, un lien vers le répertoire de log, et un lien vers le répertoire de modules. A priori, on gardera l'option serverRoot /etc/httpd.
On peut choisir plusieurs options relatives au timeout. Les concepteurs du fichier de configuration ont mis des valeurs standard. On peut les conserver, et ne les changer que si l'on constate que les performances du serveur sont insuffisantes. Les commentaires relatifs à chaque valeur permettent d'en fixer facilement l'usage.
De la même façon, on peut choisir le nombre de processus simultanés. Au démarrage, un processus père de droit root engendre au moins 5 processus enfants (users Apache), et 20 au maximum. On lance au départ en général 8 processus père. On accepte par défaut 150 connexions simultanées. Chaque processus enfant peut procéder à 1000 requêtes avant d'être tué. Ce procédé évite les processus fantôme.
Cette directive permet de lier Apache à une adresse IP spécifiques et un port spécifique. Par exemple :Listen 12.34.56.78:3000 demandera au serveur Apache d'écouter le port 3000 sur l'adresse 12.34.56.78. Cette fonction est notamment utile dans le cas de serveur virtuel.
La suite du fichier de configuration contient la liste des modules qui peuvent ou qui sont lancés. Nous ne les détaillerons pas, puisqu'ils répondent à des besoins spécifiques (et sont donc détaillés dans des cours spécifiques) ou sont standards.
Seconde section : configuration du serveur principal
Comme son nom l'indique, cette section s'attache à décrire la configuration du serveur principal, c'est-à-dire le serveur lui-même dans le cas où on ne dispose pas d'hôte virtuel.
On définit dans l'ordre :
Le port sur lequel le serveur écoute par défaut (en général 80).
L'utilisateur que représente le serveur Apache. Comme on le dit plus haut, le serveur est root au lancement. Mais immédiatement, il engendre des processus enfants qui seront ceux qui feront fonctionner le serveur et qui n’auront pas des droits root. Par défaut, le serveur est représenté par l'utilisateur Apache, du groupe Apache.
L'e-mail de l'administrateur. Il est conseillé de le renseigner, parce que c'est à cette adresse que seront notamment envoyées les alertes.
Le nom du serveur. Dans le cas d'un serveur d’essai non connecté, on peut garder localhost. Dans le cas contraire, on donnera un nom du type bob.myhouse.com ou même http : //192.168.0.1.
Le répertoire qui contient les pages Web. Par défaut, /var/www/html. On peut garder ces valeurs, mais dans le cas d'un serveur de production il sera prudent de chrooter ce répertoire.
On peut accorder des autorisations spécifiques pour certains répertoires du serveur Web. C'est d'ailleurs là l’une des grandes forces d'Apache (voir plus loin).
On peut définir aussi le répertoire utilisateur qui sera obtenu lors de l'appel d'un utilisateur au-delà de l'adresse du serveur Web. Par défaut, c'est public_html. Ainsi, l'appel de:http://bob.myhouse.com/~toto renverra vers le répertoire /home/toto/public_html de la machine bob.myhouse.com.
La directive CachenegociatedDocs permet de mettre en place un service proxy sur le serveur ; ce n'est pas le cas par défaut. Cette fonction permet d'améliorer les performances, mais amène le risque de servir des pages obsolètes.
La directive UsecanonicalName permet, sans entrer dans les détails, d'éviter qu'un mot de passe soit demandé à chaque changement de pages. Les cours sur la sécurité donnent plus de détails sur ce point. Sur un serveur standard et des pages standard, mettre cette directive sur on est préférable. Dans le même esprit, la directive HostNameLookups, qui permet de transformer les adresses IP des demandeurs en nom restent sur off, sauf dans le cas de log particulier.
Les fichiers de log par défaut répondent aux mêmes remarques que les fichiers de log des autres serveurs, ainsi que les précautions d'usage relatives au fichier log sur des machines connectées directement à l'Internet.
Suivent plusieurs lignes de configuration de confort, qui permettent au serveur de présenter un aspect plus professionnel ; ainsi par exemple les fichiers d'alias ; les pointeurs de redirection dans le cas de demande de pages obsolètes ; les directives d’index, qui permettent par exemple d'adopter des icônes spécifiques pour chaque type de fichier ; les fichiers de définition de langue des pages servies et de compression -décompression à la volée.
Un peut définir enfin les réponses à certaines erreurs pour par exemple, soit pointer une erreur 404 vers un fichier spécifique, soit déclencher une action spécifique.
La capacité d'Apache à accueillir des hôtes virtuels permet à un serveur Web de prendre en charge les requêtes entrantes pour le compte de plusieurs sites. Le contenu, les scripts, les log, peuvent tous être gérés séparément.
On définit en général plusieurs noms de sites pour une seule adresse I. P..
Par exemple :
NamevirtualHost 192.168.0.1 # répartir les requêtes à cette adresse en plusieurs hôtes.
<VirtualHost 192.168.0.1> #configuration de l'hôte virtuel qui est à cette adresse.
ServerAdmin toto@mysite.com
DocumentRoot /var/www/html/mysite
ServerName www.mysite.com
Logs…
</VirtualHost>
<VirtualHost 192.168.0.1>
ServerAdmin tutu@newsite.com
DocumentRoot /var/www/html/newsite
ServerName www.newsite.com.
Logs…
</VirtualHost>
Souvenez-vous que si l'adresse I. P.NamevirtualHost est la seule adresse I. P. sur cet hôte, vous devez ajouter en tant que de VirutalHost le DocumentRoot par défaut.
Ce fichier permet de gérer l'accès sécurisé à certains répertoires. Ce contrôle se construit en deux étapes :
Par exemple :
htpasswd - - c /var/data/webl/secret/.htpasswd toto
Cette commande créé dans le répertoire secret un fichier htpasswd pour l'utilisateur Toto. Le programme demande alors le mot de passe de l'utilisateur Toto et créé le fichier. Pour des raisons de sécurité, ce fichier n'est habituellement pas créé dans l'arborescence du site Web.
Un man htpasswd vous renseignera sur l'option –c et les autres qui sont disponibles. Un cat sur le fichier .htpasswd donnera une ligne du type toto :hulR6FFh1sxK6.
Avec un éditeur de texte, on crée un fichier du type :
AuthName « Only for Toto »
AuthType Basic
AuthUserFile /var/data/webl/secret/.htpasswd
Require user toto
La première directive concerne le message que reçoit l'utilisateur qui essaye de se connecter au répertoire. La seconde définit le type d'authentification nécessaire ; elle est toujours sur basic. La troisième donne le chemin du fichier des mots de passe, et la dernière indique que seul l'utilisateur Toto peut accéder au répertoire. Ce fichier se place dans le répertoire que l’on souhaite protéger (par exemple /home/toto/public_html).
Avant de tester cette restriction d'accès, vérifiez que seul l'utilisateur Apache peut accéder en lecture aux deux fichiers .htaccess et .htpasswd.
Une variante de cette restriction d'accès permet de créer un fichier .htgroup au lieu de .htpasswd qui comprend la liste des utilisateurs du groupe autorisé à se connecter au répertoire (du type this_group : toto titi) ; le fichier .htaccess comprendra alors la ligne require group this_group au lieu de user.
Dans le fichier de configuration d’apache, on repère (pour le bon ordre) la zone qui comprend les directives <Directory>, et on ajoute :
<Directory /home/toto/public_html>
AllowOverride AuthConfig
</Directory>
Plusieurs fichiers permettent de suivre les activités d'Apache.
Ainsi la page http://locahost/server-info permet de lire les informations de configuration par défaut du serveur.
De même la page http://locahost/server-status permet de contrôler le statut du serveur et les processus en cours.
Le fichier de configuration d'Apache permet de définir si ces pages seront accessibles à distance, ce qui est pratique mais risqué, ou si elles ne pourront être lues qu’en local.
Chaque demande de pages reçues par le serveur est loguée. La lecture des logs permet elle aussi de suivre l'activité du serveur.
Par ailleurs, la commande webalizer permet d'analyser les logs d'Apache pour en faire une lecture ultérieure. Si tout se passe bien, cette commande devrait faire travailler la machine silencieusement pendant un moment, et s'interrompre sans message d’alerte. Pour lire le fichier de sortie, on lancera par exemple mozilla /var/www/html/usage/index.html.
Apache comporte de nombreuses autres options de configuration, que l’on peut notamment lire dans le fichier httpd.conf. N’hésitez pas à les essayer pour les comprendre (sur un serveur de test bien sûr, pas sur un serveur de production !), avec une règle d’or : chaque modification demande un redémarrage du serveur Apache, et un test individuel ! En cas de doute, il existe des milliers de ressources sur Internet, à commencer par www.apache.org.