Linux / machine-id : le vérifier et préparer une image clonée

Le machine-id est un identifiant persistant pour une installation Linux basée sur systemd. Il est normalement stocké dans /etc/machine-id et ne change pas lorsque vous redémarrez ou renommez l'hôte. Si vous clonez un serveur ou une machine virtuelle sans préparer ce fichier, les systèmes séparés peuvent finir avec le même identifiant.

Qu'est-ce que l'identifiant machine ?

L'identifiant de machine (machine-id) identifie un système local avec une valeur de 128 bits. Dans /etc/machine-id, il est normalement représenté par 32 caractères hexadécimaux minuscules suivis d'un saut de ligne. Systemd établit cette valeur lors de l'installation ou du démarrage et la conserve généralement lors des démarrages ultérieurs.

Ce n'est pas un nom de serveur lisible par l'homme. Un nom d'hôte est un nom qu'un administrateur peut choisir et modifier ; l'identifiant de machine identifie l'installation du système d'exploitation. Si vous devez renommer un hôte, consultez Comment changer le nom d'hôte sur Rocky Linux.

L'identifiant de machine est également différent d'un numéro de série matériel ou de l'adresse MAC d'une interface réseau. Remplacer le matériel ou modifier les paramètres réseau ne le change pas en soi. Le manuel systemd machine-id(5) documente son format et son comportement d'initialisation.

Comment vérifier l'ID machine actuel

Sur un système que vous administrez, affichez la valeur actuelle avec :

cat /etc/machine-id

Un système normalement initialisé affiche une valeur hexadécimale de 32 caractères. N'écrivez pas une chaîne arbitraire dans le fichier simplement parce qu'il est vide ou manquant. Les images, les conteneurs et les systèmes de fichiers en lecture seule peuvent initialiser l'ID différemment lors du démarrage.

Ne collez pas l'ID réel dans un message public, un journal ou une demande d'assistance. Systemd indique qu'il doit être traité comme confidentiel et ne pas être exposé à des environnements non fiables, en particulier sur un réseau. Si une application a besoin d'un identifiant stable qu'elle peut exposer, elle devrait utiliser un ID dérivé spécifique à l'application plutôt que de publier l'ID machine brut.

Un redémarrage ou un changement de nom d'hôte l'affecte-t-il ?

Normalement, non. L'ID de machine est persistant pour une installation du système d'exploitation et n'est pas régénéré à chaque démarrage. Il est indépendant du nom d'hôte, de l'adresse IP et de l'adresse MAC.

Si deux serveurs ont des noms différents mais le même ID de machine, vérifiez si une image a été copiée sans avoir été préparée pour le clonage. Inversement, des noms d'hôte identiques n'impliquent pas nécessairement des IDs de machine identiques.

Quand devez-vous réinitialiser un ID de machine ?

Le cas principal consiste à préparer une image de système d'exploitation pour une utilisation par plusieurs machines virtuelles, instances cloud ou conteneurs. Un clonage direct du disque peut copier /etc/machine-id ainsi que tout le reste. Pour donner à chaque instance son propre ID, préparez l'image source lorsqu'elle est arrêtée, puis laissez chaque clone obtenir un ID lors de son démarrage.

Il n'y a généralement aucune raison de réinitialiser l'ID sur un serveur en fonctionnement juste pour le rendre différent. Ne le faites que pour un besoin spécifique, comme corriger des IDs en double ou créer une image de déploiement. Systemd note que les identifiants visibles sur le réseau peuvent être dérivés du machine-id ; consultez ses conseils sur la création d'images en toute sécurité.

Comment l'état du fichier affecte le premier démarrage

Supprimer /etc/machine-id et le laisser vide n'est pas équivalent. Décidez si l'image doit également exécuter l'initialisation du premier démarrage.

État dans l'image Nouvel ID au démarrage Considéré comme premier démarrage
Fichier manquant Systemd tente d'en établir un Oui
Contient uninitialized Systemd tente d'en établir un Oui
Le fichier existe mais est vide Systemd tente d'en établir un Non
Le fichier contient un ID valide L'ID existant est utilisé Non

