Как остановить автоматическое и неправильное изменение имени моего компьютера?

С тех пор, как я обновил свой iMac 2009 года до Mavericks, я часто получаю сообщение о том, что «Имя вашего компьютера« Foo »уже используется в этой сети. Имя было изменено на «Foo (2)». '. Число в конце будет постепенно увеличиваться с течением времени, так как продолжает происходить одна и та же ошибка.

Переименовать компьютер достаточно просто, но есть ли способ предотвратить это в будущем? У меня был старый Macbook Pro (под управлением Mountain Lion), у которого была такая же проблема, но моя ранняя версия MBP 2013 года с Mavericks, похоже, не страдает от этой проблемы.

Временное решение

Как и другие пользователи, я страдаю от этого раздражения, но нашел полуудовлетворительный обходной путь:

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

После выполнения этой команды вы можете проверить, что все места, где они хранят имя хоста, одинаковы с этой строкой:

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

Если Macbook продолжает немедленно переименовывать ComputerNameс суффиксом, вы можете остановить его, выключив Wake for Network Access.

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

После выключения переименуйте свою машину, используя команды выше, чтобы закончить. Вы также можете попытаться принудительно ComputerNameвернуться назад, используя System Preferences→Sharing→Computer Nameнастройки текстового поля.

Если это не помогло, попробуйте очистить кэш 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

После очистки mDNS-кэша повторите попытку переименования компьютера с помощью приведенных выше команд.

Если это все еще не работает, попробуйте убить mDNSResponderслужбу:

sudo killall -HUP mDNSResponder

Затем повторите попытку, чтобы сбросить имя компьютера с помощью приведенных выше scutilкоманд.

Если вы обнаружите, что ничего из этого не приносит никакой пользы, есть и другие решения, о которых сообщалось :

• Убедитесь, что у вас есть только одно подключение к локальной сети

• Выключите 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
  

• Выключите и перезагрузите ВСЕ сетевое оборудование

Обсуждение проблемы

По моему опыту, установка имени хоста таким образом или через стандарт System Preferences→Sharing→Computer Nameдлится недолгое время. Обычно это <24 часа, но иногда ComputerNameчетные значения немедленно изменяются, чтобы иметь суффикс в скобках (N). Я заметил, что это число сразу же устанавливается на одно (4)или (5)недавно после использования scutil --setкоманд выше.

Причиной такого поведения является некоторый код демона, работающий в Mac OS, который пытается добавить пронумерованный суффикс (N)каждый раз, когда в сети обнаруживается одно и то же имя хоста. Во всех моих тестах имена хостов, которые я выбрал, НИКОГДА не использовались ранее в сети и, кроме того, НИКОГДА не использовались также для любых устройств Bluetooth.

Истинная причина «триггера» этого поведения неизвестна и не проверена. То есть: в ходе всех моих онлайн-исследований и испытаний я не смог окончательно определить, почему Mac OS решает, что имя уже используется, когда оно явно НЕ и никогда не было.

Моя теория состоит в том, что каким - то образом , mDNSтакже известный как Bonjour( Avahiдля пользователей Linux, или в Zero-confсети для пользователей Windows) могут быть частично виноваты. Каким-то образом прежнее имя хоста устройства Macbook или Apple сохраняется где-то в mDNSили, возможно, в некоторой форме информации ARPтаблицы + имени хоста, которая обнаруживается и сохраняется устройством Macbook или Apple. Это может быть какое-то состояние гонки. Каким-то образом запись рассматривается как дубликат и вызывает поведение переименования суффикса Mac OS.

Числа с суффиксными именами узлов отображаются при использовании служебной программы обнаружения служб DNS, предоставленной Apple dns-sd:

Например, используя имя хоста my-mbp-hostname, оно может отображаться как следующие записи

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...]

Теория истинной причины не подтверждена, так как трудно найти и наблюдать за тем, что происходит на самом деле, без доступа к внутреннему состоянию Mac OS и средствам отладки Apple OS низкого уровня. Взаимодействия mdnsd, mDNSResponderи mDNSResponderHelperс другими службами , Mac OS или даже другими демонами Avahi в сети не очень хорошо документированы и легко наблюдаемые. Текущее состояние некоторых форм обнаружения сети может быть просмотрено dns-sdи / arp -aили возможно arp -a -n. Другие теории или потенциальные места, где может храниться информация об этом имени хоста:

• Имена устройств Bluetooth сохраняются где-то ОС
• Информация SMB (общий доступ к файлам Windows) периодически кэшируется из сети smbd( /System/Library/LaunchDaemons/com.apple.smbd.plist)
• AFP делится информацией, сохраненной в сети (также предположительно smbd?)
• mDNS/ Avahiотражатель (или другой тип ретрансляции пакетов Bonjour / zero-conf по сети маршрутизатором или другим устройством)?
  • Может быть кэширован mDNSResponderили mdnsd( /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist)

