Recentemente, alterei o arquivo sudoers e o nome do host por meio de /etc/hostname. Depois de alterar esses arquivos, meu comando sudo está demorando muito. Além disso, diz que sudo não consegue resolver o host kaagini (nome do host da minha máquina).
Por que o sudo precisa saber o nome do host para fornecer permissão para algo?
Meu arquivo sudoers possui um comando "Defaults env_reset". Vi algumas perguntas semelhantes, mas o contexto não é um login remoto aqui. O erro está aparecendo em um host local.
A pesquisa inicial sobre o problema diz que o arquivo /etc/hosts deve ter o nome de host real para 127.0.0.1 . Isso resolveu meu problema. Mas minha pergunta real é: por que exigimos isso para o sudo ?? O sudo deve funcionar independentemente do local de login.
Responder1
O /etc/sudoersarquivo foi projetado para poder ser distribuído entre vários servidores. Para fazer isso, cada permissão no arquivo possui uma parte de host.
Geralmente é definido como ALL=o que significa que a permissão é válida para qualquer servidor, mas pode ser definida para hosts específicos:
%sudo kaagini=(ALL) ALL
Para que o sudo saiba se esta regra deve ser aplicada, ele precisa pesquisar o host em que está sendo executado. Ele usa uma chamada que depende de /etc/hostsestar correto, por isso falha se não estiver certo.
Pode-se argumentar que sudonão é necessário se preocupar em fazer uma pesquisa de nome se a parte do host estiver definida ALL=para todas as permissões, mas simplesmente não funciona dessa maneira - parece funcionar onde está a execução antes de processar as regras .
Isso é realmente para facilitar a manutenção, pois o sudo lê apenas /etc/sudoers para ver o que o usuário pode fazer na máquina atual. Mas, como administrador com 100 servidores, isso pode exigir a manutenção de 100 arquivos /etc/sudoers diferentes. Como sudoers tem uma parte de host nas permissões, você pode manter um único arquivo sudoers e distribuí-lo para todas as máquinas, mas ainda assim ter granularidade sobre o que os usuários podem fazer em cada máquina.
Responder2
Graças aorelatório de bug vinculadoarquivado por Matthias Urlichs em outro comentário, o seguinte comando resolveu o problema para mim:
Defaults !fqdn
Coloque esta linha no /etc/sudoersarquivo
Responder3
Fantocheé um software de gerenciamento de configuração capaz de configurar automaticamente uma frota de servidores lendo arquivos Puppet Manifests. Esse arquivo pode incluir uma definição do seu arquivo /etc/sudoers, que pode então ser enviado a todos os "agentes" do seu fantoche "mestre". Então todos os hosts receberão a mesma cópia do seu arquivo /etc/sudoers, que pode (e deve) incluir definições de HOST, para que você possa conceder alguns comandos a alguns usuários.alguns anfitriões(mas não em outros).