Como faço para impedir que o nome do meu computador seja alterado automaticamente e incorretamente?

Desde que atualizei meu iMac 2009 para o Mavericks, muitas vezes recebo uma mensagem informando 'O nome do seu computador "Foo" já está em uso nesta rede. O nome foi alterado para "Foo (2)". '. O número no final aumentará continuamente ao longo do tempo, pois o mesmo erro continua acontecendo.

É trivial o suficiente para renomear o computador novamente, mas existe uma maneira de impedir que isso aconteça no futuro? Eu tinha um antigo Macbook Pro (executando o Mountain Lion) que tinha o mesmo problema, mas meu MBP do início de 2013 executando o Mavericks não parece estar sofrendo com esse problema.

Gambiarra

Como outros usuários, sou atormentado por esse aborrecimento, mas encontrei uma solução alternativa semi-satisfatória:

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

Após executar este comando, você pode verificar se todos os locais onde eles armazenam o nome do host são os mesmos com esta linha única:

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

Se o Macbook continuar renomeando imediatamente de ComputerNamevolta com um sufixo, você poderá fazê-lo parar ao desligar Wake for Network Access.

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

Uma vez desligado, renomeie sua máquina usando os comandos acima para concluir. Você também pode tentar forçar a ComputerNamevolta usando a System Preferences→Sharing→Computer Namepreferência do campo de texto.

Se isso não ajudou, tente liberar o 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

Após liberar o cache mDNS, tente renomear sua máquina usando os comandos acima.

Se isso ainda não funcionar, tente matar o mDNSResponderserviço:

sudo killall -HUP mDNSResponder

Em seguida, tente novamente para redefinir o nome do computador usando os scutilcomandos acima .

Se você achar que nada disso está sendo bom, existem outras soluções relatadas que incluem:

• Verifique se você possui apenas uma conexão com a rede local

• Desligue e ligue o 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
  

• Desligar e redefinir TODO o hardware de rede

Discussão do problema

Na minha experiência, definir o nome do host dessa maneira ou através do padrão System Preferences→Sharing→Computer Namedura apenas um curto período de tempo. Isso geralmente é <24 horas, mas às vezes o ComputerNamepar muda imediatamente para ter um número com sufixo entre parênteses (N). Observei que esse número foi definido imediatamente (4)ou (5)recentemente após o uso dos scutil --setcomandos acima.

A causa desse comportamento ocorre devido a algum código de daemon em execução no Mac OS, que tenta adicionar um sufixo numerado (N)sempre que o mesmo nome de host é encontrado na rede. Em TODOS os meus testes, os nomes de host que eu escolhi NUNCA foram usados ​​antes na rede e NUNCA foram usados ​​também para qualquer dispositivo Bluetooth.

A verdadeira causa do "gatilho" desse comportamento é desconhecida e não verificada. Ou seja: Através de todas as minhas pesquisas e testes on-line, não consegui determinar definitivamente por que o Mac OS decide que o nome já está sendo usado quando claramente NÃO é e nunca foi.

Minha teoria é que, de alguma forma, mDNStambém conhecido como Bonjour( Avahipara usuários de Linux ou Zero-confNetworking para usuários de Windows) pode ser parcialmente culpado. De alguma forma, o nome do host anterior do dispositivo Macbook ou Apple é mantido em algum lugar mDNS, ou talvez alguma forma de ARPinformação da tabela + nome do host é descoberta e armazenada pelo dispositivo Macbook ou Apple. Isso pode ser algum tipo de condição de corrida. De alguma forma, a entrada é vista como duplicada e aciona o comportamento de renomeação do sufixo do Mac OS.

O número de nomes de host com sufixo é visível ao usar o utilitário DNS Service Discovery fornecido pela Apple dns-sd:

Por exemplo, usando o nome do host my-mbp-hostname, ele pode aparecer como as seguintes entradas

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

A teoria da verdadeira causa não é confirmada, pois é difícil encontrar e observar o que realmente está acontecendo sem acesso ao estado interno do Mac OS e às ferramentas de depuração de baixo nível do Apple OS. As interações entre mdnsd, mDNSRespondere mDNSResponderHelpercom outros serviços do Mac OS ou até outros daemons da Avahi na rede não são bem documentadas ou facilmente observáveis. O estado atual de algumas formas de descoberta de rede pode ser visualizado através dns-sde arp -aou talvez arp -a -n. Outras teorias ou locais em potencial onde essas informações de nome de host podem ser armazenadas podem ser:

• Os nomes de dispositivos Bluetooth persistiram em algum lugar do SO
• Informações SMB (compartilhamento de arquivos do Windows) armazenadas em cache da rede periodicamente por smbd( /System/Library/LaunchDaemons/com.apple.smbd.plist)
• Informações de compartilhamento do AFP armazenadas em cache da rede (também presumivelmente por smbd?)
• mDNS/ Avahireflector (ou outro tipo de retransmissão de pacotes Bonjour / zero-conf na rede por um roteador ou outro dispositivo)?
  • Pode ser armazenado em cache por mDNSResponderou mdnsd( /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist)

