Quaisquer casos de uso reais em que NÃO priorizamos arquivos locais em vez de DNS em `nsswitch.conf`

Para simplificar a inicialização do sistema, ele deve ser capaz de resolver seu próprio nome de hostlocalhost , mesmo que a conectividade de rede não esteja disponível. Se esses nomes não forem resolvíveis, você poderá enfrentar vários atrasos na inicialização – o caso clássico é esperar até um minuto na inicialização se não conseguir resolver o Nome de Domínio Totalmente Qualificado do sistema.sendmail

A maneira clássica de fazer isso é colocar fileso primeiro na ordem de prioridade e ter uma entrada /etc/hostsque corresponda ao nome do host do sistema. Mas isso só funciona totalmente se o sistema tiver um endereço IP estático. Uma solução alternativa para sistemas móveis ou que usam DHCP é ter uma /etc/hostsentrada que associe o nome do host do sistema a um endereço de loopback, como 127.0.0.2(sim, .2).

Em sistemas modernos, existem outras maneiras de fazer isso. Algumas distribuições Linux incluem uma glibcbiblioteca de extensão de resolução ( libnss_myhostname.so.2) que permite inserir myhostnamea hosts:linha de /etc/nsswitch.conf. Essa biblioteca resolverá automaticamente localhost, localhost.localdomaine todas as formas (abreviadas ou FQDN) do nome do host local configurado com o(s) endereço(s) IP apropriado(s) - usando um endereço de host local se ainda não houver outras interfaces de rede ativas.

Ah, e observe: os sistemas Unix normalmente diferenciam maiúsculas de minúsculas e, em nsswitch.conf, você deve escrever dnsem minúsculas. Isso ocorre porque, pelo menos no Linux, as palavras-chave nas linhas mapeiam diretamente para nomes de arquivos de biblioteca:

• filesdiz ao sistema para usarlibnss_files.so
• dnsdiz ao sistema para usarlibnss_dns.so
• e assim por diante...

É assim que o GNU glibcimplementa o Name Service Switch; outros sistemas do tipo Unix podem fazer isso de forma diferente.

hosts:          DNS

Quais são os motivos pelos quais eles usam essa configuração?

Talvez o sistema tenha sido projetado como um dispositivo que obtém sua identidade completa e configuração de rede do servidor DHCP, e todos os serviços que ele executa tenham sido cuidadosamente verificados para não precisar de resolução de nome de host até que a rede esteja instalada e funcionando, e o dispositivo esteja documentado para precisar de resolvedores DNS totalmente funcionais e disponíveis o tempo todo, tornando qualquer interrupção em sua disponibilidade um problema de outra pessoa?

Opcional: você conhece algum outro uso divertido, mas não muito conhecido nsswitch.conf?

Que tal modificar as linhas passwd:, e para chamar bibliotecas não padrão, para que o sistema reconheça contas de usuário que não estão presentes em ? E shadow:, ao mesmo tempo, talvez omitir o clássico ou dessas linhas, para que o usual e não sejam usados ​​de fato?group:gshadow:/etc/passwdfilescompat/etc/passwd/etc/group

(Isso seria basicamente como um sistema é integrado a um sistema centralizado de gerenciamento de contas de usuário, como o Active Directory, algum outro sistema de gerenciamento de identidade ou um diretório de usuários LDAP.)

Você deve iniciar o gerenciador de pacotes da sua distribuição Linux e procurar por pacotes com nomes como libnss-*ou nss-*: a maioria deles provavelmente são bibliotecas opcionais do plugin Name Service Switch com vários efeitos. Leia as descrições dos pacotes para descobrir o que cada um deles pode fazer.

(Observação: qualquer pacote com esse nome libnss3-*provavelmente não tem relação: provavelmente se trata do Network Security Services, uma biblioteca SSL/TLS originária da Mozilla. Uma infeliz colisão de siglas.)

Casos de uso para não resolver arquivos primeiro são muito raros. Normalmente, você deseja que o arquivo substitua o servidor DNS se os dois discordarem e deseja um tempo de resposta mais rápido para os arquivos disponíveis.

No entanto, já vi algumas configurações não padronizadas que mudam isso.

Vi um administrador de sistemas optar por inverter a ordem na VM do servidor DNS. O servidor DNS tem seu próprio cliente DNS definido como localhost, e colocar os arquivos por último garante que, quando a VM do servidor tentar resolver um nome de host por motivos próprios, ela nunca discorde do serviço DNS fornecido.

Também vi arquivos removidos dentro de uma imagem do docket como uma solução alternativa para o comportamento esotérico do docker que tenta controlar o arquivo hosts do daemon do docker.

É mais comum remover arquivos de outras coisas controladas pelo nsswitch.conf, como usuários, onde os usuários do sistema operacional são controlados por um host externo.