Red Hat Linux 7.1: Guide de référence officiel Red Hat Linux | ||
---|---|---|
Précédent | Chapitre 14. Directives et modules Apache | Suivant |
Le fichier de configuration du serveur Web Apache est /etc/httpd/conf/httpd.conf. Le fichier httpd.conf est bien commenté et parle de lui-même. Sa configuration par défaut fonctionnera pour la plupart des clients. Vous ne devrez donc probablement pas changer ses directives dans httpd.conf. Vous pourriez cependant vouloir vous familiariser avec les options de configuration les plus importantes.
Les fichiers vides srm.conf et access.conf se trouvent également dans le répertoire /etc/httpd/conf. Les fichiers srm.conf et access.conf était auparavant utilisés, avec httpd.conf, comme des fichiers de configuration pour Apache.
Si vous voulez configurer Apache, il vous suffit de modifier httpd.conf et de recharger (ou d'arrêter et rallumer) le processus httpd. La la section intitulée Démarrage et arrêt httpd illustre comment recharger, arrêter et relancer Apache.
Avant de modifier httpd.conf, copiez avant tout le fichier original comme httpd.confold (ou tout autre nom). Si vous commettez ensuite une erreur durant la modification du fichier de configuration, vous devrez utiliser la copie de sauvegarde.
Si vous commettez une erreur et que votre server Web ne fonctionne pas correctement, la première chose à vérifier est ce que vous avez modifié dans le fichier httpd.conf. Vérifiez si vous n'avez pas commis de faute de frappe. La seconde chose à vérifier est le journal des erreurs du serveur Web (/var/log/httpd/error_log). Le journal des erreurs peut vous sembler difficile à interpréter si vous manquez d'expérience. Toutefois, si vous venez de rencontrer un problème, les dernières entrées du journal des erreurs devraient fournir certaines indications sur ce qu'il s'est passé.
Les sections suivantes contiennent de brèves descriptions des directives incluses dans le fichier httpd.conf, dans l'ordre dans lequel elles se présentent. Ces descriptions ne sont pas exhaustives. Pour plus d'informations, reportez-vous à la documentation d'Apache fournie au format HTML à l'adresse http://votre_domaine/manual/ ou à la documentation en ligne du groupe Apache à l'adresse http://httpd.apache.org/docs/ . Pour plus d'informations sur les directives mod_ssl, reportez-vous à la documentation incluse au format HTML à l'adresse http://votre_domaine/manual/mod/mod_ssl/, ou consultez le document mod_ssl User Manual à l'adresse http://www.modssl.org/docs/2.7/ .
Votre ServerType peut être inetd ou standalone. Par défaut, votre serveur est paramétré sur ServerType standalone.
ServerType standalone signifie que le serveur est démarré une fois, après quoi il s'occupe de toutes les connexions. ServerType inetd signifie qu'une nouvelle instance du serveur est démarrée pour chaque connexion HTTP. Chaque instance du serveur prend en charge la connexion, puis s'arrête une fois la connexion terminée. Comme vous pouvez l'imaginer, inetd n'est pas très efficace. Un autre problème est que inetd risque de ne pas fonctionner correctement, selon le groupe Apache. Enfin, du fait que Red Hat Linux 7.1 utilise xinetd, une configuration supplémentaire sera nécessaire pour faire en sorte que xinetd démarre le serveur. C'est pourquoi il est préférable de laisser le ServerType de votre secure Web server paramétré sur standalone.
Le ServerRoot est le répertoire de niveau supérieur qui contiendra les fichiers du serveur. Les serveurs tant sécurisé que non sécurisé sont paramétrés pour utiliser le ServerRoot /etc/httpd.
LockFile est le chemin d'accès du fichier de blocage utilisé lorsque le serveur Apache est compilé avec USE_FCNTL_SERIALIZED_ACCEPT ou USE_FLOCK_SERIALIZED_ACCEPT. LockFile doit normalement conserver sa valeur par défaut.
PidFile est le nom du fichier dans lequel le serveur consigne son identifiant de processus (pid). Votre serveur Web est paramétré pour consigner son pid dans /var/run/httpd.pid.
The ScoreBoardFile stocke les informations internes au processus serveur utilisées pour la communication entre le processus serveur père et ses processus fils. Le ScoreBoardFile de votre serveur Web est défini sur /var/run/httpd.scoreboard.
La directive ResourceConfig donne pour instruction au serveur de lire un fichier pour plus de directives. Un commentaire est ajouté à la directive ResourceConfig car votre serveur Web utilise httpd.conf uniquement pour les directives de configuration.
La directive AccessConfig donne pour instruction au serveur de lire le fichier dont le nom figure après AccessConfig après avoir lu le fichier nommé ResourceConfig. La directive AccessConfig est identifiée comme un commentaire parce que votre serveur Web utilise uniquement httpd.conf pour les directives de configuration.
Timeout définit, en secondes, le temps pendant lequel votre serveur attend des réceptions et des émissions en cours de communication. Plus spécifiquement, Timeout définit le temps pendant lequel le serveur attend de recevoir une demande GET, le temps pendant lequel il attend de recevoir des paquets TCP sur une requête POST ou PUT et le temps pendant lequel il attend entre des ACK répondant aux paquets TCP. Timeout est défini sur 300 secondes, ce qui convient dans la plupart des cas.
KeepAlive définit si votre serveur autorisera des connexions persistantes (c'est-à-dire plusieurs demandes par connexion). KeepAlive peut être utilisé pour empêcher tout client de consommer trop de ressources du serveur. Par défaut, KeepAlive est défini sur on, ce qui signifie que votre serveur autorise les connexions persistantes. Vous pouvez le définir sur off, ce qui désactive les connexions persistantes. Reportez-vous à la la section intitulée MaxKeepAliveRequests pour connaître une manière apparentée de limiter le nombre de demandes par connexion.
Cette directive définit le nombre maximum de demandes autorisées par connexion persistante. Le groupe Apache recommande d'utiliser un paramétrage élevé, qui améliorera les performances de votre serveur. Par défaut, MaxKeepAliveRequests est paramétré sur 100, ce qui convient dans la plupart des cas.
KeepAliveTimeout définit la durée en secondes pendant laquelle votre serveur attendra, après avoir servi une demande, la demande suivante, avant d'interrompre la connexion. Une fois une demande reçue, c'est la directive Timeout qui s'applique à la place.
Le serveur Web Apache s'adapte de façon dynamique à la charge reçue en maintenant un nombre de processus serveur de rechange approprié en fonction du trafic. Le serveur vérifie le nombre de processus attendant une requête et en supprime s'ils sont plus nombreux que MaxSpareServers ou en crée s'ils sont moins nombreux que MinSpareServers.
La valeur MinSpareServers par défaut de votre serveur est 5 ; la valeur MaxSpareServers par défaut de votre serveur est 20. Ces paramètres par défaut doivent être appropriés dans presque toutes les situations. Ne définissez pas une valeur très élevée pour MinSpareServers car cela créera une charge de traitement importante sur le serveur, même si le trafic est faible.
StartServers définit le nombre de processus créés au démarrage. Du fait que le serveur Web supprime et crée des processus serveur, de façon dynamique en fonction de la charge du trafic, il est inutile de modifier ce paramètre. Votre serveur Web est réglé pour lancer huit processus serveur au démarrage.
MaxClients définit une limite au nombre total de processus serveur (c'est-à-dire le nombre de clients connectés simultanément) pouvant s'exécuter en même temps. Conservez une valeur élevée pour MaxClients (par défaut, la valeur du serveur est réglée sur 150) car personne d'autre ne sera autorisé à se connecter une fois ce nombre atteint. Vous ne pouvez pas définir pour MaxClients une valeur supérieure à 256 sans recompiler Apache. La principale raison d'être de MaxClients est d'éviter qu'un serveur Web surchargé ne perturbe votre système d'exploitation.
MaxRequestsPerChild définit le nombre total de demandes que chaque processus serveur fils sert avant de disparaître. La principale raison justifiant de définir MaxRequestsPerChild consiste à éviter des pertes de mémoire induites par les processus longs. La valeur par défaut de MaxRequestsPerChild pour votre serveur est 100.
Listen identifie les ports sur lesquels votre serveur Web accepte les demandes entrantes. Votre secure Web server est paramétré pour écouter sur le port 80 pour les communications Web non sécurisées et (dans les balises d'hôte virtuel définissant le serveur sécurisé) sur le port 443 pour les communications Web sécurisées.
Si vous paramétrez Apache pour écouter sur un port dont le numéro est inférieur à 1024, le processus httpd devra démarrer avec les droits de root. Pour les ports dont le numéro est égal ou supérieur à 1024, httpd peut démarrer comme utilisateur normal.
Listen peut également être utilisée pour spécifier des adresses IP particulières sur lesquelles le serveur acceptera des connexions.
BindAddress permet de spécifier les adresses IP pour lesquelles votre serveur réagira. Utilisez plutôt la directive Listen si vous avez besoin de cette fonctionnalité. La commande BindAddress n'est pas utilisée par votre serveur Web ; par défaut, elle est identifiée comme un commentaire dans httpd.conf.
LoadModule est utilisée pour charger des modules DSO (Dynamic Shared Object, objet partagé dynamique). Pour plus d'informations sur le support DSO de secure Web server, y compris la manière précise d'utiliser la directive LoadModule, reportez-vous à la la section intitulée Ajout de modules au serveur. L'ordre des modules étant important, ne les déplacez pas.
Les balises <IfDefine> et </IfDefine> entourent des directives de configuration. Elles s'appliquent si le "test" indiqué dans la balise <IfDefine> est vrai ; les directives sont ignorées si le test est faux.
Le test dans les balises <IfDefine> est un nom de paramètre (par exemple, HAVE_PERL). Si le paramètre est défini (c'est-à-dire spécifié comme argument de la commande de démarrage du serveur), le test est vrai. Dans ce cas, votre secure Web server est démarré, le test est vrai et les directives contenues dans les balises IfDefine sont appliquées.
Par défaut, les balises <IfDefine HAVE_SSL> entourent les balises d'hôtes virtuels pour votre serveur sécurisé. Les balises <IfDefine HAVE_SSL> entourent également les directives LoadModule et AddModule pour le ssl_module.
ClearModuleList est située immédiatement avant la longue liste de directives AddModule. ClearModuleList efface la liste de modules actifs dans le serveur. Ensuite, la liste de directives AddModule recrée la liste, immédiatement après ClearModuleList.
AddModule est la directive utilisée pour créer une liste complète de tous les modules disponibles. Vous utiliserez la directive AddModule si vous ajoutez votre propre module comme DSO. Pour plus d'informations sur la manière dont AddModule est utilisé pour la prise en charge de DSO, reportez-vous à la la section intitulée Ajout de modules au serveur.
ExtendedStatus contrôle le fait qu'Apache génère des informations d'état sommaires (off) ou détaillées (on) lorsque le module de commande server-status est appelé. Server-status est appelé à l'aide des balises Location ; pour plus d'informations sur l'appel de server-status, reportez-vous à la la section intitulée Location.
Normalement, Port définit le port sur lequel votre serveur écoute. Toutefois, le secure Web server contrôle plusieurs ports par défaut, du fait que la directive Listen est également utilisée. Lorsque les directives Listen sont activées, votre serveur contrôle tous ces ports. Pour plus d'informations sur Listen, reportez-vous à la description de la directive Listen.
La commande Port est également utilisée pour spécifier le numéro de port utilisé pour créer un nom autorisé pour votre serveur. Reportez-vous à la la section intitulée UseCanonicalName pour plus d'informations sur le nom canonique de votre serveur.
La directive User définit l'ID utilisateur utilisé par le serveur pour répondre aux demandes. Le paramétrage de User détermine l'accès au serveur. Tous les fichiers inaccessibles à cet utilisateur seront également inaccessibles aux visiteurs de votre site Web. La valeur par défaut pour User est apache.
User devrait avoir pour seuls privilèges la possibilité d'accéder à des fichiers supposés visibles par le monde extérieur. User est également le propriétaire de tous les processus CGI engendrés par le serveur. User ne devrait pas être autorisé à exécuter un code non destiné à constituer une réponse à des demandes HTTP.
Remarque | |
---|---|
A moins d'être absolument certain de savoir ce que vous faites, ne paramétrez pas User sur root. Le fait d'utiliser root comme valeur pour User risque d'ouvrir une brèche importante dans la sécurité de votre serveur Web. |
Le processus httpd parent commence par s'exécuter comme root en cours de fonctionnement normal, puis est immédiatement transmis à l'utilisateur apache. Le serveur doit démarrer comme root parce qu'il doit se relier à un port sous 1024 (le port par défaut pour les communications Web sécurisées est le port 443 ; le port par défaut pour les communications Web non sécurisées est le port 80). Les ports sous 1024 étant réservés à l'usage du système, ils ne peuvent être utilisés que par quelqu'un connecté en tant que root. Une fois que le serveur s'est connecté à son port, il transmet le processus au User avant d'accepter la moindre demande de connexion.
La directive Group est similaire à User. Group définit le groupe sous lequel le serveur répondra à des demandes. La valeur de Group par défaut est également apache.
ServerAdmin indique l'adresse électronique de l'administrateur du serveur Web. Cette adresse électronique apparaîtra dans les messages d'erreur sur les pages Web générées par le serveur afin que les utilisateurs puissent signaler un problème en envoyant un message électronique à l'administrateur du serveur. La valeur par défaut de ServerAdmin est root@localhost.
Généralement, une bonne manière de configurer ServerAdmin consiste à utiliser la valeur webmaster@votre_domaine.com. Ensuite, créez un alias pour webmaster au nom de la personne responsable du serveur Web, dans /etc/aliases. Enfin, exécutez /usr/bin/newaliases pour ajouter le nouvel alias.
ServerName permet de définir un nom pour votre serveur, qui diffère du nom réel de votre hôte. Par exemple, vous pouvez utiliser www.votre_domaine.com alors que le nom réel de votre serveur est foo.votre_domaine.com. Notez que ServerName doit être un nom DNS (Domain Name Service) valide de la machine sur laquelle tourne le serveur.
Si vous spécifiez un ServerName, assurez-vous que son adresse IP et son nom de serveur sont inclus dans votre fichier /etc/hosts.
DocumentRoot est le répertoire contenant la plupart des fichiers HTML qui seront servis en réponse aux demandes. La valeur de DocumentRoot par défaut pour les serveurs Web sécurisés et non sécurisés est /var/www/html. Par exemple, le serveur pourrait recevoir une demande pour le document suivant :
http://votre_domaine/foo.html |
Le serveur recherchera le fichier suivant dans le répertoire par défaut :
/var/www/html/foo.html |
Si vous voulez modifier le DocumentRoot afin qu'il ne soit pas partagé par les serveurs Web sécurisés et non sécurisés, reportez-vous à la la section intitulée Utilisation d'hôtes virtuels.
Les balises <Directory /path/to/directory> et </Directory> sont utilisées pour entourer un groupe de directives de configuration devant uniquement s'appliquer à ce répertoire et tous ses sous-répertoires. Toute directive applicable à un répertoire peut être utilisée à l'intérieur des balises <Directory>. Les balises <File> peuvent être utilisées de la même manière, appliquées à un fichier spécifique.
Par défaut, des paramètres très restrictifs sont appliqués au répertoire racine, à l'aide des directives Options (voir la section intitulée Options) et AllowOverride (voir la section intitulée AllowOverride). Dans cette configuration, il faut explicitement attribuer ces paramètres à tout répertoire du système ayant besoin de paramètres plus permissifs.
Les balises Directory permettent de définir le DocumentRoot (désigné comme "/") avec des paramètres moins rigides, de manière à ce qu'il puisse servir des demandes HTTP.
Le répertoire cgi-bin est configuré pour permettre l'exécution de scripts CGI avec l'option ExecCGI. Si vous devez exécuter un script CGI dans un autre répertoire, vous devez définir ExecCGI pour ce répertoire. Par exemple, si votre répertoire cgi-bin est /var/www/cgi-bin mais que vous voulez exécuter des scripts CGI depuis /home/mon_répertoire_cgi, ajoutez une directive ExecCGI à un ensemble de directives Directory tel que le suivant dans votre fichier httpd.conf :
<Directory /home/my_cgi_directory> Options +ExecCGI </Directory> |
Pour permettre l'exécution de scripts CGI dans /home/my_cgi_directory, il vous faudra entreprendre des démarches supplémentaires au paramétrage de ExecCGI. Vous devrez aussi décommander la directive AddHandler pour identifier les fichiers qui ont une extension .cgi (scripts CGI). Vous trouverez des instructions sur le paramétrage de AddHandler dans la la section intitulée AddHandler. Les permissions pour les scripts CGI et le chemin d'accès aux scripts doivent être paramétrés à 0755. Enfin, le script et le répertoire doivent être détenus par le même utilisateur.
La directive Options contrôle les fonctions du serveur disponibles dans un répertoire particulier. Par exemple, en vertu des paramètres restrictifs spécifiés pour le répertoire racine, Options est défini uniquement sur FollowSymLinks. Aucune fonction n'est activée, à l'exception du fait que le serveur est autorisé à suivre les liens symboliques dans le répertoire racine.
Par défaut, dans votre répertoire DocumentRoot, Options est paramétré pour inclure Indexes, Includes et FollowSymLinks. Indexes permet au serveur de générer le contenu d'un répertoire si aucun DirectoryIndex (c'est-à-dire index.html, etc.) n'est spécifié. Includes signifie que des fichiers à inclure côté serveur sont autorisés. FollowSymLinks permet au serveur de suivre des liens symboliques dans ce répertoire.
Vous devez également inclure des instructions Options pour les répertoires à l'intérieur de directives d'hôtes virtuels si vous voulez que vos hôtes virtuels reconnaissent ces Options.
Par exemple, les fichiers à inclure côté serveur sont déjà activés dans le répertoire /var/www/html en raison de la présence de la ligne Options Includes dans la section des directives Location "/". Toutefois, si vous voulez qu'un hôte virtuel reconnaisse que les fichiers à inclure côté serveur sont autorisés dans /var/www/html, vous devez inclure une section telle que la suivante à l'intérieur des balises de votre hôte virtuel :
<Directory /var/www/html> Options Includes </Directory> |
La directive AllowOverride définit si des Options peuvent être invalidées par les instructions d'un fichier .htaccess. Par défaut, DocumentRoot est paramétré pour ne pas autoriser la prise en compte des instructions de fichiers .htaccess .
La directive Order contrôle simplement l'ordre dans lequel les directives Allow et Deny sont analysées. Votre serveur est configuré pour analyser les directives Allow avant les directives Deny pour votre répertoire DocumentRoot.
Allow spécifie quel demandeur peut accéder à un répertoire donné. Le demandeur peut être all, un nom de domaine, une adresse IP, une adresse IP partielle, une paire réseau/masque réseau, etc. Votre répertoire DocumentRoot est configuré pour Allow (permettre) les demandes de all (tous).
Deny fonctionne exactement comme allow, mais vous spécifiez à qui l'accès est refusé. Votre DocumentRoot n'est pas configuré pour deny (refuser) les demandes de quiconque.
UserDir est le nom du sous-répertoire, au sein du répertoire de départ personnel de chaque utilisateur, où devraient être placés les fichiers HTML personnels devant être servis par le serveur Web. Par défaut, le sous-répertoire est public_html. Par exemple, le serveur pourrait recevoir la demande suivante :
http://votre_domaine/~utilisateur/foo.html |
Le serveur rechercherait le fichier :
/home/utilisateur/public_html/foo.html |
Dans l'exemple ci-dessus, /home/utilisateur est le répertoire personnel de l'utilisateur (notez que le chemin d'accès par défaut aux répertoires personnels des utilisateurs peut être différent sur votre système).
Assurez-vous que les autorisations relatives aux répertoires personnels des utilisateurs sont correctement définies. Les répertoires personnels des utilisateurs doivent être définis sur 0755. Les bits de lecture (r) et d'exécution (x) doivent être définis sur les répertoires public_html de l'utilisateur (0755 fonctionnera). Les fichiers qui seront servis dans les répertoires public_html des utilisateurs doivent être définis sur au moins 0644.
DirectoryIndex est la page servie par défaut lorsqu'un utilisateur demande un index de répertoire en insérant une barre oblique (/) à la fin de l'URL.
Lorsqu'un utilisateur demande la page http://votre_domaine/ce_répertoire/, il obtient soit la page DirectoryIndex, si elle existe, soit la liste du contenu du répertoire générée par le serveur. La valeur par défaut pour DirectoryIndex est index.html index.htm index.shtml index.php index.php4 index.php3 index.cgi. Le serveur essaie de trouver l'un de ces fichiers et retourne le premier qu'il trouve. S'il ne trouve aucun de ces fichiers et si Options Indexes est paramétré pour ce répertoire, le serveur génère et retourne une liste, au format HTML, des fichiers et sous-répertoires contenus dans le répertoire.
AccessFileName nomme le fichier que le serveur doit utiliser pour les informations de contrôle d'accès dans chaque répertoire. Par défaut, votre serveur Web est paramétré pour utiliser .htaccess, s'il existe, afin d'accéder aux informations de contrôle d'accès dans chaque répertoire.
Juste après la directive AccessFileName, une série de balises Files appliquent un contrôle d'accès à tout fichier commençant par .ht. Ces directives refusent l'accès Web à tous les fichiers .htaccess (ou d'autres commençant par .ht) pour des raisons de sécurité.
Par défaut, votre serveur Web demande aux serveurs proxy de ne pas mettre en cache des documents négociés sur la base du contenu (c'est-à-dire qui peuvent changer avec le temps ou suite à l'entrée du demandeur). Si vous annulez le commentaire de CacheNegotiatedDocs, vous désactivez cette fonction et les serveurs proxy seront autorisés à mettre en cache les documents à partir de ce moment.
UseCanonicalName est paramétré par défaut sur on. UseCanonicalName permet au serveur de créer une URL qui se référence elle-même, en utilisant ServerName et Port. Lorsque le serveur fait référence à lui-même en réponse aux demandes des clients, il utilise cette URL. Si vous paramétrez UseCanonicalName sur off, le serveur utilisera plutôt la valeur figurant dans la demande du client pour pointer sur lui-même.
TypesConfig nomme le fichier qui définit la liste par défaut des correspondances de type MIME (extensions de nom de fichier associées à des types de contenu). Le fichier TypesConfig par défaut est /etc/mime.types. Au lieu d'éditer /etc/mime.types, il est recommandé d'ajouter des types MIME à l'aide de la directive AddType.
DefaultType définit un type de contenu par défaut pour le serveur Web à utiliser pour des documents dont les types MIME ne peuvent pas être déterminés. Par défaut, votre serveur Web suppose que tout fichier au contenu indéterminé est de type texte brut.
Les balises <IfModule> et </IfModule> entourent des directives conditionnelles. Les directives contenues à l'intérieur des balises IfModule sont traitées dans l'un des deux cas suivants. Les directives sont traitées si le module contenu dans la balise de début <IfModule> est compilé dans le serveur Apache. Si un point d'exclamation ("!") est inclus devant le nom du module, les directives ne sont traitées que si le module dans la balise de départ <IfModule> n'est pas compilé.
Le fichier mod_mime_magic.c est utilisé dans ces balises IfModule. Le module mod_mime_magic est comparable à la commande UNIX file, qui examine quelques octets du contenu d'un fichier, puis utilise des "nombres magiques" et d'autres indices pour déterminer le type MIME du fichier.
Si le module mod_mime_magic est compilé dans Apache, ces balises IfModule indiquent au module mod_mime_magic où se trouve le fichier de définition des indices : share/magic dans ce cas.
Le module mod_mime_magic n'est pas compilé par défaut. Si vous voulez l'utiliser, reportez-vous à la la section intitulée Ajout de modules au serveur pour plus de détails sur la manière d'ajouter des modules à votre serveur.
HostnameLookups peut être défini sur on, off ou double. Si vous autorisez HostnameLookups (en le paramétrant sur on), votre serveur résoudra automatiquement l'adresse IP pour chaque connexion demandant un document de votre serveur Web. La résolution de l'adresse IP signifie que votre serveur établit une ou plusieurs connexions avec le DNS pour rechercher le nom d'hôte correspondant à une adresse IP particulière. Si vous paramétrez HostnameLookups en double, votre serveur établira un DNS double inversé. En d'autres termes, après la recherche inverse (IP vers nom), une recherche en avant (nom vers IP) est lancée sur le résultat. Cette double recherche doit ramener à l'adresse IP de départ.
Généralement, vous devez laisser HostnameLookups paramétré sur off, du fait que les demandes de DNS ajoutent une charge à votre serveur et peuvent le ralentir. Si votre serveur est occupé, les effets de HostnameLookups peuvent être sensibles.
HostnameLookups pose également une question pour Internet dans son ensemble. Les connexions individuelles établies pour rechercher chaque nom d'hôte s'additionnent. C'est pourquoi, pour le bien de votre propre serveur Web, de même que pour celui d'Internet dans son ensemble, laissez HostnameLookups paramétré sur off.
ErrorLog nomme le fichier dans lequel sont consignées les erreurs du serveur. Comme cette directive l'indique, le fichier journal des erreurs relatif à votre serveur Web se trouve dans /var/log/httpd/error_log.
Le journal des erreurs est intéressant si votre serveur Web génère des erreurs ou des pannes dont vous ne connaissez pas la cause.
LogLevel définit le niveau de détail des messages d'erreur des journaux des erreurs. LogLevel peut être défini (du moins détaillé au plus détaillé) sur emerg, alert, crit, error, warn, notice, info ou debug. Par défaut, le LogLevel de votre serveur Web est défini sur warn.
Les directives LogFormat de votre fichier httpd.conf définissent un format pour les messages d'erreur ; ce format devrait rendre votre journal des accès plus lisible.
CustomLog identifie le fichier journal et le format de fichier journal. Dans la configuration par défaut de votre secure Web server, CustomLog définit le fichier journal dans lequel sont consignés les accès à votre serveur Web : /var/log/httpd/access_log. Vous devez connaître l'emplacement de ce fichier pour pouvoir générer des statistiques concernant les performances d'accès à votre serveur Web.
CustomLog définit également le format du fichier journal ordinaire. Le format du fichier journal ordinaire ressemble à ceci :
remotehost rfc931 authuser [date] "request" status bytes |
Nom d'hôte distant. Si le nom d'hôte n'est pas disponible auprès du DNS, ou si HostnameLookups est paramétré sur Off, remotehost sera l'adresse IP de l'hôte distant.
Non utilisé. Le signe - figure dans le fichier journal à sa place.
Si l'authentification est requise, il s'agit du nom sous lequel l'utilisateur s'est identifié. Habituellement, il n'est pas utilisé, de sorte que vous voyez le signe - à sa place.
La date et l'heure de la demande.
La chaîne de demande telle qu'elle est venue du navigateur ou du client.
Code d'état retourné au navigateur ou au client.
Taille du document.
La commande CustomLog permet de configurer des fichiers journaux spécifiques pour enregistrer des pointeurs (URL de la page Web liée à une page de votre serveur Web) et/ou des agents (navigateurs utilisés pour récupérer des pages Web sur votre serveur Web). Les lignes CustomLog correspondantes sont identifiées comme des commentaires, comme illustré, mais vous devez supprimer le commentaire si vous voulez utiliser ces deux fichiers journaux :
#CustomLog /var/log/httpd/referer_log referer #CustomLog /var/log/httpd/agent_log agent |
Vous pouvez également définir la directive CommonLog pour qu'elle utilise un journal combiné en supprimant le commentaire de la ligne suivante :
#CustomLog /var/log/httpd/access_log combined |
Un journal combiné ajoutera les champs du pointeur et de l'agent à la fin des champs de journal communs. Si vous voulez utiliser un journal combiné, commentez la directive CustomLog définissant votre journal des accès sur le format de fichier journal commun.
La directive ServerSignature ajoute une ligne contenant la version du serveur Apache et le ServerName de l'hôte servant à tout document généré par le serveur (par exemple, les messages d'erreur renvoyés à des clients). ServerSignature est paramétré sur on par défaut. Vous pouvez définir la valeur off afin qu'aucune ligne de signature ne soit ajoutée, ou définir la valeur EMail. EMail ajoute une balise HTML mailto:ServerAdmin à la ligne de signature.
Le paramètre Alias permet aux répertoires de se trouver en dehors du répertoire DocumentRoot tout en restant accessibles au serveur Web. Toute URL se terminant par l'alias sera automatiquement convertie en chemin d'accès de l'alias. Par défaut, un alias est déjà configuré. Un répertoire icons est accessible par le serveur Web, mais le répertoire n'est pas le DocumentRoot. Le répertoire icons, un alias, est en réalité /var/www/icons/, pas /var/www/html/icons/.
Le paramètre ScriptAlias définit l'endroit où les scripts CGI (ou d'autres types de scripts) peuvent être trouvés. Généralement, il est préférable de ne pas laisser de scripts CGI dans DocumentRoot. Si des scripts CGI figurent dans DocumentRoot, ils pourraient être considérés comme des documents de texte. Même s'il vous est indifférent que certaines personnes peuvent voir (et utiliser) vos scripts CGI, le fait de révéler la manière dont ils fonctionnent peut permettre à des personnes peu scrupuleuses d'exploiter d'éventuelles failles de sécurité du script, menaçant ainsi la sécurité de votre serveur. Par défaut, le répertoire cgi-bin est un ScriptAlias de /cgi-bin/, et se trouve en réalité dans /var/www/cgi-bin/.
Options ExecCGI est sélectionné pour votre répertoire /var/www/cgi-bin, ce qui signifie que l'exécution de scripts CGI est autorisée dans ce répertoire.
Reportez-vous à la la section intitulée AddHandler et à la la section intitulée Directory pour obtenir des instructions sur la manière d'exécuter des scripts CGI dans des répertoires autres que cgi-bin.
Lorsqu'une page Web est déplacée, la commande Redirect peut être utilisée pour mapper l'ancienne URL sur une autre URL. Le format est le suivant :
Redirect /chemin/foo.html http://nouveau_domaine/chemin/foo.html |
Ainsi, si une demande HTTP est reçue pour une page qui se trouve habituellement à l'URL http://votre_domaine/chemin/foo.html, le serveur retourne la nouvelle URL (http://nouveau_domaine/chemin/foo.html) au client, qui essaie d'extraire le document de la nouvelle URL.
contrôle l'aspect des listes de contenu de répertoire générées par le serveur en ajoutant des icônes et des descriptions de fichiers, etc. Si Options Indexes est défini (voir la section intitulée Options), votre serveur Web peut générer une liste du contenu du répertoire lorsqu'il reçoit une demande HTTP telle que celle-ci :
http://votre_domaine/ce_répertoire
Tout d'abord, votre serveur Web recherche dans ce répertoire un fichier de la liste figurant après la directive DirectoryIndex (par exemple, index.html). Si votre serveur Web ne trouve pas l'un de ces fichiers, il génère une liste HTML des fichiers et sous-répertoires figurant dans ce répertoire. Vous pouvez modifier l'aspect de cette liste du contenu du répertoire à l'aide de certaines directives de httpd.conf, notamment IndexOptions.
Par défaut, FancyIndexing est activé. Si FancyIndexing est activé, le fait de cliquer sur les en-têtes de colonne de la liste modifie l'ordre d'affichage en fonction du contenu de cette colonne. Un autre clic sur le même en-tête permet de basculer de l'ordre ascendant à l'ordre descendant, et inversement. FancyIndexing affiche également des icônes différentes pour les différents fichiers, en fonction des extensions de fichier. Si vous utilisez la directive AddDescription et activez FancyIndexing, une brève description de fichier sera incluse dans la liste du contenu du répertoire générée par le serveur.
IndexOptions comprend un certain nombre d'autres paramètres qui peuvent être définis pour contrôler l'aspect des répertoires générés par le serveur. Les paramètres incluent IconHeight et IconWidth, pour faire en sorte que le serveur inclue des balises HTML HEIGHT et WIDTH pour les icônes dans les pages Web générées par le serveur ; IconsAreLinks, pour faire en sorte que les icônes agissent comme une partie de l'ancre du lien HTML, en même temps que le nom de fichier, et autres.
Cette directive nomme des icônes qui seront affichées par fichier, avec codage MIME, dans des listes de répertoire générées par le serveur. Par défaut, votre serveur Web montre l'icône compressed.gif à côté des fichiers codés MIME x-compress et x-gzip dans des listes de répertoire générées par serveur.
Cette directive nomme des icônes qui s'afficheront à côté des fichiers avec des types MIME dans des listes de répertoire générées par serveur. Par exemple, votre serveur est paramétré pour afficher l'icône text.gif à côté de fichiers avec un type MIME "texte" dans des listes de répertoire générées par serveur.
AddIcon indique au serveur l'icône à afficher dans les listes de répertoire générées par le serveur pour certains types de fichiers ou pour des fichiers avec certaines extensions. Par exemple, votre serveur Web est paramétré pour afficher l'icône binary.gif pour les fichiers portant les extensions .bin ou .exe.
DefaultIcon nomme l'icône à afficher dans les listes de répertoire générées par le serveur pour les fichiers pour lesquels aucune autre icône n'est spécifiée. unknown.gif est la DefaultIcon par défaut pour ces fichiers.
Vous pouvez utiliser AddDescription pour afficher le texte que vous spécifiez pour certains fichiers dans les listes du contenu de répertoires générées par le serveur (vous devez également activer FancyIndexing comme une IndexOptions). Vous pouvez nommer des fichiers spécifiques, utiliser des expressions comprenant des caractères spéciaux de recherche ou des extensions de fichier pour spécifier les fichiers auxquels cette directive devrait s'appliquer. Par exemple, vous pourriez utiliser la ligne suivante :
AddDescription "Fichier se terminant par .ni" |
Dans les listes de répertoire générées par serveur, les noms de tous les fichiers portant des extensions .ni seraient suivis de la description Fichier se terminant par .ni. Il faut également que FancyIndexing soit activé.
nomme le fichier qui (s'il existe dans le répertoire) sera ajouté à la fin des listes de répertoire générées par serveur. Le serveur Web commencera par essayer d'inclure le fichier comme document HTML, puis essaiera de l'inclure comme texte brut. Par défaut, ReadmeName est paramétré sur README.
HeaderName nomme le fichier qui (s'il existe dans le répertoire) sera ajouté au début des listes de répertoire générées par serveur. Comme ReadmeName, le serveur essaiera, si possible, de l'inclure sous la forme d'un document HTML, ou, sinon, comme texte brut.
IndexIgnore affiche une liste d'extensions de fichier, de noms de fichier partiels, d'expressions contenant des caractères spéciaux de recherche ou de noms de fichiers complets. Le serveur Web n'inclura pas les fichiers correspondant à l'un de ces paramètres dans les listes de répertoire générées par serveur.
AddEncoding nomme des extensions de nom de fichier qui devraient spécifier un type de codage particulier. AddEncoding permet également de donner pour instruction à certains navigateurs (pas tous) de décompresser certains fichiers pendant leur déchargement.
AddLanguage associe des extensions de nom de fichiers à des langues spécifiques. Cette directive est essentiellement utile pour la négociation de contenu, lorsque le serveur retourne un document parmi d'autres, en fonction de la préférence linguistique du client telle que définie dans son navigateur.
LanguagePriority permet de définir l'ordre de préféence des langues pour le service des fichiers, qui produit un effet si le client n'a paramétré aucune préférence linguistique dans son navigateur.
Utilisez la directive AddType pour définir des paires de type MIME et d'extension de fichier. Par exemple, si vous utilisez PHP4, votre serveur Web utilise la directive AddType afin de reconnaître les fichiers portant l'extension PHP (.php4, .php3 .phtml .php) comme des types MIME PHP.
La ligne AddType suivante indique au serveur de reconnaître l'extension de fichier .shtml (pour fichiers à inclure côté serveur) :
AddType text/html .shtml |
Vous devrez inclure la ligne ci-dessus à l'intérieur des balises de l'hôte virtuel pour tous les hôtes virtuels devant autoriser des fichiers à inclure côté serveur.
AddHandler mappe des extensions de fichier sur des modules de commande spécifiques. Par exemple, le module de commande cgi-script peut être utilisé en association avec l'extension .cgi pour traiter automatiquement un fichier dont le nom se termine par .cgi comme un script CGI. Ceci fonctionnera même pour les fichiers situés hors du répertoire ScriptAlias (si vous suivez les instructions fournies ici).
Vous avez une ligne CGI AddHandler dans votre fichier httpd.conf :
AddHandler cgi-script .cgi |
Il faut supprimer le commentaire de la ligne. Ensuite, Apache exécutera les scripts CGI pour les fichiers se terminant par .cgi, même s'ils se trouvent hors du répertoire ScriptAlias, qui est défini par défaut pour contenir votre répertoire /cgi-bin/ dans /var/www/cgi-bin/.
Vous devez également définir ExecCGI comme Options pour tout répertoire contenant un script CGI. Reportez-vous à la la section intitulée Directory pour plus d'informations sur la définition de ExecCGI pour un répertoire. Vous devrez en outre vous assurer que les autorisations sont correctement définies pour les scripts CGI et les répertoires contenant des scripts CGI. Les scripts CGI et tout le chemin d'accès aux scripts doivent être paramétrés sur 0755. Enfin, le propriétaire du répertoire et celui du fichier de script doivent coïncider.
Vous devrez ajouter la même ligne AddHandler à votre configuration VirtualHost si vous utilisez des hôtes virtuels et voulez qu'ils reconnaissent également des scripts CGI hors de ScriptAlias.
Outre des scripts CGI, votre serveur Web utilise également AddHandler pour traiter des fichiers HTML analysés par le serveur.
Action vous permet d'associer un type MIME à un CGI, de sorte que chaque demande d'un fichier de ce type déclenche l'exécution d'un script CGI particulier.
MetaDir spécifie le nom d'un répertoire où votre serveur Web doit rechercher des fichiers contenant des informations META (en-têtes HTTP supplémentaires) à inclure lorsqu'il sert des documents.
MetaSuffix spécifie le suffixe du nom du fichier contenant les informations META (en-têtes HTTP supplémentaires), qui devrait se trouver dans le répertoire MetaDir.
Par défaut, en cas de problème ou d'erreur, votre serveur Web renvoie un simple message d'erreur (habituellement obscur) au client ayant formulé la demande. Au lieu d'utiliser le paramétrage par défaut, vous pouvez utiliser ErrorDocument afin de configurer votre serveur Web pour qu'il renvoie un message personnalisé ou redirige le client vers une URL locale ou externe. ErrorDocument associe simplement un code de réponse HTTP à un message ou à une URL qui sera renvoyé au client.
La directive BrowserMatch permet à votre serveur de définir des variables d'environnement et/ou de prendre des mesures appropriées en fonction du champ d'en-tête User-Agent HTTP qui identifie le navigateur du client. Par défaut, votre serveur Web utilise BrowserMatch pour refuser des connexions à certains navigateurs présentant des problèmes connus de même que pour désactiver les keepalives et vidages d'en-tête HTTP pour les navigateurs ayant des problèmes avec ces actions.
Les balises <Location> et </Location> permettent de spécifier un contrôle d'accès basé sur l'URL.
L'utilisation suivante des balises Location consiste à les placer à l'intérieur des balises IfModule mod_perl.c. Ces directives de configuration sont effectives si le DSO mod_perl.so est chargé. Reportez-vous à la la section intitulée Ajout de modules au serveur pour plus d'informations sur l'ajout de modules à Apache.
Les balises Location nomment le répertoire /var/www/perl (Alias pour /perl) comme celui à partir duquel les scripts Perl seront servis. Si un document est demandé avec une URL dans le chemin de laquelle figure la chaîne /perl, votre serveur Web recherche le script Perl approprié dans /var/www/perl/.
Plusieurs autres options de <Location> sont identifiées comme des commentaires dans votre fichier httpd.conf. Si vous voulez activer leur fonctionnalité, supprimez le commentaire de la section appropriée des directives.
Immédiatement après les directives Perl décrites plus haut, votre fichier httpd.conf contient une section de directives permettant d'activer HTTP PUT (par exemple, la fonction de publication de Netscape Gold qui permet de publier des pages Web sur un serveur Web). Si vous voulez autoriser HTTP PUT, vous devez supprimer le commentaire de cette section toute entière :
#Alias /upload /tmp #<Location /upload> # EnablePut On # AuthType Basic # AuthName Temporary # AuthUserFile /etc/httpd/conf/passwd # EnableDelete Off # umask 007 # <Limit PUT> # require valid-user # </Limit> #</Location> |
Vous devrez aussi annuler les commentaires des lignes suivantes au début de httpd.conf, de façon à ce que le module mod_put se charge dans Apache.
#LoadModule put_module modules/mod_put.so #AddModule mod_put.c |
Si vous voulez permettre aux personnes qui se connectent depuis votre domaine de consulter des rapports sur l'état du serveur, annulez le commentaire de la section de directives suivante :
#<Location /server-status> # SetHandler server-status # Order deny,allow # Deny from all # Allow from .votre_domaine.com #</Location> |
Vous devez remplacer .votre_domaine.com par votre nom de domaine de second niveau.
Si vous voulez fournir des rapports de configuration de serveur (y compris des modules installés et des directives de configuration) en réponse à des demandes en provenance de votre domaine, vous devez supprimer le commentaire des lignes suivantes :
#<Location /server-info> # SetHandler server-info # Order deny,allow # Deny from all # Allow from .votre_domaine.com #</Location> |
Une fois encore, vous devez remplacer .votre_domaine.com.
La section de directives suivante utilise des balises Location pour permettre l'accès à la documentation dans /usr/share/doc (par exemple, avec une URL telle que http://votre_domaine/doc/fichier.html) . Ces directives permettent uniquement cet accès aux demandes faites depuis l'hôte local.
Une autre utilisation des balises Location est définie dans une section identifiée comme un commentaire destinée à permettre un suivi des attaques dirigées contre votre serveur Web qui exploitent un vieux bogue d'avant Apache 1.1. Si vous voulez effectuer un suivi de ces demandes, supprimez le commentaire des lignes suivantes :
#<Location /cgi-bin/phf*> # Deny from all # ErrorDocument 403 http://phf.apache.org/phf_abuse_log.cgi #</Location> |
Si ces lignes ne sont pas identifiées comme des commentaires, votre serveur Web redirige toute demande se terminant par /cgi-bin/phf* vers un script CGI de journalisation exécuté par le groupe Apache.
Si vous supprimez le commentaire des balises IfModule entourant la section ProxyRequests, votre serveur Apache fonctionnera également comme un serveur Proxy. Vous devez également charger le module mod_proxy. Pour obtenir des instructions sur la manière de charger des modules, reportez-vous à la la section intitulée Ajout de modules au serveur.
La commande ProxyVia contrôle si une ligne d'en-tête HTTP Via: est envoyée en même temps que les demandes ou les réponses transitant par le serveur proxy Apache. L'en-tête Via: indique le nom d'hôte si ProxyVia a pour valeur On, le nom d'hôte et la version d'Apache s'il a pour valeur Full, toutes les lignes Via: sont transférées inchangées s'il a pour valeur Off, et les lignes Via: sont supprimées s'il a pour valeur Block.
Plusieurs directives cache sont identifiées comme des commentaires dans les balises proxy IfModule mentionnées plus haut. Si vous utilisez la fonctionnalité du serveur proxy et voulez également activer le cache proxy, supprimez le commentaire des directives cache en procédant de la manière décrite. Les paramètres par défaut pour vos directives cache doivent être appropriés pour la plupart des configurations.
CacheRoot définit le nom du répertoire qui contiendra les fichiers mis en cache. Le CacheRoot par défaut est /var/cache/httpd.
CacheSize définit la quantité d'espace que le cache peut utiliser, exprimée en Ko. La valeur de CacheSize par défaut est 5 Ko.
CacheGcInterval définit un nombre d'heures. Une fois ce délai écoulé, les fichiers du cache sont supprimés si le cache utilise un espace supérieur à celui défini pour CacheSize. La valeur par défaut de CacheGcInterval est de quatre heures.
Les documents HTML mis en cache seront retenus (sans rechargement du serveur Web dont ils proviennent) dans le cache pendant le nombre d'heures maximum défini par CacheMaxExpire. La valeur par défaut est de 24 heures.
Le paramètre CacheLastModifiedFactor affecte la création d'une date d'expiration pour un document qui a été reçu du serveur sans date d'expiration définie. La valeur par défaut de CacheLastModifiedFactor est 0.1, ce qui signifie que la date d'expiration d'un document de ce type est égale à un dixième du temps écoulé depuis la dernière modification du document.
CacheDefaultExpire est le temps d'expiration, exprimé en heures, d'un document reçu à l'aide d'un protocole ne prenant pas en charge les délais d'expiration. La valeur par défaut est d'une heure.
Tout document récupéré sur un hôte et/ou un domaine correspondant à celui défini dans NoCache ne sera pas mis en cache. Si vous avez connaissance d'hôtes ou de domaines dont vous ne voulez pas mettre les documents en cache, supprimez le commentaire devant NoCache et définissez ici leurs noms de domaine ou d'hôte.
Vous devrez utiliser la directive NameVirtualHost pour l'adresse IP (et le numéro de port, si nécessaire) de tout hôte virtuel nommé que vous configurez. La configuration d'hôtes virtuels nommés est utilisée pour configurer plusieurs hôtes virtuels pour plusieurs domaines, lorsque vous n'avez pas (ou ne voulez pas utiliser) d'adresses IP différentes pour les différents noms de domaine pour lesquels votre serveur Web sert des documents.
Remarque | |
---|---|
Vous ne pouvez pas utiliser d'hôtes virtuels nommés avec votre serveur sécurisé. Tout hôte virtuel nommé que vous configurez ne peut fonctionner qu'avec des connexions HTTP non sécurisées, et non avec des connexions SSL. Vous ne pouvez pas utiliser d'hôtes virtuels nommés avec votre serveur sécurisé parce que l'établissement de liaison SSL (lorsque le navigateur accepte le certificat d'authentification du serveur Web sécurisé) intervient avant la demande HTTP qui identifie l'hôte virtuel nommé correct. Autrement dit, l'authentification intervient avant l'identification des différents hôtes virtuels nommés. Si vous voulez utiliser des hôtes virtuels avec votre serveur sécurisé, vous devez opter pour des hôtes virtuels basés sur l'adresse IP. |
Si vous utilisez des hôtes virtuels basés sur le nom, supprimez le commentaire de la directive de configuration NameVirtualHost et ajoutez l'adresse IP correcte de votre serveur derrière NameVirtualHost. Ajoutez ensuite des informations supplémentaires sur les différents domaines utilisant les balises Virtual Host qui entourent ServerName pour chaque hôte virtuel, plus toutes les autres directives de configuration exclusivement applicables à cet hôte virtuel.
Des balises <VirtualHost> et </VirtualHost> entourent toutes les directives de configuration destinées à être appliquées à un hôte virtuel. La plupart des directives de configuration peuvent être utilisées à l'intérieur de balises d'hôte virtuel, et s'appliquent exclusivement à cet hôte virtuel particulier.
Des balises VirtualHost identifiées comme des commentaires entourent certains exemples de directives de configuration et espaces réservés aux informations à entrer pour configurer un hôte virtuel. Reportez-vous à la la section intitulée Utilisation d'hôtes virtuels pour plus d'informations sur les hôtes virtuels.
La directive de configuration Apache SetEnvIf permet de désactiver la fonction keep-alive HTTP et d'autoriser SSL à fermer la connexion sans générer d'alerte de notification de fermeture du navigateur client. Ce paramètre est nécessaire pour certains navigateurs qui n'interrompent pas la connexion SSL avec une grande fiabilité.
Les directives SSL figurant dans le fichier httpd.conf de votre serveur sont incluses pour permettre des communications Web sécurisées à l'aide de SSL et TLS.
Pour plus d'informations sur les directives SSL, utilisez votre navigateur pour consulter la page http://votre_domaine/manual/mod/mod_ssl/. Pour plus d'informations sur les directives SSL, reportez-vous à la page http://www.modssl.org/docs/2.7/ssl_reference.html, un chapitre sur mod_ssl rédigé par Ralf Engelschall. Ce document, le mod_ssl User Manual, commence à l'URL http://www.modssl.org/docs/2.7/ et constitue une excellente référence pour mod_ssl (évidemment) et pour la cryptographie Web en général. Ce manuel contient des informations générales sur la sécurisation de votre serveur Web, au Chapitre 13.
Remarque | |
---|---|
Ne modifiez pas vos directives SSL si vous n'êtes pas absolument certain de savoir ce que vous faites. Pour la grande majorité des secure Web server, la configuration par défaut des directives SSL convient parfaitement. |
Précédent | Sommaire | Suivant |
Directives et modules Apache | Niveau supérieur | Ajout de modules au serveur |