Solução (espaço reservado)

A partir de 6 de outubro de 2017, ainda não havia uma solução ou solução completa da Apple para impedir que esse problema ocorra novamente. Eu recomendo arquivar um relatório de bug na Apple descrevendo esse problema. Você também pode entrar em contato com o Suporte ao cliente Apple .

Quanto mais pessoas fizerem barulho sobre esse problema irritante, mais rápido os gerentes de produto da Apple priorizarão para que os engenheiros possam corrigi-lo.

Depuração / futuras linhas de investigação

Esta discussão no fórum MacRumors tem algumas informações úteis, além de adicionar uma teoria de que o Wake for Wi-Fi Network Accessdispositivo Wake / Sleep tem algo a ver com esse problema. Outras teorias apresentadas têm a ver com o uso de vários adaptadores de rede (por exemplo: WiFi + Thunderbolt Ethernet), roteadores que possuem vários pontos de acesso anunciados em várias bandas, como em 802.11 b/g/n(2,4 GHz) ou 802.11 a/ac(5 GHz). Essas combinações podem fazer com que uma versão "fantasma" do dispositivo Apple seja exibida temporariamente na rede de alguma forma, acionando o comportamento de renomeação.

Havia há linhas de registo úteis em /var/log/system.logque apareceu relacionadas com este comportamento renomeação sendo acionado. Supostamente mDNSResponderpode ser configurado para níveis mais altos de log:

• Erro - mensagens de erro
• Aviso - Operações iniciadas pelo cliente
• Aviso - Operações de proxy de suspensão
• Info - Mensagens informativas

Como definir esses níveis de depuração além de talvez por um arquivo inexistente /Library/Preferences/com.apple.mDNSResponder.plistnão estava claro. Eu não tinha um exemplo de configuração do plist para usar, então não consegui obter nenhuma informação extra de log mDNSResponder.

Ferramentas como o Wireshark podem ser úteis para mostrar mDNSpacotes sendo transmitidos na rede, juntamente com outras informações de pacotes ARP potencialmente relevantes, entre outros tráfegos.

No Mac OS, outras ferramentas, como dscacheutilpodem existir, para exibir essas informações. Não está bem documentado ou claro como visualizar o cache definitivo dessas informações, que é usado pelo código de renomeação do nome do host. Quando testei esse utilitário, ele não produziu nenhuma saída útil, exceto ao usar o modo de consulta para o nome do host exato (IPs eliminados por privacidade):

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

Você está usando dois dispositivos de rede que estão na mesma LAN? Por exemplo, wifi e ethernet com fio? Tente desativar um deles. Eu costumava ter esse problema e o corrigia dessa maneira.

Mesmo problema aqui. Mas parece que o nome foo (2) é aceito pela máquina do tempo e ainda faz o backup no mesmo local (parece não refazer o backup inteiro, continua). Portanto, não há mal nenhum, falta. Eu acho que está relacionado a várias interfaces ativas, eu abri a Ethernet para acelerar meu backup.

Não há uma boa maneira de parar isso. A Apple precisaria substituir o código do nome do host para que os usuários (pessoas e programas) sempre apresentem o nome do host definido por scutile faça toda a renomeação / tradução sob o capô.

Como isso acontece em todas as linhas de produtos da Apple (Apple TV, iPhone, Mac e presumivelmente até o Apple Watch) desde 2012, pelo menos, não está claro se a Apple vê isso como um problema a ser corrigido.

Provavelmente, isso tem a ver com o usuário que está ativo quando você ingressa na rede e configura a máquina pela primeira vez. É provável que, ao criar essas máquinas, você sempre o faça como o mesmo usuário

Se você criar um usuário, por exemplo, dave on, por exemplo, um MacBook Pro, a máquina configurará automaticamente a nomeação da seguinte maneira:

Nome do Computador: dave's MacBook Pro

nome do host local: daves-MacBook-Pro.local

e no Terminal, o nome do host será exibido como: daves-mbp

Supondo que a próxima máquina em que você se conecte como 'dave' também seja um MacBook Pro, ela definirá exatamente os mesmos detalhes - você se conectará à rede e receberá a mensagem sobre o nome duplicado.

Onde trabalho, alteramos o nome no compartilhamento, abrimos um terminal e executamos o seguinte comando: sudo scutil –-set HostName new_hostname

(onde new_hostname é o nome escolhido)

Então saia e reinicie o terminal e você verá o novo nome do host.

Você também terá esse problema ao migrar usuários para novas máquinas - o assistente de migração / time machine renomeará a nova máquina

algumas informações tipicamente fracas sobre nomes - http://support.apple.com/kb/PH13790

Isso ocorre ao executar dois servidores DHCP sobrepostos. Se você estiver usando mais de um roteador (modo de ponte), verifique se apenas um deles está executando o DHCP sem um IP estático.