Installation et configuration d`Apache sous Linux RedHat 7.1 Pascal

Installation et configuration d’Apache
sous Linux RedHat 7.1
Pascal AUBRY – Ambroise DIASCORN
IFSIC – Université de Rennes 1
Octobre 2001 – version 3.0
ESAT – MSI 2ème année
Travaux pratiques (4 heures)
L’utilisation de ce document dans un but de formation de groupe, y compris dans le
domaine universitaire, est soumise à une autorisation explicite et préalable de ses auteurs.
Présentation
Le but de ce TP est d’appréhender les difficultés rencontrés par les administrateurs de sites web. Il vous permettra de voir
comment on installe, configure et entretient un serveur HTTP, et de mieux comprendre à quoi correspondent les erreurs
rencontrées en tant qu’utilisateur.
Vous n’aurez plus lors de ce TP votre rôle habituel, celui d’utilisateur du réseau, mais celui d’administrateur (avec les avantages
et les inconvénients que cela représente).
Afin de se concentrer sur Apache en lui-même, vous n’avez pas à installer le serveur et disposez d’un PC préinstallé muni de la
configuration suivante :
• Processeur : Intel PII 400 MHz
• Mémoire : 128 Mo
• Disque dur : IDE 6.4 Go (maître sur le port IDE 0)
• Adaptateur réseau : 10/100 Mbts 3Com 3C509B
• Lecteur CD-ROM : IDE (maître sur le port IDE 1)
Les PC sont reliés au réseau de l’IFSIC.
Installation du serveur
Voici la procédure d’installation des PCs de la salle de TP.
L’installation de la version 7.1 de la distribution RedHat est faite via NFS. Une disquette de boot réseau (bootnet.img) permet de
démarrer l’installation et les paramètres sont les suivants :
• Langage : French
• Clavier : fr-latin1
• Méthode d’installation : NFS
On choisit ensuite une assignation dynamique de l’adresse IP, ce qui n’est pas recommandé pour un serveur (car cela induit une
dépendance vis-à-vis du serveur DHCP) mais qui sera suffisant pour le TP. Le serveur DHCP renseigne alors la machine sur les
paramètres tels que la paserelle par défaut, le serveur DNS, ...
• Site web : ajax
• Répertoire RedHat : /current
Configuration du disque dur
Bien qu’installant un serveur, on choisit le type d’installation Custom system car l’installation est plus courte et encore une fois
suffisante.
On effectue un partitionnement automatique.
Le disque est partionné de la manière suivante :
• Une partition de swap de 128Mo
•
Une partition principale sur laquelle on installe le système (montage de la racine /) occupant le reste du disque, soit environ
4Go. Le formatage de cette partition est fait sans contrôle des blocs défectueux (trop long).
Paramétrage de LILO
On installe LILO sans passer de paramètre au noyau, sur le Master Boot Record (MBR) du disque ;
On garde l’identifiant par défaut du démarrage du système (linux).
Paramètres divers
On garde le nom de machine (i207mxx.ifsic.univ-rennes1.fr) proposé par la procédure d’installation (obtenu du serveur de noms
à partir du numéro IP renvoyé par le serveur DHCP)
• Souris : Generic 3 Button Mouse (PS/2)
• Pas de parefeu
• Horloge : Conserver le choix proposé
Utilisateurs
On ne renseigne que le mot de passe du compte super-utilisateur (ne pas créer de compte utilsateur, ceci est fait par la
finalisation de l’installation) :
• Mot de passe super-utilisateur : rootmsi2
La configuration des utilisateurs se termine en indiquant les paramètres suivants :
• Shadow password : oui
• MD5 encoding : oui
• NIS : non
• LDAP : non
• Kerberos : non
Paquetages à installer
On sélectionne les catégories suivantes :
• X-Window system
• KDE
• WWW-mail-news
• Emacs
• Poste de travail en réseau
• Serveur SQL
• Serveur Web
Si nécessaire, on demande finalement de satisfaire les dépendances manquantes.
Création d’une disquette de démarrage
On passe cette étape.
Configuration de X-Window
Bien que l’on installe en général pas d’environnement graphique sur un serveur, nous le faisons car les machines servent à la fois
de serveur et de machine cliente (pour les tests). On accepte alors les choix proposés par la procédure d’installation :
• ATI Mach 64
• Moniteur : Dell D1025HE
• Profondeur et résolution : garder le choix proposé
Première connexion
On se connecte comme super-utilisateur et on lance une fenêtre de commande pour exécuter :
wget http://perso/diascorn/formation/msi2/apache/install.sh
chmod +x install.sh
./install.sh
Ce script rapatrie divers fichiers et les installe sur la machine pour en parfaire l’installation.
Il crée également deux utilisateurs qui serviront pendant le TP :
Le compte usager de test user_xx (par exemple user_04) est l’usager sur lequel vous vous connecterez pendant le TP, et a
pour mot de passe mdpu_xx (par exemple mdpu_04).
Le compte invité guest_xx (par exemple guest_04), sur lequel les autres utilisateurs pourront se connecter sur votre machine,
et dont le mot de passe est mdpg_xx (par exemple mdpg_04).
Préparation du TP
Pour appréhender au mieux ce TP, il est conseillé de se connecter sur la machine (i207mxx) sous l’utilisateur user_xx, et
d’adopter la configuration suivante :
Configuration de base de Apache
Apache est le nom du serveur HTTP installé par la distribution RedHat de Linux. Il lance un (en fait des) démon(s) qui scrute(nt)
en permanence les requêtes sur le port 80 (par défaut).
Démarrage
Question 1. Vérifier que le service est bien lancé (à l’aide du script ou par ps -aux | grep httpd). S’il n’est pas démarré,
le démarrer.
Le service est lancé à l’installation du paquetage. Pour le lancer, il faudrait exécuter :
/etc/rc.d/init.d/httpd start
Question 2. Vérifier que le service sera bien lancé à chaque démarrage du serveur à l’aide de l’utilitaire /usr/sbin/ntsysv.
Cet utilitaire permet de décider les services qui seront démarrés au boot de la machine.
Question 3. Vérifier que le service fonctionne bien en lançant un navigateur (netscape-navigator, par l’utilisateur
user_xx) et en atteignant l’URL http://i207mxx/, ou http://localhost, ou http://i207mxx.ifsic.univrennes1.fr, ou http://148.60.5.(81+xx)/ (le numéro IP de i207mxx).
La réponse indique que tout fonctionne.
Mise à disposition de documents
Le fichier de configuration d’Apache est dans le répertoire /etc/http/conf, et est nommé
httpd.conf :
Il ne suffit pas de modifier ce fichier pour modifier le comportement du serveur HTTP (utiliser /etc/rc.d/init.d/httpd).
index des répertoires
Question 4. Au contenu de quel fichier correspond l’affichage visible à l’URL
http://i207mxx.ifsic.univ-rennes1.fr/ ?
Il s’agit de /var/www/html/index.html :
DocumentRoot /var/www/html
DocumentIndex index.html
# httpd.conf
# httpd.conf
Question 5. Visualiser le contenu du fichier /var/www/html/public/test.tp. Inspecter l’URL
http://i207mxx/public. Comment faire en sorte que cette URL renvoie le contenu du fichier test.tp ?
DirectoryIndex test.tp index.html
# httpd.conf
types de documents
La réponse du serveur à une requête HTTP est constituée de plusieurs éléments, dont trois essentiels (se référer à la RFC 2616
pour une description précise du protocole HTTP) :
• le code de retour
• le type (MIME) de la réponse
• le contenu de la réponse
Question 6. Comment est interprétée la séquence <BR> du fichier test.tp ? Que cela signifie-t-il ?
Elle n’est pas interprétée, ce qui signifie que le contenu n’est pas considéré comme du HTML.
Question 7. récupérer le fichier /var/www/html/public/test.ps à l’aide du navigateur. Qu’observez-vous ?
Le navigateur demande un chemin pour sauvegarder la réponse sur disque.
Question 8. Placez-vous dans le répertoire /tmp et récupérez le fichier test.ps à l’aide du programme wget :
cd /tmp
wget http://i207mxx/public/test.ps
Quel est le type MIME de la réponse à la requête HTTP ?
Le type de la réponse est application/postscript.
Dans toute la suite, wget peut être utilisé pour obtenir des documents via HTTP.
Question 9. Comment faire pour visualiser directement le contenu du fichier ?
Il faut configurer le navigateur (Edit, Preferences, Navigator, Applications, PostScript Document, Edit,
Application, ghostview %s).
Question 10. Qu’en déduisez-vous sur le navigateur Netscape ?
Le type des documents qui lui sont renvoyés est donné par le serveur. Il effectue des opérations différentes suivant le type
(affichage textuel, au format HTML, sauvegarde sur disque, lancement d’une application externe, ...).
Question 11. Quel est la directive qui permet à Apache de savoir quel type MIME il doit renvoyer en fonction du fichier à
servir ? Quel est le fichier concerné ? Sur quel propriété des fichiers dont il doit renvoyer le contenu se base Apache pour
décider du type de la réponse ?
TypesConfig /etc/mime.types
# httpd.conf
Apache se base sur l’extension des fichiers.
Question 12. Comment peut-on faire pour qu’Apache se base sur le contenu des fichiers ?
Il faut utiliser la directive MimeMagicFile.
Question 13. Que se passe-t-il lorsque l’on ne précise pas le type MIME à renvoyer ?
Cela dépend de la directive DefaultType.
Question 14. Comment ajouter un nouveau type ? Comment faire en sorte que la séquence <BR> de test.tp soit interprétée
comme un saut de ligne ?
En utilisant la directive :
AddType text/html .tp
Protection des données
Par le système de fichier
Question 15. Quel est l’utilisateur qui exécute le démon httpd ( ps aux | grep httpd) ?
C’est apache.
Question 16. Quelle directive permet de changer d’utilisateur (httpd.conf) ?
La directive User.
Question 17. À quel utilisateur appartient le fichier /var/www/html/index.html ? Quel sont les permissions du fichier ?
Il appartient à apache (groupe apache), permissions rw-r--r--.
Question 18. À quel utilisateur appartient le fichier /var/www/html/index2.html ? Quel sont les permissions du fichier ?
Il appartient à root (groupe root), permissions rw-rw----.
Question 19. Que se passe-t-il lorsque l’on essaie d’atteindre l’URL http://i207mxx/index2.html ?
On obtient une erreur 403 Forbidden, car apache ne peut plus lire le contenu du ficher index2.html.
Question 20. Quelles permissions faut-il donner à index2.html pour que l’URL soit lisible ?
Il faut que l’utilisateur apache puisse lire le fichier.
Par le serveur Apache, par répertoire
Un mécanisme utilisé est celui des fichiers .htaccess, qui décrit la protection des fichiers des répertoires dans lesquels on les
trouve. On préfère souvent une protection par des directives, ce qui permet une centralisation des règles de protection dans les
fichiers de configuration. C’est ce dernier mécanisme que nous allons étudier.
Noter que la protection par le serveur Apache s’ajoute à celle du système de fichiers, sans la remplacer.
Le premier type de protection est une protection par répertoire.
Question 21. Peut-on accéder à tous les fichiers du serveur via le protocole HTTP ?
Non, pas par défaut (à cause de la directive <Directory />...</Directory>.
Question 22. Comment faire en sorte que l’on puisse lire tous les fichiers de /etc ?
En donnant les mêmes directives de contrôle à ce répertoire du système qu’au répertoire /var/www/html.
En fait on ne peut pas voir la racine ; il faut indiquer un nom de répertoire .
Question 23. Est-ce conseillé ? Pourquoi ?
Certainement pas, car cela donne accès à des fichiers sensibles, tels /etc/passwd.
Question 24. Le mécanisme de protection par les fichiers .htaccess est-il actif par défaut ?
Non, grâce à la directive AllowOverride None.
Par le serveur Apache, par client
Le deuxième type de protection des données par le serveur Apache se base sur la machine émettant la requête HTTP, le client.
Pour tester la protection basée sur l’émetteur de la requête, vous ouvrirez une session sur une autre machine de la salle
(i207myy), en tant qu’utilisateur user_yy (rsh i207myy -l user_yy). Le plus simple est ensuite de lancer le programme
wget, ou bien un navigateur graphique (netscape-navigator).
Question 25. Comment faire pour n’autoriser l’accès au répertoire /var/www/html qu’au serveur lui-même ? Modifier la
configuration du serveur et tester.
Utliser des directives du type :
order allow,deny
allow from 148.60.5.(81+xx)
Question 26. Comment faire pour interdire l’accès au répertoire /var/www/html à partir de la machine i207myy ? Tester.
Ajouter simplement :
deny from 148.60.5.(81+yy)
Par le serveur Apache, en utilisant l’authentification de HTTP
Le troisième type de protection consiste en le rajout d’une authentification nominative par le client.
Comme super-utilisateur, créer un fichier de mot passe users.passwd dans
/var/www/html/private à l’aide du programme htpasswd. Donner ensuite les droits de lecture sur ce fichier à l’utilisateur
apache (seulement).
chgrp apache /var/www/html/private/users.passwd
chmod 640 /var/www/html/private/users.passwd
Ajouter la protection suivante pour le répertoire /var/www/html/private :
<Directory /var/www/html/private>
AuthType Basic
AuthUserFile /var/www/html/private/users.passwd
AuthName "private directory"
require valid-user
</Directory>
Question 27. Que se passe-t-il lorsque vous accédez de nouveau au serveur ? Que se passe-t-il si vous vous trompez dans le mot
de passe ?
Une autentification est demandée. En cas d’échec, on obtient une erreur 401 Unauthorized.
Authentification = un royaume + un user + un password
Il faut faire un échec ! !
Question 28. L’autentification est-elle nécessaire ensuite ? Pourquoi ?
Non, ces informations d’authentification sont mémorisées par le navigateur et transportées par le protocole HTTP.
Par le serveur Apache, en utilisant les deux
Créer le répertoire private2 dans /var/www/html, un fichier de d’authentification users.passwd dans ce répertoire
(différent du fichier précédent), puis ajouter la protection du répertoire /var/www/html/private2 de la façon suivante :
<Directory /var/www/html/private2>
order allow,deny
deny from all
allow from 148.60.5.(81+xx)
AuthType Basic
AuthUserFile /var/www/html/private2/users.passwd
AuthName "private2 directory"
require valid-user
satisfy any
</Directory>
Question 29. Qu’observez-vous depuis i207mxx ? depuis i207myy ?
L’authentification n’est demandée que depuis i207myy.
Exécution de programmes via HTTP
Nous ne verrons dans ce TP que deux modes d’exécution de programmes via HTTP à savoir CGI (Common Gateway Interface),
et PHP. Ce choix est basé sur le fait que ces deux modes se basent en continu sur le protocole HTTP (et non pas seulement pour
initialiser un processus communiquant avec le serveur sur un autre port que le port HTTP).Les deux autres langages les plus
connus fonctionnant sous ce mode sont ASP et JSP.
Les programmes CGI
Question 30. Peut-on exécuter des programme CGI par défaut ? Comment faire ?
Oui, les programmes CGI doivent se trouver dans le répertoire /var/www/cgi-bin (voir la directive ScriptAlias).
Question 31. Essayer d’atteindre l’URL http://i207mxx/cgi-bin/test.sh. Que doivent être les permissions des
programmes pour être exécutables via HTTP ?
Il doivent être lisibles et exécutables par l’utilisateur apache.
Question 32. Pour répondre à la question suivante, modifier le contenu du programme test.sh pour appeler le programme id.
Lorsqu’un programme est exécuté, sous quelle identité l’est-il ?
C’est l’utilisateur apache qui exécute les programmes CGI.
Question 33. Quels problèmes cela pose-t-il ?
Des problèmes de sécurité. On peut ainsi exécuter des programmes sur le serveur sans authentification.
Question 34. Comment peut-on changer l’utilisateur d’exécution des programmes ?
En faisant exécuter par apache un programme suid root qui change ensuite d’identité pour exécuter un autre programme
(cgiwrap, SuExec).
Les programmes PHP
Le but de cette partie est l’ observation de la configuration d’ un module d’Apache (PHP4).
Question 35. Observer via le système de fichiers au fichier /var/www/html/test.php. Puis accéder via HTTP au fichier
/var/www/html/test.php. Qu’observez-vous ? Pourquoi ?
Le fichier n’est pas chargé comme page statique mais il est exécuté.
Question 36. Quelles directives indiquent à Apache comment gérer les scripts PHP ?
AddType application/x-httpd-php php
LoadModule php_module modules/libphp.so
AddModule mod_php.c
Base de données
Le but de cette partie est d’installer un gestionnaire de bases de données (PostgreSQL, logiciel libre, qui a été installé lors de la
première partie de ce TP) et de voir comment on peut simplement l’interfacer avec Apache pour créer des applications
accessibles par le protocole HTTP.
Installation
Le démon (/usr/sbin/postmaster) est géré par le script /etc/rc.d/init.d/postgresql (démarrage, arrêt, statut,
redémarrage, rechargement de la configuration).
Question 37. Vérifier que le service est bien lancé (à l’aide du script ou par ps -aux | grep postmaster). S’il n’est pas
démarré, le démarrer. Que se passe-t-il ?
Le service n’est pas lancé à l’installation du paquetage. Lorsque l’on essaie de le lancer, le système crée une base de données
template1 à laquelle on peut ensuite se connecter.
Question 38. Vérifier que le service sera bien lancé à chaque démarrage du serveur à l’aide de l’utilitaire ntsysv.
PostgreSQL n’est pas lancé par défaut au démarrage. Il faut le faire pour les prochains reboots du serveur.
Question 39. Essayer de lancer l’interpréteur psql pour se connecter à la base de données template1 (psql template1).
Que se passe-t-il ?
L’utilisateur root n’est pas déclaré dans la base de données. (La base de données possède sa propre base d’utilisateurs)
Passer sous l’identité postgres :
[root@i207mxx ~]# su - postgres
[postgres@i207mxx pgsql]$
Se connecter à la base template1 :
[postgres@i207mxx pgsql]$ psql template1
template1=>
Créer une nouvelle base de données :
template1=> create database newdb ;
CREATEDB
template1=>
Se connecter à la nouvelle base :
template1 => \c newdb
newdb=>
Créer une table dans la base newdb :
newdb=> create table MyTable (cle integer,constraint MyTable_pk primary key(cle),valeur text );
newdb=>
Quitter psql :
newdb=> \q
[postgres@i207mxx pgsql]$ exit
[root@i207mxx ~]#
Utilisation
Question 40. Exécuter le fichier /tmp/script.sql (psql newdb < /tmp/script.sql). Que se passe-t-il ? Expliquer.
La troisième ligne duplique l’index de la table.
Question 41. Atteindre l’URL http://i207mxx/script.php. Que se passe-t-il ? Expliquer.
L’utilisateur apache n’a pas le droit de se connecter à la base de données.
Question 42. Résoudre le problème en déclarant l’utilisateur apache dans la base de données (la création des utilisateurs dans la
base de données se fait à l’aide de l’utilitaire createuser). Que se passe-t-il alors ?
L’utilisateur apache n’a pas le droit de lire la table MyTable.
Question 43. Résoudre ce dernier problème sous psql avec la commande grant. Cela marche-t-il ?
[postgres@i207mxx pgsql]$ psql newdb
newbd=> grant select on MyTable to apache ;
newdb=> \q
[postgres@i207mxx pgsql]$
Oui ;-)
Hébergement de sites
Cette dernière partie montre comment une seule machine peut répondre à des requêtes apparament adressées à des machines
différentes. Notamment utilisé par les hébergeurs et fournisseurs d’accès, ce mécanisme est également utilisé à l’IFSIC (pour les
sites des associations d’étudiants par exemple).
Ajouter les directives suivantes à la fin du fichier /etc/httpd/conf/httpd.conf :
NameVirtualHost 148.60.5.(80+xx)
<VirtualHost i207mxx.ifsic.univ-rennes1.fr>
ServerName i207mxx.ifsic.univ-rennes1.fr
ServerAlias i207mxx
DocumentRoot /var/www/html
</VirtualHost>
<VirtualHost serv_ixx.ifsic.univ-rennes1.fr>
ServerName serv_ixx.ifsic.univ-rennes1.fr
ServerAlias serv_ixx
DocumentRoot /var/www/auberge/serv_ixx.ifsic.univ-rennes1.fr
</VirtualHost>
Créer le répertoire /var/www/auberge/serv_ixx.ifsic.univ-rennes1.fr.
Question 44. Atteindre l’URL http://serv_xx. Expliquer.
Apache offre un mécanisme qui lui permet de se faire passer pour plusieurs machines.
Question 45. Que faut-il faire pour que cela marche depuis n’importe quelle machine de l’internet ?
Il faut que la machine serv_ixx.ifsic.univ-rennes1.fr soit déclarée dans le DNS et ait pour numéro IP celui de
i207mxx.
Ce qui manque
Le but de ce TP n’est évidemment pas de former un administrateur HTTP ; il n’est que de donner une représentation pratique
aux concepts vu en cours.
Les manques principaux à ce vernis de webmaster sont :
• L’exécution de programmes sous HTTP, longtemps limitée aux programmes CGI, revêt maintenant de nombreuses formes
(Javascript, Python, ASP, ...).
• La navigation sous HTTP comporte de nombreux mécanismes de cache (applicatifs, locaux, distants).
• Enfin, le développement d’applications via HTTP doit répondre à des impératifs de sécurité que HTTP seul ne peut pas
remplir. HTTPS (HTTP + SSL) permet par exemple le cryptage des communications client/serveur.
Références
La distribution Linux RedHat :
Le protocole HTTP :
Le serveur HTTP Apache :
La programmation CGI :
Le wrapper cgiwrap :
La fonctionnalité SuExec d’Apache :
Le langage PHP :
Le gestionnaire de bases de données PostgreSQL :
Le cache Squid :
Le cryptage par SSL :
http://www.redhat.com
http://www.w3.org/Protocols/
http://www.apache.org
http://hoohoo.ncsa.uiuc.edu/cgi/overview.html
http://www.unixtools.org/cgiwrap/
http://www.apache.org/docs/suexec.html
http://www.php.net
http://www.postgresql.org
http://squid_cache.org
http://www.netscape.com/eng/ssl3/