Comment attribuer un nom d’hôte statique à une machine Linux

Un nom d’hôte statique est un label lisible par l’homme, configuré de manière permanente et attribué à un système Linux, qui persiste après les redémarrages et n’est pas écrasé par les services réseau tels que DHCP. Contrairement à un nom d’hôte transitoire — qui peut être défini dynamiquement par le démon réseau et réinitialisé au prochain démarrage — un nom d’hôte statique est stocké sur le disque et reste autoritaire quelle que soit la manière dont la machine obtient son adresse IP.

Cette distinction est d’une importance capitale dans les environnements de production. Lorsque vous exploitez un VPS ou un serveur dédié, un nom d’hôte stable constitue l’ancre des entrées SSH known-hosts, des Subject Alternative Names des certificats TLS, des identifiants syslog, des labels cibles Prometheus et des noms principaux Kerberos. Un nom d’hôte qui change silencieusement après un renouvellement DHCP peut briser tous ces éléments simultanément.

Qu’est-ce exactement qu’un nom d’hôte Linux ?

Linux suit trois classes distinctes de noms d’hôte, chacune servant un objectif différent :

Le nom d’hôte statique est celui que vous configurez intentionnellement. Le nom d’hôte transitoire est celui que le noyau utilise actuellement — normalement identique au statique, sauf si un serveur DHCP ou systemd-timesyncd l’a remplacé. Le nom d’hôte joli est purement cosmétique (par ex., "Alex's Web Server") et n’est jamais utilisé dans DNS ou SSH.

Les noms d’hôte statiques valides suivent les règles RFC 1123 : lettres minuscules, chiffres et tirets uniquement ; pas de tirets bas ; pas de tirets en début ou en fin ; maximum 63 caractères par label ; maximum 253 caractères au total pour un nom de domaine pleinement qualifié (FQDN).

Vérification du nom d’hôte actuel

Avant d’apporter des modifications, auditez l’état actuel des trois types de noms d’hôte :

hostnamectl

Exemple de sortie sur un système basé sur systemd :

 Static hostname: old-server-name
 Pretty hostname: Old Server Name
Transient hostname: dhcp-assigned-name
       Icon name: computer-server
         Chassis: server
      Machine ID: a1b2c3d4e5f6...
         Boot ID: 9f8e7d6c5b4a...
Operating System: Ubuntu 22.04.3 LTS
          Kernel: Linux 5.15.0-91-generic
    Architecture: x86-64

Si le nom d’hôte transitoire diffère du nom d’hôte statique, votre client DHCP remplace la valeur statique — un problème traité dans la section sur la persistance ci-dessous.

Pour les systèmes sans hostnamectl, utilisez :

hostname
cat /etc/hostname
uname -n

Méthode 1 : Utilisation de hostnamectl (distributions basées sur systemd)

Cette méthode s’applique à Ubuntu 16.04+, Debian 8+, CentOS 7+, RHEL 7+, Fedora 15+, AlmaLinux, Rocky Linux, et toute distribution exécutant systemd en tant que PID 1.

Étape 1 : Définir le nom d’hôte statique

sudo hostnamectl set-hostname new-static-hostname

hostnamectl écrit la valeur dans /etc/hostname, appelle le syscall sethostname(2) pour mettre à jour le noyau en cours d’exécution immédiatement, et notifie systemd-hostnamed — le tout de manière atomique. Aucun redémarrage n’est nécessaire.

Pour définir les trois types de noms d’hôte simultanément :

sudo hostnamectl set-hostname "new-static-hostname" --static
sudo hostnamectl set-hostname "New Static Hostname" --pretty
sudo hostnamectl set-hostname "new-static-hostname" --transient

Étape 2 : Vérifier le changement

hostnamectl

Confirmez que le champ nom d’hôte statique affiche votre nouvelle valeur. Vérifiez également que le noyau l’a pris en compte :

hostname

Étape 3 : Mettre à jour /etc/hosts

