Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

[Apache] "La connexion a échoué" sur localhost

Jarodd

Bonjour,

J'essaye de mettre en place un serveur web (j'utilise Ubuntu 18.04).

J'ai installé apache et php :

$ php -v
PHP 7.2.15-0ubuntu0.18.04.1 (cli) (built: Feb  8 2019 14:54:22) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.2.15-0ubuntu0.18.04.1, Copyright (c) 1999-2018, by Zend Technologies

$ apache2 -v
Server version: Apache/2.4.29 (Ubuntu)
Server built:   2018-10-10T18:59:25

J'ai créé mon vhost :

$ vi /etc/apache2/sites-available/tests.dev.conf

<VirtualHost *:80>

        ServerName tests.dev
        DocumentRoot /var/www/tests

        ErrorLog ${APACHE_LOG_DIR}/tests.dev.error.log
        CustomLog ${APACHE_LOG_DIR}/tests.dev.access.log combined

</VirtualHost>

Le répertoire /var/www/tests existe bien, je suis son propriétaire, et j'ai les permissions :

$ ls -al /var/www/tests/
total 88
drwxr-xr-x 22 jarodd jarodd 4096 juil. 26  2018 .
drwxr-xr-x 12 jarodd jarodd 4096 mars  20 21:15 ..

J'ai mis à jour /etc/hosts :

127.0.0.1 tests.dev

J'ai redémarré apache :

jarodd@ubuntu:~$ sudo systemctl restart apache2
jarodd@ubuntu:~$

