Jak zatrzymać automatyczną i niepoprawną zmianę nazwy mojego komputera?

Od kiedy zaktualizowałem swój iMac 2009 do Mavericks, często pojawia się komunikat „Nazwa twojego komputera„ Foo ”jest już używana w tej sieci. Nazwa została zmieniona na „Foo (2)”. ”. Liczba na końcu będzie stale zwiększać się w czasie, gdy ten sam błąd będzie się powtarzał.

Zmiana nazwy komputera z powrotem jest wystarczająco trywialna, ale czy istnieje sposób, aby temu zapobiec w przyszłości? Miałem starego Macbooka Pro (z systemem Mountain Lion), który miał ten sam problem, ale wydaje mi się, że mój wczesny MBP z systemem Mavericks z 2013 roku nie cierpi z tego powodu.

Obejście

Podobnie jak inni użytkownicy, nękają mnie te irytacje, ale znalazłem częściowo zadowalające obejście:

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

Po uruchomieniu tego polecenia możesz sprawdzić, czy wszystkie miejsca, w których przechowują nazwę hosta, są takie same za pomocą tego linku:

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

Jeśli Macbook od razu zmienia nazwę ComputerNamez przyrostkiem, być może uda się go zatrzymać, wyłączając Wake for Network Access.

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

Po wyłączeniu zmień nazwę komputera za pomocą powyższych poleceń, aby zakończyć. Możesz także spróbować wymusić ComputerNameodpowiedź za pomocą System Preferences→Sharing→Computer Namepreferencji pola tekstowego.

Jeśli to nie pomogło, spróbuj wyczyścić pamięć podręczną 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

Po opróżnieniu pamięci podręcznej mDNS spróbuj ponownie zmienić nazwę komputera, korzystając z powyższych poleceń.

Jeśli to nadal nie działało, spróbuj zabić mDNSResponderusługę:

sudo killall -HUP mDNSResponder

Następnie spróbuj ponownie, aby zresetować nazwę komputera za pomocą powyższych scutilpoleceń.

Jeśli okaże się, że nic z tego nie działa, istnieje kilka innych zgłoszonych rozwiązań, które obejmują:

• Upewnij się, że masz tylko jedno połączenie z siecią lokalną

• Wyłącz Bonjour i włącz go ponownie

  # 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
  

• Zamknij i zresetuj CAŁY sprzęt sieciowy

Dyskusja o problemie

Z mojego doświadczenia wynika, że ​​ustawienie nazwy hosta w ten sposób lub poprzez standard System Preferences→Sharing→Computer Nametrwa tylko przez krótki czas. Zazwyczaj jest to <24 godziny, ale czasami ComputerNamenawet parzystość zmienia się natychmiast, tak aby liczba w nawiasach była powiększona (N). Zauważyłem, że po użyciu powyższych poleceń liczba ta została natychmiast ustawiona na jedną (4)lub (5)niedawno scutil --set.

Przyczyna tego zachowania wynika z działania jakiegoś kodu demona w systemie Mac OS, który próbuje dodać numeryczny sufiks za (N)każdym razem, gdy w sieci zostanie znaleziona ta sama nazwa hosta. We WSZYSTKICH moich testach wybrane przeze mnie nazwy hostów NIGDY nie były wcześniej używane w sieci, a ponadto NIGDY nie były używane również w przypadku jakichkolwiek urządzeń Bluetooth.

Prawdziwa przyczyna „wyzwalacza” tego zachowania jest nieznana i niezweryfikowana. Innymi słowy: przez wszystkie moje badania online i testy nie byłem w stanie definitywnie ustalić, dlaczego Mac OS decyduje, że nazwa jest już używana, kiedy wyraźnie NIE jest i nigdy nie była.

