Comment puis-je empêcher le changement automatique et incorrect du nom de mon ordinateur?

Depuis que j'ai mis à niveau mon iMac 2009 vers Mavericks, je reçois souvent un message indiquant «Le nom de votre ordinateur« Foo »est déjà utilisé sur ce réseau. Le nom a été changé en "Foo (2)". '. Le nombre à la fin augmentera progressivement au fil du temps car la même erreur continue de se produire.

Il est assez trivial de renommer l'ordinateur en arrière, mais existe-t-il un moyen d'empêcher que cela ne se reproduise à l'avenir? J'avais un ancien Macbook Pro (exécutant Mountain Lion) qui avait le même problème, mais mon début 2013 MBP exécutant Mavericks ne semble pas souffrir de ce problème.

solution de contournement

Comme d'autres utilisateurs, je suis en proie à cette gêne, mais j'ai trouvé une solution semi-satisfaisante:

my_hostname='your-hostname-here'; for key in LocalHostName ComputerName HostName ; do sudo scutil --set $key $my_hostname; done

Après avoir exécuté cette commande, vous pouvez vérifier que tous les endroits où ils stockent le nom d'hôte sont les mêmes avec ce one-liner:

for key in LocalHostName ComputerName HostName ; do sudo scutil --get $key; done

Si le Macbook continue de renommer immédiatement ComputerNameavec un suffixe, vous pourrez peut-être l' arrêter en le désactivant Wake for Network Access.

• System Preferences→Energy Saver→Wake for Wi-Fi network access → Unchecked

Une fois éteint, renommez votre machine en utilisant les commandes ci-dessus pour terminer. Vous pouvez également essayer de forcer le ComputerNameretour en utilisant la System Preferences→Sharing→Computer Namepréférence de champ de texte.

Si cela n'a pas aidé, essayez de vider votre cache mDNS :

# El Capitan (10.11) and later
#   check if you have dscacheutil command with: which dscacheutil
sudo dscacheutil -flushcache

# Yosemite (10.10) and ealier
#   check if you have discoveryutil command with: which discoveryutil
sudo discoveryutil mdnsflushcache
sudo discoveryutil mdnsrestartquestions
sudo discoveryutil mdnsrestartregistrations
sudo discoveryutil udnsflushcache
sudo discoveryutil udnsrestartquestions

Après avoir vidé le cache mDNS, essayez de renommer votre ordinateur à l'aide des commandes ci-dessus.

Si cela ne fonctionne toujours pas, essayez de tuer le mDNSResponderservice:

sudo killall -HUP mDNSResponder

Ensuite, réessayez pour réinitialiser le nom de votre ordinateur à l'aide des scutilcommandes ci-dessus .

Si vous constatez que rien de tout cela ne sert à rien, il existe d' autres solutions signalées, notamment:

• Assurez-vous que vous n'avez qu'une seule connexion au réseau local

• Désactiver et réactiver Bonjour

  # Yosemite (10.10) (and other versions with discoveryd?)
  # Check for discoveryd with:  ps auxww | grep -i discoveryd
  sudo killall discoveryd
  sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.discoveryd.plist
  sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.discoveryd.plist
  
  # Mac OS versions without discoveryd
  # Check for mDNSResponder with:  ps auxww | grep -i mDNSResponder
  sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
  sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
  

• Arrêtez et réinitialisez TOUS les matériels réseau

Discussion du problème

D'après mon expérience, définir le nom d'hôte de cette façon, ou via la norme, System Preferences→Sharing→Computer Namene dure que peu de temps. Ceci est généralement <24 heures, mais parfois ComputerNamemême les changements immédiatement pour avoir un nombre suffixé entre parenthèses (N). J'ai observé que ce nombre était immédiatement défini sur (4)ou (5)récemment après avoir utilisé les scutil --setcommandes ci-dessus.

La cause de ce comportement est due à l'exécution de code démon sous Mac OS qui tente d'ajouter un suffixe numéroté (N)chaque fois que le même nom d'hôte est trouvé sur le réseau. Dans TOUS mes tests, les noms d'hôtes que j'ai choisis n'ont JAMAIS été utilisés auparavant sur le réseau et n'ont en outre JAMAIS été utilisés pour des appareils Bluetooth.

La véritable cause du «déclencheur» de ce comportement est inconnue et non vérifiée. C'est-à-dire: à travers toutes mes recherches en ligne et mes tests, je n'ai pas pu déterminer définitivement pourquoi Mac OS décide que le nom est déjà utilisé alors qu'il n'est clairement PAS et qu'il ne l'a jamais été.