hostnamectl ne met pas à jour /etc/hosts automatiquement. Ne pas mettre à jour ce fichier provoque l’émission par sudo de l’avertissement unable to resolve host, casse les applications qui appellent gethostbyname() sur le nom d’hôte local, et peut provoquer l’échec au démarrage des services basés sur Java (Elasticsearch, Kafka).

sudo nano /etc/hosts

Le fichier doit contenir au minimum :

127.0.0.1   localhost
127.0.1.1   new-static-hostname.yourdomain.com  new-static-hostname

La deuxième ligne utilise 127.0.1.1 (et non 127.0.0.1) pour le nom d’hôte de la machine sur les systèmes de la famille Debian. Sur les systèmes de la famille RHEL, utilisez l’adresse IP principale réelle à la place :

192.168.1.50  new-static-hostname.yourdomain.com  new-static-hostname

Si vous gérez un VPS avec cPanel, l’outil de changement de nom d’hôte de cPanel gère /etc/hosts automatiquement, mais vous devriez tout de même vérifier le résultat manuellement.

Méthode 2 : Édition manuelle de /etc/hostname (distributions non-systemd)

Cette méthode s’applique aux anciennes versions Debian/Ubuntu utilisant SysVinit ou Upstart, Alpine Linux, Gentoo avec OpenRC, Void Linux, et les systèmes embarqués.

Étape 1 : Éditer /etc/hostname

sudo nano /etc/hostname

Le fichier doit contenir exactement une ligne — le nom d’hôte court sans espace de fin ni saut de ligne au-delà du terminateur de ligne standard :

new-static-hostname

Étape 2 : Mettre à jour /etc/hosts

sudo nano /etc/hosts

Appliquez le même mappage décrit dans la Méthode 1.

Étape 3 : Appliquer le changement sans redémarrer

Notifiez immédiatement le noyau en cours d’exécution du nouveau nom d’hôte :

sudo hostname new-static-hostname

Sur les systèmes avec systemd-hostnamed disponible même sans adoption complète de systemd :

sudo systemctl restart systemd-hostnamed

Sur les systèmes SysVinit purs, la commande hostname ci-dessus est suffisante. Le changement prend effet pour tous les nouveaux processus ; les shells existants afficheront toujours l’ancienne invite jusqu’à ce que vous ouvriez une nouvelle session de terminal ou exécutiez :

exec bash

Méthode 3 : Remplacement cloud-init (critique pour les instances VPS cloud)

Il s’agit du scénario le plus souvent manqué. Sur les plateformes cloud — y compris la plupart des fournisseurs VPS — cloud-init s’exécute à chaque démarrage et réinitialise le nom d’hôte à ce que retourne l’API de métadonnées de l’instance. Votre modification de /etc/hostname sera silencieusement écrasée au prochain redémarrage.

Pour qu’un nom d’hôte statique survive à cloud-init, éditez /etc/cloud/cloud.cfg :

sudo nano /etc/cloud/cloud.cfg

Trouvez ou ajoutez la directive suivante :

preserve_hostname: true

Vous pouvez également créer un fichier de remplacement drop-in pour éviter de modifier la configuration gérée par le paquet :

sudo mkdir -p /etc/cloud/cloud.cfg.d/
sudo tee /etc/cloud/cloud.cfg.d/99_hostname.cfg > /dev/null <<EOF
preserve_hostname: true
EOF

Après ce changement, cloud-init ne touchera plus au nom d’hôte lors des démarrages suivants.

Empêcher DHCP de remplacer le nom d’hôte statique

Même sans cloud-init, un client DHCP peut écraser le nom d’hôte transitoire. La correction dépend du client DHCP utilisé par votre distribution.

Pour dhclient (Debian/Ubuntu hérité)

Éditez /etc/dhcp/dhclient.conf :

sudo nano /etc/dhcp/dhclient.conf

Ajoutez ou modifiez :

send host-name "new-static-hostname";
supersede host-name "new-static-hostname";

La directive supersede garantit que le client ignore tout nom d’hôte proposé par le serveur DHCP.

