Questions souvent posée sur le TP cloud

Après avoir fait un partage entre le repertoire de la VM /docker/nginx/config et celui du docker /etc/nginx le docker ne démarre plus et la commande

docker logs nginx

donne l'erreur

2016/10/29 16:44:16 [emerg] 1#1: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory)
nginx: [emerg] open() "/etc/nginx/nginx.conf" failed (2: No such file or directory)

Cela signifie que nginx ne démarre pas car il n'arrive pas à lire sont fichier de configuration principal /etc/nginx/nginx.conf. Puisqu'il y a un partage, ce fichier devrait être pour la VM /docker/nginx/config/nginx.conf. Afficher donc ce répertoire :

ls -l /docker/nginx/config/

En général, cette erreur est le signe que le fichier n'existe pas :

1. Soit vous avez oublié de copier le répertoire (vous avez oublié la question Copiez le répertoire /etc/nginx du docker test dans le répertoire /docker/nginx/config de la VM (commande docker cp …))
2. Soit vous avez commis commis une légère erreur en copiant le répertoire dans un sous répertoire de /docker/nginx/config/. Assez souvent on trouve /docker/nginx/config/nginx/nginx.conf.

La solution est de déplacer les fichier de configuration dont a besoin nginx au bon endroit. Le répertoire doit contenir :

ubuntu@testfabien:~$ ls -l /docker/nginx/config/
total 36
drwxr-xr-x 2 root root 4096 Oct 20 22:19 conf.d
-rw-r--r-- 1 root root 1007 Oct 18 15:03 fastcgi_params
-rw-r--r-- 1 root root 2837 Oct 18 15:03 koi-utf
-rw-r--r-- 1 root root 2223 Oct 18 15:03 koi-win
-rw-r--r-- 1 root root 3957 Oct 18 15:03 mime.types
lrwxrwxrwx 1 root root   22 Oct 18 16:56 modules -> /usr/lib/nginx/modules
-rw-r--r-- 1 root root  643 Oct 18 16:55 nginx.conf
-rw-r--r-- 1 root root  636 Oct 18 15:03 scgi_params
-rw-r--r-- 1 root root  664 Oct 18 15:03 uwsgi_params
-rw-r--r-- 1 root root 3610 Oct 18 15:03 win-utf

Dans la dernière partie, tout a l'air bien mais le serveur web apache vous répond :

'403 forbidden you don't have permission to access /tiny-master/ on this server'.

Cette erreur signifie qu'il y a un problème de droit. Soit la configuration apache est faite pour interdire la lecture de ce répertoire à ce client, soit le système refuse que le serveur apache lise ce répertoire.

La première solution a peu de chance d'être vraie car vous n'avez rien changé à la configuration d'apache qui permettait bien de lire des fichiers dans les questions précédentes. Donc on regarde la seconde raison.

Le serveur apache est exécuté dans un docker sous le nom www-data avec le numéro d'utilisateur 33 (voir dans le fichier /etc/passwd et la commande ps aux qui affiche tous les processus qui s'exécutent, c'est toujours le cas pour des distributions debian ou ubuntu). La question est donc Est-ce que cet utilisateur à le droit de lire ce répertoire.

Si je regarde le répertoire :

root@machine-tp2:/docker/apache/html# ls -l /docker/apache/html/
total 8
-rw-r--r-- 1 root root   56 Oct 26 15:44 test.php
drwx------ 5 root user 4096 Oct 28 15:16 tiny-master

Il y a 3 groupes de droits, ceux de l'utilisateur propriétaire du répertoire (ici root), ceux du groupe propriétaire du répertoire (ici user), ceux des autres. Les droits sont les groupe de lettre rwx ou - au début de la ligne. Ici les droit sont :

• pour root rwx;
• pour le groupe user - - - (c'est à dire rien);
• pour les autres - - -.

Le répertoire n'est accessible qu'à root et pas aux autres donc www-data ne peux y allez, c'est la cause de l'erreur.

Pour qu'apache accède à un répertoire il lui faut le droit x (r permet de lister les fichiers ce qui n'est pas nécessaire vu que les scripts php connaissent tous les noms de fichiers utilisés, w permettrait d'ajouter un fichier par exemple pour faire une zone de dépôt).

La commande

root@machine-tp2:/docker/apache/html# chmod a+x /docker/apache/html/tiny-master/

ajoute bien le droit d'accès, mais si on teste ce n'est pas suffisant car les sous répertoires ne sont pas non plus accessibles.

root@machine-tp2:/docker/apache/html# ls -l /docker/apache/html/tiny-master/
total 32
drwx------ 8 root root 4096 Oct 28 15:16 application
-rw-r--r-- 1 root root  545 Oct 28 15:16 composer.json
-rw-r--r-- 1 root root 1347 Oct 28 15:16 index.php
drwx------ 2 root root 4096 Oct 28 15:16 _installation
drwx------ 5 root root 4096 Oct 28 15:16 public
-rw-r--r-- 1 root root 9900 Oct 28 15:16 README.md

Une façon de résoudre est de mettre le droit x sur tous les répertoires et les sous-répertoires mais cela est fastidieux. Le plus simple ici est de changer le propriétaire de tout ces fichiers. Si le propriétaire est www-data, les droits seront bon :

root@machine-tp2:/docker/apache/html# chown -R www-data /docker/apache/html/tiny-master/
root@machine-tp2:/docker/apache/html# ls -l /docker/apache/html/tiny-master/
total 32
drwx------ 8 www-data root 4096 Oct 28 15:16 application
-rw-r--r-- 1 www-data root  545 Oct 28 15:16 composer.json
-rw-r--r-- 1 www-data root 1347 Oct 28 15:16 index.php
drwx------ 2 www-data root 4096 Oct 28 15:16 _installation
drwx------ 5 www-data root 4096 Oct 28 15:16 public
-rw-r--r-- 1 www-data root 9900 Oct 28 15:16 README.md

Attention, apache obtient alors le droit de modifier ces fichiers. Dans un site en production, c'est rarement une bonne idée car si le site php à un trou de sécurité, il devient possible de modifier ces fichiers. Cela permet d'ajoutr par exemple du code malveillant. Mais dans le cas d'un exercice de TP, c'est ce qu'il y a de plus simple.

Il est très courant qu'une application dans un docker ou derrière un proxy inverse gère mal les liens vers des parties d'elle même. En effet, beaucoup de ces sites utilisent une variable pour créer l'url vers eux-même. Cette variable est soit écrite dans la configuration soit crée à partir de la requête qui amène à ce site. Un docker sur un réseau interne et derrière un proxy qui le contacte avec une adresse qui n'est pas l'adresse officielle peut avoir des problèmes à reconstituer cette url. Dans le cas du serveur tiny, cette variable est crée dans le fichier config.php par :

define('URL_PROTOCOL', 'http://');
define('URL_DOMAIN', $_SERVER['HTTP_HOST']);
define('URL_SUB_FOLDER', 'tiny-master');
define('URL_INDEX_FILE', 'index.php' . '/');

Il faut que cette dernière soit celle que vous utilisez pour arriver à la page d'accueil. Le protocole doit être bon (http ou https selon le chiffrement). L'adresse du serveur aussi, c'est celle de la VM et pas celle du docker. La variable utilisée : $_SERVER['HTTP_HOST'] est celle interne du docker sauf si vous avez configuré nginx pour qu'il la modifie. Utilisez les options proxy_set_header expliquées ici.

Le sous répertoire dépend de votre installation et de la présence ou non du / à la fin de la configuration proxy_pass dans nginx. En effet, avec

location /truc {
    proxy_pass   http://apache1/;
}                         

nginx contacte l'adresse http://apache1/ si vous lui demandez http://son_adrsse/truc et avec

location /truc {
    proxy_pass   http://apache1;
}                         

nginx contacte l'adresse http://apache1/truc si vous lui demandez http://son_adrsse/truc.

C'est souvent du à une erreur php qui ne s'affiche pas. En effet, par défaut, les sites ne doivent pas afficher ce type d'erreurs pour éviter d'aider les pirates. Ce qui signifie qu'une erreur dans le script php peut donner une erreur pour l’interpréteur php qui est silencieuse (elle s'affiche dans des logs à l'intérieur du docker mais n'apparait nul part dans la VM hôte ni sur la page web). Lorsqu'on fait une installation ou qu'on cherche un problème, il est utile de changer ce comportement.

Vous pouvoir soit activer les erreur php dans le dockrfile, soit modifier le comportement d'un docker existant. Pour le 2eme cas :

• affichez le contenu du fichier de configuration php dans le docker apache1 (attention de ne pas mettrre -it mais -t). La localisation du fichier php.ini correspond à une ubuntu xenial, elle est susceptible de changer.

docker exec -t apache1 cat /etc/php/7.O/apache2/php.ini | less

si vous rechercher vous trouverez la ligne display_errors = Off

• modifiez la valeur

docker exec -t apache1 sed -ie 's/display_errors = Off/display_errors = On/' /etc/php/7.0/apache2/php.ini

• vérifiez et relancer le docker

docker exec -t apache1 cat /etc/php/7.0/apache2/php.ini | less
docker restart apache1

Vous pouvez retourner sur le site et voir les erreurs php.

Si vous souhaitez modifier le comportement directement dans le dockerfile, il suffit de rajouter la ligne :

RUN sed -ie 's/display_errors = Off/display_errors = On/' /etc/php/7.0/apache2/php.ini

Mais attention, vos docker ne seront alors pas utilisable en production.