Renommer un serveur Linux avec hostnamectl sans casser le DNS

Renommer un serveur Linux ne se résume pas à changer le texte affiché dans l’invite SSH. Le nom peut aussi être repris dans /etc/hosts, le DNS, les certificats, la supervision, les sauvegardes ou l’inventaire du parc.

hostnamectl règle le nom du système, mais il ne modifie ni votre zone DNS ni les outils qui identifient encore la machine avec l’ancien nom. Je vous conseille donc de relever ces dépendances avant le changement, puis de les vérifier une par une.

Relever le nom actuel et les adresses du serveur

Commencez par garder une session SSH ouverte. Si le serveur est distant, assurez-vous aussi de disposer d’une console de secours chez l’hébergeur. Le changement de hostname ne coupe normalement pas SSH, mais une erreur dans /etc/hosts, le DNS ou une automatisation peut compliquer la reconnexion.

hostnamectl status
hostname
hostname -f
cat /etc/hostname
getent hosts "$(hostname)"
ip -br address

hostname affiche le nom utilisé par le noyau. Le fichier /etc/hostname contient le nom statique chargé au démarrage sur un système géré par systemd. La commande hostname -f tente de retrouver le nom pleinement qualifié via la résolution locale. Si elle échoue ou renvoie un résultat inattendu, ne forcez pas le changement tout de suite : vérifiez d’abord /etc/hosts et le DNS.

Notez aussi l’adresse réellement utilisée par le serveur. Le guide sur ip addr sous Linux vous aidera à distinguer l’adresse de l’interface, la route utilisée et une éventuelle IP publique fournie par un NAT.

Avant d’écrire, sauvegardez les deux fichiers susceptibles d’être corrigés :

sudo cp -a /etc/hostname "/etc/hostname.bak-$(date +%F-%H%M)"
sudo cp -a /etc/hosts "/etc/hosts.bak-$(date +%F-%H%M)"

Changer le hostname avec hostnamectl

Choisissez un nom court, stable et compatible DNS, par exemple srv-app-02. Évitez les espaces, les accents, les underscores et les noms qui décrivent une adresse IP susceptible de changer. Un hostname statique reste prioritaire sur un nom transitoire reçu par DHCP.

sudo hostnamectl set-hostname srv-app-02
hostnamectl status
hostname
cat /etc/hostname

Sans option de ciblage, hostnamectl set-hostname met à jour les noms pretty, statique et transitoire. Pour un serveur, un nom court comme srv-app-02 évite de mélanger le hostname du système avec son FQDN srv-app-02.example.net. La page de manuel de hostnamectl détaille ces trois niveaux.

La commande doit prendre effet immédiatement. L’invite de votre session SSH peut toutefois garder l’ancien nom jusqu’à l’ouverture d’un nouveau shell. Ne redémarrez pas le serveur uniquement pour rafraîchir le prompt. Ouvrez plutôt une seconde session et comparez le résultat de hostname.

Corriger /etc/hosts sans casser la résolution locale

hostnamectl ne réécrit pas /etc/hosts. Recherchez l’ancien nom avant de modifier le fichier :

grep -nE '(^|[[:space:]])srv-app-01([[:space:]]|$)' /etc/hosts
sudoedit /etc/hosts

Sur Debian et Ubuntu, une ligne en 127.0.1.1 est souvent utilisée pour associer localement le FQDN et le nom court :

127.0.0.1 localhost
127.0.1.1 srv-app-02.example.net srv-app-02

Sur un serveur disposant d’une adresse privée stable, vous pouvez trouver une association directe avec cette adresse, par exemple 192.0.2.25 srv-app-02.example.net srv-app-02. Ne copiez pas un modèle au hasard. Corrigez uniquement la ligne qui désigne déjà la machine et conservez les entrées localhost IPv4 et IPv6.

getent hosts srv-app-02
getent hosts srv-app-02.example.net
hostname -f

getent interroge la résolution configurée par /etc/nsswitch.conf. Il tient donc compte de /etc/hosts, du DNS et, selon votre environnement, de sources comme LDAP. C’est plus représentatif qu’une simple lecture du fichier.

Mettre à jour le DNS direct et inverse séparément

Le nouveau nom local ne crée aucun enregistrement DNS. Dans la zone concernée, ajoutez ou modifiez l’enregistrement A, l’éventuel AAAA et, si vous le gérez, le PTR de l’adresse. Gardez l’ancien enregistrement pendant la transition si des applications l’utilisent encore, puis retirez-le après contrôle.

dig +short A srv-app-02.example.net
dig +short AAAA srv-app-02.example.net
dig +short -x 192.0.2.25

Faites ces tests depuis une autre machine et, si nécessaire, avec plusieurs résolveurs. L’article sur dig sous Linux montre comment comparer le DNS local, un serveur public et le serveur autoritaire sans vider les caches au hasard.

Un DNS correct ne garantit pas que tout soit prêt. Vérifiez les certificats TLS, les fichiers de configuration qui contiennent l’ancien FQDN et les règles de pare-feu basées sur un nom. Pour SSH, une connexion vers le nouveau nom utilise toujours la clé d’hôte du serveur, mais elle crée une nouvelle entrée logique dans known_hosts. Comparez l’empreinte avant de l’accepter.

Contrôler SSH, les logs et la supervision après le renommage

Ouvrez une seconde connexion SSH avec le nouveau FQDN sans fermer la première. Vérifiez ensuite les services en échec et les messages liés au changement :

hostnamectl status
systemctl --failed
journalctl -u systemd-hostnamed --since "-15 minutes" --no-pager
journalctl --since "-15 minutes" --no-pager | grep -iE 'hostname|srv-app-01|srv-app-02'

La présence de l’ancien nom dans les lignes écrites avant le changement est normale. Ce qui compte est le nom utilisé dans les nouveaux événements. Ne redémarrez pas tous les services par réflexe. Contrôlez d’abord ceux qui déclarent explicitement le hostname au démarrage, comme certains agents de logs, de sauvegarde ou de supervision.

Dans votre outil de supervision, vérifiez que la machine n’apparaît pas comme un nouvel hôte vide pendant que l’ancien passe hors ligne. Faites le même contrôle pour l’inventaire, les sauvegardes et les alertes. Un renommage réussi côté Linux peut sinon créer deux objets distincts dans ces plateformes.

Si l’ancien hostname revient après le redémarrage

Quand le nom revient à sa valeur précédente, cherchez une couche de provisionnement avant de relancer hostnamectl. Une image cloud peut appliquer le hostname au démarrage avec cloud-init :

grep -R "preserve_hostname" /etc/cloud/cloud.cfg /etc/cloud/cloud.cfg.d 2>/dev/null
journalctl -b -u cloud-init --no-pager
cat /etc/hostname
hostnamectl status

Vérifiez aussi le panneau de l’hébergeur, Terraform, Ansible ou le script d’initialisation qui gère la VM. Corrigez la source de vérité au lieu de lutter contre elle à chaque démarrage. Une fois le nom stable, refaites les contrôles getent, dig, SSH, logs et supervision. Vous saurez alors que le serveur a été renommé partout où ce changement compte réellement.

sudo apt update && sudo apt upgrade