Ma théorie est qu'en quelque sorte mDNSégalement connu sous le nom de Bonjour( Avahipour les utilisateurs de Linux ou pour les utilisateurs de Zero-confréseau pour Windows) peut être en partie à blâmer. D'une manière ou d'une autre, le nom d'hôte précédent du Macbook ou du périphérique Apple est conservé quelque part mDNS, ou peut-être une forme d' ARPinformations de table + nom d'hôte qui est découverte et stockée par le Macbook ou le périphérique Apple. Cela pourrait être une sorte de condition de concurrence. D'une manière ou d'une autre, l'entrée est considérée comme dupliquée et déclenche le comportement de changement de nom du suffixe Mac OS.

Le nombre de noms d'hôtes suffixés est visible lorsque vous utilisez l' utilitaire de découverte de service DNS fourni par Apple dns-sd:

Par exemple, en utilisant le nom d'hôte my-mbp-hostname, il peut apparaître comme les entrées suivantes

dns-sd -Z _ssh._tcp
; To direct clients to browse a different domain, substitute that domain in place of '@'
lb._dns-sd._udp                                 PTR     @

; In the list of services below, the SRV records will typically reference dot-local Multicast DNS names.
; When transferring this zone file data to your unicast DNS server, you'll need to replace those dot-local
; names with the correct fully-qualified (unicast) domain name of the target host offering the service.

_ssh._tcp                                       PTR     my-mbp-hostname\032(5)._ssh._tcp
my-mbp-hostname\032(5)._ssh._tcp                           SRV     0 0 22 my-mbp-hostname.local. ; Replace with unicast FQDN of target host
my-mbp-hostname\032(5)._ssh._tcp                           TXT     ""

[...SNIP...]
[...OTHER SSH HOSTS HERE...]
[...SNIP...]

La théorie de la véritable cause n'est pas confirmée car il est difficile de trouver et d'observer ce qui se passe réellement sans accès à l'état interne de Mac OS et aux outils de débogage Apple OS de bas niveau. Les interactions entre mdnsd, mDNSResponderet mDNSResponderHelperavec d'autres services Mac OS ou même d'autres démons Avahi sur le réseau ne sont pas bien documentées ou facilement observables. L'état actuel de certaines formes de découverte de réseau peut être visualisé à travers dns-sdet arp -aou peut-être arp -a -n. D'autres théories ou lieux potentiels où ces informations de nom d'hôte peuvent être stockées pourraient être:

• Les noms des appareils Bluetooth sont conservés quelque part par le système d'exploitation
• Informations SMB (partage de fichiers Windows) mises en cache périodiquement à partir du réseau par smbd( /System/Library/LaunchDaemons/com.apple.smbd.plist)
• Informations de partage AFP mises en cache depuis le réseau (également probablement par smbd?)
• mDNS/ Avahiréflecteur (ou autre type de rediffusion de paquets Bonjour / zero-conf sur le réseau par un routeur ou un autre appareil)?
  • Pourrait être mis en cache par mDNSResponderou mdnsd( /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist)

Solution (espace réservé)

Au 6 octobre 2017, il n'y avait toujours pas de solution complète d'Apple ni de solution pour éviter que ce problème ne se reproduise. Je recommande de déposer un rapport de bogue auprès d'Apple décrivant ce problème. Vous pouvez également contacter le service client Apple .

Plus il y a de gens qui font du bruit à propos de ce problème ennuyeux, plus les chefs de produit Apple accordent la priorité aux ingénieurs afin qu'ils puissent le résoudre.

Débogage / Lignes d'investigation futures

Cette discussion du forum MacRumors contient des informations utiles ainsi que l'ajout d'une théorie selon laquelle le Wake for Wi-Fi Network Accessréveil / sommeil de l'appareil a quelque chose à voir avec ce problème. Les autres théories présentées concernent l'utilisation de plusieurs adaptateurs réseau (par exemple: WiFi + Thunderbolt Ethernet), des routeurs qui ont plusieurs points d'accès annoncés sur plusieurs bandes, comme sur 802.11 b/g/n(2,4 GHz) ou 802.11 a/ac(5 GHz). Ces combinaisons peuvent provoquer une version "fantôme" de l'appareil Apple sur le réseau temporairement, déclenchant le comportement de changement de nom.

Il n'y avait pas de lignes de journaux utiles dans /var/log/system.logqui semblaient liés à ce comportement de changement de nom déclenchée. Soi-disant mDNSResponderpeut être configuré à des niveaux de journal plus élevés:

