Comment en finir avec l’édition du fichier hosts ?

Aujourd’hui, la plupart des développeurs web sont familiarisés avec le fonctionnement du fichier hosts pour rediriger le trafic d’un domaine vers une IP, par exemple 127.0.0.1.
Le problème avec cette approche est que tout ajout ou modification de projet nécessite d’intervenir sur le fichier. En plus il ne peut pas être modifié par un utilisateur lambda, seulement un administrateur.

Heureusement, il existe d’autres méthodes pour simplifier ces modifications. Il est possible de passer par un serveur DNS local et de lui faire gérer tout le routage des domaines. Pour cela, Dnsmasq est tout indiqué, il est simple à installer et à configurer.

Dans cet article, je présente le processus d’installation et de configuration sur un mac.

Installation

Il existe différentes méthodes d’installation (compilation, téléchargement de binaires…). J’utilise, sur ma machine, le gestionnaire de dépendance Homebrew. Si vous ne connaissez pas Homebrew, je vous invite à découvrir les différentes méthodes d’installation sur wiki Gihub.

Une simple commande permet d’installer dnsmasq :

#Mise à jour des dépôts
brew update #Installation
brew install dnsmasq

Une fois l’exécution terminée, plusieurs informations sont affichées sur l’emplacement de la configuration à utiliser.

Configuration

La mise en place de ce logiciel a pour objectif de simplifier la configuration d’un poste de développeur. Personnellement, j’utilise des domaines en .dev sur mes environnements de développements pour faire facilement la différence entre ma version locale et la version en ligne.

L’outil est fournit avec une configuration d’exemple qu’il va falloir dupliquer pour commencer !

cp $(brew list dnsmasq | grep /dnsmasq.conf.example$) /usr/local/etc/dnsmasq.conf

Il faut ensuite éditer le fichier /usr/local/etc/dnsmasq.conf dans un éditeur de texte et rajouter la ligne suivante :

address=/.dev/127.0.0.1

Cette ligne va permettre à l’outil d’envoyer toutes les URLs contenant .dev vers l’IP 127.0.0.1. Si vous préférer utiliser un autre TLD, libre à vous, il suffit d’adapter la ligne.
La configuration d’exemple est très complète et détaillée mais est totalement commentée. J’ajoute donc la ligne juste en dessous du commentaire « #address=/double-click.net/127.0.0.1 » pour rester cohérent et la retrouver facilement même si je viens à modifier d’autres paramètres.

Lancer Dnsmasq

Maintenant que la configuration est en place, il faut démarrer le service. Lors de l’installation le fichier plist utile à la mise en place a été placé sur la machine. On copie d’abord ce fichier dans le répertoire contenant les scripts d’initialisation des daemons et on le charge avec launchctl pour qu’il démarre :

sudo cp -fv /usr/local/opt/dnsmasq/*.plist /Library/LaunchDaemons/
sudo launchctl load /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist

Pour vérifier que tout est en ordre, il est possible d’utiliser la commande dig pour envoyer une requête DNS :

dig toto.dev @127.0.0.1

Vous devez normalement obtenir un résultat décrivant un enregistrement de type A pointant vers 127.0.0.1 :

... ;; ANSWER SECTION: toto.dev. 0 IN A 127.0.0.1 ...

Si jamais vous avez besoin de démarrer ou arrêter le service, il suffit d’utiliser launchctl :

sudo launchctl stop homebrew.mxcl.dnsmasq sudo launchctl start homebrew.mxcl.dnsmasq

Configuration du système

Maintenant que dnsmasq est démarré et opérationnel, il faut configurer le système pour lui demander de l’utiliser. En effet, avoir démarré un serveur DNS est une chose mais pour le moment il n’intercepte aucune requête.

Pour cela il y a deux approches :

  • Envoyer toutes les requêtes DNS vers dnsmasq ;
  • Envoyer uniquement les requêtes pour les domaines *.dev vers dnsmasq.

La première est très simple car il suffit d’aller dans les préférences systèmes et modifier le DNS dans la configuration réseau. Mais la configuration mise en place précédemment n’est pas celle d’un serveur DNS complet. Devoir maintenir son propre serveur DNS sur son poste de travail n’est pas une mince affaire !

La seconde demande d’exécuter quelques commandes mais est plus viable à long terme. La plupart des systèmes Unix ont un fichier de configuration /etc/resolv.conf qui décrit au système comment les requêtes DNS doivent être traitées.
Par chance, Mac OS est basé sur un système Unix, dispose de ce fichier et va, en plus, nous permettre de créer des règles de résolution spécifiques dans le répertoire /etc/resolver.

Il n’existe probablement pas, il faut donc le créer :

sudo mkdir -p /etc/resolver

Ensuite, il faut décrire notre règle. Un fichier ayant le même nom que le domaine de premier niveau (ou TLD) choisit doit être créé, dans mon cas c’est dev.
Il est possible de configurer tout un tas de chose sur la méthode de résolution et les règles à appliquer. Pour cela, je vous invite à étudier le fonctionnement de resolv.conf. Seule la directive nameserver nous intéresse ici. C’est elle qui permet d’envoyer les requêtes vers un serveur DNS particulier (ici 127.0.0.1).

Il faut finalement créer le fichier dev :

sudo tee /etc/resolver/dev >/dev/null <<EOF nameserver 127.0.0.1 EOF

Mac OS recharge directement la configuration, il n’y a plus aucune modification à effectuer. Le processus d’installation est totalement terminé. Dorénavant, dès que vous accéder à un domaine se terminant par « .dev » sur votre machine, vous êtes envoyé vers 127.0.0.1. C’est une sorte de fichier hosts automatique.

Ca ne supprime pas du tout le fonctionnement du fichier hosts, c’est un complément sympa pour ne plus avoir à y toucher. Il y a quelques manipulations à effectuer mais le tout est relativement simple à intégrer.

J’ai repris toutes les commandes dans un gist unique que vous pouvez utiliser pour tout faire d’un coup :

La prochaine étape est de configurer le serveur web (Apache, Nginx, …) pour qu’il puisse tirer avantage de ce nouveau dynamisme. J’en parlerai dans un prochain article.

Si tout n’est pas clair, n’hésitez pas à me faire vos retours sur ce pas à pas pour que je puisse l’améliorer !

Publié par

Stéphane

Passionné par les nouvelles technologies, la veille est mon quotidien. Je mets au service mon expertise et ma curiosité pour la conceptions de solutions techniques pérennes.
Consultant et formateur je manipule au quotidien PHP, SolR, ElasticSearch, JavaScript, HTML5, WordPress…

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *