L'invite qui affichait une chose en affiche désormais une autre, et la connexion qui a changé était un VPN. C'est toute la preuve dont dispose la plupart des gens avant de conclure que le Mac a été renommé, et elle ne suffit pas. macOS conserve au moins trois valeurs de nom distinctes, chacune avec un rôle différent, et une invite de shell n'en montre au plus qu'une, d'une manière facile à mal lire.

Les comparer demande trois commandes et règle la question avant que quiconque modifie quoi que ce soit.

Trois valeurs, trois rôles

Toutes trois sont des chaînes que le système signalera volontiers, et la tentation est de tenir la première trouvée pour faisant autorité. C'est ainsi qu'un utilisateur finit par « réparer » le mauvais champ et regarde le symptôme survivre.

ValueWhat it is responsible for
ComputerNameThe friendly name a person sees in About and on the network browser; this is the one users mean by "my Mac's name"
LocalHostNameThe Bonjour name used on the local link, usually shown with a .local suffix in Sharing
HostNameAn explicitly configured host name that may simply not be set at all

La troisième ligne est là où commence l'essentiel de la confusion. Un HostName non défini est un état normal, pas une corruption, et cela signifie que le système se rabat sur d'autres sources lorsqu'il a besoin d'un nom d'hôte. Lire ce vide comme un dommage mène à une correction qui n'a jamais été nécessaire. Cela masque aussi la vraie question, qui n'est pas le nom de la machine mais le nom qu'utilisent une recherche ou une invite données à cet instant. Répondez à cela, et la valeur vide cesse de ressembler à un défaut.

Lire avant d'écrire

Ces trois commandes ne font que signaler des valeurs. Elles ne changent rien, ce qui les rend sûres à exécuter pendant une investigation.

scutil --get ComputerName
scutil --get LocalHostName
scutil --get HostName

Exécutez-les dans la même session locale avant et après une connexion VPN autorisée, et notez quelle valeur diffère réellement. Si rien ne diffère et que l'invite semble toujours incorrecte, le nom n'a jamais été le problème : quelque chose dans la configuration du shell ou dans la session distante affiche une chaîne différente.

Le guide d'Apple sur les noms d'ordinateur et les noms d'hôte locaux place le nom convivial sous General et About, et le nom local sous General et Sharing. Il documente aussi le suffixe automatique ajouté lorsqu'un autre Mac sur le même lien utilise déjà un nom, ce qu'il vaut la peine de savoir avant de prendre un numéro inattendu pour une preuve de manipulation.

Ce qu'une invite de shell prouve vraiment

Une invite est une chaîne que le shell construit, et son élément de nom d'hôte peut venir du nom d'hôte étendu, d'une forme abrégée de celui-ci ou d'une valeur codée en dur dans un fichier de profil. Elle peut aussi appartenir à une session SSH sur une machine complètement différente, ce qui est l'explication la moins glamour et de loin la plus courante pour une invite qui a changé à l'instant où vous avez connecté un VPN.

Vérifiez où vous êtes avant de vérifier comment vous vous appelez. Exécutez hostname et comparez-le aux trois valeurs stockées, puis regardez le réglage d'invite du shell pour voir s'il affiche l'hôte. Si l'invite contient une chaîne littérale que quelqu'un a tapée dans un fichier de configuration il y a des années, aucun changement système ne la fera jamais correspondre.

La comparaison compte aussi pour le rapport. Une invite qui semble différente et un ComputerName stocké qui a réellement changé sont deux constats avec deux propriétaires différents, et les fusionner en une seule phrase envoie l'ingénieur suivant au mauvais endroit.

Où un VPN peut légitimement toucher au nommage

Un VPN change quels résolveurs et domaines de recherche sont pertinents, et il peut fournir au client un nom d'hôte via DHCP si le client est configuré pour en accepter un. C'est un mécanisme réel, et il est aussi plus étroit que « le VPN a renommé mon Mac ». Qu'un résolveur change quel nom se résout pour une adresse donnée ne réécrit pas les valeurs locales stockées.

Séparez donc deux questions. L'identité propre de la machine est-elle différente, ou est-ce le nom qu'elle utilise pour atteindre autre chose qui est différent ? La première est répondue par les trois valeurs stockées ; la seconde par les requêtes DNS et par le profil de connexion utilisé. Les traiter comme une seule question produit des modifications des réglages d'identité en réponse à un problème de résolution de noms.

Si un nom d'hôte permanent est vraiment requis

Définir une valeur est une action administrative délibérée, pas une préférence esthétique, et la valeur doit venir de celui qui possède la politique de nommage de la machine. Écraser un nom géré pour que l'invite paraisse familière peut casser les vérifications de certificats, la supervision et tout ce qui identifie l'hôte.

Là où le changement est réellement nécessaire, le même outil qui a lu les valeurs les écrit, et HostName accepte un nom pleinement qualifié tandis que les deux autres attendent les formes locales. Notez ce que vous avez changé et pourquoi, car c'est exactement le genre de modification qui surprend la personne suivante à regarder la machine.

Pour la plupart des rapports, la bonne réponse est plus petite que la question ne le suggère : lisez les trois valeurs, identifiez celle qui diffère et ne corrigez que celle-là. L'invite était le symptôme de quelque chose, et les trois commandes vous disent de quoi.

Articles similaires