O uso do cliente NIS no Ubuntu 18.04 trava o Gnome e o Unity

Question

Eu executo clientes NIS no desktop Ubuntu em nossos laboratórios de estudantes. Como parte do nosso projeto de verão, eu instalei o Ubuntu 18.04 em um PC e coloquei o cliente NIS nele. Tudo parecia bem, o domínio está correto, ypwhich , ypcat e yptest todos trabalham com sucesso.

Quando eu logro no entanto usando uma conta NIS (com uma home local ou uma home NFS), tanto o GDM quanto o LightDM (eu tentei os dois) travam e, eventualmente, o X trava. Funciona bem com a conta local e o diretório inicial.

O log de erros mostra apenas esta mensagem:

pam_systemd(sshd:session): failed to create session

Se eu tentar o mesmo login NIS usando apenas um terminal ( Ctrl + Alt + F1 ) eu posso autenticar, mas a sessão congela por aproximadamente 25 segundos antes de me dar um shell bash, o diretório home seja local ou o NFS seja montado corretamente Isso funcionou bem para mim no Ubuntu 16.04, eventualmente. (Eu tive que adicionar a seguinte linha para fazer o systemd iniciar rpc.bind: /bin/systemctl add-wants multi-user.target rpcbind.service .) Eu tentei isso com o Ubuntu 18.04 sem sucesso. Parece que há um atraso entre a autenticação e a criação da sessão que está causando esse problema. Eu baixei e instalei as atualizações mais recentes, etc, e as últimas apt-get de seu etc.

Obrigado pelas respostas. Eu tentei instalar o lightdm e tive um pouco de sucesso com o logon como um usuário do NIS para X. No entanto, eu achei inconsistente para mim, às vezes logando no X, outras vezes o tempo limite, portanto não utilizável em uma situação de laboratório. Eu re-instalei 16.04 novamente e isso trabalhou bem, assim ia deixar isto até isso 18.04 camas um pouco abaixo. Depois de fazer aquele Paulo acabei de ver sua resposta! Vou dar uma olhada em reinstalar 18.04 e voltar Felicidades