Ces règles supposent que le paramètre du noyau systemd.condition_first_boot= ne force pas un autre comportement. Un identifiant déjà présent dans D-Bus ou fourni par la virtualisation peut aussi être repris : un fichier vide ne garantit pas à lui seul une nouvelle valeur unique.

Lorsque systemd considère qu’un démarrage est le premier, les unités avec ConditionFirstBoot=yes peuvent s’exécuter, ainsi que d’autres initialisations. Un fichier vide permet d’établir un ID sans déclencher ces actions de premier démarrage. Un système de fichiers en lecture seule peut également nécessiter un fichier vide existant pour qu’un ID temporaire puisse y être monté par liaison. Voir la section sur la sémantique du premier démarrage de machine-id(5) pour les règles exactes.

Réinitialisation de l’ID dans une image destinée au clonage

L’exemple suivant suppose qu’une image éteinte a été montée par un système de gestion séparé à /mnt/image-root. Remplacez ce chemin par le point de montage réel. Ces commandes ne sont pas des instructions pour modifier /etc/machine-id sur un serveur de production en cours d’exécution.

  1. Éteignez la VM ou l'image source et effectuez une sauvegarde ou un instantané. Conservez l'original si vous transformez une copie en modèle réutilisable.
  2. Montez l'image sur un autre système. Confirmez que /mnt/image-root est vraiment le point de montage de l'image, puis inspectez les deux chemins de fichiers d’identification :
findmnt --mountpoint /mnt/image-root
ls -l /mnt/image-root/etc/machine-id /mnt/image-root/var/lib/dbus/machine-id

Si findmnt n'affiche pas le point de montage prévu, arrêtez-vous. /var/lib/dbus/machine-id peut être un lien symbolique vers /etc/machine-id ou un fichier séparé. Si un fichier séparé conserve l'ancien ID, systemd peut le réutiliser.

Avant toute écriture, contrôlez aussi que /mnt/image-root/etc/machine-id est le fichier régulier attendu. Si ce chemin est un lien symbolique, arrêtez la procédure et vérifiez sa résolution depuis le système de gestion : un lien absolu peut viser un fichier de ce système au lieu de celui de l’image. Ne poursuivez pas avec tee ou truncate tant que la cible n’est pas certaine.

Pour exécuter également l'initialisation du premier démarrage

Sur une image modifiable qui doit être reconnue comme un premier démarrage, vérifiez à nouveau le point de montage et supprimez le fichier à l'intérieur de l'image :

sudo rm -- /mnt/image-root/etc/machine-id

Alternativement, si l'image nécessite que le fichier reste présent, écrivez uninitialized suivi d'un saut de ligne. Choisissez une méthode, pas les deux :

printf 'uninitialized\n' | sudo tee /mnt/image-root/etc/machine-id > /dev/null

Si /var/lib/dbus/machine-id est un fichier régulier séparé contenant l'ID précédent, il doit également être réinitialisé. Ce n'est qu'après avoir confirmé avec ls -l qu'il ne s'agit pas d'un lien symbolique que vous devez supprimer ce fichier de l'image éteinte :

sudo rm -- /mnt/image-root/var/lib/dbus/machine-id

S'il s'agit d'un lien symbolique, ne lancez pas cette commande. Vérifiez plutôt sa cible et la disposition de la distribution. Systemd peut réutiliser un ID D-Bus séparé lorsque /etc/machine-id est vide ou absent.

Pour obtenir un nouvel ID sans actions au premier démarrage

Si les unités destinées au premier démarrage ne doivent pas s'exécuter, laissez un fichier vide à l'intérieur de l'image :

sudo truncate -s 0 -- /mnt/image-root/etc/machine-id

Systemd peut établir un ID à partir d'un fichier vide mais ne considère pas ce démarrage comme le premier. Un fichier vide peut également être important pour une image en lecture seule. Cette méthode nécessite toujours de vérifier un ID D-Bus séparé qui pourrait être réutilisé, comme décrit ci-dessus.

Démontez l'image proprement, démarrez un clone et vérifiez que chaque instance déployée a un ID différent. Comparez les valeurs réelles uniquement dans un environnement de gestion de confiance ; ne les publiez pas. Exécuter systemd-machine-id-setup seul ne garantit pas un ID aléatoire, car il peut réutiliser un ID D-Bus existant ou une autre valeur fournie. Son ordre de priorité est décrit dans le manuel systemd-machine-id-setup(1).

