Transcription du cours de skateinmars pour u-classroom.
Le Web est (de manière simple) un réseau composé de l'ensemble des sites Internet disponibles publiquement, reliés entre eux par des hyperliens. Un site Internet (ou site Web) est quand à lui un ensemble de pages Web, liées entre elles.
Un site web a une adresse, comme celle du site Ubuntu-fr : http://ubuntu-fr.org. La page Web principale de ce site propose des liens hypertextes vers d'autres pages et d'autres sites, par exemple : http://ubuntu-fr.org/telechargement.
Attention à ne pas faire d'amalgame entre Web et Internet. Le salon IRC sur lequel s'est déroulée cette séance utilise Internet, pas le Web.
Pour accéder à un site web, il vous faut utiliser un client Web, appelé communément Navigateur, par exemple : firefox, lynx, opera, konqueror, w3m…
C'est la qu'intervient le protocole HTTP. Voyez par exemple le site suivant http://test.skateinmars.net/. Visitez le avec votre navigateur et vous verrez une page toute simple qui s'affiche. Comment votre navigateur peut-il afficher cette page ? Il l'a en fait demandée au serveur qui s'occupe de ce site.
Faisons la même chose à la main. Ouvrez une console et saisissez (après avoir installé le paquet telnet si nécessaire) :
telnet test.skateinmars.net 80
Vous verrez s'afficher :
Trying 82.228.105.196... Connected to skateinmars.net.
Vous êtes donc connecté au serveur identifié par le nom skateinmars.net et l'adresse IP 82.228.105.196. Le serveur attend une action de votre part. Saisissez :
GET / HTTP/1.1 Host: test.skateinmars.net
Puis 2 fois <entrée> Vous voyez alors s'afficher du texte HTML. C'est la même page que le navigateur vous a affiché précédemment. La connexion est coupée après l'affichage du texte.
Ce texte que vous pouvez voir, c'est le même que vous avez vu dans votre navigateur tout à l'heure : c'est une page Web. Vérifiez dans votre navigateur en regardant la source de la page : bouton droit de la souris, "Code source de la page" sous Firefox.
Vous venez donc d'utiliser le protocole HTTP. HTTP est un protocole de communication. C'est à dire une spécification qui définit comment 2 machines doivent dialoguer entre elles. HTTP est le protocole choisi pour le Web. Il y a en d'autres pour d'autres usages, FTP par exemple. Vous pouvez d'ailleurs reconnaître le protocole dans l'adresse d'une page web : http:
HTTP veut dire Hypertext Transfer Procotol, soit « protocole de transfert hypertexte ». Hypertexte, en raison des liens hypertextes qui pointent vers les ressources accessibles par HTTP. On utilise donc HTTP à chaque fois que l'on visite une page Web.
HTTP est apparu dans les années 89/90, sur une proposition de Tim Berners-Lee, aujourd'hui président du W3C, l'organisme qui produit des recommandations qui servent de standards pour le Web (XML, HTML, CSS entre autres). Comme pour de nombreux protocoles, il en existe plusieurs versions. La première version est appelée HTTP/0.9, et la version 1.0 est devenue un standard IETF en mars 1996. Elle est definie dans la RFC 1945. La norme actuelle est HTTP/1.1 et elle est décrite dans les RFC 2616 et 2068.
Comme vous avez pu le remarquer lors de l'utilisation de telnet, HTTP utilise par défaut le port 80. Votre navigateur le sait et c'est pour cela que vous n'avez pas à taper http://www.google.fr:80/ (vous pouvez néanmoins essayer, ca marche).
Quand on utilise HTTP, il faut définir deux choses essentielles : la ressource sur laquelle on agit, représentée par l'url, "/bob" par exemple, puis la méthode à utiliser.
Il y a plusieurs méthodes disponibles, la plus utilisée étant GET. C'est celle que les navigateurs utilisent pas défaut quand vous cliquez sur un lien ou tapez l'adresse d'un site à consulter. Une autre méthode, très utilisée, et la méthode POST. Elle est souvent utilisée avec des formulaire, pour envoyer un message sur un forum par exemple. Ceux qui ont deja touché à PHP ou au développement web connaissent ces deux méthodes, il y en a d'autres mais elles sont beaucoup moins courantes : HEAD, PUT, DELETE, etc.
Reprenons telnet :
telnet test.skateinmars.net 80 GET /test/test.txt HTTP/1.0 Host: test.skateinmars.net Connection: close
Vous obtenez la ressource test/test.txt, qui est un simple fichier texte, après avoir utilisé la méthode GET. Vous avez également utilisé HTTP en version 1.0.
Recommencez maintenant ces étapes mais en terminant par :
Connection: keep-alive
Vous pouvez voir que telnet reste connecté au serveur et vous pouvez ainsi envoyer une autre requete.
Analysons un peu plus ce que l'on vient de faire :
Connection permet de spécifier si l'on veut rester connecté au serveur après avoir recu la ressource ou si l'on souhaite se déconnecter (on peut voir la différence avec keep-alive). Il y a bien d'autre options disponibles, chacune étant un "en-tête".Regardons maintenant les quelques lignes renvoyées par notre action :
Ici on peut voir le protocole utilisé, et le code de retour. Le code de retour est très important, il nous permet de savoir si la requête a reussi ou non. Ici le code est 200, soit OK. Le code 200, vous le recevez à peu prêt tout le temps, il signifie que la requête a réussi. Bien sur vous ne le voyez pas dans votre navigateur puisque celui-ci affiche la ressource reçue (ce qui vous interresse plus d'habitude que de savoir simplement si elle a été recue !). Si vous êtes curieux vous pouvez essayer un telnet sur une ressource non existante, et vous verrez le code 404 bien connu qui signifie que la ressource n'existe pas. Les codes d'erreur en 2XX sont des codes de réussite, en 3XX ce sont des redirections, en 4XX des erreurs de requête et en 5XX des erreurs du serveur. Une liste de tous les codes est bien sûr disponible dans la RFC.
C'est simplement le nom et les informations sur le serveur qui vous a répondu. Ici Apache version 2.2.3. On peut configurer son serveur pour cacher ces options et éviter les crackers qui recherchent une version précise d'apache vulnérable à certaines failles (notez qu'il vaut mieux corriger la faille dans ce cas ;).
C'est la date à laquelle la ressource a été modifiée pour la dernière fois.
Etag représente un identifiant du fichier. Ces deux options permettent au navigateur de les comparer avec les fichiers qu'il a dans son cache pour ne pas retélécharger inutilement un fichier qu'il a déjà demandé auparavant.
Content-Length définit la taille du contenu que le serveur vous envoie, et
C'est le type MIME du contenu (texte, image, etc.).
Notez qu'il est inutile de se servir de ETag et Last-Modified si l'on télécharge tout de même la ressource ; on peut donc utiliser HEAD au lieu de GET pour demander ce genre d'informations.
Apache a été concu en 1995 a partir d'une série de patchs sur le serveur NCSA HTTPd, un des premiers serveurs existants, d'ou son nom : "A patchy server" (qui ressemble a la prononciation d'Apache en anglais). C'est un logiciel libre, distribué sous la licence Apache, version 2.0. La version courante est la 2.2.6, et 1.3.39 pour la branche "legacy" 1.X qui est parfois préférée pour éviter de migrer d'une branche à l'autre. Nous allons utiliser la version 2.X, n'ayant pas de contraintes à ce niveau.
Ouvrez une console et installez apache avec la commande suivante :
sudo apt-get install apache2 apache2-mpm-prefork
Vous pouvez donc voir une fois cela terminé qu'apache a été démarré :
Vérifions son bon fonctionnement, en ouvrant votre navigateur et vous rendant sur http://localhost/. Vous verrez une page vous informant que le serveur marche correctement :)
le message suivant apparaît : It works!
Maintenant que le serveur est installé et fonctionne correctement, nous allons voir les bases à connaître de sa configuration.
Rendez-vous dans le répertoire /etc/apache2/, et regardez les fichiers le composant :
.conf conf.d envvars httpd.conf mods-available mods-enabled ports.conf sites-available sites-enabled
La plupart de ces fichiers sont plus ou moins spécifiques à debian/ubuntu et nous permettent de séparer la configuration en plusieurs parties.
httpd.conf est le fichier utilisé par apache1, il est conservé vide dans apache2 pour assurer la rétrocompatibilité. Il ne nous servira pas ;envvars est utilisé pour définir des variables d'environnement propres à apache ;ports.conf est plus interressant. Regardez son contenu :Listen 80
Cette option de configuration (appelée directive) demande à apache d'écouter sur le port 80. Si vous utilisez HTTPS vous aurez à y spécifier le port 443. Bien sûr on peut utiliser n'importe quel port mais restons dans les standards.
apache2.conf est le fichier principal de configuration ;conf.d est un répertoire qui contient plusieurs petits fichiers qui seront analysés par apache. Le seul fichier pour le moment est charset, qui spécifie l'encodage à utiliser par défaut ;mods-available contient la liste des modules d'apache installés ;mods-enabled celle des modules utilisés ;sites-available contient la liste des vhosts installés ;sites-enabled celle des vhosts utilisés.Ce fichier est par défaut allègrement commenté. Un commentaire commence par # (le texte qui suit est ignoré par apache). Voyons un peu les premières options :
ServerRoot "/etc/apache2" : définit le dossier de base qui contient la configuration d'apache. A ne pas toucher donc ;Timeout : nombre de secondes maximum au bout duquel une connection au serveur est interrompue ;KeepAlive : on a vu son utilité tout à l'heure, vous pouvez ici le désactiver. Il y a également d'autres options pour KeepAlive pour l'affiner ;User et Group déterminent l'utilisateur avec lequel seront exécutés les processus d'apache ;
Ce répertoire contient les différents vhosts que vous utiliserez. Les vhosts (Virtual Hosts) vous permettent de définir plusieurs sites différents sur une même machine, le plus souvent des sous-domaines (www.chose.fr, machin.chose.fr, etc.). Éditez le seul vhost existant pour le moment : default (en root).
NameVirtualHost définit les IPs à utiliser par apache, ici * signifie qu'on utilise n'importe quel IP pour acceder au serveur : 127.0.0.1 (ip locale), 192.168.x.x (ip du reseau local), ou une IP externe. Cette directive est en dehors du Vhost, on pourrait donc la déplacer dans apache2.conf. Dans tous les cas elle ne doit pas être reprise dans les autres vhosts si elle est déjà définie à *
Ensuite vient le vhost proprement dit : il est compris dans un bloc <VirtualHost>, un peu à la manière d'une balise XML. Ces blocs définissent la "portée" de la validité des directives qui y sont définies. Le * derrière VirtualHost définit ici également que le vhost est valable pour toutes les IPs sur lesquelles apache écoute.
La directive ServerAdmin vous permet de spécifier un email à utiliser en cas de problème, sur une page d'erreur 404 par exemple.
Il manque une directive importante que l'on va ajouter :
ServerName machin
Remplacez machin par le nom que vous souhaitez utiliser pour le vhost. Si vous possedez un compte dyndns ou d'un service du genre vous pouvez l'utiliser, sinon mettez ce qui vous passe par la tête, comme truc.com.
DocumentRoot définit le dossier dans lequel seront stockés les fichiers du site.
Les sous-blocs suivants définissent des options spécifiques au dossier du site. Options FollowSymLinks par exemple demande à apache de suivre les liens symboliques si necessaire.
AllowOverride permet de définir si l'on peut changer certaines options en utilisant des fichiers .htaccess dans le répertoire du site.
Indexes permet d'autoriser le listage de fichiers d'un répertoire qui ne contient pas d'index.
Alias permet de définir un répertoire précis pour certaines requêtes. Ici /doc correspondra au dossier /usr/share/doc/, mais selon la directive Allow, seul les IPs locales y ont accès.
Enregistrons les changements et fermons le fichier.
Il faut maintenant que le vhost soit actif. Pour activer un vhost il faut créer un lien symbolique du fichier vhost vers le dossier sites-enabled/, mais une commande est là pour nous aider dans cette tâche.
(Tout d'abord faites un sudo rm sites-enabled/000-default, c'est une configuration d'origine d'apache plus génante qu'autre chose.)
Utilisez donc
sudo a2ensite nomduvhost
Notez que a2dissite va logiquement réaliser le contraire. Cette méthode du lien symbolique permet de réaliser rapidement des changements dans la configuration d'apache.
Comme vous l'indique le résultat de la commande, vous devez recharger la configuration d'apache avec un
sudo /etc/init.d/apache2 reload
Vous devrez recharger apache à chaque changement de configuration. Notez aussi l'option force-reload du script. Après cela votre vhost est actif. Reste encore une modif à faire : ouvrez le fichier /etc/hosts, et entrez une nouvelle ligne :
127.0.0.1 nomduvhost
Avec nomduvhost le ServerName que vous avez choisi. Cela permettra à votre système de faire la correspondance entre le nom de l'host et votre machine locale.
Testez maintenant votre vhost ! Ouvrez votre navigateur (ou telnet) et entrez votre ServerName dans la barre d'adresse. Ca devrait marcher :)
Notez que sous debian/ubuntu 2 les pages a utiliser comme index sous spéficiées dans le module dir (mods-available/dir.conf).
On a donc maintenant un apache fonctionnel, mais on va terminer avec un petit bonus et installer mod_php pour rapidement aborder les modules. Les modules sont des extensions d'apache qui ajoutent des fonctionnalités diverses, du support d'un langage aux réécritures d'urls. On va ainsi installer mod_php5 qui ajoutera comme son nom l'indique le support de php5 directement dans apache. Installez le paquet libapache2-mod-php5, attendez le redemarrage d'apache, et voila !
On va vérifier que cela marche. Regardez le dossier mods-enabled, vous pourrez y voir les fichiers php5.conf et php5.load. Là aussi, il s'agit de liens symboliques vers mods-available comme pour les vhosts, et vous devinerez l'utilité des commandes a2enmod et a2dismod.
Créez ensuite le fichier /var/www/test.php, et écrivez-y le contenu suivant :
<?php phpinfo(); ?>
Ouvrez ensuite cette page dans votre navigateur (http://servername/test.php), vous y verrez la page interprétée (la fonction phpinfo affiche une page html d'informations sur votre installation de php).