Tentei a ponta do Paulos como acima. Infelizmente não consegui mapear os mesmos arquivos de configuração no Ubuntu 18.04 (ou seja, não encontrei um /etc/systemd/system/systemd-login.service.d ou /usr/lib/systemd/system/systemd-logind.service Procurando mais, encontrei um /etc/system/logind.conf. Eu tentei colocar na declaração IPAddressAllow lá (não havia nenhuma menção ou nenhum padrão lá), mas não foi reconhecido. Também tentei inserir meu próprio arquivo .conf no mesmo diretório sem sucesso. Soa muito como os mesmos sintomas, ou pode muito bem ser minha falta de conhecimento aqui. Vou dar outra olhada novamente, mas no momento espero que o Ubuntu possa lançar uma atualização ou patch em breve que classifique este problema

    

Answer 1

Eu também fui afetado por isso e no começo eu também resolvi esse problema comentando

IPAdressDeny=Any em /lib/systemd/system/systemd-logind.service

como muitos outros aqui mencionados antes.

No entanto, além de ser um risco de segurança, isso só funcionará até a próxima atualização do conjunto de ferramentas systemd, como mencionado no Arch-Wiki . O que o wiki não explica muito bem é como estender a configuração do systemd-logind.service de modo que um determinado intervalo de endereços seja permitido e que essas configurações sobrevivam uma atualização. Após algumas leituras na documentação do RHEL (especialmente a seção 10.6.4: Modificando arquivos de unidades existentes ), a seguinte solução funcionou para mim:

1. Crie um novo diretório em /etc/systemd/system/ com o nome exatamente após o serviço que você deseja estender, incluindo um .d . Aqui, isso seria: systemd-logind.service.d

2. Crie um novo arquivo choose_an_appropriate_name.conf (por exemplo, nis_open_network_interface.conf ) dentro do diretório recém-criado com o seguinte conteúdo, que especifica o intervalo IP ou IP que você deseja permitir:

   [Service]
   IPAddressAllow=10.10.0.0/16
   

3. Faça um systemctl daemon-reload

4. E verifique se a nova configuração é realmente parte da sua unidade systemd-logind.service usando systemctl cat systemd-logind.service
5. Por fim, reinicie o serviço systemctl restart systemd-logind.service ( Isso te tirará da sessão do gnome em execução e você terá que fazer o login novamente. )

Não há necessidade de modificar nenhum outro arquivo! Neste ponto, você poderá fazer login novamente com os usuários do NIS, sem precisar congelar o sistema. Porém, esteja ciente de que isso ainda é considerado inseguro (endereços IP na lista de permissões) e que o comportamento de área restrita do systemd-logind é desejado. O NIS / YP é meio desatualizado, mas ainda acho que é usado com tanta frequência. Também pode haver uma solução melhor para isso envolvendo um daemon de cache de nomes usando nscd ou sssd como mencionado neste questão do github systemd lidando com toda a situação. Mas isso está fora do meu alcance no momento.

Esta resposta recolhe todos os bits e peças de posts anteriores e espero esclarecer um pouco para dar uma boa solução para o problema.

Felicidades

    

Answer 2

Eu tive um problema semelhante, atualizei de 17,10 para 18,04. Embora eu pudesse efetuar login com um usuário local, a sessão não durou tanto tempo antes de reiniciar. Eu não consegui entrar com meu usuário nis sem reiniciar o gui.

Ao mudar o gerenciador de exibição para lightdm, consegui contornar o problema.

sudo apt install lightdm
sudo dpkg-reconfigure gdm3

Em seguida, selecione lightdm como seu gerente. Reiniciei e consegui fazer login com meu usuário nis.

Não resolve o tempo que leva para entrar, mas me permite obter um gui.

    

Answer 3

Eu estava enfrentando o mesmo problema em um laboratório que estou configurando para meus alunos. Minha solução provisória era usar 17,10 clientes. Eles funcionam mesmo se o servidor for 18.04.

Mas agora que estou em casa, acabei de encontrar um comentário muito interessante sobre Wiki do Arch Linux . Chama atenção para uma mudança no systemd que ocorreu no dia 10/2017. Parece mesmo que este é o problema. Eles também sugerem uma solução baseada em "Isso pode ser feito criando um novo arquivo .conf dentro do /etc/systemd/system/systemd-logind.service.d/", que coloca listas de permissões no servidor NIS. Só poderei tentar isso na segunda-feira quando eu voltar ao trabalho (ou não resistirei e tentarei pelo ssh). Mas se você tiver acesso ao seu sistema, experimente-o e informe-o.

    

Answer 4

Eu tentei a dica do Paulos, mas há vários problemas com o trabalho descrito quando você segue o link.

A segunda solução eu comecei a trabalhar. Eles só tem o caminho errado para o Ubuntu, o arquivo está aqui:

/lib/systemd/system/systemd-logind.service

Acabei de comentar esta linha:

# IPAddressDeny=any

e depois da reinicialização funcionou.

A primeira solução parece a melhor, mas eu encontrei vários problemas com ela e não consigo entender a sintaxe corretamente. Para começar, o nome está errado, não é um nome válido, então deve ser um link simbólico, não um arquivo real. Cheguei a criar

/lib/systemd/system/open_nis_interface.service

e preenchendo com:

[Service]
IPAddressAllow=10.0.0.0/16

ligando:

mkdir /etc/systemd/system/systemd-logind.service.wants/
ln -s /lib/systemd/system/open_nis_interface.service /etc/systemd/system/systemd-logind.service.wants/

Eu tenho o arquivo sendo carregado, mas minha sintaxe não está correta. O systemd fornece mensagens ok se você executar:

dmesg | grep systemd

Como eu disse, o segundo método de apenas substituir o arquivo de sistema funciona para mim, talvez alguém possa concluir o primeiro método que parece uma solução melhor a longo prazo.

Tom

    

Answer 5

Eu posso confirmar que a segunda solução que Tom menciona agora funciona perfeitamente para mim também (o Hadnt notou o caminho errado - obrigado). Eu também tentei a primeira solução, mas novamente não parece funcionar para mim. Eu também inadvertidamente descobri que o arquivo /etc/systemd/system.conf tem um

IPAddressAllow = (entrada comentada)

Eu tentei colocar minhas entradas na rede interna, por exemplo, (por exemplo, 10.0.0.0/16), mas não parece ter efeito. Sou um novato systemd (vindo do Ubuntu 14.04). Por enquanto a solução 2 é perfeita e eu posso contornar as atualizações, etc, mas vou dar uma olhada na opção 1, se o tempo permitir, ou alguém pode quebrar isso. Graças a um milhão por ajuda pessoal

    

Answer 6

No Ubuntu 18.04 LTS, você deve ser capaz de corrigir seu problema. Basta remover a linha

IPAddressDeny=any

de /lib/systemd/system/systemd-logind.service

Não parece ser o seu caso, dado o que você descreveu, mas tenha cuidado com o diretório home do usuário do NIS que você está tentando conectar, esse usuário deve ter permissão de leitura / gravação para esse diretório, e que em algum momento pode levar algum tempo para se conectar ao servidor NIS.