Moja teoria jest taka, że ​​jakoś ( mDNSjak dla użytkowników Linuksa lub Networking dla użytkowników Windows) można częściowo winić. W jakiś sposób wcześniejsza nazwa hosta Macbooka lub urządzenia Apple zostaje utrwalona gdzieś w innym miejscu , a może jakaś forma tabeli i informacji o nazwie hosta, które są wykrywane i przechowywane przez Macbooka lub urządzenie Apple. To może być jakiś warunek wyścigu. W jakiś sposób pozycja jest postrzegana jako zduplikowana i wyzwala zachowanie zmiany nazwy sufiksu Mac OS.BonjourAvahiZero-confmDNSARP

Liczba przyrostek nazwy hostów są widoczne podczas używania Jabłko warunkiem DNS Service Discovery narzędzia dns-sd:

Na przykład przy użyciu nazwy hosta my-mbp-hostnamemoże wyglądać jak poniższe wpisy

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

Teoria prawdziwej przyczyny jest niepotwierdzona, ponieważ trudno jest znaleźć i zaobserwować, co się właściwie dzieje bez dostępu do wewnętrznych narzędzi do debugowania stanu systemu Mac OS i niskiego poziomu systemu Apple OS. Interakcje pomiędzy mdnsd, mDNSResponderoraz mDNSResponderHelperz innymi usługami Mac OS lub nawet innych demonów avahi w sieci nie są dobrze udokumentowane i łatwo obserwowalne. Obecny stan niektórych form wykrywania sieci może być przeglądany przez, dns-sda arp -amoże i arp -a -n. Inne teorie lub potencjalne miejsca, w których mogą być przechowywane te informacje o nazwie hosta, mogą być:

• Nazwy urządzeń Bluetooth utrwalone gdzieś w systemie operacyjnym
• Informacje SMB (udostępnianie plików systemu Windows) okresowo buforowane z sieci przez smbd( /System/Library/LaunchDaemons/com.apple.smbd.plist)
• Informacje o udostępnianiu AFP buforowane z sieci (prawdopodobnie także przez smbd?)
• mDNS/ Avahireflektor (lub inny rodzaj ponownej emisji pakietów Bonjour / zero-conf w sieci przez router lub inne urządzenie)?
  • Może być buforowany przez mDNSResponderlub mdnsd( /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist)

Rozwiązanie (symbol zastępczy)

Na dzień 6 października 2017 r. Nadal nie ma pełnego rozwiązania ze strony Apple ani rozwiązania, które zapobiegałoby ponownemu wystąpieniu tego problemu. Polecam złożenie raportu o błędach w Apple opisującego ten problem. Możesz również skontaktować się z obsługą klienta Apple .

Im więcej osób będzie hałasować z powodu tego irytującego problemu, tym szybciej menedżerowie produktów Apple będą traktować priorytetowo, aby inżynierowie mogli to naprawić.

Debugowanie / Przyszłe linie dochodzenia

Ta dyskusja na forum MacRumors zawiera kilka użytecznych informacji, a także dodanie teorii, że Wake for Wi-Fi Network Accessi urządzenie Wake / Sleep ma coś wspólnego z tym problemem. Inne przedstawione teorie dotyczą używania wielu kart sieciowych (np .: WiFi + Thunderbolt Ethernet), routerów z wieloma punktami dostępu reklamowanymi w wielu pasmach, takich jak 802.11 b/g/n(2,4 GHz) lub 802.11 a/ac(5 GHz ). Te kombinacje mogą spowodować, że „widmowa” wersja urządzenia Apple pojawi się w sieci w jakiś sposób tymczasowo, powodując zachowanie zmiany nazwy.

Nie było żadnych użytecznych wiersze dziennika w /var/log/system.logktóry pojawił związane z tym zachowanie zmiana nazwy jest wyzwalany. Podobno mDNSRespondermożna go skonfigurować na wyższe poziomy dziennika:

• Błąd - komunikaty o błędach
• Ostrzeżenie - operacje inicjowane przez klienta
• Uwaga - Operacje proxy uśpienia
• Informacje - wiadomości informacyjne