En cas d’échec du démarrage ou de dépendance inattendue à l’ancienne identité, arrêtez la copie et restaurez l’image ou l’instantané conservé avant la modification. Ne déployez pas le modèle à grande échelle avant d’avoir validé plusieurs instances distinctes.

Que font réellement deux des commandes les plus couramment suggérées ?

Vous pouvez également voir cette paire présentée comme un moyen de réinitialiser le machine-id :

sudo truncate -s 0 /etc/machine-id
sudo rm -f /var/lib/dbus/machine-id

La première commande réduit /etc/machine-id à zéro octet sans le supprimer. Systemd peut établir un ID au prochain démarrage, mais un fichier vide ne déclenche pas les unités réservées au premier démarrage. Il ne remplace pas immédiatement l'ID déjà détenu par le système en cours d'exécution et ses services.

La deuxième commande supprime le chemin d'ID D-Bus. Si ce chemin est un fichier régulier séparé contenant l'ancien ID, le supprimer peut empêcher sa réutilisation. S'il s'agit d'un lien symbolique vers /etc/machine-id, en revanche, rm -f ne supprime que le lien. L'option -f supprime également une erreur lorsque le chemin n'existe pas, donc l'exécution réussie n'est pas une preuve que les IDs ont été réinitialisés correctement.

Ne copiez pas ces deux commandes directement sur un serveur de production en cours d'exécution comme procédure courante. Inspectez d'abord les chemins avec ls -l /etc/machine-id /var/lib/dbus/machine-id. Pour un modèle de clonage, utilisez la procédure d'image éteinte ci-dessus et vérifiez le résultat après chaque démarrage du clone. Systemd peut obtenir un ID à partir d'autres sources fournies par l'environnement ainsi que via D-Bus ; voir l'ordre d'initialisation dans machine-id(5).

Si les serveurs en cours d'exécution ont déjà des ID dupliqués

Ne vous contentez pas de vider ou de supprimer /etc/machine-id tout en continuant à exécuter un serveur de production. Les processus en cours peuvent avoir mis en cache la valeur existante, et l'état du journal, du réseau ou des applications peut être affecté. Identifiez l'original et le clone, choisissez quelle instance devra changer et planifiez un temps d'arrêt.

Sauvegardez les services et les données affectés, éteignez le clone et modifiez son disque depuis un environnement séparé. Après le démarrage, vérifiez que son nouvel ID diffère des autres systèmes et que le réseau et les services pertinents fonctionnent normalement. La préparation d'un modèle complet de VM peut également nécessiter la réinitialisation des clés hôtes SSH, des fichiers d’amorçage du générateur aléatoire, des noms d'hôtes et d'autres états spécifiques à chaque instance. Le guide Red Hat sur les modèles de VM décrit l'utilisation de virt-sysprep; consultez l'ensemble des modifications avant de l'utiliser.

Questions fréquemment posées

Puis-je utiliser un machine-id comme mot de passe ou jeton d'authentification ?

Non. Il identifie un système ; ce n'est pas un secret d'authentification. Évitez d'exposer la valeur brute, mais ne concevez pas l'authentification autour de celle-ci.

Des machine-id identiques prouvent-ils que deux systèmes sont identiques ?

Non. Un processus de clonage peut avoir copié l’ID. Inspectez les systèmes et le processus de déploiement de l’image plutôt que de supposer qu’il s’agit de la même machine.

Changer le nom d’hôte avec hostnamectl change-t-il le machine-id ?

Non. Le nom d’hôte et le machine-id ont des fonctions différentes et sont stockés séparément. Renommer un hôte ne génère pas un nouveau /etc/machine-id.

Dois-je supprimer ou vider le fichier dans une image clonée ?

Supprimez-le ou marquez-le uninitialized si l’initialisation au premier démarrage doit s’exécuter. Laissez-le vide si vous avez seulement besoin d’un nouvel ID sans ces actions de premier démarrage. Vérifiez les exigences du générateur d’images, y compris les systèmes de fichiers en lecture seule.