Pour systemd-networkd avec systemd-resolved

Éditez ou créez un fichier .network dans /etc/systemd/network/ :

[DHCP]
SendHostname=yes
UseHostname=no

UseHostname=no empêche le nom d’hôte proposé par DHCP d’écraser le nom d’hôte statique.

Pour NetworkManager (la plupart des distributions de bureau et serveurs modernes)

sudo nmcli con modify "connection-name" ipv4.dhcp-hostname "new-static-hostname"
sudo nmcli con modify "connection-name" ipv4.dhcp-send-hostname yes

Pour empêcher NetworkManager d’accepter entièrement un nom d’hôte de DHCP, ajoutez à /etc/NetworkManager/NetworkManager.conf :

[main]
hostname-mode=none

Propagation du nom d’hôte : ce qui doit également être informé

Définir le nom d’hôte dans le système d’exploitation est nécessaire mais pas suffisant dans un environnement en réseau. Tenez compte de ces systèmes en aval :

• Enregistrements DNS directs et inverses : Mettez à jour l’enregistrement A et l’enregistrement PTR de votre zone DNS. Sans enregistrement PTR correspondant, de nombreux serveurs de messagerie rejetteront les e-mails sortants, et certains outils de sécurité signaleront l’hôte comme suspect.
• Certificats SSL/TLS : Si votre nom d’hôte fait partie du CN ou du SAN d’un certificat, vous avez besoin d’un nouveau certificat. Les certificats SSL liés à l’ancien nom d’hôte produiront des erreurs de validation.
• Enregistrement de domaine et propagation DNS : Si le nom d’hôte correspond à un FQDN public, mettez à jour l’enregistrement DNS auprès de votre registraire de domaine et prévoyez un délai de propagation basé sur le TTL.
• Agents de surveillance : L’exportateur de nœuds Prometheus, Datadog, Zabbix et les agents similaires utilisent le nom d’hôte comme label. Après un changement de nom d’hôte, les métriques historiques peuvent apparaître sous une identité d’hôte différente.
• /etc/ssh/ssh_known_hosts : Les fichiers known-hosts à l’échelle du cluster référençant l’ancien nom d’hôte doivent être mis à jour.
• Fichiers de configuration des applications : Tout nom d’hôte codé en dur dans les configurations d’application, les chaînes de connexion JDBC ou les listeners annoncés des courtiers de messages doit être mis à jour.

Comparaison : méthodes de configuration du nom d’hôte

Cas limites réels et pièges

Piège 1 : La boucle d’avertissement sudo. Si vous définissez le nom d’hôte mais oubliez de mettre à jour /etc/hosts, chaque invocation de sudo affichera sudo: unable to resolve host new-static-hostname. Ce n’est pas fatal, mais cela ajoute de la latence à chaque commande privilégiée et inonde les journaux.

Piège 2 : Les services Java refusent de démarrer. InetAddress.getLocalHost() de Java résout le nom d’hôte via gethostbyname(). Si le nom d’hôte n’est pas dans /etc/hosts ou résolvable via DNS, des services comme Elasticsearch, Kafka et Cassandra lèvent UnknownHostException au démarrage.

Piège 3 : Nom d’hôte avec des tirets bas. Bien qu’ils soient largement utilisés de manière informelle, les tirets bas dans les noms d’hôte violent les RFC 952 et RFC 1123. Certains résolveurs DNS, bibliothèques TLS et composants Kubernetes les rejetteront ou les géreront mal. Utilisez toujours des tirets.

Piège 4 : FQDN vs. nom d’hôte court. hostnamectl ne stocke que le nom d’hôte court (par ex., web01). Le FQDN (par ex., web01.example.com) est résolu en combinant le nom d’hôte court avec la liste de recherche de domaine dans /etc/resolv.conf ou /etc/systemd/resolved.conf. Définissez Domains=example.com dans resolved.conf ou search example.com dans resolv.conf pour que hostname --fqdn retourne la valeur correcte.

