O arquivo hosts no Mountain Lion parou de funcionar de repente

6

Eu usei meu arquivo hosts (localizado em / private / etc / hosts) por vários meses para bloquear sites que causam distração durante o dia de trabalho. Isso funcionou muito bem até agora. Hoje, de repente, parou de funcionar.

Algumas linhas de amostra do arquivo hosts:

127.0.0.1 facebook.com
127.0.0.1 www.facebook.com

Coloquei esse texto no arquivo de hosts seguindo as etapas abaixo:

sudo nano /etc/hosts
wrote the lines above, then ^O to write the file, Enter to confirm the filename and ^X to exit the editor.

Entre o IP do host local e o nome do domínio, eu tenho uma guia. Os finais de linha são estilo Unix (LF), e a parte estranha é que, quando eu uso o comando ping , ele parece fazer o trabalho corretamente:

ping facebook.com
PING facebook.com (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.137 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.122 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.118 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.110 ms
^C
--- facebook.com ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.110/0.122/0.137/0.010 ms

Mas quando tento acessar o facebook.com no Safari ou no Firefox ainda posso acessar o site. Este é também o caso de outro site que eu bloqueei de maneira semelhante. Eu esvaziei o cache para ambos os navegadores, mas isso não resolveu o problema.

O que posso fazer para resolver este problema?

Atualização 1: Agora estou verificando todos os sites que bloqueei e descobri que o comportamento não é consistente em diferentes domínios. Estes são o "time-waster" que estou bloqueando em / private / etc / hosts:

#Block time-killers
127.0.0.1 9gag.com
127.0.0.1 flabber.nl
127.0.0.1 geenstijl.nl
127.0.0.1 dumpert.nl
127.0.0.1 facebook.com
127.0.0.1 www.9gag.com
127.0.0.1 www.flabber.nl
127.0.0.1 www.geenstijl.nl
127.0.0.1 www.dumpert.nl
127.0.0.1 www.facebook.com
##

Todos os sites desta lista fazem ping para 127.0.0.1 , mas 9gag.com e flabber.nl são inacessíveis a qualquer navegador, mas geenstijl.nl , dumpert.nl e facebook.com são alcançáveis.

Eu tentei reiniciar, isso não resolveu o problema. Antes desse problema eu não mudei a configuração do sistema por uma atualização de algum tipo.

Atualização 2: Três horas atrás eu podia acessar facebook.com através do Safari e Firefox, agora eu não posso mais. geenstijl.nl e dumpert.nl ainda estão acessíveis. Eu não mudei nada nas últimas três horas, apenas usei o Word e naveguei na Web com o Safari.

Atualização 3: Agora, quatro horas após a segunda atualização, o arquivo hosts funciona normalmente novamente. No processo de se atrapalhar com o arquivo hosts, removi as entradas que não funcionavam e adicionei-as novamente, uma a uma, testando cada uma depois que ela foi adicionada. Eu não tenho ideia do que estava acontecendo e não posso mais usar o wireshark no tráfego, já que não há nenhum comportamento defeituoso que eu possa observar.

Atualização 4: E o problema está de volta. Os mesmos sites da atualização 1 mostram o comportamento errado.

Atualização 5:
Tudo funciona novamente como deveria. Vou manter as soluções postadas aqui em mente quando encontrar o erro novamente.

    
por Saaru Lindestøkke 18.02.2013 / 12:14

5 respostas

4

A resolução de DNS no OS X deu errado na atualização do Snow Leopard para o Lion. Depois de uma instalação limpa, tudo deve funcionar corretamente, mas se você tiver seguido a rota de atualização, as coisas podem ficar descontroladas.

Opção 1: endereçamento IPv6

Muitos sites e ISPs oferecem suporte a IPv6 se o IPv4 estiver inacessível. Coloque as definições no começo do seu /etc/hosts assim:

# Block Facebook IPv4
127.0.0.1   www.facebook.com
127.0.0.1   facebook.com

# Block Facebook IPv6
fe80::1%lo0 www.facebook.com
fe80::1%lo0 facebook.com

Opção 2: usar DNSMasq

Se o aviso anterior falhar, você pode instalar o DNSMasq .

    
por 03.09.2013 / 16:25
2

Após qualquer alteração em /etc/hosts run dscacheutil -flushcache na linha de comando para limpar o cache DNS local. Isso funciona para mim todas as vezes, com uma exceção: o Firefox tem seu próprio cache de DNS, então você terá que reiniciá-lo.

    
por 13.08.2013 / 19:50
1

O sistema OSX não usa / etc / hosts para a maioria de suas operações de rede. Na maior parte, os comandos do terminal / linha de comando (coisas do Unixy) usam MAIOR o / etc / hosts, enquanto qualquer coisa do Maccy (!) Usa as tabelas internas do tipo plist em outro lugar.

O uso não é consistente e problemático porque torna o OSX "unix" não-determinístico. Como você descobriu.

Eu não tenho mais um Mac para descobrir exatamente onde o Mac OSX armazena sua emulação do arquivo hosts, mas espero que esta informação aponte para você na direção certa.

Eu sei que vai estar no diretório / Library (e / ou ~ / Library), e os arquivos plist são compactados, então você não pode simplesmente procurar por coisas. O comando 'plutil' pode descompactar / exibir o conteúdo de arquivos .plist (acho que esse é o nome). Talvez comece com um

find ~/Library /Library -iname "*host*" -ls

para ver o que está escondido naquele pântano de complexidade semelhante a janelas.

Não é exatamente unix (netbsd) ... mas não é exatamente ... o que mais você pode chamar (GUI?). Mesmo o Windows é consistente. Talvez errado ... mas consistente.

    
por 25.07.2013 / 03:19
1

Apenas adicionando outro pedaço de vodu aqui. As entradas do meu arquivo hosts no 10.8.2 foram completamente ignoradas pelo sistema até .

  1. Mudei minhas entradas para o topo do arquivo

  2. Eu usei uma única guia para separar o endereço IP e o nome do host

  3. Eu joguei um $ dnscacheutil -flushcache apenas para estar seguro

Eu não pesquisei profundamente por que isso acontece, apenas passando o ritual que resolveu para mim.

    
por 17.10.2013 / 18:39
1

Descobri que no OS X 10.9 o Safari e o Firefox continuavam a acessar os domínios bloqueados até que eu tivesse implementado blocos IPv6 no arquivo etc / hosts. Apenas o Chrome foi afetado pelos bloqueios do IPv4.

    
por 10.10.2014 / 21:35