Serveur Web

Dans ce nouveau chapitre, je vais installer et configurer un serveur web qui me permettra de tester mes différents sites en local uniquement. Ces sites, dits « de développement » ne devront pas être accessibles depuis Internet.

Après avoir hésité à utiliser Lighttpd, j'ai finalement opté pour Apache car lorsque viendra le temps de mettre certains sites en ligne, il y a de fortes chances pour que l'hébergeur l'utilise. Histoire donc de coller au plus près de la réalité.

Mes sites étant statiques, je n'ai pas besoin de PHP ni de SQL.

Les noms de domaine de mes sites en production (c'est-à-dire accessibles en ligne) sont « hypertuxte.net » (en projet au moment de la rédaction de ces lignes) et un commerce en ligne (présentement fonctionnel); soyons original, appelons le « commerce.biz ».

Afin de tester mes sites en local, je vais leur assigner un nom de domaine un peu différent, du style www.test-hypertuxte.net.

Toutes les opérations décrites ci-dessous s'effectuent via SSH, donc en mode console toto@projetx:~$ depuis le C50-A.

Certains liens sources de ce document pointent vers des pages qui décrivent des syntaxes de configuration pour les versions antérieures à Apache 2.4. Ces pages comportent cependant des renseignements utiles pour comprendre la signification de certaines choses.

Installation de Apache2

Profitons-en pour mettre Debian à jour : sudo apt-get update && sudo apt-get dist-upgrade

Puis on installe le serveur Apache : sudo apt-get install apache2

La première chose à faire est de s'assurer que le serveur web fonctionne bien. Lorsqu'on installe Apache sur une machine en mode graphique, il suffit d'entrer localhost dans la barre d'adresse d'un navigateur situé sur la même machine et on doit obtenir la page par défaut :

Page index du serveur Apache

Je vais donc profiter du fait que je travaille depuis le C50-A et utiliser Firefox. Pour cela, il faut écrire une nouvelle règle du pare-feu (pour rappel, seul à été autorisé jusqu'ici le trafic entrant du C50-A sur le port 22, hors Apache fonctionne sur le port 80).

sudo ufw allow from 192.168.1.0/24 to any port 80 proto tcp

Ici, j'ai autorisé les requêtes de toutes les machines du réseau local sur le port 80 du T500, uniquement pour le protocole TCP. Pourquoi tout le réseau local et non pas uniquement le C50-A ? Parce que cela permettra à toute la maisonnée de pouvoir afficher mes sites en développement.

Dans la barre d'adresse de Firefox j'entre http://192.168.1.30 et j'obtiens bien la fameuse page Apache It works!.

Les propriétaires et permissions

Les sites web sont déposés dans le répertoire /var/www/html.

Le problème est que le répertoire html appartient à root. Tel quel, on pourra ajouter ou supprimer des dossiers et fichiers qu'en étant « root » ce qui n'est pas franchement pratique. Il faut donc changer le propriétaire de ce répertoire.

sudo chown -R toto:www-data /var/www/html/

Le dossier html est maintenant propriété de l'utilisateur toto et du groupe www-data, ce dernier étant le serveur Apache.

L'option -R (pour « récursif ») de la commande chown (change owner) indique que le contenu du dossier va hériter des mêmes droits.

On va maintenant vérifier les permissions sur le répertoire html.

ls -l /var/www/ donne pour résultat drwxr-xr-x 2 toto www-data 4096 sep 2 15:59 html

Hormis le fait que le répertoire html a été créé un 2 septembre, une minute avant l'heure des tartines au Nutella, que nous apprend cette réponse ?

  1. L'utilisateur toto peut lire, écrire et exécuter dans le répertoire html (rwx).
  2. Le groupe www-data peut lire et exécuter mais pas écrire (r-x).
  3. Les autres, soit le reste du monde, peuvent lire et exécuter mais pas écrire (r-x).

Soit une permission de 755 en système octal. Je vais changer pour 750 car il me semble que le reste du monde n'a nullement besoin de permissions.

chmod 750 /var/www/html

Enfin, on peut supprimer le fichier index par défaut (la page « It works! »).

cd /var/www/html pour se positionner dans le répertoire html puis rm index.html.

Mise en place des sites

En étant placé dans le répertoire html, je crée un dossier pour chaque site : mkdir test-commerce test-hypertuxte.

Techniquement, ces dossiers n'ont pas besoin d'avoir le même nom que les noms de domaine des sites.

Afin de pouvoir tester les configurations qui vont suivre, je crée un fichier index.html dans chacun de ces dossiers. Par exemple dans le dossier test-hypertuxte : touch index.html puis sudo nano index.html pour éditer une phrase du style « Hypertuxte fonctionne ! ».

Depuis le C50-A, dans la barre d'adresse de Firefox, http://192.168.1.30/test-hypertuxte/index.html me sert bien la page « Hypertuxte fonctionne ! ». J'effectue la même opération en remplaçant dans l'URL test-hypertuxte par test-commerce, ce qui donne un résultat similaire : « Commerce fonctionne ! ».

Rendons maintenant l'accès aux sites plus facile que par les longues URI un peu barbares en éditant le fichier par défaut de configuration des hôtes qui se trouve à /etc/apache2/sites-available/000-default.conf.

Pour être prises en compte, toutes les modifications du fichier 000-defautl.conf necessitent le redémarrage du serveur.

sudo nano /etc/apache2/sites-available/000-default.conf

Dans ce fichier, la configuration de chaque site est située entre les balises VirtualHost.

Le fichier original 000-default.conf contient une seule section VirtualHost et beaucoup de commentaires (lignes débutants par #).

Ici je vais écrire la configuration de chaque site dans le même fichier, même s'il serait préférable de les séparer en créant un fichier .conf pour chacun des hôtes (voir les questions existentielles à la fin de cette page).

<VirtualHost *:80>
	ServerName www.test-hypertuxte.net
		ServerAlias test-hypertuxte.net
		ServerAdmin webmaster@localhost
		DocumentRoot /var/www/html/test-hypertuxte

		ErrorLog ${APACHE_LOG_DIR}/error.log

</VirtualHost>

<VirtualHost *:80>
	ServerName www.test-commerce.biz
		DocumentRoot "/var/www/html/test-commerce"
</VirtualHost>
ServerName est le nom de domaine complet du site (ou FQDN).
ServerAlias est la ou les autres adresses à partir desquelles le site pourra être accessible.
DocumentRoot indique le chemin vers le répertoire du site sur le serveur.

On recharge Apache pour que cette configuration soit prise en compte : sudo service apache2 reload

Afficher les sites web

Finalement, afin que les sites soient accessibles depuis tout le réseau local grâce à leurs URL, il faut éditer le fichier hosts de chaque ordinateur.

sudo nano /etc/hosts et écrire :

	192.168.1.30 www.test-hypertuxte.net
	192.168.1.30 test-hypertuxte.net
	192.168.1.30 www.test-commerce.biz

Voilà ! Le site test-hypertuxte est accessible avec ou sans les www et le site test-commerce ne sera affiché qu'avec les www.

Sécuriser les sites

On va limiter l'accès des sites aux machines du réseau local, donc retour dans le fichier de configuration des hôtes :

sudo nano /etc/apache2/sites-available/000-default.conf

Dans chaque section VirtualHost (et donc pour chaque site), il faut ajouter une section Directory juste en dessous de la ligne DocumentRoot; par exemple pour le site « hypertuxte » :

<Directory /var/www/html/test-hypertuxte>
	Options Indexes FollowSymLinks MultiViews
	AllowOverride None
 <RequireAny>
 Require ip 192.168.1.3
 Require ip 192.168.1.5
 </RequireAny>
</Directory>

Directory /var/... indique le chemin vers le répertoire du site concerné par les paramètres qui suivent.

Même si elles ne sont peut-être pas vraiment utiles dans le contexte de mon projet, j'ai laissé ici les lignes Options et AllowOverride à titre indicatif. La première définie les options que l'on peut donner au dossier, la deuxième autorise ou non un fichier .htaccess a outrepasser la configuration.

La balise RequireAny indique les IP des ordinateurs qui seront seuls autorisés à consulter le site. Ici un ordinateur de test sur la première ligne et mon C50-A sur la deuxième ligne. Évidemment, on pourrait autoriser le réseau local en entier ou même une adresse IP extérieure.

Configuration finale

Voici la configuration finale de mes hôtes virtuels, avec quelques précisions ajoutées à la suite de l'image.

Fichier de configuration Apache VirtualHost

Qu'il est bon de savoir

Une petite erreur dans le fichier de configuration des hôtes peut empêcher Apache de redémarrer. Cela m'est arrivé quand j'ai essayé de paramétrer l'option d'origine -Indexes (signe moins (-) devant), pensant que cela la désactive. Le redémarrage de Apache renvoyait alors :

Job for apache2.service failed. See 'systemctl status apache2.service' and 'journalctl -xn' for details.

sudo apache2ctl configtest est LA commande magique qui peut montrer où les erreurs de syntaxe sont situées sans le fichier de configuration. Si le test réussi, le message suivant va s'afficher Syntax OK (ne pas tenir compte de l'éventuel message au dessus Could not reliably determine the server's fully qualified domain name).

Dans le cas de l'erreur citée plus haut, configtest donnait le message :

AH00526: Syntax error on line 7 of /etc/apache2/sites-enabled/000-default.conf: 
Either all Options must start with + or -, or no Option may

Les fichiers journaux (log)

Le journal error.log enregistre toutes les erreurs survenus sur le serveur.

Le journal access.log enregistre les requêtes au serveur. Dans le fichier de configuration, l'option common enregistre certaines données de base alors que combined enregistre deux données supplémentaires : le site de provenance et l'agent utilisateur.

Les fichiers « log » se trouvent par défaut dans /var/log/apache2 mais on peut choisir de les placer ailleurs. ATTENTION ! Les dossiers qui contiennent les journaux ainsi que les journaux eux-mêmes doivent être accédés par root et aucun autre utilisateur.

L'utilisateur toto ne peut d'ailleurs pas ouvrir le répertoire apache2 : -bash: cd: apache2: Permission non accordée.

État du serveur

sudo service apache2 restart va redémarrer le serveur. Sur un site en développement c'est probablement une bonne option. Sur un site en ligne, cette commande va « éjecter » les internautes du site. Dans ce cas, préférer la commande sudo service apache2 reload qui va recharger la configuration sans pour autant redémarrer le serveur au complet.

sudo service apache2 status ou systemctl status apache2 indiquent si Apache est en service en affichant l'un de ces messages :

Le serveur est simplement arrêté

	● apache2.service - LSB: Apache2 web server
	   Loaded: loaded (/etc/init.d/apache2)
	   Active: inactive (dead)

Le serveur n'a pas pu démarrer

	 apache2.service - LSB: Apache2 web server
	   Loaded: loaded (/etc/init.d/apache2)
	   Active: failed (Result: exit-code) since dim 2016-09-04 15:19:20 EDT; 6min ago
	  Process: 553 ExecStart=/etc/init.d/apache2 start (code=exited, status=1/FAILURE)

Le serveur est en fonction

	 apache2.service - LSB: Apache2 web server
	   Loaded: loaded (/etc/init.d/apache2)
	   Active: active (running) since dim 2016-09-04 15:28:40 EDT; 28s ago

Démarrer Apache à la demande

Grâce au daemon httpd, le serveur est opérationnel au démarrage de l'ordinateur; sans que l'utilisateur toto ait besoin d'ouvrir une cession.

L'idée est de désactiver ce comportement par défaut afin de mettre Apache en service uniquement lorsque cela est necessaire. Il est en effet inutile d'avoir un serveur qui fonctionne en permanence en tache de fond si on a besoin de ses services que sporadiquement.

sudo systemctl disable apache2 désactive en permanence le lancement du serveur au démarrage.

Ensuite, lorsque j'ai besoin de lancer le serveur : sudo systemctl start apache2.

On peut réactiver le lancement automatique : sudo systemctl enable apache2. Cette commande systemctl est évidemment valable pour n'importe quel autre service daemon qui se lance au démarrage d'un système.

Questions existentielles

À résoudre ultérieurement (car considéré comme non-urgent dans le contexte du projet).

Peut-être ici une mise en place plus propre. Même si une question demeure : pourquoi laisser root propriétaire du dossier www et créer une arborescence aussi longue (.../www/site.com/public_html) ?


Installation de OpenSSHMise en place du FTP