• Erreur - Messages d'erreur
• Avertissement - Opérations initiées par le client
• Remarque - Opérations du proxy de mise en veille
• Info - Messages d'information

Comment définir ces niveaux de débogage autrement que peut-être via un fichier inexistant /Library/Preferences/com.apple.mDNSResponder.plistn'était pas clair. Je n'avais pas d'exemple de configuration plist à utiliser, donc je n'ai pas pu obtenir d'informations de journalisation supplémentaires mDNSResponder.

Des outils tels que Wireshark pourraient être utiles pour montrer les mDNSpaquets diffusés sur le réseau avec d'autres informations de paquets ARP potentiellement pertinentes parmi d'autres trafics.

Sous Mac OS, d'autres outils tels que ceux dscacheutilqui existent peuvent afficher ces informations. Il n'est pas bien documenté ou clair comment afficher le cache définitif de ces informations qui est utilisé par le code de changement de nom d'hôte. Lorsque j'ai testé cet utilitaire, il n'a produit aucune sortie utile, sauf lors de l'utilisation du mode de requête pour le nom d'hôte exact (adresses IP nettoyées pour la confidentialité):

sudo dscacheutil -cachedump -entries host
Unable to get details from the cache node
sudo dscacheutil -cachedump
Unable to get details from the cache node
dscacheutil -cachedump
Unable to get details from the cache node
dscacheutil -cachedump -entries host
Unable to get details from the cache node

dscacheutil -q host -a name my-mbp-hostname.local
name: my-mbp-hostname.local
ipv6_address: fe80:4::1a:1234:abcd:ef01
ipv6_address: 2601:280:1b00:1234:567:abcd:ef01:1234

name: my-mbp-hostname.local
ip_address: 192.168.1.123

Utilisez-vous deux périphériques réseau qui se trouvent sur le même réseau local? Par exemple, wifi et ethernet filaire? Essayez de désactiver l'un d'eux. J'avais l'habitude d'avoir ce problème et de le résoudre de cette façon.

Même problème ici. Mais il semble que le nom foo (2) soit accepté par Time Machine et qu'il effectue toujours la sauvegarde au même endroit (il ne semble pas refaire toute la sauvegarde, il continue). Donc pas de mal, pas de faute. Je pense que cela est lié à plusieurs interfaces actives, j'ai fait apparaître Ethernet pour accélérer ma sauvegarde.

Il n'y a aucun bon moyen d'arrêter cela. Apple devrait remplacer le code du nom d'hôte afin que les utilisateurs (personnes et programmes) soient toujours présentés avec le nom d'hôte défini par scutilet effectuent tous les renommages / traductions sous le capot.

Étant donné que cela se produit dans toutes les gammes de produits Apple (Apple TV, iPhone, Mac et probablement même l'Apple Watch) depuis 2012 au moins, il n'est pas clair que Apple considère cela comme un problème à résoudre.

Cela est probablement dû à l'utilisateur qui est actif lorsque vous rejoignez le réseau et configurez la machine pour la première fois. Il est probable que lorsque vous construisez ces machines, vous le faites toujours en tant que même utilisateur

Si vous créez un utilisateur, par exemple dave on, par exemple un MacBook Pro, la machine configurera automatiquement la dénomination comme suit:

Nom de l'ordinateur: MacBook Pro de Dave

nom d'hôte local: daves-MacBook-Pro.local

et dans Terminal, le nom d'hôte s'affichera comme: daves-mbp

En supposant que la prochaine machine à laquelle vous vous connectez en tant que `` dave '' est également un MacBook Pro, il définira exactement les mêmes détails - vous vous connectez au réseau et vous obtenez le message sur le nom en double.

Là où je travaille, nous changeons le nom dans le partage, puis ouvrons un terminal et exécutons la commande suivante: sudo scutil –-set HostName new_hostname

(où new_hostname est le nom que vous avez choisi)

Ensuite, quittez et redémarrez le terminal et vous verrez le nouveau nom d'hôte.

Vous obtiendrez également ce problème lors de la migration des utilisateurs vers de nouvelles machines - l'assistant de migration / Time Machine renommera la nouvelle machine

quelques informations généralement faibles sur les noms - http://support.apple.com/kb/PH13790

Cela se produit lors de l'exécution de deux serveurs DHCP qui se chevauchent. Si vous utilisez plus d'un routeur (mode pont), assurez-vous qu'un seul d'entre eux exécute DHCP sans IP statique.