Решение (заполнитель)

По состоянию на 6 октября 2017 года от Apple до сих пор нет полного решения или средства, чтобы предотвратить повторение этой проблемы. Я рекомендую подать в Apple отчет об ошибке, описывающий эту проблему. Вы также можете обратиться в службу поддержки Apple .

Чем больше людей будут шуметь по поводу этой надоедливой проблемы, тем быстрее менеджеры по продуктам Apple будут расставлять приоритеты, чтобы инженеры могли ее исправить.

Отладка / Будущие линии исследования

Это обсуждение на форуме MacRumors содержит некоторую полезную информацию, а также добавление теории о том, что Wake for Wi-Fi Network Accessустройство Wake / Sleep как-то связано с этой проблемой. Другие представленные теории касаются использования нескольких сетевых адаптеров (например, WiFi + Thunderbolt Ethernet), маршрутизаторов с несколькими точками доступа, объявленных в нескольких диапазонах, таких как 802.11 b/g/n(2,4 ГГц) или 802.11 a/ac(5 ГГц ). Эти комбинации могут вызвать временное появление в сети «призрачной» версии устройства Apple, что приведет к переименованию.

Там не было никаких полезных линий журнала в /var/log/system.logтом , что , казалось , связанные с этим поведение переименованием быть вызвано. Предположительно mDNSResponderможет быть настроен для более высоких уровней журнала:

• Ошибка - Сообщения об ошибках
• Предупреждение - инициированные клиентом операции
• Обратите внимание - Спящие прокси-операции
• Инфо - Информационные сообщения

Как установить эти уровни отладки, кроме, возможно, через несуществующий файл, /Library/Preferences/com.apple.mDNSResponder.plistбыло не ясно. У меня не было конфигурационного примера plist для использования, поэтому я не смог получить дополнительную информацию о регистрации mDNSResponder.

Такие инструменты, как Wireshark, могут быть полезны для отображения mDNSпакетов, передаваемых по сети, наряду с другой потенциально важной информацией о пакетах ARP среди другого трафика.

В Mac OS могут использоваться другие инструменты, например, dscacheutilдля просмотра этой информации. Недостаточно задокументировано или не ясно, как просмотреть определенный кэш этой информации, который используется кодом переименования имени хоста. Когда я тестировал эту утилиту, она не выдает никаких полезных выходных данных, кроме случаев использования режима запроса для точного имени хоста (IP-адреса очищаются для конфиденциальности):

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

Используете ли вы два сетевых устройства, которые находятся в одной локальной сети? Например, Wi-Fi и проводной Ethernet? Попробуйте отключить один из них. Я имел обыкновение иметь эту проблему и исправил это таким образом.

Та же проблема здесь. Но похоже, что имя foo (2) принимается машиной времени, и оно все еще выполняет резервное копирование в то же место (похоже, оно не восстанавливает всю резервную копию, оно продолжается). Так что без вреда, без фола. Я думаю, что это связано с несколькими активными интерфейсами, я открыл Ethernet для ускорения резервного копирования.

Нет хорошего способа остановить это. Apple придется заменить код имени хоста, чтобы пользователи (люди и программы) всегда были представлены с именем хоста, которое установлено, scutilи делали все переименование / перевод под капотом.

Поскольку это происходит во всех линейках продуктов Apple (Apple TV, iPhone, Mac и, возможно, даже в Apple Watch), по крайней мере с 2012 года, неясно, что Apple рассматривает эту проблему как проблему, которую необходимо решить.

Это, вероятно, связано с пользователем, который активен, когда вы подключаетесь к сети и настраиваете машину в первый раз. Вполне вероятно, что когда вы создаете эти машины, вы всегда делаете это как один и тот же пользователь

Если вы создаете пользователя, например, dave на, например, MacBook Pro, аппарат автоматически настроит именование следующим образом:

Имя компьютера: MacBook Pro Дэйва

локальное имя хоста: daves-MacBook-Pro.local

а в терминале имя хоста будет отображаться как: daves-mbp

Предполагая, что следующая машина, в которую вы войдете как «dave», также MacBook Pro, он будет точно такой же, как вы: вы подключитесь к сети и получите сообщение о повторении имени.

Там, где я работаю, мы меняем имя в Sharing, затем открываем терминал и запускаем следующую команду: sudo scutil –-set HostName new_hostname

(где new_hostname - ваше выбранное имя)

Затем выйдите и перезапустите терминал, и вы увидите новое имя хоста.

Эта проблема также возникает при переносе пользователей на новые машины - помощник по миграции / машина времени переименует новую машину

некоторая обычно слабая информация об именах - http://support.apple.com/kb/PH13790

Это происходит при запуске двух перекрывающихся DHCP-серверов. Если вы используете более одного маршрутизатора (режим моста), убедитесь, что только один из них использует DHCP без статического IP-адреса.