(pas d'erreur)

Mais lorsque je me rends sur l'adresse tests.dev, j'ai l'erreur :
"La connexion a échoué" (Firefox)
"Ce site est inaccessible" (Chromium)

Je pense que c'est bien un problème de config, car si je me rends sur une adresse qui n'existe pas en local, j'ai l'erreur :
"Hum, nous ne parvenons pas à trouver ce site."
(ce qui est logique)
J'atteins bien ma config, mais je ne sais pas à quel moment ça foire.

Un ping sur tests.dev ne renvoie pas d'erreur :

$ ping tests.dev
PING tests.dev (127.0.0.1) 56(84) bytes of data.
64 bytes from ip6-localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.045 ms
64 bytes from ip6-localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.066 ms
64 bytes from ip6-localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.066 ms
64 bytes from ip6-localhost (127.0.0.1): icmp_seq=4 ttl=64 time=0.076 ms

Donc je suppose que le hosts est atteint, mais que cela coince en arrivant sur la config apache. Simple supposition...

Bref, j'ai l'impression d'avoir tout fait comme il faut, mais cela ne fonctionne pas.
Votre aide est la bienvenue, merci d'avance.

Edit 21/03 : résolu, il ne faut pas utiliser le tld .dev, mais mettre à la place .localhost

Iamawalrus

Salut, si tu te connectes sur ton navigateur à ton IP locale, ça dit quoi ?

Est-ce que t'as activé ton site ?

sudo a2ensite tests.dev

sudo /etc/init.d/apache2 force-reload

Par ailleurs après avoir vérifié ce point, que donne le statut d'Apache ? Est-ce que tu trouves des erreurs dans les logs ?

sudo systemctl status apache2

bruno

Bonjour,

Il ne faut pas utiliser .dev comme TLD pour un usage strictement local, il est réservé et délégué. Voir cette discussion entre autres.

Je t'invite à remplacer partout dans ta configuration test.dev par test.localhost

Jarodd

Salut,

Si je me connecte à 127.0.0.1, j'arrive bien sur la page " Apache2 Ubuntu Default Page " (qui est dans /var/www/html).

Les sites sont bien activés :

$ sudo a2ensite tests.dev
Site tests.dev already enabled

$ ll /etc/apache2/sites-enabled/
total 8
drwxr-xr-x 2 root root 4096 mars  21 07:04 ./
drwxr-xr-x 8 root root 4096 mars  20 20:34 ../
lrwxrwxrwx 1 root root   35 mars  21 07:04 000-default.conf -> ../sites-available/000-default.conf
lrwxrwxrwx 1 root root   33 mars  20 20:53 tests.dev.conf -> ../sites-available/tests.dev.conf

Apache est bien lancé et ne retourne pas d'erreur (les voyants sont au vert).

$ sudo systemctl status apache2
● apache2.service - The Apache HTTP Server
   Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: 
  Drop-In: /lib/systemd/system/apache2.service.d
           └─apache2-systemd.conf
   Active: active (running) since Thu 2019-03-21 06:55:46 CET; 6min ago
  Process: 2175 ExecStart=/usr/sbin/apachectl start (code=exited, status=0/SUCCE
 Main PID: 2213 (apache2)
    Tasks: 9 (limit: 4444)
   CGroup: /system.slice/apache2.service
           ├─2213 /usr/sbin/apache2 -k start
           ├─2217 /usr/sbin/apache2 -k start
           ├─2218 /usr/sbin/apache2 -k start
           ├─2219 /usr/sbin/apache2 -k start
           ├─2220 /usr/sbin/apache2 -k start
           ├─2221 /usr/sbin/apache2 -k start
           ├─3834 /usr/sbin/apache2 -k start
           ├─3835 /usr/sbin/apache2 -k start
           └─3836 /usr/sbin/apache2 -k start

mars 21 06:55:46 ubuntu systemd[1]: Starting The Apache HTTP Server...
mars 21 06:55:46 ubuntu apachectl[2175]: AH00558: apache2: Could not reliably d
mars 21 06:55:46 ubuntu systemd[1]: Started The Apache HTTP Server.

Jarodd

Salut Bruno,

Merci pour l'info. J'utilise .dev depuis des années pour mes sites en local, j'ignorais que ce tld était réservé. Je modifie me config et vous tiens au courant 🙂

Jarodd

Avec tests.localhost, ça fonctionne, merci pour le coup de main ! 🙂

Edit : ceci dit, je ne comprends pas pourquoi le ping m'a répondu sur tests.dev ?

Iamawalrus

Jarodd a écritAvec tests.localhost, ça fonctionne, merci pour le coup de main ! 🙂

Edit : ceci dit, je ne comprends pas pourquoi le ping m'a répondu sur tests.dev ?

Je pense aussi qu'il pourrait y avoir un problème au niveau d'Apache. Mais je ne vois pas de lien entre Apache et la résolution de nom à part à modifier le fichier hosts, ce qui semble avoir été fait.

Sinon, si t'as le temps, tu peux tester avec l'extension .lan pour voir si ça fonctionne ?

Pour ce qui est des extensions comme .dev, je suis d'accord qu'i faille suivre les RFC mais je ne vois pas pourquoi ça créerait des erreurs dans le réseau local. Donc en tant que test, ça devrait fonctionner.

bruno

La commande ping utilise la configuration du système pour résoudre les noms en se basant sur /etc/nsswitch.conf. Par défaut, c'est donc le fichier le fichier /ertc/hosts qui est interrogé en premier.
Le navigateur web lui cherche d'abord à utiliser les résolveurs DNS, c'est pourquoi il ne faut surtout pas utiliser des TLD enregistrés et délégués pour un pseudo-domaine qui ne doit être résolu que localement.
Pour info ces TLD peuvent être utilisés sans risque jusqu'à nouvel ordre (le .lan. est à éviter) :

home.arpa.
invalid.
localhost.
test.

Jarodd

Sinon, si t'as le temps, tu peux tester avec l'extension .lan pour voir si ça fonctionne ?

Je viens de tester, ça fonctionne bien aussi.
Mais pas avec .local

bruno

Normal. Le TLD .local est réservé pour mDNS.

Iamawalrus

bruno a écritLe navigateur web lui cherche d'abord à utiliser les résolveurs DNS, c'est pourquoi il ne faut surtout pas utiliser des TLD enregistrés et délégués pour un pseudo-domaine qui ne doit être résolu que localement.

Je croyais au contraire que ça passait par le fichier hosts en premier. Aurais-tu des sources à propos de cette affirmation (juste par curiosité) ?

Pour info ces TLD peuvent être utilisés sans risque jusqu'à nouvel ordre (le .lan. est à éviter) :

home.arpa.
invalid.
localhost.
test.

Merci pour cette liste. Et par ailleurs quel est le problème avec .lan ?

Jarodd a écritJe viens de tester, ça fonctionne bien aussi.

Merci. On pourrait estimer que problème venait bien de .dev alors.

bruno

Edhelharn a écrit
bruno a écritLe navigateur web lui cherche d'abord à utiliser les résolveurs DNS, c'est pourquoi il ne faut surtout pas utiliser des TLD enregistrés et délégués pour un pseudo-domaine qui ne doit être résolu que localement.
Je croyais au contraire que ça passait par le fichier hosts en premier. Aurais-tu des sources à propos de cette affirmation (juste par curiosité) ?

J'ai simplifié, le problème est sans doute un peu plus complexe. Je ne trouve pas de documentation technique là-dessus et j'ai un peu la flemme de chercher 😉
Quoiqu'il en soit l’expérience montre que dès lors qu'un TLD réservé et délégué à un bureau d'enregistrement par l'IANA est utilisé le navigateur ignore le fichier hosts et se sert des résolveurs configurés sur la machine hôte. De toute façon, cela va à l'encontre d'un principe de base du DNS qui est l'unicité des noms de domaine. On ne peut pas utiliser ce type de TLD sans l'avoir réservé auprès du bureau d'enregistrement auquel il a été délégué, même localement.

Le TLD .lan. n'est pas dans la liste des domaines à usage particulier de l'IANA (déjà citée). Le risque est donc grand qu'il soit dans le futur réservé et délégué et qu'il ne fonctionne donc plus localement.

Je redonne le lien vers https://www.bortzmeyer.org/8244.html qui décrit en détail cette problématique un peu complexe.

Iamawalrus

bruno a écritLe TLD .lan. n'est pas dans la liste des domaines à usage particulier de l'IANA (déjà citée). Le risque est donc grand qu'il soit dans le futur réservé et délégué et qu'il ne fonctionne donc plus localement.

Si on en croit cette RFC ils sont au courant que c'est un nom de domaine très utilisé en local.

À priori (si j'ai bien compris.. ça c'est une autre histoire) l'IANA "traîne des pieds" pour la réserver.

Finalement plus on l'utilisera (et en plus, mal :lol:) plus on aura de chance de se la voir réserver. 😛

bruno

Edhelharn a écritFinalement plus on l'utilisera (et en plus, mal :lol:) plus on aura de chance de se la voir réserver. 😛

Dis cela à ceux qui ont utilisé corp. pour le réseau local pendant des années :lol: (et c'est la même chose pour le dev.)

Iamawalrus

Haha j'avais pas vu. 🙂

Bon d'un autre côté c'est pas un drame. Si les administrateurs se servent des noms de domaines comme ça, c'est pour faire des tests en local, et à leurs risques et périls. Ils sont sensés connaître les RFC par ailleurs.

Foutre un intranet en .corp par exemple en production, c'est n'importe quoi.