Piège 5 : Isolation des conteneurs et des espaces de noms. À l’intérieur d’un conteneur Docker ou d’un espace de noms LXC, hostnamectl peut échouer avec Failed to connect to bus: No such file or directory car systemd-hostnamed ne s’exécute pas. Utilisez hostname new-name directement, ou définissez le nom d’hôte au moment de la création du conteneur via docker run --hostname ou la clé hostname: dans docker-compose.yml.

Liste de contrôle pratique

Utilisez cette liste de contrôle avant et après chaque changement de nom d’hôte dans un environnement de production :

• Confirmez que le nouveau nom d’hôte est conforme à la RFC 1123 (minuscules, tirets uniquement, max 63 caractères par label)
• Exécutez hostnamectl avant le changement et sauvegardez la sortie à des fins d’audit
• Définissez le nom d’hôte statique avec hostnamectl set-hostname ou en éditant /etc/hostname
• Mettez à jour /etc/hosts avec le nom d’hôte court et le FQDN sur la même ligne
• Si le système est une instance cloud, définissez preserve_hostname: true dans la configuration cloud-init
• Si DHCP est actif, configurez le client DHCP pour ignorer les noms d’hôte proposés par le serveur
• Mettez à jour les enregistrements DNS A et PTR
• Renouvelez ou réémettez tout certificat TLS référençant l’ancien nom d’hôte
• Redémarrez les services dépendants du nom d’hôte (syslog, agents de surveillance, applications Java)
• Ouvrez une nouvelle session shell et vérifiez que hostname, hostname --fqdn et hostnamectl retournent tous des valeurs cohérentes
• Vérifiez /var/log/syslog ou journalctl -b pour toute erreur post-changement référençant l’ancien nom d’hôte

FAQ

hostnamectl set-hostname nécessite-t-il un redémarrage pour prendre effet ?

Non. hostnamectl appelle le syscall sethostname(2) immédiatement, mettant à jour le noyau en cours d’exécution en temps réel. Le changement est également écrit dans /etc/hostname pour la persistance. Les nouveaux processus et les nouvelles sessions shell verront le nom d’hôte mis à jour sans aucun redémarrage.

Pourquoi mon nom d’hôte revient-il à son état précédent après chaque redémarrage sur un VPS cloud ?

Cloud-init l’écrase presque certainement. Ajoutez preserve_hostname: true à /etc/cloud/cloud.cfg ou créez un fichier drop-in dans /etc/cloud/cloud.cfg.d/99_hostname.cfg avec la même directive. C’est la cause la plus courante de réversion du nom d’hôte sur les machines hébergées dans le cloud.

Quelle est la différence entre 127.0.0.1 et 127.0.1.1 dans /etc/hosts ?

127.0.0.1 est l’adresse de bouclage standard mappée à localhost. Les distributions de la famille Debian utilisent 127.0.1.1 comme adresse de bouclage secondaire spécifiquement pour le nom d’hôte de la machine, évitant les conflits lorsque la machine n’a pas d’IP statique. Sur les systèmes de la famille RHEL et les machines avec une IP fixe, utilisez l’adresse IP principale réelle pour le mappage du nom d’hôte à la place.

Puis-je utiliser un tiret bas dans un nom d’hôte Linux ?

Techniquement, le système d’exploitation l’acceptera, mais vous ne devriez pas le faire. Les tirets bas violent les RFC 952 et RFC 1123. Ils provoquent des échecs dans la résolution DNS (BIND les rejette par défaut), la validation des certificats TLS et la dénomination des nœuds Kubernetes. Utilisez exclusivement des tirets.

Comment vérifier que le nom d’hôte est entièrement cohérent sur toutes les couches du système ?

Exécutez la séquence suivante et confirmez que toutes les sorties correspondent :

hostname
hostname --fqdn
hostnamectl --static
cat /etc/hostname
systemd-resolve --status | grep "Current hostname"

Si l’une de ces commandes retourne des valeurs différentes, l’une des couches — cloud-init, client DHCP ou NetworkManager — remplace toujours le paramètre statique.