MAR : 130 MAD
HORS-SÉRIE CAN : 18,00 $ cad LES GUIDES DE
DOM TOM : 13,90 ����
BEL/PORT.CONT : 13,90
CH : 18,00 CHF France METRO : 12.90 E
LEAPACH GUIDE COMPLET POUR METTRE EN PLACE ET BIEN CONFIGURER VOTRE SERVEUR WEB
Tutoriels Des pas-à-pas Aller plus loin pour passer rapidement
C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 Des éléments de à la pratique Programmer con guration avancée pour des besoins plus pour le Web ques Installation et PHP, Python, Perl spéci ff rement, ...) guration (LDAP, chi con et Ruby : Introduction quelques bases Édité par Les Éditions Diamond Installer son premier il faut savoir pour bien L 15066 - 66 H - F: 12,90 € - RD Apache serveur et choisir Tout ce qu programmer avec le mécanisme cation le sur les origines d les langages du et sur ses principales dauthenti fonctionnalités Web plus adapté www.ed-diamond.com Retrouvez toutes nos publications Editi ns
lEs diamond sur www.ed-diamond.com
GNU/Linux Magazine Hors-Série est édité par Les éditions Diamond
B.P. 20142 / 67603 Sélestat Cedex Tél. : 03 67 10 00 20 / Fax : 03 67 10 00 21 E-mail : [email protected] [email protected] Service commercial : [email protected] Sites : www.gnulinuxmag.com www.ed-diamond.com Directeur de publication : Arnaud Metzler Rédacteur en chef : Denis Bodor Secrétaire de rédaction : Véronique Sittler Remerciements à Sébastien Maccagnoni-Munch Conception graphique : Kathrin Scali Responsable publicité : Tél. : 03 67 10 00 27 Service abonnement : Tél. : 03 67 10 00 20 Impression : pva, Druck und Medien-Dienstleistungen GmbH, Landau, Allemagne Distribution France : (uniquement pour les dépositaires de presse) MLP Réassort : Plate-forme de Saint-Barthélemy-d’Anjou. Tél. : 02 41 27 53 12 Plate-forme de Saint-Quentin-Fallavier. Tél. : 04 74 82 63 04 Service des ventes : Distri-médias : Tél. : 05 34 52 34 01 IMPrIMé en Allemagne - PrINTED in Germany Dépôt légal : A parution N° ISSN : 0183-0864 Commission Paritaire : K78 976 Périodicité : Bimestrielle Prix de vente : 12,90 Euros
La rédaction n’est pas responsable des textes, illustrations et photos qui lui sont communiqués par leurs auteurs. La reproduction totale ou partielle des articles publiés dans GNU/Linux Magazine France Hors-série est interdite sans accord écrit de la société Les éditions Diamond. Sauf accord particulier, les manuscrits, photos et dessins adressés à GNU/Linux Magazine France Hors-série, publiés ou non, ne sont ni rendus, ni renvoyés. Les indications de prix et d’adresses figurant dans les pages rédactionnelles sont données à titre d’information, sans aucun but publicitaire. Toutes les marques citées dans ce numéro sont déposées par leur propriétaire C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 respectif. Tous les logos représentés dans le magazine sont la propriété de leur ayant droit respectif.
Les articles non signés contenus dans ce numéro ont été rédigés par les membres de l'équipe rédactionnelle des Éditions Diamond.
2 GNU/LiNUx maGaziNe Hors-série N°66 : apacHe préface nternet est un enchevêtrement de différents outils matériels et logiciels, qui n’ont pour point commun que de savoir communiquer avec les mêmes protocoles. Le Web, qui utilise Internet, présente la même hétérogénéité : il existe de nombreux navigateurs web, comme il existe de nombreux serveurs Iweb ; il existe de nombreux langages de programmation, comme il existe de nombreux systèmes de bases de données. Et tout ce monde cohabite joyeusement, toujours grâce à des protocoles ouverts et standardisés. Parmi les serveurs web, il y en a un qui sort du lot : le serveur HTTP Apache. Celui-ci, basé sur l’ancêtre des serveurs web (NCSA HTTPd), a rapidement gagné en notoriété, car il est le fruit de la collaboration de nombreux développeurs, experts dans leurs domaines : la fondation Apache a ainsi permis de créer l’un des meilleurs serveurs web, performant et polyvalent. Aujourd’hui, Apache dessert 60% des sites web. Vous avez sûrement déjà lu (ou entendu) le terme « LAMP », qui désigne une architecture de serveur web qui fait office de « standard de fait ». Apache, c’est le « A » de LAMP : Linux, Apache, MySQL et PHP. Il a gagné cette notoriété grâce à une forte modularité, qui lui permet de proposer de nombreuses fonctionnalités avancées – pas nécessairement compatibles entre elles, mais activables ou désactivables à la demande – parmi lesquelles on retrouve différentes méthodes d’authentification, la possibilité de desservir plusieurs sites web sur un seul serveur, le chiffrement de données avec le protocole SSL... On peut également utiliser de nombreux langages de programmation, parmi lesquels on retrouve les « poids lourds » que sont PHP, Perl, Python et Ruby. Nous ne pouvons bien sûr pas aborder ici tous les aspects de ce serveur : on se concentrera sur les fonctionnalités les plus couramment utilisées, les incontournables, afin de vous permettre d’apprendre à monter un site web « comme un pro ». Nous devrons cependant occulter certains aspects, on abordera ainsi que certaines méthodes d’authentification, certaines manières d’implémenter le support des langages de programmation, une seule bibliothèque de chiffrement SSL (car Apache supporte aussi bien OpenSSL que GnuTLS), etc. On essaiera tout de même d’approfondir certains points, qui pourront paraître exotiques ou inutiles à certains, mais qui donnent indéniablement matière à réflexion et qui vous donneront sans aucun doute l’envie d’approfondir le sujet et de plonger dans la documentation officielle de ce projet. Finalement, vous retrouverez des tutoriels qui vous permettront de rapidement mettre en œuvre certaines configurations spécifiques, à commencer, justement, par la mise en place d’un serveur LAMP. Nous démarrerons bien évidemment par les notions de base avec un éventail d’articles grâce auxquels, nous l’espérons, vous ferez des découvertes utiles, à mettre en application pour vos propres besoins. C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 La rédaction
GNU/LiNUx maGaziNe Hors-série N°66 : apacHe 3 sommaire GNU/Linux magazine Hors-série N°66 apacHe iNtrodUctioN
page 08 Le Web, un peu d'histoire 1 page 10 Le protocole HTTP page 16 La fondation Apache page 20 Présentation d'Apache
iNstaLLatioN
page 26 Mon premier Apache C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 page 36 Configuration basique 2 page 46 Authentification proGrammer poUr Le web page 62 Sites dynamiques et CGI 3 page 66 PHP, le langage du Web dynamique page 70 Perl, un classique toujours d'usage page 74 Les possibilités offertes par Python page 78 Ruby, un langage révélé par son framework
aLLer pLUs LoiN
page 84 Authentification avec LDAP page 102 Chiffrement et 4 authentification SSL
tUtorieLs
page 126 Installer LAMP sur Ubuntu page 130 Déménagement et redirection
C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 5 page 132 phpMyAdmin sur Ubuntu page 134 Protection contre les DoS avec « mod_evasive » page 136 Le framework Django sur Ubuntu page 140 Statistiques avec AWStats 1 C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5
6 GNU/LiNUx maGaziNe Hors-série N°66 : apacHe iNtrodUctioN 1 à découvrir dans cette partie... page 08 Le Web, un peu d'histoire Arrivé quelques années après le réseau Internet, le web est né au CERN dans les années 80. Petite rétrospective pour comprendre comment tout cela s'est mis en place.
page 10 Le protocole HTTP Ce protocole de communication est la base du Web. Inventé en même temps que ce dernier, c'est lui qui permet aux ordinateurs de demander des pages web aux serveurs.
page 16 La fondation Apache Apache est peut-être un serveur web, mais c'est également une fondation importante, réunissant des centaines de développeurs : un incontournable du Web.
page 20 Présentation d'Apache Le serveur HTTP Apache est le plus connu et l'un des premiers à avoir existé. Devenu un
C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 poids lourd du secteur, il a commencé « tout petit » comme beaucoup de logiciels.
GNU/LiNUx maGaziNe Hors-série N°66 : apacHe 7 Installation : mon premier Apache 1 iNtrodUctioN
Le web : UN peU d’Histoire C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5
lors qu’Internet, en tant qu’interconnexion de réseaux, existe depuis la fin des années 60, le Web (www, World Wide Web) lui-même est bienA plus jeune ! Retour sur son histoire...
8 GNU/LiNUx maGaziNe Hors-série N°66 : apacHe Introduction : le web - un peu d'histoire
1 Internet et le Web
Tâchons de dissocier Internet et World Wide Web. Internet désigne l’interconnexion mondiale de réseaux, permettant à des milliards d’équipements disséminés dans le monde de communiquer. Le Web, de son côté, désigne le système hypertexte constitué de l’ensemble des pages desservies par les serveurs HTTP de par le monde. Ce n’est qu’une des applications d’Internet, aux côtés de la messagerie électronique (e-mail) ou des messageries instantanées, par exemple.
2 La création du Web
Alors qu’Internet est créé entre les années 60 et 70 (d’abord appelé ARPANET) par les militaires américains, le Web a été inventé en Europe par Tim Berners-Lee en 1989, année où il a soumis au CERN un premier jet de ses spécifications ; après évolution de sa proposition par lui-même et Robert Cailliau, une première démonstration a eu lieu en 1990 et le premier système www a été mis à la disposition de la communauté des physiciens des hautes énergies en 1991, via la bibliothèque de logiciels du CERN. Ce n’est qu’un peu plus tard que ce système fut connecté à Internet, ce qui a permis sa diffusion dans le monde. (crédits : Paul Clarke, via Wikimedia Commons) Tim Berners-Lee, Le premier serveur web américain a été mis en place en décembre 1991 au Centre de l’inventeur du web l’accélérateur linéaire de Stanford (SLAC), en Californie.
3 Les premiers navigateurs web
à cette époque, seuls deux navigateurs web existaient : la version ayant servi au développement d’origine, disponible uniquement sur des machines NeXT et une version en mode ligne, très simple à installer et à exécuter, mais limitée en puissance et peu conviviale. Tim Berners-Lee lança alors un appel via Internet pour que d’autres développeurs puissent apporter leurs connaissances, l’équipe de développement du CERN n’était pas suffisamment importante pour prendre à sa charge ces développements. C’est alors que le National Center for Supercomputing Applications (NCSA) de l’université de l’Illinois développa le premier navigateur web convivial, baptisé MOSAIC, qu’il publia en 1993 pour l’environnement X-Window. L’essentiel de l’équipe ayant développé MOSAIC a quitté le NCSA pour C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 créer Netscape Navigator, publié en 1994. Netscape Navigator a donné naissance à Mozilla Firefox en 2004... Vous connaissez la suite ! Microsoft, de son côté, a développé Internet Explorer à partir de 1995, ce qui a mené à la première guerre des navigateurs à partir de 1996, gagnée par Microsoft en 1998 : Internet Explorer détenait alors 96% Le premier navigateur web convivial, de parts de marché. ▪ NCSA MOSAIC
GNU/LiNUx maGaziNe Hors-série N°66 : apacHe 9 Installation : mon premier Apache 1 iNtrodUctioN
Le protocoLe Http
C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 our communiquer, un serveur et un client ont besoin d’utiliser un protocole commun. Pour le Web, ce protocole s’appelle HyperText Transfer Protocol ; il Pa été inventé par Tim Berners-Lee, comme pierre angulaire du World Wide Web.
10 GNU/LiNUx maGaziNe Hors-série N°66 : apacHe Introduction : le protocole HTTP
à savoir 1 Versions de HTTP IETF et RFC L’Internet Engineering Lors de l’invention du Web, Tim Berners-Lee a envisagé l’utilisation du Task Force est un groupe informel (pas de statut, protocole FTP pour transférer les documents hypertextes le composant. pas de membres, pas Cependant, FTP est limité au simple transfert de fichiers et ne supporte pas d’adhésion, ouvert à tout la notion de formats de données. C’est pourquoi il a imaginé un nouveau individu...) qui participe à protocole, qu’il a appelé HTTP... l’élaboration des standards pour Internet. Les travaux de l’IETF sont répartis en 1.1 HTTP/0.9 une centaine de groupes de travail. La première version publique de ce protocole est HTTP/0.9. Elle a été pré- L’IETF publie notamment sentée au début des années 90, en même temps que le Web lui-même. Ce les RFC (Requests For numéro de version a en réalité été donné lorsque la version HTTP/1.0 est Comments), qui tiennent sortie : à l’origine, aucun numéro de version n’avait été donné à ce protocole. lieu de normes sur Internet. Ce protocole est extrêmement simple : Notons que, traditionnel- 1. Connexion du client au serveur, lement et ce depuis 1978, 2. Envoi par le client d’une requête GET, l’IETF publie un ou plu- sieurs canular(s) chaque 3. Envoi de la réponse par le serveur, 1er avril : Internet par 4. Fermeture de la connexion par le serveur. pigeon voyageur, messages subliminaux par Telnet, La requête a la forme suivante : etc. Ne les confondons pas Fichier avec des normes réalistes ! GET /chemin/d/une/page.html
La réponse correspond directement et intégralement au fichier demandé, dans le cas d’une page HTML cela donnerait : Fichier
Ceci est une page d’exemple.
1.2 HTTP/1.0 C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 En mai 1996, le protocole HTTP/1.0 devient standard de l’IETF et est décrit dans la RFC 1945. Cette version du protocole intègre notamment le support des serveurs HTTP virtuels (hôtes virtuels, voir plus loin), la gestion de cache et l’identification. Le déroulement des connexions est le même qu’avec HTTP/0.9 : connexion, requête, réponse, déconnexion.
GNU/LiNUx maGaziNe Hors-série N°66 : apacHe 11 Introduction : le protocole HTTP 1 1.2.1 Requête
La requête est plus évoluée ; elle prend la forme suivante : Fichier
La première ligne ressemble à la requête en HTTP/0.9, avec l’ajout du nom du protocole à la fin ; la méthode peut être GET comme avec HTTP/0.9, elle peut également être HEAD ou POST. Vous retrouverez plus loin l’explication détaillée de ces méthodes. Les lignes d’en-tête permettent de donner au serveur des détails sur la requête. Vous retrouverez plus loin des détails sur ces en-têtes. Le corps de la requête correspond aux données que le client envoie au serveur ; par exemple, dans le cas d’une requête POST (généralement utilisée lorsqu’on remplit un formulaire), les données sont transmises au serveur dans cette section. Par exemple, une requête pourra avoir la forme suivante : Fichier GET /page.html HTTP/1.0 Host: example.com Referer: http://example.com/ User-Agent: CERN-LineMode/2.15 libwww/2.17b3
1.2.2 Réponse
à l’instar de la requête, la réponse du serveur est plus complexe avec HTTP/0.9. Elle prend la forme suivante : Fichier
La première ligne inclut le code réponse – les plus connus sont 200 (lorsque la requête s’est bien déroulée) et 404 (lorsque la page n’est pas trouvée) – ainsi qu’une description textuelle de ce code réponse. De la même manière que dans la requête, les lignes d’en-tête permettent de préciser au client des détails sur la réponse du serveur. Vous retrouverez plus loin des détails sur ces en-têtes. Le corps de la réponse est, bien sûr, le contenu du fichier demandé. Par exemple, une réponse pourra avoir la forme suivante : Fichier C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 HTTP/1.0 200 OK Date: Fri, 31 Dec 1999 23:59:59 GMT Server: Apache/0.8.4 Content-Type: text/html Content-Length: 59 Expires: Sat, 01 Jan 2000 00:59:59 GMT Last-Modified: Fri, 09 Aug 1996 14:21:40 GMT
12 GNU/LiNUx maGaziNe Hors-série N°66 : apacHe Introduction : le protocole HTTP
Fichier
Ceci est une page d’exemple.
1.3 HTTP/1.1
La version HTTP/1.1 est sortie en janvier 1997, décrite dans la RFC 2068 ; elle a été révisée en juin 1999, cette révision est décrite dans la RFC 2616. Elle ajoute le support du trans- fert en pipeline (plusieurs requêtes en une seule connexion) et la négociation de type de contenu et améliore la gestion du cache.
La syntaxe des requêtes et réponses est identique à la syntaxe avec HTTP/1.0, en remplaçant bien sûr la mention HTTP/1.0 par HTTP/1.1 dans la première ligne de la requête et de la réponse.
Le déroulement d’une connexion est légèrement différent, car avec cette version du proto- cole, le serveur ne ferme pas la connexion après avoir envoyé une réponse ; la connexion reste ouverte en attente d’une nouvelle requête, éventuellement accompagnée d’une instruc- tion de fermeture de la connexion, ou en attente de la fermeture de la part du client.
La conversation peut alors correspondre au cheminement suivant : 1. Connexion du client au serveur, 2. Envoi par le client d’une requête GET, 3. Envoi de la réponse par le serveur, 4. Envoi par le client d’une seconde requête GET avec demande de fermeture de connexion, 5. Envoi de la seconde réponse par le serveur, 6. Fermeture de la connexion par le serveur.
2 Méthodes
La première ligne d’une requête HTTP précise avant tout une méthode d’interrogation. Chaque méthode demande au serveur d’effectuer une action différente. Voici une liste (non exhaustive) des méthodes HTTP les plus courantes : → GET : récupération du contenu d’un document ; → HEAD : récupération des en-têtes de la réponse uniquement – cette méthode est utilisée par un client web lorsqu’il souhaite des informations sur un document sans le télécharger en entier ; → POST : envoi de données au serveur – ces données sont ensuite traitées par une
C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 application côté serveur, un script PHP par exemple ; → PUT : stockage d’un fichier à l’URL mentionnée par le client ; → DELETE : suppression du fichier à l’URL mentionnée par le client ; → CONNECT : accès à un serveur web sécurisé (HTTPS) par l’intermédiaire d’un serveur d’authentification.
Dans les faits, les méthodes les plus utilisées sont GET, HEAD et POST.
GNU/LiNUx maGaziNe Hors-série N°66 : apacHe 13 Introduction : le protocole HTTP 1
3 En-têtes
Le protocole HTTP, à partir de la version 1.0, permet d’ajouter des en-têtes, aussi bien à à savoir la requête qu’à la réponse. De très nombreux en-têtes existent, nous n’allons pas tous les lister. Voyons quelques-uns des plus courants d’entre eux... Liste complète des en-têtes La liste exhaustive des en-têtes peut être consultée 3.1 Côté client (requête) dans la RFC 2616 ; mais si vous essayez de Le client web peut donner différents détails au serveur pour l’aider à desservir les bonnes lire une RFC, vous vous données ou dans un but statistique. En voici un extrait. rendrez vite compte que → Un des en-têtes les plus importants pour les requêtes HTTP est Host ; il est même ces documents ne sont obligatoire avec HTTP/1.1. Cet en-tête permet d’indiquer au serveur l’hôte virtuel pas des plus évidents à comprendre. Vous pourrez que l’on souhaite interroger (voir plus loin pour une explication détaillée des hôtes consulter cette liste plus virtuels). agréablement sur la page → L’en-tête Referer permet d’indiquer au serveur le site qui nous renvoie vers « List of HTTP header cette adresse (cela offre notamment la possibilité aux webmestres d’effectuer des fields » de Wikipédia en anglais. statistiques de provenance des visiteurs). → User-Agent contient la désignation du navigateur qui effectue la requête auprès du serveur (c’est cette valeur-là que l’on change pour faire passer notre navigateur pour un autre auprès de sites faisant du filtrage sur le navigateur utilisé). → L’en-tête Accept, quant à lui, permet d’indiquer au serveur le type de fichier que l’on à savoir souhaite recevoir en réponse à la requête ; cela permet au serveur de desservir une même donnée dans différents formats, selon le contexte. Le cache du → L’en-tête Accept-Language, quant à lui, permet de préciser la langue dans navigateur laquelle on souhaite recevoir le document ; cela permet de gérer un site multilingue Tout navigateur digne de directement au niveau du serveur. Ces en-têtes entrent dans le cadre du mécanisme de ce nom est équipé d’un multivues, que nous aborderons plus loin. cache. Ce cache permet de conserver en mémoire → L’en-tête Authorization contient les informations d’authentification auprès tout ou partie d’une page, du serveur web ; nous verrons cet en-tête plus en détail dans le chapitre dédié à afin de ne pas avoir à l’authentification. relancer un transfert pour des données qui sont déjà → L’en-tête Connection permet de gérer les connexions persistantes. Avec HTTP/1.1 connues. les connexions sont persistantes par défaut, alors on pourra surtout trouver l’en-tête Ce mécanisme est efficace Connection: close qui demande au serveur de fermer la connexion à la fin de uniquement si le serveur la requête. retourne les bonnes informations, notamment l’en-tête Expires : à partir de là, le navigateur sait 3.2 Côté serveur (réponse) qu’il peut conserver tel ou C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 tel fichier jusqu’à telle ou Le serveur peut fournir de nombreuses informations au client lorsqu’il répond aux telle date. requêtes. Parmi celles-ci, les plus courantes sont les suivantes : → Date contient la date à laquelle la réponse est générée. → Server permet d’identifier le logiciel faisant fonctionner le serveur qui a répondu. → Content-Type précise au client le format de la donnée retournée, l’aidant à l’interpréter.
14 GNU/LiNUx maGaziNe Hors-série N°66 : apacHe Introduction : le protocole HTTP
→ Content-Length indique la taille → 301 Moved Permanently : le serveur totale du fichier retourné, cela permet au indique ici que la ressource demandée a navigateur de valider qu’il a bien reçu la été déplacée à une adresse différente, il réponse complète. indique le nouvel emplacement dans l’en-tête Location ; → Expires contient la date précise à laquelle le fichier expire ; cette information est très → 307 Moves Temporarily : par cette utile pour les navigateurs : elle leur permet erreur, le serveur signale que la ressource de savoir combien de temps conserver une peut être temporairement trouvée à une donnée en cache. autre adresse, mais que pour des requêtes futures il faudra toujours passer par l’adresse → Last-Modified contient la date à laquelle courante ; le fichier a été modifié pour la dernière fois ; il est également retourné lors d’une requête → 401 Unauthorized : ce code est HEAD, cela permet éventuellement au client retourné quand une requête est dirigée web de vérifier qu’un document en sa vers une ressource protégée, il faut possession est toujours à jour. alors refaire la requête, mais avec des Notons que tous ces en-têtes sont facultatifs : informations d’authentification dans l’en-tête il ne faut pas s’appuyer de manière Authorization ; inconditionnelle sur ceux-ci, que ce soit côté → 404 Not Found : on a tous rencontré cette serveur ou côté client... erreur un jour ou l’autre, elle indique que le fichier demandé n’existe pas ;
→ 405 Method Not Allowed : le serveur Codes signale là que la méthode utilisée pour la 4 requête (GET, POST, etc.) est incorrecte par réponse rapport à ce que la ressource supporte ;
Un serveur web peut retourner un grand → 500 Internal Server Error : par ce nombre de codes réponse différents. Ces codes code, le serveur indique qu’il a rencontré sont classés dans 5 grandes catégories : un problème interne lorsqu’il a essayé de → du code 100 au code 199 : simple message récupérer les données de réponse ; informatif ; → 503 Service Unavailable : ce code → du code 200 au code 299 : ces codes indique que le serveur ne peut pas répondre indiquent que la requête s’est déroulée avec pour le moment, il indique optionnellement succès ; le délai à attendre avant la remise en service dans l’en-tête Retry-After. → du code 300 au code 399 : ces codes d’erreur correspondent à des redirections : le client HTTP a une ou des actions complémentaires à effectuer ; → du code 400 au code 499 : ceux-là indiquent 5 HTTPS qu’il y a un problème dans la requête (incomplète ou incorrecte) ; Une connexion chiffrée (sécurisée) avec le → du code 500 au code 599 : ces derniers protocole SSL ou TLS n’est pas très différente C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 codes correspondent aux erreurs propres aux d’une connexion classique non chiffrée : une serveurs. fois le chiffrement négocié et en place, les requêtes sont les mêmes que sur un serveur Listons certains de ces codes, parmi les plus HTTP classique. Bien sûr, la négociation du courants : chiffrement a un coût non négligeable en termes → 200 OK : la requête s’est correctement de processeur, les connexions persistantes sont déroulée et la réponse est retournée ; encore plus justifiées dans ce cas. ▪
GNU/LiNUx maGaziNe Hors-série N°66 : apacHe 15 Le protocole HTTP 1 iNtrodUctioN
La foNdatioN apacHe
Ce document est la propriété exclusive de jean-paul garrigos ([email protected]) - 26 avril 2013 à 01:35 eur serveur HTTP est le premier et le plus connu de leurs projets, mais la fondation Apache va bien plus loin que cela : OpenOffice.org, Subversion, Tomcat... Cette Lfondation gère d’autres projets d’envergure. Faisons le tour du propriétaire...
16 GNU/LiNUx maGaziNe Hors-série N°66 : apacHe Introduction : la fondation Apache
La fondation et à savoir 1 ses projets ApacheCon La fondation Apache (de son nom exact Apache Software Foundation) La conférence de la fondation est une organisation à but non lucratif, dont l’objectif est développer Apache (ApacheCon) permet des logiciels open source. L’ensemble des logiciels développés par cette de réunir les développeurs fondation sont protégés par la licence Apache. des différents projets Cela aurait peu de sens de donner ici la liste complète des projets de la Apache et de présenter les technologies et les logiciels fondation Apache : cette liste est consultable sur le site de la fondation. développés par la fondation. La fondation supporte plus de 100 projets, programmés dans près de 30 Elle se déroule à chaque langages différents par plusieurs centaines de développeurs bénévoles ; fois dans un lieu différent : elle compte plus d’une centaine de membres. Ces bénévoles, développeurs Canada en 2011, Allemagne et membres, sont répartis dans le monde : il n’y a pas de groupe local plus en 2012, États-Unis en 2013... important qu’un autre.
La fondation Apache n’a aucun employé : autant le bureau que les développeurs sont bénévoles. Les dépenses de la fondation portent sur les conférences officielles (appelées « ApacheCon »), l’infrastructure informatique et les relations publiques.
1.1 Historique
L’histoire d’Apache a commencé en 1995, lorsque huit développeurs se sont réunis pour améliorer le serveur HTTP du NCSA (National Center for Supercomputing Applications), le NCSA HTTPd. à cette époque, ce serveur HTTP était utilisé par 95% des sites sur Internet ; la majorité de ces sites sont passés sur le serveur Apache. à savoir Ce groupe de développeurs s’est rapidement fait connaître sous le nom Le nom Apache « The Apache Group ». Le nom « Apache » a été La fondation Apache a été formée le 25 mars 1999, tout d’abord pour choisi pour faire honneur à la nation des Apaches, chapeauter le serveur HTTP ; elle a rapidement pris sous son aile d’autres reconnus pour leur projets. supériorité stratégique et pour leur forte endurance. C’est aussi un jeu de mots 1.2 Organisation des projets sur « a patchy web server », car le serveur HTTP Le bureau de la fondation Apache est chargé de gérer la communication Apache était d’abord une autour des projets et de les superviser dans leur ensemble, mais il série de patches pour le C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 serveur NCSA HTTPd ; en n’a aucune autorité en matière de choix techniques. La fondation est effet, en anglais « Apache » composée de plusieurs « projets de premier niveau » (nommés Project se prononce comme « a Management Committees), qui ont chacun un certain nombre de patchy ». Ce jeu de mots n’est « sous-projets ». cependant pas la raison première du nom. Les décisions techniques se font de manière indépendante au niveau de ces projets.
GNU/LiNUx maGaziNe Hors-série N°66 : apacHe 17 Introduction : la fondation Apache 1
1.3 Quelques projets...
Parmi les plus populaires des projets de la fondation Apache, on peut retrouver :
→ le serveur HTTP Apache, projet créé en 1995 ayant contribué à fonder la fondation en 1999 ;
à savoir → le serveur LDAP Apache Directory, projet créé en 2002 sous le nom Compatibilité « LDAPd » et donné à la fondation en 2003 ; GNU GPL → la suite bureautique OpenOffice.org, créée en 2000 par Sun Microsystems et donnée à la fondation en 2011 par Oracle ; La compatibilité avec la licence GNU GPL signifie → le filtre anti-spam SpamAssassin, créé en 2001 et donné à la fondation qu’il est juridiquement en 2004 ; facile de faire interagir du code provenant de la → le logiciel de gestion de versions Subversion, créé par CollabNet en 2000 fondation Apache avec et donné à la fondation en 2010 ; du code provenant de → le serveur HTTP en Java Tomcat, projet interne à Sun Microsystems la FSF (Free Software Foundation) : des bouts donné à la fondation en 1999. de code protégés par ces On peut constater que, malgré une orientation globale plutôt tournée vers le deux licences peuvent être Web, la fondation Apache ne se limite pas à cela et chapeaute de nombreux réutilisés dans un seul et projets logiciels différents. même logiciel.
2 La licence Apache
La licence Apache (en version 2, existant depuis 2004) est une licence libre compatible avec la licence GNU GPL v3.
Cette licence permet, comme toute autre licence open source, la réutilisation, la redistribution et la modification du code.
Les points de différence, qui ont notamment fait que cette licence en version 1.0 et 1.1 n’était pas compatible avec la GNU GPL, portaient sur quelques points de détail comme la façon de présenter la licence au sein du code, l’inclusion d’éventuelles autorisations de ré-exploiter un brevet logiciel (aux États-Unis), etc.
C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 2.1 Permissivité
Notons aussi que la licence Apache est permissive : il n’est pas obligatoire de publier sous licence Apache un logiciel qui contient des bouts de code sous licence Apache, contrairement à la GNU GPL, qui force à publier tout code utilisant du code GNU GPL sous la même licence (on caractérise parfois de « virales » de telles licences).
18 GNU/LiNUx maGaziNe Hors-série N°66 : apacHe Introduction : la fondation Apache
Lorsque l’on développe du code sous GNU GPL, on est assuré que tout développeur réutilisant le code publie son logiciel sous GNU GPL également ; lorsque l’on développe du code sous licence Apache, on permet aux autres développeurs de publier leur logiciel sous la licence de leur choix, seul le bout de code réutilisé reste sous licence Apache.
2.2 Licence et propriété du code à savoir Membres Contrairement à d’autres structures de promotion et d’hébergement de logiciels libres, tout projet hébergé par la fondation Apache doit fondateurs obligatoirement être publié sous licence Apache et faire l’objet d’un contrat de Les personnes à l'origine de la fondation Apache licence de contributeur, donnant à la fondation Apache la possibilité d’utiliser n'ont pas d'autre lien et surtout de protéger le logiciel en question, notamment d’un point de vue que celui d'avoir voulu légal : cela contribue à la protection du code source concerné. créer le meilleur serveur Tout contributeur reste propriétaire du code qu’il a écrit : il ne s’agit que d’une HTTP possible : c'est grâce à Internet qu'ils autorisation explicite donnée à la fondation Apache par contrat et non d’un se sont rencontrés et don (et changement de propriétaire) pur et simple du code source. par Internet qu'ils ont travaillé ensemble. Il s'agit par exemple de Brian Behlendorf, l'un des fondateurs de la société Le projet Apache Organic, Inc. (créatrice du site web du magazine 3 HTTP Server Wired), de Roy Fielding, l'un des principaux Bien qu’il ait contribué à la création de la fondation, le serveur HTTP est un auteurs de la spécification HTTP, ou encore du projet comme les autres, avec son équipe de développeurs et son organisation cryptologue anglais propre. Aujourd’hui, plus une seule ligne de code ne provient du serveur Ben Laurie. NCSA HTTPd : tout le code a été réécrit.
Depuis avril 1996, le serveur HTTP Apache est le serveur web le plus populaire. En décembre 2012, il est utilisé pour desservir plus de 60% des sites web.
En raison de cette grande popularité, on appelle souvent ce serveur simplement « Apache ». Mais ne nous y trompons pas : dire « j’utilise Apache » n’a en réalité pas de sens, il faudrait dire « j’utilise le serveur HTTP Apache » ou « mon serveur HTTP est Apache HTTP Server » pour qu’on sache de quoi il est question... ▪ C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 Références Site de la fondation Apache : http://www.apache.org/
Site de la conférence Apache : http://www.apachecon.com/
Site du serveur HTTP Apache : http://httpd.apache.org/
GNU/LiNUx maGaziNe Hors-série N°66 : apacHe 19 La fondation Apache 1 iNtrodUctioN
préseNtatioN d’apacHe
u sein de la fondation Apache, le serveur HTTP continue d’évoluer. Il a bien sûr C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 atteint aujourd’hui un seuil de maturité qui fait que les évolutions se font en douceur,A mais nous allons voir qu’il est le fruit de beaucoup de réflexions et de choix, grâce auxquels nous disposons aujourd’hui d’un outil puissant et modulaire.
20 GNU/LiNUx maGaziNe Hors-série N°66 : apacHe Introduction : présentation d'Apache
1 Histoire
1.1 Naissance
Nous l’avons vu, le serveur HTTP Apache est basé sur le démon httpd, développé par Rob McCool au NCSA (National Center for Supercomputing Applications), ce même NCSA qui a créé le premier navigateur web convivial. Rob McCool a été l’un des premiers employés de Netscape, en suivant ses collègues du NCSA dans la création de la société : le serveur NCSA httpd a donc rapidement été orphelin... Pendant quelques mois à partir de mi-1994, chaque webmestre y allait de son patch à ce serveur, pour lui permettre de supporter telle ou telle option. Un groupe informel s’est créé parmi ces webmestres, c’est ainsi que le groupe Apache (the Apache Group) est né. Ce groupe a réuni un maximum de ces patches, les a fusionnés dans ce qui était à l’époque la version 1.3 du serveur httpd du NCSA, le serveur Apache 0.6.2 a ainsi été publié en avril 1995. Très rapidement, une nouvelle architecture serveur a été inventée, avec une structure modulaire telle qu’on la connaît aujourd’hui, pour donner naissance à Apache 0.8.8 en août de la même année, puis à Apache 1.0 en décembre 1995. Courant 1995, le serveur Apache a dépassé celui du NCSA en popularité pour devenir le premier serveur utilisé sur Internet, il n’a jamais quitté cette place depuis.
1.2 Évolution
La version 1.3 d’Apache (dernière évolution de la version 1) est sortie en 1999, apportant de nombreuses améliorations. Cette version est restée longtemps préférée de certains administrateurs, notamment en raison des changements dans la licence d’Apache 2.0 qui n’ont pas plu à tout le monde... Apache 2.0 alpha est publié en 2000, suivi d’Apache 2.0 « stable » en 2002, puis d’Apache 2.2 en 2005 et Apache 2.4 en 2012, chaque version apportant son lot de nouvelles fonctionnalités... Aujourd’hui, les distributions Linux incluent souvent encore Apache 2.2 (c’est le cas de Debian et Ubuntu) : il va leur falloir quelques mois avant de pouvoir intégrer la dernière version proprement. C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 1.3 Part de marché
La popularité du serveur HTTP Apache a varié depuis 1996, gagnant ou perdant des parts de marché selon les périodes, mais il a toujours conservé une très grande avance sur ses compétiteurs, représentant toujours plus de 50% des sites web desservis. En 2009, il a dépassé les 100 millions de sites web desservis.
GNU/LiNUx maGaziNe Hors-série N°66 : apacHe 21 Introduction : présentation d'Apache 1
2 Modularité et fonctionnalités
L’une des grandes forces d’Apache est sa modularité. Nous l’avons vu, ce logiciel a adopté une structure modulaire dès l’une des toutes premières versions, avant même la sortie de la version 1.0 « stable ».
Cette modularité a permis de développer de nombreuses fonctionnalités de manière totalement indépendante. Les fonctionnalités de base sont elles aussi développées sous forme de modules, même si lors de la compilation par les éditeurs de distributions, certaines sont intégrées statiquement dans l’exécutable binaire et ne peuvent être désactivées.
Faisons le tour de quelques fonctionnalités implémentées par ces modules... De nombreux autres modules sont également disponibles !
2.1 Chiffrement
Apache supporte – bien évidemment – le protocole sécurisé HTTPS, qui permet de chiffrer les communications afin d’en empêcher la lecture par un tiers.
Ce support est disponible avec le module mod_ssl.
2.2 Hôtes virtuels
Une seule instance du serveur HTTP Apache est capable de desservir de nombreux sites différents, cela grâce aux hôtes virtuels : selon l’hôte demandé par le client HTTP (en général un navigateur web), le serveur répondra d’une manière adaptée...
Cette fonctionnalité est offerte par le module core : elle fait partie des fonctionnalités de base.
2.3 Journalisation
Apache permet bien sûr d’enregistrer des journaux (logs), afin de tracer d’éventuels problèmes rencontrés. Mais les possibilités en termes de journalisation vont plus loin ; on peut notamment personnaliser les journaux relatifs aux requêtes effectuées par les clients.
Ces fonctionnalités sont offertes par les modules mod_log_config, mod_log_debug, mod_ log_forensic et mod_logio.
2.4 Authentification C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 Apache propose de nombreuses possibilités en termes d’authentification des utilisateurs : authentification simple, utilisation des données d’une base SQL, d’une base LDAP, de fichiers DBM... Ces fonctionnalités sont fournies par différents modules, dont le nom commence systématiquement par « auth » : mod_auth_basic ou mod_authnz_ldap, par exemple.
Par ailleurs, des modules fournis par d’autres organisations ou personnes sont disponibles, comme le module auth_kerb pour l’authentification Kerberos.
22 GNU/LiNUx maGaziNe Hors-série N°66 : apacHe Introduction : présentation d'Apache
2.5 Traitement conditionnel
Apache peut être configuré afin d’effectuer un traitement conditionnel, le module mod_setenvif permettant de mettre en place des variables d’environnement selon les en-têtes fournis par le client, ces variables d’environnement pouvant être utilisées par certaines directives de configuration ou par des scripts appelés lors des requêtes.
2.6 Alias et redirections Définition De nombreuses approches pour les alias et les redirections sont possibles avec Apache : un alias de base permet de desservir une donnée qui n’est normalement pas dans Proxy et reverse l’arborescence d’un site web ; une redirection permet de renvoyer directement un code proxy d’erreur de la famille des 300 sans autre traitement ; une règle de réécriture permet de Un proxy permet rediriger les requêtes finement selon l’URL demandée ou les en-têtes de la requête (pour de centraliser et rediriger un navigateur mobile vers une version spécifique du site, par exemple). éventuellement filtrer les accès à Internet au sein Ces fonctionnalités sont offertes par les modules mod_alias et mod_rewrite. d’un réseau ; cela permet par exemple de mutualiser les ressources et de servir 2.7 Proxy de cache au niveau du réseau, en ne chargeant une Apache peut également être utilisé comme proxy ou comme reverse proxy. De même image qu’une seule fois, même pour plusieurs nombreuses configurations sont possibles à ce niveau, il peut d’ailleurs supporter clients. différents protocoles : AJP, CONNECT, FastCGI, FTP, HTTP et SCGI. Il permet également Un reverse proxy, c’est la de faire de la répartition de charge... même logique côté serveur ; Cette fonctionnalité est éclatée en plusieurs modules, le module mod_proxy en étant c’est un serveur qui reçoit la base et les autres modules dont le nom commence par « proxy_ » fournissant les les requêtes des clients et fonctionnalités plus précises, comme mod_proxy_ftp pour le protocole FTP. qui les redirige vers un ou plusieurs serveurs web, tout en cachant les données qu’il peut, afin de limiter la 2.8 WebDAV charge sur les serveurs web eux-mêmes. Le protocole WebDAV permet d’utiliser des méthodes HTTP supplémentaires, afin de gérer un stockage centralisé de données (généralement des fichiers) avec gestion des versions ; ces méthodes sont par exemple PROPFIND, COPY, MOVE.... Certains outils de gestion électronique de documents (GED) implémentent le protocole WebDAV à leur niveau, mais Apache2 est capable de gérer cet aspect également. Cette fonctionnalité est supportée par le module mod_dav.
2.9 Sécurité
Il est également possible de mettre en œuvre des processus d’audit et de filtrage des requêtes, afin d’empêcher certains types d’attaques par exemple, comme le Cross-Site C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 Scripting ou les injections SQL. Cette fonctionnalité est apportée par l’infrastructure logicielle ModSecurity, qui propose un module Apache mod_security. En réalité, ModSecurity est né sous la forme d’un module Apache, ce n’est que par la suite qu’il a été compartimenté pour être également utilisable avec d’autres serveurs HTTP pour devenir un pare-feu d’applicatif web (web application firewall) à part entière. ▪
GNU/LiNUx maGaziNe Hors-série N°66 : apacHe 23 2 C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5
24 GNU/LiNUx maGaziNe Hors-série N°66 : apacHe iNstaLLatioN 2 à découvrir dans cette partie... page 26 Mon premier Apache Découvrons l'architecture de base du serveur HTTP Apache, la méthode pour l'installer et sa modularité. Le « petit serveur web » a grandi et a gagné en complexité et en performance.
page 36 Configuration basique Une fois le serveur HTTP Apache installé, que faire ? Configurer les accès aux documents, les sites à desservir, les autorisations et les enregistrements système.
page 46 Authentification Quand on a des documents confidentiels, on n'a pas envie de les partager avec n'importe qui : filtrons alors les accès à un site selon des noms d'utilisateurs et mots de passe. C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5
GNU/LiNUx maGaziNe Hors-série N°66 : apacHe 25 Installation : mon premier Apache 2 iNstaLLatioN
moN premier apacHe e nombreuses solutions existent pour desservir des sites web ; le serveur HTTP
C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 de la fondation Apache reste cependant le leader sur ce marché, avec plus de la moitié desD sites l’utilisant dans le monde. Nous appellerons cet incontournable « Apache » par la suite, mais rappelons-nous que ce n’est pas le seul projet de cette fondation ! Nous aborderons plus précisément la version 2 de ce logiciel, qui est également appelée « Apache2 ».
26 GNU/LiNUx maGaziNe Hors-série N°66 : apacHe Installation : mon premier Apache
1 Installation
L’installation d’Apache à proprement parler est très simple à partir du moment où l’on utilise une distribution Linux digne de ce nom. En effet, il est à retenir tellement populaire qu’il est fourni sous forme de paquet pour l’ensemble des distributions. Son installation se résume donc à une commande (en tant que Commandes super-utilisateur du système) : exécutées → sous Debian GNU/Linux : Nous donnerons Terminal ici comme ~# apt-get install apache2 exemple de nombreuses commandes : ne → sous Ubuntu Linux : les exécutez pas Terminal aveuglément ! ~# apt-get install apache2 Certaines sont incompatibles entre elles, → sous Red Hat Enterprise Linux et Fedora : certaines sont Terminal redondantes, certaines ne ~# yum install httpd servent qu’à vous montrer Détaillons l’installation sous Debian Squeeze (version 6) : des aspects Terminal d’Apache. ~# apt-get install apache2 Lecture des listes de paquets... Fait Construction de l’arbre des dépendances Lecture des informations d’état... Fait Les paquets supplémentaires suivants seront installés : apache2-mpm-worker apache2-utils apache2.2-bin apache2.2-common libapr1 libaprutil1 libaprutil1-dbd-sqlite3 libaprutil1-ldap ssl-cert Paquets suggérés : apache2-doc apache2-suexec apache2-suexec-custom openssl-blacklist Les NOUVEAUX paquets suivants seront installés : apache2 apache2-mpm-worker apache2-utils apache2.2-bin apache2.2-common libapr1 libaprutil1 libaprutil1-dbd-sqlite3 libaprutil1-ldap ssl-cert
C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 0 mis à jour, 10 nouvellement installés, 0 à enlever et 0 non mis à jour. Il est nécessaire de prendre 2 073 ko dans les archives. Après cette opération, 6 963 ko d’espace disque supplémentaires seront utilisés. Souhaitez-vous continuer [O/n] ?
GNU/LiNUx maGaziNe Hors-série N°66 : apacHe 27 Installation : mon premier Apache 2 Parmi les dépendances du paquet, on remarque particulièrement apache2-mpm-worker. C’est en réalité ce paquet qui contient le binaire qui est exécuté lorsque l’on démarre Apache : le fichier /usr/sbin/apache2 est un lien vers ce « MPM » : Terminal ~# ls -l /usr/sbin/apache2 lrwxrwxrwx 1 root root 33 4 mars 11:42 /usr/sbin/apache2 -> ../lib/apache2/mpm-worker/apache2
En réalité, Apache2 offre une modularité non seulement au niveau des compléments qu’on peut y ajouter (support de langages, extensions diverses), mais également au niveau de la manière dont les connexions sur le serveur sont gérées. On parle alors de Multi-Processing Modules (ou MPM), chargés de définir la politique de gestion de ces connexions. Par défaut, le modèle installé par Debian est « worker », mais plusieurs sont proposés : Terminal ~# apt-cache search apache2-mpm apache2-mpm-event - Apache HTTP Server - event driven model apache2-mpm-itk - multiuser MPM for Apache 2.2 apache2-mpm-prefork - Apache HTTP Server - traditional non-threaded model apache2-mpm-worker - Apache HTTP Server - high speed threaded model
2 Les MPM
Faisons un tour de ces modules...
2.1 MPM Prefork
Ce module fonctionne de la même manière qu’Apache 1.3 ; le multithreading n’est absolument pas pris en charge et les connexions sont traitées par des forks. Ce module offre donc une stabilité et une isolation exemplaires, permettant d’utiliser un service HTTP basé qui ne serait pas « thread safe » ; les requêtes et les processus sont totalement isolés, de cette manière un problème sur l’un des processus forkés ne pourra pas impacter l’ensemble du serveur web.
C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 L’aspect négatif de ce module est bien sûr les performances. Faire un fork est plus gourmand en processeur que de créer un thread. On échange donc une perte de performances contre un gain de stabilité et d’isolation. Précisons cependant que la perte de performance ne se ressent pas sur des serveurs à faible trafic : c’est sur des serveurs très chargés que cet aspect pourra être important.
28 GNU/LiNUx maGaziNe Hors-série N°66 : apacHe Installation : mon premier Apache
Dans la pratique, ce module est de moins en moins utilisé, car les bibliothèques utilisées sur un serveur Apache sont « thread safe »... sauf le module pour PHP mod_php5, qui reste l’un Définition des plus utilisés. Thread ou fork ? Le multithreading est une approche 2.1.1 Configuration de Prefork qui a pour particularité de lancer des fils d’exécution (threads) parallèles, Ce module ne nécessite généralement pas de configuration partageant un même espace mémoire. particulière, car il se régule automatiquement en reposant C’est une approche très efficace sur la gestion des processus par le système d’exploitation pour exécuter plusieurs instructions sous-jacent. en parallèle au détriment de la compartimentation des données : c’est Cinq paramètres de configuration permettent cependant de aux différents fils de gérer les accès à contrôler finement cette gestion... la mémoire, pour être « thread-safe ». MaxClients, la plus importante (et la plus utile) de ces Les forks sont des créations de options, détermine le nombre total de requêtes pouvant être nouveaux processus indépendants ; chacun de ces processus a son espace exécutées simultanément vers le serveur : cette variable peut mémoire qui n’entre pas en conflit être ajustée à la baisse (pour limiter les risques de plantage avec les autres – il reste bien sûr ou de ralentissement liés à une sur-utilisation du processeur la possibilité de créer des espaces ou de la mémoire) ou à la hausse (pour accepter un plus mémoire partagés. Les forks sont grand nombre de visiteurs simultanés). La valeur par défaut cependant plus gourmands en est de 256. mémoire que les threads. Avec ce module, le nombre maximum de clients est égal au nombre maximum de processus (forks) d’« écoute » qu’Apache va exécuter. Cette valeur est limitée par le paramètre ServerLimit, lui aussi à 256 par défaut pour Prefork. StartServers indique le nombre de processus à créer au démarrage d’Apache : il s’agit du nombre de processus à retenir « en attente de clients », prêts à desservir les pages ou applications web. Il n’est généralement pas nécessaire Le paramètre ServerLimit de modifier ce paramètre, étant donné que le nombre de Il s’agit d’un paramètre commun processus est dynamique (dans la limite de MaxClients). représentant le nombre maximal Ce paramètre (dont la valeur par défaut est de 5) peut être de processus pouvant être exécutés augmenté si on met en place un serveur qui doit « encaisser », simultanément. Il convient de ne dès sa mise en production, de très nombreuses requêtes pas configurer ce paramètre trop (par exemple dans le cas d’un cluster de haute disponibilité, haut afin d’éviter les surcharges où plusieurs centaines de connexions peuvent passer d’un de la mémoire. Par mesure de sécurité, cette valeur ne pourra serveur à l’autre en quelques secondes). jamais dépasser 20 000 (ou 200 000 MinSpareServers et MaxSpareServers déterminent spécifiquement pour Prefork). respectivement le minimum et le maximum de processus Notons qu’un changement de cette actifs « en attente de requête ». Apache se charge de conserver valeur n’est pris en compte que dynamiquement un certain nombre de processus « en écoute » lorsqu’Apache est arrêté puis relancé en plus des processus en cours de traitement de requêtes : (stop puis start), mais pas lors d’un simple redémarrage d’Apache C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 il crée de nouveaux processus si le nombre courant est (restart). en-dessous de la valeur minimale, ou en « tue » si ce nombre est au-dessus de la valeur maximale. Modifier ces valeurs (qui sont respectivement à 5 et 10 par défaut) n’a de sens que sur des serveurs à charge fortement variable où on s’attend à accueillir de nombreuses connexions supplémentaires en très peu de temps (cas de l’« effet Slashdot »).
GNU/LiNUx maGaziNe Hors-série N°66 : apacHe 29 Installation : mon premier Apache 2 MaxRequestsPerChild, enfin, permet de définir le nombre maximal de requêtes qu’un seul processeur pourra desservir. Cela permet de ne pas créer un nouveau processus à chaque nouvelle requête mais de réutiliser les processus existants. Sa valeur par défaut est de 10 000. Il faut être très prudent avec ce paramètre : si l’application desservie a une fuite de mémoire, cette fuite s’additionne dans la limite de cette valeur. Par exemple, si un script PHP a une fuite de mémoire de 1 Ko par requête et que chaque processus peut traiter 10 000 requêtes, chaque processus peut avoir 10 Mo de fuite de mémoire ; avec la limite par défaut de 256 processus simultanés, on peut monter jusqu’à 2,5 Go uniquement en fuite de mémoire. De plus, avec une valeur de 0 (c’est la valeur configurée par de nombreuses distributions par défaut), un processus n’expire jamais. Les paramètres par défaut de chaque MPM sur Debian sont donnés dans le fichier /etc/apache2/apache2.conf. Dans le cas du Définition module Prefork, les valeurs par défaut de Debian sont les suivantes : Effet Slashdot Fichier L’« effet Slashdot »
C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 multiprocessus et multithreads. Cette approche permet de combiner les avantages des deux techniques : performances brutes supérieures et sécurité par rapport au plantage d’un processus. Ce module lance plusieurs processus, qui eux-mêmes sont divisés en plusieurs threads. Apache est alors capable de desservir simultanément autant de requêtes que le nombre total de threads lancés par l’ensemble des processus.
30 GNU/LiNUx maGaziNe Hors-série N°66 : apacHe Installation : mon premier Apache
2.2.1 Configuration de Worker
La configuration de ce module passe par six paramètres... StartServers a la même signification qu’avec Prefork : il indique le nombre de processus à lancer dès le démarrage. Sa valeur par défaut est de 3, limitée par à retenir ServerLimit comme pour Prefork. Valeurs par défaut ThreadsPerChild , de son côté, définit le nombre Nous voyons ici deux de threads créés au sein de l’un de ces processus – types de valeurs par ce nombre est invariable ; dès qu’un processus est défaut : d’un côté les créé, il contient ce nombre de threads. à l’instar de valeurs par défaut ServerLimit pour StartServers, cette valeur est d’Apache même, qui sont limitée par ThreadsLimit, qui a une valeur de 64 codées « en dur » lors de la compilation (ce sont par défaut. les valeurs données au MaxClients a la même signification que pour Prefork, sein des paragraphes) c’est le nombre total de requêtes traitées simultanément : et les valeurs par défaut ici, ce sera le nombre de threads exécutés ; à diviser par le pour Debian, qui sont faciles à modifier (elles nombre de threads par processus (ThreadsPerChild) sont configurées dans le pour obtenir le nombre maximal de processus exécutés. fichier /etc/apache2/ MaxRequestsPerChild représente ici le nombre de apache2.conf). requêtes qui seront traitées par un processus ; à diviser par le nombre de threads par processus pour obtenir le nombre de requêtes traitées par thread en moyenne. Comme pour le MPM Prefork, le système est capable de se réguler tout seul et ne nécessite pas de reconfiguration particulière, sauf dans des cas très spécifiques. à retenir Les paramètres par défaut du MPM Worker sur Debian, À l’instar de ServerLimit, dans le fichier /etc/apache2/apache2.conf, sont ThreadLimit a une valeur les suivants : qui ne pourra jamais Fichier dépasser 20 000 (valeur codée « en dur »).
Si on exécute la commande pstree sur une machine avec ce MPM et la configuration par défaut d’Ubuntu, on constate qu’il y a en effet deux processus de lancés, C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 contenant chacun 26 threads - un thread de gestion et 25 threads d’écoute : Terminal ~# pstree | grep apache2 |-apache2-+-apache2 | `-2*[apache2---26*[{apache2}]]
GNU/LiNUx maGaziNe Hors-série N°66 : apacHe 31 Installation : mon premier Apache 2 2.3 MPM Event
Worker et Prefork sont les MPM les plus utilisés et les plus stables, mais il faut également compter avec d’autres modules... Le MPM Event, fourni comme paquet Debian, est conçu spécialement pour les sites devant traiter un nombre important de connexions persistantes. Notons toutefois que, comme la documentation officielle et la description du paquet Debian l’indiquent, ce MPM reste expérimental pour Apache 2.2 : il faut faire très attention si on l’utilise... ou passer à Apache 2.4, version dans laquelle ce MPM est stabilisé. Lorsqu’un client distant envoie une requête, il lui est possible de garder la connexion ouverte afin d’envoyer d’autres requêtes. Le principal avantage de ce fonctionnement est d’éviter de réitérer les opérations d’ouverture et fermeture de socket à chaque à savoir requête. Le problème avec Worker et Prefork, c’est qu’un thread ou un processus est alors monopolisé par un client, dans l’attente MPM sur d’autres systèmes de données de sa part. D’autres MPM existent, notamment Le MPM Event propose alors de dédier un thread à l’attente sur d’autres systèmes d’exploitation. de connexions et à la gestion de la persistance, déportant ainsi On retrouve par exemple le MPM uniquement les tâches de traitement des requêtes aux autres netware optimisé pour la gestion threads, sans aucun verrou spécifique aux clients. des threads sur un système Novell NetWare, le MPM os2 pour le Les paramètres de configuration de ce MPM sont les mêmes que système d’exploitation IBM OS/2 ceux de Worker. On notera toutefois que, étant donné l’aspect ou le MPM winnt pour les serveurs expérimental de ce MPM et des risques de dysfonctionnement Microsoft Windows... induits, les connexions chiffrées SSL/TLS ainsi que bon nombre de mécanismes de filtrage sont proscrits.
2.4 MPM ITK
Le MPM ITK est un module développé de manière indépendante (c’est-à-dire hors du giron de la fondation Apache) qui permet une séparation de privilèges au niveau des VirtualHosts. Il devient possible de faire fonctionner chacun des hôtes virtuels sous une identité (UID et GID) différente. Dès lors, les scripts, les données et les fichiers de configuration d’un hôte virtuel n’ont plus besoin d’être lisibles par les autres. Cela devrait plaire à n’importe quel administrateur soucieux de bien séparer les sites, ou encore à celui devant gérer plusieurs utilisateurs n’ayant rien en commun. Ce MPM est basé sur Prefork, il hérite donc de ses avantages et de ses inconvénients, notamment la non-utilisation des threads, source de problèmes de performance sur des serveurs C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 très chargés. Cela est d’autant plus vrai que la séparation des privilèges implique un processus minimum pour chaque hôte virtuel. Ce MPM accepte les mêmes paramètres que Prefork, auxquels on ajoute les suivants, à configurer dans chaque hôte virtuel (VirtualHost)...
32 GNU/LiNUx maGaziNe Hors-série N°66 : apacHe Installation : mon premier Apache
AssignUserID permet de spécifier l’UID et le GID des processus desservant cet hôte virtuel. En l’absence de ce paramètre, le couple UID/GID par défaut de la configuration d’Apache sera utilisé. MaxClientsVHost est l’équivalent de MaxClients, au niveau de l’hôte virtuel. Cela permet de limiter les ressources consommées par un hôte, ou au contraire d’en privilégier un par rapport aux autres. NiceValue, dans le même ordre d’idées, permet de spécifier une valeur de nice (« niceness ») pour les processus de l’hôte en question. Ce MPM étant distribué indépendamment et moins utilisé, notons qu’il est moins testé que Worker et Prefork ; il n’est cependant pas expérimental et fonctionne correctement.
Configuration Définition 3 et modules Niceness La valeur de nice, ou niceness Lors de l’installation du paquet apache2, un certain nombre en anglais, est une notion liée à d’éléments de configuration ont été mis en place (répertoires et l’exécution des processus sur un fichiers). Ainsi, on retrouve dans le répertoire /etc/apache2 système UNIX. Cette valeur définit une configuration par défaut fonctionnelle et prête à accueillir nos la priorité de chaque processus modifications, selon nos besoins. lorsque le noyau doit décider à quel processus donner la main. D’ailleurs, un site web de base est déjà desservi : en allant à l’adresse Par défaut, cette valeur est de 10. http://127.0.0.1 (ou à l’adresse IP du serveur, si Apache est installé Lorsque la valeur est plus grande (le sur une machine tierce) dans un navigateur web, on voit s’afficher le processus est plus « sympathique », célèbre « It works! ». nice en anglais), le processus a une plus faible priorité ; au contraire, plus la valeur est petite plus le processus est prioritaire. Cette valeur va de -20 à 19.
Ça marche, le serveur HTTP lui-même nous le dit !
Sur les distributions Debian, Ubuntu et leurs dérivées, la C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 configuration d’Apache2 est répartie dans plusieurs fichiers. On retrouve alors dans le fichier de configuration apache2.conf tous les éléments qui concernent le serveur dans son ensemble – ce fichier est très rarement modifié. Par le biais d’instructions Include, ce fichier en appelle d’autres, de manière à répartir cette configuration.
GNU/LiNUx maGaziNe Hors-série N°66 : apacHe 33 Installation : mon premier Apache 2 On appelle de cette manière les fichiers et ensembles de fichiers suivants : → mods-enabled/*.load et mods-enabled/*.conf pour l’activation des modules. Les fichiers .load regroupent les directives de chargement des modules (LoadModule), alors que les fichiers .conf comprennent les éléments de configuration propres aux modules en question ;
→ httpd.conf pour les paramètres spécifiques à l’administrateur/au système. Généralement, ce fichier est vide et inutilisé ;
→ ports.conf pour les ports TCP en écoute ; c’est ici qu’on retrouvera les directives Listen (indiquant d’écouter sur le port HTTP 80 et le port 443 si le module SSL est activé), ainsi que les directives NameVirtualHost, permettant de configurer les hôtes virtuels (voir plus loin) ; à savoir → sites-enabled/* pour la configuration spécifique L'arborescence que l'on découvre ici est spécifique aux distributions des sites. Un fichier 000-default est en place avec Debian, Ubuntu et leurs dérivées. l’installation par défaut. C’est ce fichier qui détermine Cette organisation des fichiers ne comment afficher la page « It works! » que nous avons vue sera pas retrouvée sur d'autres plus haut ; distributions, par exemple Fedora ou Red Hat. Ces dernières proposent → conf.d/* pour les éléments de configuration une organisation bien plus simplifiée complémentaires ; en général des configurations globales au (fichiers /etc/httpd/httpd.conf et serveur que l’on peut modifier. /etc/httpd/conf.d/*.conf) ; c'est une autre approche, ni meilleure, ni Notons que la configuration spécifique aux sites web est dans moins bien : à chacun de configurer des fichiers spécifiques et non dans apache2.conf ou son serveur web comme il l'entend. httpd.conf. C’est une bonne pratique à conserver : diviser la On peut d'ailleurs tout à fait configuration dans plusieurs fichiers, un fichier par site. mettre en place sous Fedora une configuration telle que celle de Ceux qui auront lu les paragraphes précédents en consultant Debian, et inversement. le contenu du répertoire /etc/apache2 sur leur ordinateur n’auront pas manqué de remarquer la présence des répertoires mods-available et sites-available. En réalité, les répertoires mods-enabled et sites- enabled ne contiennent que des liens symboliques vers leurs équivalents en *-available. C’est encore là un bon exemple à suivre : créer des configurations dans un répertoire « available » et activer ces configurations à la demande avec des liens. En réalité, ces liens symboliques sont gérés par des commandes spécifiques :
C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 → a2ensite pour activer un site (apache2 enable site) ;
→ a2dissite pour désactiver un site (apache2 disable site) ;
→ a2enmod pour activer un module (apache2 enable module) ;
→ a2dismod pour désactiver un module (apache2 disable module).
34 GNU/LiNUx maGaziNe Hors-série N°66 : apacHe Installation : mon premier Apache
Ces commandes peuvent être utilisées de deux manières : soit directement avec le nom d’un site (d’un fichier de sites-available, en vérité) ou d’un module en argument, soit sans aucun argument ; dans ce dernier cas, la commande proposera la liste des sites ou des modules qui peuvent être activés : Terminal ~# a2ensite Your choices are: default default-ssl Which site(s) do you want to enable (wildcards ok)? ~# a2enmod ssl Enabling module ssl. See /usr/share/doc/apache2.2-common/README.Debian.gz on how to configure SSL and create self-signed certificates. Run ‘/etc/init.d/apache2 restart’ to activate new configuration!
Notons que le contenu des fichiers est chargé par ordre alphabétique : si un fichier doit forcément être chargé avant un autre, charge à l’administrateur de les nommer de manière adéquate. En réalité, toutes les fonctionnalités d’Apache2 sont implémentées sous forme de modules. Certains d’entre eux sont simplement compilés directement dans Apache de manière statique. Pour en connaître la liste, il suffit d’exécuter apache2 avec l’option -l : Terminal ~# apache2 -l Compiled in modules: core.c mod_log_config.c mod_logio.c worker.c http_core.c mod_so.c
Conclusion
Arrêtons là cette présentation du serveur HTTP Apache. Nous avons vu comment cet outil s'articule, les différents modes de fonctionnement qu'il propose, ainsi que son architecture modulaire. En réalité, avec la simple commande apt-get install apache2 nous avons déjà un serveur prêt à faire son office ; mais sa configuration reste minimale et on peut l'affiner de différentes manières. Nous allons voir par la suite les principaux points de configuration :
C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 les hôtes virtuels et l'authentification. ▪
Références Documentation Apache sur les MPM : http://httpd.apache.org/docs/2.4/mpm.html Site web du MPM ITK : http://mpm-itk.sesse.net/
GNU/LiNUx maGaziNe Hors-série N°66 : apacHe 35 Installation : mon premier Apache 2 iNstaLLatioN
coNfiGUratioN basiqUe C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5
ne fois un serveur Apache en place, il est nécessaire de le configurer afin de répondre à nos besoins. Cette configuration se fait à travers un certain nombre de fichiers, à Umodifier avec votre éditeur de texte préféré.
36 GNU/LiNUx maGaziNe Hors-série N°66 : apacHe Installation : configuration basique
Définition URL 1 Les hôtes virtuels Le sigle URL (pour Universal Resource Très souvent, un serveur matériel est largement surdimensionné par Locator) désigne la rapport aux besoins d’un seul site web ; cela d’autant plus que les chaîne que l’on appelle couramment « adresse serveurs récents sont de plus en plus puissants. De plus, placer toutes web », utilisée pour vos applications et toutes vos données dans des sous-répertoires de pointer de manière unique /var/www n’est pas très élégant. Heureusement, un concept simple vers une ressource sur permet d’obtenir une solution parfaitement adaptée : les hôtes virtuels. Internet : document HTML, image, son, vidéo, Dans les grandes lignes, lorsque l’on saisit l’adresse (URL) d’un site e-mail, forum Usenet, etc. dans un navigateur, une requête DNS transforme cette adresse textuelle (appelée FQDN, pour Fully Qualified Domain Name) en adresse IP numérique. Cette adresse IP est celle de votre machine où réside le serveur Apache (votre serveur web). Cette association FQDN/adresse IP n’est pas nécessairement exclusive : un nombre illimité de FQDN peuvent être associés à une seule et même adresse IP. à partir de là, lorsque votre navigateur web interroge un serveur, il précise le FQDN qu’il recherche et le serveur HTTP - Apache en l’occurrence - est capable de desservir des données différentes selon le serveur demandé. L’hôte physique est le même, mais il s’agit virtuellement, pour les navigateurs (clients) qui s’y connectent, de serveurs différents : dans la terminologie d’Apache, on parle alors d’« hôtes virtuels ». Dans le cas de figure le plus courant, on souhaite donc héberger deux sites web ou plus, ayant des adresses (URL) différentes, mais avec une seule interface réseau et une seule adresse IP.
1.1 Configuration
La configuration d’Apache utilise des balises sous la forme <...> / , à l’instar des langages HTML et XML. Un hôte virtuel est défini avec un bloc tel que le suivant : Fichier
C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5
Nous définissons donc ici un hôte virtuel. L’argument en ouverture du bloc, « *:80 », correspond à l’interface physique et au port sur lequel écouter. L’adresse IP de l’interface physique peut être remplacée par *, comme ici, pour indiquer que cet hôte virtuel doit être desservi sur toutes les interfaces réseau. C’est le cas pour la plupart des serveurs.
GNU/LiNUx maGaziNe Hors-série N°66 : apacHe 37 Installation : configuration basique 2 On peut également rencontrer, à la place de l’adresse IP, directement un FQDN ; dans ce cas, il sera résolu lors du démarrage d’Apache et l’adresse IP résultante sera utilisée. Notons également qu’une adresse IPv6 doit être placée entre crochets [ et ]. Enfin, le mot-clé _default_ permettra de créer un point de chute pour les connexions sur des adresses IP non configurées, le cas échéant. On pourrait donc également rencontrer la forme suivante : Fichier
1.1.2 NameVirtualHost
Dans les deux cas, Apache devra avoir été « prévenu » de la définition de tels hôtes virtuels, par l’intermédiaire de la directive NameVirtualHost.
C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 Dans la configuration par défaut proposée par Debian et Ubuntu, cette directive est placée dans le fichier /etc/apache2/ports.conf, associée à la définition du port en écoute : Fichier NameVirtualHost *:80 Listen 80
38 GNU/LiNUx maGaziNe Hors-série N°66 : apacHe Installation : configuration basique
Il n’est généralement pas nécessaire de modifier cette configuration (sauf cas particuliers), vu qu’elle correspond à l’usage que l’on en fait la plupart du temps.
1.1.3 Plusieurs fichiers
Conformément aux bonnes pratiques indiquées par la configuration par défaut de Debian et Ubuntu, il est préférable de placer un hôte virtuel ou un groupe d’hôtes liés dans un seul fichier de configuration. Ces fichiers de configuration seront à placer dans le répertoire /etc/apache2/ sites-available, puis activés avec la commande a2ensite.
1.2 Ordre de priorité
L’ordre des directives est important. En effet, si Apache ne sait pas définir précisément quel hôte virtuel distribuer, il fait au mieux et prend le premier à savoir qui correspond. Le répertoire /srv Cela est notamment important lorsque l’on accède au serveur directement par Historiquement, les son adresse IP ou si on lui demande une URL qu’il ne connaît pas : dans ce cas, fichiers correspondant il retourne le premier hôte virtuel qui correspond à l’adresse IP définie. aux sites web sont placés C’est pour cela que l’hôte virtuel de la configuration par défaut d’Apache2 dans le répertoire /var/ www. Cependant, cet usage sur Debian et Ubuntu est dans un fichier 000-default : ces trois zéros ne correspond pas à lui permettent d’être évalué en premier lieu et de servir d’hôte par défaut. l’objectif initial du point Autrement dit, ne placez pas une application critique et privée dans le de montage /var, à savoir tout premier hôte virtuel : n’importe qui pourrait y accéder sans même l’hébergement de données connaître son URL ! variables comme des logs, des tampons, des files d’attentes... C’est pourquoi le point de 1.3 Exemple montage /srv a été intégré à la FHS (Filesystem Imaginons deux sites, que nous appellerons Bachi et Bouzouk et que nous Hierarchy Standard) : rendrons accessibles par les adresses « www.bachi.org », « bachi.org », celui-ci a pour objectif « www.bouzouk.net », « w.bouzouk.net » et « bouzouk.net ». d’héberger les données Nous allons placer les données de ces deux sites dans les répertoires relatives aux serveurs en suivants : fonctionnement sur la machine : sites web, bases → /srv/www/bachi de données... → /srv/www/bouzouk De plus, les outils systèmes automatiques ne doivent Pour cette démonstration, nous placerons dans ces répertoires des pages normalement pas toucher HTML très simples, qui nous permettront de vérifier le bon fonctionnement à /srv, ce qui permet de notre configuration. de s’assurer que toute Une telle situation serait matérialisée par les deux fichiers suivants : donnée dans /srv y a été placée manuellement et → /etc/apache2/sites-available/bachi : est gérée manuellement Fichier
C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 par l’administrateur du
GNU/LiNUx maGaziNe Hors-série N°66 : apacHe 39 Installation : configuration basique 2 → /etc/apache2/sites-available/bouzouk : Fichier
Nous savons comment définir des hôtes virtuels... Voyons maintenant comment les configurer !
2 Configuration d’un site
La majorité de la configuration d’Apache se fait dans ces fichiers « sites-available » ; les paramètres sont pour la plupart spécifiques à chaque site, c’est pourquoi ils doivent être placés dans les blocs VirtualHost (à l’instar de ServerName et ServerAlias).
Avant tout, le paramètre DocumentRoot, que nous venons de rencontrer, permet de signaler à Apache où il doit chercher les fichiers à desservir. Ce paramètre peut être défini dans le contexte global ou dans les hôtes virtuels. Contexte, vous dites ?
2.1 Contextes
Chaque paramètre peut être défini dans un ou plusieurs contexte(s). Le contexte définit la portée du paramètre en question. Les contextes possibles sont les suivants :
→ La configuration du serveur, que l’on peut également appeler « contexte global », contient tous les paramètres qui ne sont pas définis dans un bloc ; le paramètre NameVirtualHost, que nous avons vu plus haut, ne peut être défini que dans ce contexte ;
→ Chaque hôte virtuel est un contexte, un paramètre configuré dans un hôte virtuel étant actif uniquement pour celui-ci ;
→ Au sein des hôtes virtuels ou dans le contexte global, on peut définir des droits selon les répertoires grâce à un bloc
→ Les fichiers .htaccess permettent également de définir des contextes : les paramètres dans ces fichiers ne sont actifs que dans le répertoire où ils sont placés et ses sous-répertoires. C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 2.1.1 .htaccess
Vous avez sûrement déjà entendu parler de fichiers .htaccess : ces fichiers permettent de modifier certains aspects de la configuration d’Apache sans avoir accès aux fichiers de configuration ; c’est très utile sur des serveurs où les webmestres n’ont pas accès au serveur en tant que root : ils peuvent alors définir certains points de configuration de manière indépendante.
40 GNU/LiNUx maGaziNe Hors-série N°66 : apacHe Installation : configuration basique
L’utilisation ou non de ces fichiers est conditionnée par la directive AllowOverride. Ce paramètre spécifie quels types de directives présentes dans un .htaccess peuvent prévaloir sur la configuration système. None bloque toute modification de la configuration et désactive ce mécanisme dans son ensemble, All autorise tous les cas d’utilisation de ces fichiers. Les autres arguments acceptés par cette directive sont : à retenir → AuthConfig permet de modifier la configuration des méthodes d’authentification. C’est l’un des cas les plus courants d’utilisation du Fichiers .htaccess fichier .htaccess, avec une demande de et performances login/pass simple pour l’accès au contenu d’un répertoire ; Bien que très utiles → Limit permet l’utilisation des directives concernant l’accès au serveur dans certains cas, les (Allow, Deny et Order – voir plus loin pour la signification de ces fichiers .htaccess ont directives) ; un impact négatif sur les performances. En → FileInfo permet d’autoriser la manipulation des directives sur les effet, à chaque requête, fichiers (types MIME, pages d’erreur, filtres, règles de réécriture...) ; Apache doit alors relire et réinterpréter ce → Indexes concerne la manipulation des paramètres concernant fichier pour modifier l’indexation des répertoires et sa présentation ; temporairement sa → Options autorise la modification de la configuration des options sur configuration. De plus, les répertoires. Apache recherche ce fichier dans le répertoire Cette directive n’est acceptée que dans le contexte de répertoires. cible de la requête, mais également dans ses répertoires parents, de 2.2 DirectoryIndex manière récursive et cela, à chaque requête La directive DirectoryIndex permet de préciser les fichiers d’index également. à utiliser lorsqu’une requête est dirigée vers un répertoire et non vers un Lorsque vous avez fichier. Cette directive est acceptée dans les quatre contextes. accès aux fichiers de configuration d’Apache, En argument de cette directive est donné un certain nombre de noms de il est préférable d’y fichiers ; ils sont essayés dans l’ordre. Notons que l’on n’est pas obligé insérer directement les de pointer vers des fichiers du répertoire en question : on peut donner directives nécessaires, le chemin relatif vers un fichier dans un sous-répertoire, ou encore un sans passer par un fichier .htaccess, et désactiver chemin absolu vers un autre fichier, un script CGI par exemple. totalement leur utilisation Par défaut sur Debian, sa valeur est la suivante : (AllowOverride None). Fichier DirectoryIndex index.html index.cgi index.pl index.php index.xhtml index.htm
Cette fonction peut être complètement désactivée avec l’argument disabled.
2.3 Options C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 La directive Options permet de spécifier des options à appliquer quant au traitement des requêtes à destination du contexte courant (elle est acceptée dans les quatre contextes). Avec l’argument None, aucune option n’est activée ; avec l’argument All, toutes les options sont activées, sauf MultiViews. Les options peuvent être précédées de « + » (pour forcer leur activation) ou « - » (pour forcer leur désactivation).
GNU/LiNUx maGaziNe Hors-série N°66 : apacHe 41 Installation : configuration basique 2 Voyons les options les plus courantes : → ExecCGI autorise l’exécution de scripts CGI (voir plus loin) ;
→ FollowSymlinks précise au serveur de suivre les liens symboliques placés dans ce répertoire. Notez que le fait de désactiver cette option ne doit pas être considéré comme un mécanisme de sécurité. Si vous souhaitez interdire l’utilisation des liens symboliques dans un répertoire de votre arborescence web, supprimez-les tout simplement ;
→ Indexes permet d’afficher le contenu du répertoire si un fichier d’index n’y est pas présent – cet affichage est géré par le module autoindex d’Apache2 – désactiver cette option est équivalent à l’utilisation de la directive DirectoryIndex disabled ;
→ MultiViews active le mécanisme de multivues (si le module negotiation est chargé – c’est le cas dans l’installation par défaut de Debian).
Contenu d’un répertoire, généré par le module autoindex
2.4 Négociation de contenu et multivues
La notion de négociation de contenu est présente dans le standard HTTP/1.1. Il s’agit, pour le serveur, de pouvoir choisir la façon la plus adaptée de présenter un contenu en fonction des préférences du navigateur qui aura émis la requête. Un exemple typique est la langue préférée de l’utilisateur distant. Le navigateur précise la langue souhaitée dans l’en-tête HTTP et le serveur essaie de faire le choix le plus approprié en fonction des données dont il dispose. Ce sont les concepts de ressources et de représentations qui sont mis en œuvre. Le navigateur demande une ressource et Apache dispose d’une ou plusieurs représentations (variantes) qu’il va donc négocier. Un autre exemple concerne le format. Avec des ressources graphiques, les différentes variantes d’une représentation peuvent être différents formats de plus ou moins bonne qualité. L’algorithme de négociation d’Apache utilisé pour faire le choix de la représentation à desservir est détaillé dans la documentation officielle du serveur. Vous pouvez affiner son
C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 fonctionnement via des fichiers de correspondance de types pour chaque ressource. Notez que cette option, bien que présente dans les fichiers de configuration, n’est que rarement d’un grand intérêt ; les fonctionnalités qu’elle adresse sont souvent gérées par l’application web desservie. De plus, il est nécessaire de bien comprendre qu’à l’instar des fichiers .htaccess ce mécanisme induit une charge sur le système hébergeant les sites. Dans la majorité des cas, désactiver le module (ou au moins l’option MultiViews) est une bonne idée.
42 GNU/LiNUx maGaziNe Hors-série N°66 : apacHe Installation : configuration basique
2.5 Autorisations d’accès
Les directives Order, Allow et Deny permettent de définir les autorisations d’accès, selon les éléments fournis par les requêtes (adresses IP, nom d’hôte, user-agent...) :
→ Allow définit les clients autorisés ;
→ Deny définit les clients interdits ;
→ Order définit l’ordre dans lequel évaluer ces deux directives.
Les possibilités fournies par Allow et Deny sont complexes. Nous nous penchons ici uniquement sur la fonctionnalité la plus basique : l’autorisation ou l’interdiction selon l’adresse IP du client. La syntaxe de ces directives est : Fichier Allow from
Dans le cas du filtrage par adresse IP du client, la définition est simplement cette adresse IP... La définition peut être remplacée par all pour signaler qu’on autorise ou qu’on interdit tous les clients. La directive Order peut prendre deux formes : Order allow,deny pour vérifier les autorisations avant les interdictions ou Order deny,allow pour vérifier les interdictions avant les autorisations. Il est important de noter que toutes les directives Allow et Deny sont vérifiées : par conséquent, si un hôte a des critères lui permettant d’être autorisé et interdit, c’est la dernière règle qui sera utilisée : interdiction pour Order allow,deny ou autorisation pour Order deny,allow.
2.5.1 Exemples
Commençons par la configuration la plus courante : Fichier Order allow,deny Allow from all
Cette configuration permet d’autoriser l’accès à tous les clients, sans exception. Si l’on veut autoriser l’accès à tous les hôtes d’un réseau sauf l’un d’entre eux, la configuration ressemblera à :
C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 Fichier Order allow,deny Allow from 192.168.0 Deny from 192.168.0.42
Ici, tout le réseau 192.168.0.x est autorisé sauf l’adresse 192.168.0.42.
GNU/LiNUx maGaziNe Hors-série N°66 : apacHe 43 Installation : configuration basique 2 Si on prend les mêmes lignes, mais qu’on inverse l’ordre : Fichier Order deny,allow Allow from 192.168.0 Deny from 192.168.0.42
L’accès est alors autorisé pour 192.168.0.42, car la ligne Allow est Définition interprétée en dernier. Syslog Syslog est une infrastruc- ture systématiquement 2.6 Alias installée sur les serveurs Une autre directive souvent rencontrée est Alias, ainsi que sa petite Linux, qui peut gérer les logs (journaux) du système sœur ScriptAlias. Ces deux directives sont gérées par le module alias. de manière centralisée. Pour ordonner les fichiers à desservir proprement, on aimerait parfois Cette infrastructure permet les stocker ailleurs que dans DocumentRoot ; on a même parfois besoin par exemple de rediriger d’avoir une arborescence totalement différente entre le serveur web et les logs vers un serveur tiers, afin de centraliser les systèmes de fichiers. C’est là que la directive Alias entre en jeu : les journaux d’un ensemble elle permet de faire pointer un chemin (une adresse web) vers un autre de serveurs dans une seule répertoire du système. base. Par exemple, si les images sont stockées dans /srv/commun/images L’utilisation de Syslog mais doivent être accessibles dans /images sur le site web, la directive n’est pas systématique : suivante peut être utilisée : la configuration par Fichier défaut d’Apache sur Debian n’utilise pas Syslog, cela ne Alias /images /srv/commun/images pose aucun problème. Il est conseillé d’utiliser cette méthode plutôt que des liens symboliques. La directive ScriptAlias est à utiliser à la place d’Alias lorsque le répertoire en question contient des scripts CGI (voir plus bas).
à savoir 2.7 Journaux Variables d’environnement Enfin, les dernières directives très courantes sont ErrorLog, LogLevel et CustomLog. Ces trois directives permettent de configurer Les variables l’enregistrement de journaux. d’environnement peuvent être utilisées ErrorLog prend comme seul argument l’endroit où stocker les journaux dans la configuration d’erreur : d’Apache, sous la forme ${
44 GNU/LiNUx maGaziNe Hors-série N°66 : apacHe Installation : configuration basique
CustomLog est une directive proposée par le module log_config (compilé « en dur » sur Debian), qui permet de définir où stocker les journaux de l’ensemble des requêtes effectuées. Cette directive a la syntaxe suivante : Fichier CustomLog
La cible peut être : → le chemin d’un fichier ; → le chemin d’une commande précédée d’un « pipe » |. Le format est une chaîne de caractères où les différentes données que l’on peut intégrer sont préfixées par le signe %. Par exemple, %h sera remplacé par le nom de l’hôte qui fait la requête, %m par la méthode de la requête (GET, POST, etc.), %u par le nom d’utilisateur s’il y a authentification, %r par la première ligne de la requête... La liste complète peut être trouvée dans la documentation officielle du serveur HTTP Apache. Le format peut également être remplacé par un nom de format, qui aura été défini par la directive LogFormat. La configuration par défaut de Debian définit les noms de formats vhost_combined, combined, common, referer et agent ; le format le plus utilisé sera combined.
2.8 Exemple
En compilant toutes ces connaissances, on peut constituer une configuration comme l’exemple suivant, tout à fait correct pour un serveur de production : Fichier
DocumentRoot /srv/www /monsite
ScriptAlias /cgi-bin/ /srv/cgi/cgi-bin/
ErrorLog ${APACHE_LOG_DIR}/monsite.fr/error.log LogLevel warn
C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 CustomLog ${APACHE_LOG_DIR}/monsite.fr/access.log combined
Références Documentation d’Apache : http://httpd.apache.org/docs/2.4/fr/ ▪
GNU/LiNUx maGaziNe Hors-série N°66 : apacHe 45 Installation : mon premier Apache 2 iNstaLLatioN
aUtHeNtificatioN
uel que soit le type de site web que l’on désire mettre en place, un moment arrive où le besoin se fait sentir de restreindre C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 Q l’accès à certaines ressources : stockage de données privées, interfaces d’administration... Apache met à disposition, en standard, un certain nombre de mécanismes d’authentification et de traitement ; d’autres mécanismes peuvent être installés par ajout de modules.
46 GNU/LiNUx maGaziNe Hors-série N°66 : apacHe Installation : authentification
1 Précisions
Commençons par un peu de jargon. Dans les dernières versions du serveur HTTP Apache (à partir d’Apache 2.2), une normalisation des noms des modules d’authentification a eu lieu : on distingue les modules auth_*, authn_*, authz_* et authnz_*. Cette convention de nommage permet de distinguer authentification et autorisation. L’authentification (ou identification) est le procédé permettant de s’assurer qu’une entité est bien celle qu’elle prétend être. Au quotidien, cette identification peut être effectuée en montrant sa carte d’identité. L’autorisation, en revanche, est l’acte de vérifier et valider qu’une entité (préalablement authentifiée) est bien en droit d’accomplir une action précise. On peut donc distinguer les familles de modules suivantes : → authn : ce sont les modules ne traitant que de l’authentification ; → authz : ce sont les modules ne traitant que de l’autorisation ; → authnz : ce sont les modules couvrant les deux fonctionnalités ; → auth : ce sont les modules « frontaux », chargés de la méthode de communication des données, mais n’effectuant pas eux-mêmes les actions d’authentifier ou d’autoriser. Il convient en effet de faire la différence entre le type d’authentification HTTP (modules auth_*) et le back-end d’authentification utilisé (modules authn*). Le type d’authentification HTTP définit la manière dont les données sont transmises entre le client et le serveur (basic ou digest, par exemple) alors que le back-end d’authentification implémente la manière dont les données d’authentification sont stockées et interrogées.
2 Les types d’authentification
Deux types d’authentification sont disponibles lorsqu’on parle de transmission de données par le protocole HTTP (nous excluons ici ce qui concerne le protocole chiffré HTTPS, qui sera traité plus loin). Des deux types disponibles, basic et digest, le premier est le plus simple et le plus courant. Le second, bien que standard, peut poser problème avec certaines applications basiques, ainsi qu’avec les anciennes versions d’Internet Explorer (IE5 et IE6).
2.1 Basic C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5
La méthode d’authentification basic est décrite dans les RFC 1945 (HTTP/1.0) et 2617 (HTTP Authentication : Basic and Digest Access Authentication). C’est la plus simple à mettre en œuvre, car elle possède la caractéristique (déplaisante) de faire circuler le mot de passe en clair sur le réseau. Il est donc très facile de sniffer ce type de données en transit à chaque requête et de voler le mot de passe de l’utilisateur. Par contre, c’est la méthode qui fonctionnera à coup sûr avec tous les clients HTTP.
GNU/LiNUx maGaziNe Hors-série N°66 : apacHe 47 Installation : authentification 2 L’échange entre le client et le serveur HTTP est alors le suivant :
1. Le client demande une URL au serveur sans préciser d’authentification ;
2. Le serveur répond avec le code d’erreur 401 Unauthorized accompagné d’un en-tête WWW-Authenticate: Basic realm="
3. Le navigateur demande éventuellement le nom d’utilisateur et le mot de passe à son utilisateur et retente la requête, en ajoutant l’en-tête Authorization: Basic
4. Le serveur vérifie les données d’authentification envoyées par le Définition client, puis : 4a. si l’authentification est correcte, il retourne la ressource Base64 demandée, Base64 est une norme 4b. si l’authentification échoue, il renvoie une erreur 401, de codage utilisant puis retour à l’étape 2. 64 caractères, chaque caractère représentant La configuration et le choix de ce type d’authentification côté 6 bits de l’information serveur Apache se font avec la directive AuthType Basic. d’origine. Les caractères Voici un exemple de configuration : utilisés sont les lettres Fichier majuscules, les lettres minuscules, les chiffres AuthType Basic ainsi que + et /. Cela AuthName «ma zone privee» permet de s’assurer que AuthBasicProvider file les données ne seront pas AuthUserFile /etc/apache2/users altérées lors du transport Require valid-user des données, car ces 64 caractères sont identiques On utilise ici le back-end file (voir plus loin pour des détails sur dans toutes les variantes locales de la table ASCII. les back-ends) ; la directive Require valid-user permet de restreindre l’accès aux utilisateurs dont l’authentification est valide ; Attention, il ne faut pas AuthUserFile file confondre codage et la directive est nécessaire pour le back-end , chiffrement : le premier nous la rencontrerons à nouveau plus loin. ne sert qu’à changer le format d’une donnée et est réversible sans clé ni mot de passe. Base64 ne 2.2 Digest protège pas les données L’authentification digest est définie dans la RFC 2617, qui remplace transmises. la RFC 2069 (An Extension to HTTP : Digest Access Authentication). Elle offre un peu plus de sécurité en ne laissant pas transiter le mot de passe entre le navigateur et le serveur : le mot de passe est alors C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 hashé. En contre-partie, le mécanisme est bien plus complexe et la configuration demande plus de paramètres pour être efficace. L’échange entre le client et le serveur HTTP est alors un peu plus complexe qu’avec basic : 1. Le client demande une URL au serveur sans préciser d’authentification ;
48 GNU/LiNUx maGaziNe Hors-série N°66 : apacHe Installation : authentification
2. Le serveur répond avec le code d’erreur 401 Unauthorized accompagné d’un en-tête WWW-Authenticate: Digest
3. Le navigateur demande éventuellement le nom d’utilisateur et le mot de passe à son utilisateur, puis calcule une réponse en fonction du challenge et du mot de passe, il transmettra alors la réponse sous forme d’un digest MD5 ;
4. Le serveur vérifie les données d’authentification envoyées par le client en les comparant avec le hash MD5 qui est en sa possession, puis : 4a. si l’authentification est correcte, il retourne la ressource demandée, 4b. si l’authentification échoue, il renvoie une erreur 401, puis retour à l’étape 2. à retenir La mise en œuvre de ce mode d’authentification avec Apache2 Hashage prendra la forme suivante : Le hashage consiste à Fichier calculer une empreinte AuthType Digest permettant d’identifier AuthName «ma zone privee» une donnée de manière AuthDigestProvider file unique, sans transmettre AuthDigestDomain /prive la donnée elle-même. AuthUserFile /etc/apache2/users Les algorithmes de Require valid-user hashage assurent que deux données différentes n’auront jamais la même Avec cette authentification, les champs utilisés dans l’en-tête empreinte. HTTP WWW-Authenticate sont les suivants : Pour un maximum de → realm est le « royaume » (ou domaine de protection), tel sécurité, le hashage est que défini par AuthName (de la même manière qu’avec « salé » (une autre valeur l’authentification basic) ; y est adjointe), afin de ne pas transmettre → domain permet de spécifier un ou plusieurs URI qui se deux fois la même trouvent dans le même domaine de protection, ce champ étant empreinte. Le serveur défini par la directive AuthDigestDomain ; ayant connaissance de l’empreinte simple et → nonce correspond à un nombre à usage unique à utiliser pour du sel sera capable de le challenge ; cette valeur peut éventuellement être contrôlée valider l’exactitude de par la directive optionnelle AuthDigestNonceLifetime, l’empreinte « salée ». déterminant la durée pendant laquelle elle est valable ; réduire cette durée de vie permet de limiter les risques de rejeu d’un même challenge, la valeur par défaut étant de 5 minutes, une valeur négative imposant une durée illimitée de validité du nonce (dangereux) ;
C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 → opaque est une chaîne de caractères optionnellement fournie au navigateur, qui devra la retourner à l’identique ; → stale est un code de réponse permettant de signaler au navigateur que le nonce utilisé est expiré : si c’est le cas, le navigateur retourne une réponse avec le code d’erreur 401 et la valeur stale à true, forçant ainsi le navigateur à utiliser le nouveau nonce ;
GNU/LiNUx maGaziNe Hors-série N°66 : apacHe 49 Installation : authentification 2 → algorithm indique l’algorithme de hashage à utiliser pour le calcul du digest – pour l’heure, seul l’algorithme MD5 est supporté, alors que la norme définit également la possibilité d’utiliser MD5-sess, mais la documentation d’Apache indique que ce dernier est mal implémenté ; → qop (pour quality of protection) permet un choix théorique entre une simple authentification avec auth et une authentification avec contrôle d’intégrité avec auth-int. Lorsque les deux valeurs sont spécifiées, le navigateur peut choisir le niveau de qualité qu’il souhaite utiliser. Cependant, Apache n’implémente pas encore auth-int.
2.3 Form
Cette troisième option n’est pas à proprement parler un type d’authentification HTTP. Il s’agit d’une implémentation, au sein du navigateur, d’une habitude qui a été prise par la plupart des développeurs d’applications web : l’authentification par formulaire. En effet, les fenêtres d’authentification des navigateurs ne sont pas toujours très « sexy », les sites présentent alors des formulaires. Dans ce cas, l’authentification est entièrement déportée dans l’application elle-même, en contournant complètement les mécanismes d’authentification d’Apache. Ce pseudo-type d’authentification permet de conserver cette présentation en formulaire tout en utilisant les mécanismes (back-ends) d’authentification d’Apache. Notons que, dans ce cas, le mot de passe circule en clair sur le réseau, comme dans le cas de l’authentification basic. Pour utiliser cette authentification, les lignes suivantes peuvent par exemple être utilisées dans la configuration d’Apache : Fichier AuthType form AuthFormProvider file AuthUserFile /etc/apache2/users AuthName «ma zone privee» AuthFormLoginRequiredLocation /login.html Session On SessionCookieName session path=/ SessionCryptoPassphrase
Cette option n’est disponible qu’à partir d’Apache 2.4, elle n’est donc pas utilisable sur des serveurs Debian ou Ubuntu actuels...
Les back-ends
C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 3
Maintenant que nous en savons un peu plus sur les types d’authentification possibles, nous pouvons nous pencher sur la partie la plus intéressante : la manière de stocker les informations d’authentification sur notre serveur. Il existe un nombre important de providers différents. Certains peuvent être utilisés indifféremment avec une authentification basic ou digest, d’autres ne fonctionneront qu’avec basic (ou form).
50 GNU/LiNUx maGaziNe Hors-série N°66 : apacHe Installation : authentification
C’est le cas, par exemple, de l’authentification via LDAP, qui n’est pas compatible avec le stockage des hashs car utilisant le système d’authentification du serveur LDAP. Ce module, authnz_ldap, mérite à lui seul un article spécifique tant il y a de choses à dire sur sa mise en œuvre. Nous l’aborderons ultérieurement. Le choix du provider à utiliser se fait grâce à la directive AuthBasicProvider, AuthDigestProvider ou AuthFormProvider.
3.1 File
Le provider file est le plus simple à mettre en œuvre, il est généralement le plus utilisé sur des serveurs « personnels ». Il permet de traiter les données stockées dans de simples fichiers texte, où le nom d’utilisateur et le mot de passe associé sont référencés ligne par ligne. Par défaut, le mot de passe est chiffré par la fonction crypt(), mais il est également possible de choisir un stockage sous forme de hash MD5, voire pour les plus téméraires par un stockage du mot de passe en clair. Sa mise en place est très simple, avec une configuration comme ce que nous avons vu plus haut : Fichier AuthType Basic AuthName «ma zone privee» AuthBasicProvider file AuthUserFile /etc/apache2/users Require valid-user
La seule directive utilisée par ce provider est AuthUserFile, qui doit pointer vers le fichier qui contient les mots de passe.
3.1.1 Gérer le fichier de mots de passe
Le fichier de mots de passe pour ce provider avec une authentification basic peut être géré avec la commande htpasswd. L’utilisation de base de cette commande est la suivante : Fichier htpasswd
Pour une première exécution, cette commande prend l’argument -c (pour create, créer le fichier). Pour créer le fichier /etc/apache2/users avec un utilisateur monlogin, la commande sera donc : Terminal
C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 ~# htpasswd -c /dev/apache2/users monlogin
Pour automatiser cette commande, on peut utiliser l’option -b, qui permet de donner le mot de passe en argument : Terminal ~# htpasswd -b /dev/apache2/users autrelogin sonmotdepasse
GNU/LiNUx maGaziNe Hors-série N°66 : apacHe 51 Installation : authentification 2 Mais attention, si vous exécutez cette commande manuellement, il y a de fortes chances que le mot de passe soit stocké en clair... dans l’historique de votre shell !
Les autres options intéressantes sont -m pour utiliser MD5, -s pour forcer SHA, -D pour supprimer un utilisateur...
Lorsque le type d’authentification est digest, l’outil pour gérer le fichier de mots de passe est htdigest. Cette commande n’accepte que l’argument -c, pour créer le fichier de mots de passe. Il n’est pas possible de donner le mot de passe en ligne de commandes, par exemple. De plus, cette commande prend un argument supplémentaire, le domaine de protection (realm) : Fichier htdigest [-c]
Par exemple : Terminal ~# htdigest -c /etc/apache2/users «ma zone privee» monlogin
3.2 DBM
Lorsqu’on gère un nombre de plus en plus important d’utilisateurs, les fichiers texte, non optimisés pour les recherches, arrivent à leurs limites. Il faut donc envisager l’utilisation d’un format de base de données plus adapté à ce genre de manipulations.
La version « light » de cette mise en œuvre prend forme avec le module authn_dbm, permettant de stocker les couples login/mot de passe dans un fichier au format Berkeley DB.
Une configuration d’Apache pour ce provider peut, par exemple, être la suivante : Fichier AuthType Basic AuthName «ma zone privee» AuthBasicProvider dbm AuthDBMUserFile /etc/apache2/users.dbm AuthDBMGroupFile /etc/apache2/users.dbm Require valid-user
3.2.1 Gérer la base DBM
C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 Un tel fichier pourra être créé très facilement pour le type d’authentification basic. Un outil spécialement conçu et livré avec Apache est disponible, sous le nom dbmmanage. Cette commande prend différents arguments :
→ En premier, le nom de fichier sur lequel travailler ;
→ En second, la sous-commande à exécuter ;
→ Enfin, le ou les arguments relatifs à cette sous-commande.
52 GNU/LiNUx maGaziNe Hors-série N°66 : apacHe Installation : authentification
Voici quelques exemples d’utilisation de cette commande... → Ajouter un utilisateur à la base : Terminal ~# dbmmanage /etc/apache2/users.dbm adduser monlogin
→ Ajouter un utilisateur en précisant son groupe : Terminal ~# dbmmanage /etc/apache2/users.dbm adduser autrelogin – autregroupe
→ Modifier le groupe auquel appartient un utilisateur : Terminal ~# dbmmanage /etc/apache2/users.dbm update monlogin . mongroupe
→ Supprimer un utilisateur : Terminal ~# dbmmanage /etc/apache2/users.dbm delete monlogin
→ Lister les utilisateurs de la base (le retour de cette commande précise également le groupe) : Terminal ~# dbmmanage /etc/apache2/users.dbm view
3.2.2 DBM et digest
Si on essaye de changer le type d’authentification de basic à digest, on se rend rapidement compte d’un problème dans les journaux d’Apache : Fichier Digest: user ‘monlogin’ in realm ‘ma zone privee’ not found: /prive/
Le fichier DBM ne contient pas l’information nécessaire à l’authentification digest, car la commande dbmmanage ne dispose d’aucune option adaptée à ce type d’authentification. Il est cependant possible de forcer un peu la main de dbmmanage en faisant nous-mêmes une partie du travail. En regardant les sources du serveur et des modules, on comprend ce qu’Apache s’attend à trouver en lisant les fichiers DBM pour ce type d’authentification. Le nom d’utilisateur stocké, tout d’abord, est composé à la fois du login et du domaine de protection, les deux étant séparés par un double-point. Ceci est relativement facile à régler en ligne de commandes. C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 D’autre part, le mot de passe chiffré dans la base DBM doit être le condensé MD5 de la concaténation du nom d’utilisateur, du domaine de protection et du mot de passe en clair de l’utilisateur, séparés par des double-points. En d’autres termes, il faut stocker le résultat de echo -n "
GNU/LiNUx maGaziNe Hors-série N°66 : apacHe 53 Installation : authentification 2 On peut donc écrire un court script shell qui servira de wrapper à dbmmanage : Fichier # !/bin/sh FILE=$1 CMD=$2 USER=$3 REALM=$4 PASS=$5 GROUP=$6
HASH=$(echo -n «$USER:$REALM:$PASS» | md5sum | cut -d» « -f1) DBUSER=$(echo -n «$USER:$REALM)
/usr/bin/dbmmanage «$FILE» «$CMD» «$DBUSER» «$HASH» «$GROUP»
Ce n’est là, bien entendu, qu’un premier jet ne demandant qu’à être amélioré et nettoyé. Dans les grandes lignes, on génère, dans la variable $HASH, le condensé (ou hash) MD5 qui servira de mot de passe et le nom d’utilisateur dans $DBUSER. On reprend ensuite les autres éléments de la commande pour composer la syntaxe de dbmmanage. Ce n’est, bien entendu, qu’une solution parmi d’autres, car en y regardant de plus près... Terminal ~# file $(which dbmmanage) /usr/bin/dbmmanage: a /usr/bin/perl script text executable
... dbmmanage est un script Perl, qu’on peut tout à fait modifier pour l’adapter à nos besoins.
3.3 MySQL
Le provider dbm permet de simplifier la gestion des utilisateurs et surtout, d’accélérer les recherches si le « cheptel » est important. Cependant, la manipulation de fichiers DBM, en particulier depuis des interfaces web en PHP, Perl ou Python, n’est pas une partie de plaisir. Il s’agit en effet d’un format de base de données, mais non d’un système complet et adapté à tous les usages. Pour stocker les utilisateurs sous une forme plus facilement gérable, on peut utiliser le module auth_mysql, disponible sous Debian et Ubuntu grâce au paquet libapache2-mod-auth-mysql : Terminal ~# apt-get install libapache2-mod-auth-mysql
Comme le précise la documentation de ce module, les informations strictement nécessaires à placer dans une table MySQL sont le nom d’utilisateur et le mot de
C e d o c u m n t s l a p r i é x v j - g ( @ h . ) 2 6 0 1 3 à : 5 passe. Avec ce provider, la configuration d’Apache peut accepter les directives suivantes (cette liste n’est pas exhaustive, elle ne détaille que les directives les plus intéressantes) : → AuthMySQLHost
54 GNU/LiNUx maGaziNe Hors-série N°66 : apacHe Installation : authentification
→ AuthMySQLSocket
→ AuthMySQLUser
→ AuthMySQLPassword
→ AuthMySQLDB
→ AuthMySQLUserTable