Sposób ustawienia tych poziomów debugowania innych niż być może przez nieistniejący plik /Library/Preferences/com.apple.mDNSResponder.plistnie był jasny. Nie miałem do użycia przykładowej konfiguracji plist, więc nie mogłem uzyskać żadnych dodatkowych informacji logowania mDNSResponder.

Narzędzia takie jak Wireshark mogą być przydatne do pokazywania mDNSpakietów transmitowanych w sieci wraz z innymi potencjalnie istotnymi informacjami o pakietach ARP między innymi ruchem.

W systemie Mac OS dscacheutilmogą być dostępne inne narzędzia do wyświetlania tych informacji. Nie jest dobrze udokumentowane ani jasne, jak wyświetlić ostateczną pamięć podręczną tych informacji, które są używane przez kod zmiany nazwy hosta. Kiedy przetestowałem to narzędzie, nie wygenerowało ono żadnych użytecznych danych wyjściowych, z wyjątkiem trybu zapytania o dokładną nazwę hosta (adresy IP oczyszczone w celu zachowania prywatności):

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

Czy używasz dwóch urządzeń sieciowych, które są w tej samej sieci LAN? Na przykład Wi-Fi i przewodowy Ethernet? Spróbuj wyłączyć jeden z nich. Miałem ten problem i naprawiłem go w ten sposób.

Mam ten sam problem. Wygląda jednak na to, że nazwa foo (2) jest akceptowana przez wehikuł czasu i nadal wykonuje kopię zapasową w tym samym miejscu (wydaje się, że nie przywraca całej kopii zapasowej, kontynuuje). Więc bez szkody, bez faulu. Myślę, że jest to związane z wieloma aktywnymi interfejsami. Podłączyłem sieć Ethernet, aby przyspieszyć tworzenie kopii zapasowej.

Nie ma dobrego sposobu na powstrzymanie tego. Apple musiałoby zastąpić kod dla nazwy hosta, aby użytkownicy (ludzie i programy) zawsze otrzymywali nazwę hosta ustawioną przez użytkownika scutili przeprowadzali całą zmianę nazwy / tłumaczenia pod maską.

Ponieważ dzieje się tak we wszystkich liniach produktów Apple (Apple TV, iPhone, Mac i przypuszczalnie nawet Apple Watch) przynajmniej od 2012 roku, nie jest jasne, że Apple postrzega to jako problem do rozwiązania.

Prawdopodobnie ma to związek z użytkownikiem, który jest aktywny po dołączeniu do sieci i skonfigurowaniu urządzenia po raz pierwszy. Jest prawdopodobne, że budując te maszyny, zawsze robisz to jako ten sam użytkownik

Jeśli utworzysz użytkownika, np. Dave on, na przykład MacBook Pro, urządzenie automatycznie skonfiguruje nazewnictwo w następujący sposób:

Nazwa komputera: dave's MacBook Pro

lokalna nazwa hosta: daves-MacBook-Pro.local

a w terminalu nazwa hosta będzie wyświetlana jako: daves-mbp

Zakładając, że następna maszyna, na którą zalogujesz się jako „dave”, to także MacBook Pro, ustawią dokładnie te same szczegóły - połączysz się z siecią i otrzymasz wiadomość o zduplikowanej nazwie.

Tam, gdzie pracuję, zmieniamy nazwę w Udostępnianiu, a następnie otwieramy terminal i uruchamiamy następującą komendę: sudo scutil –-set nazwa_hosta nowa_nazwa hosta

(gdzie new_hostname to wybrane przez Ciebie imię)

Następnie zamknij i uruchom ponownie terminal, a zobaczysz nową nazwę hosta.

Ten problem pojawi się również podczas migracji użytkowników na nowe komputery - asystent migracji / Time Machine zmieni nazwę nowego komputera

niektóre zazwyczaj słabe informacje o nazwach - http://support.apple.com/kb/PH13790

Dzieje się tak, gdy działają dwa nakładające się serwery DHCP. Jeśli używasz więcej niż jednego routera (tryb mostka), upewnij się, że tylko jeden z nich działa DHCP bez statycznego adresu IP.