Ubuntu 16.04 sudo w / NIS muito lento, bind (2) portas lotta e continua a conexão lotta entre o servidor de domínio NIS

Question

Ubuntu 16.04 sudo w / NIS muito lento, bind (2) portas lotta e continua a conexão lotta entre o servidor de domínio NIS

#1 resposta do blablabla (1 votos)
#2 resposta do Jon Kuroda (1 votos)

1

O título diz tudo. De qualquer forma, eu acabei de atualizar meu servidor de 14.04 LTS para 16.04 LTS e percebi que o sudo é executado muito mais lento que o 14.04.

Eu me esforcei e obtive o seguinte resultado:

$ sudo strace sudo true

---------------------------- snip -------------------------------

...
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 9
bind(9, {sa_family=AF_INET, sin_port=htons(722), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
bind(9, {sa_family=AF_INET, sin_port=htons(723), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
bind(9, {sa_family=AF_INET, sin_port=htons(724), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
bind(9, {sa_family=AF_INET, sin_port=htons(725), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
bind(9, {sa_family=AF_INET, sin_port=htons(726), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
bind(9, {sa_family=AF_INET, sin_port=htons(727), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
bind(9, {sa_family=AF_INET, sin_port=htons(728), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
bind(9, {sa_family=AF_INET, sin_port=htons(729), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
bind(9, {sa_family=AF_INET, sin_port=htons(730), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
bind(9, {sa_family=AF_INET, sin_port=htons(731), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
bind(9, {sa_family=AF_INET, sin_port=htons(732), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
bind(9, {sa_family=AF_INET, sin_port=htons(733), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
bind(9, {sa_family=AF_INET, sin_port=htons(734), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
bind(9, {sa_family=AF_INET, sin_port=htons(735), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
bind(9, {sa_family=AF_INET, sin_port=htons(736), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
bind(9, {sa_family=AF_INET, sin_port=htons(737), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
bind(9, {sa_family=AF_INET, sin_port=htons(738), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
bind(9, {sa_family=AF_INET, sin_port=htons(739), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
...

---------------------------- snip -------------------------------

O próprio comando sudo foi bem-sucedido, demorou muito tempo, como 5 segundos.

O intervalo de porta é 512-1023, parece que ele tenta ligar a porta de privilégio para algo como garantir que está tendo privilégio de superusuário.

E após o sucesso do sudo, netstat -an mostra:

---------------------------- snip -------------------------------

...
tcp        0      0 192.168.0.10:959     192.168.0.1:617      TIME_WAIT  
tcp        0      0 192.168.0.10:910     192.168.0.1:617      TIME_WAIT  
tcp        0      0 192.168.0.10:932     192.168.0.1:617      TIME_WAIT  
tcp        0      0 192.168.0.10:34470   192.168.0.1:111      TIME_WAIT  
tcp        0      0 192.168.0.10:966     192.168.0.1:617      TIME_WAIT  
tcp        0      0 192.168.0.10:903     192.168.0.1:617      TIME_WAIT  
tcp        0      0 192.168.0.10:875     192.168.0.1:617      TIME_WAIT  
tcp        0      0 192.168.0.10:45452   192.168.0.1:111      TIME_WAIT  
tcp        0      0 192.168.0.10:970     192.168.0.1:617      TIME_WAIT  
tcp        0      0 192.168.0.10:907     192.168.0.1:617      TIME_WAIT  
tcp        0      0 192.168.0.10:41063   192.168.0.1:111      TIME_WAIT  
tcp        0      0 192.168.0.10:45659   192.168.0.1:111      TIME_WAIT  
tcp        0      0 192.168.0.10:948     192.168.0.1:617      TIME_WAIT  
tcp        0      0 192.168.0.10:50370   192.168.0.1:111      TIME_WAIT  
tcp        0      0 192.168.0.10:56145   192.168.0.1:111      TIME_WAIT  
tcp        0      0 192.168.0.10:929     192.168.0.1:617      TIME_WAIT  
tcp        0      0 192.168.0.10:909     192.168.0.1:617      TIME_WAIT  
tcp        0      0 192.168.0.10:33648   192.168.0.1:111      TIME_WAIT  
tcp        0      0 192.168.0.10:33556   192.168.0.1:111      TIME_WAIT  
tcp        0      0 192.168.0.10:55209   192.168.0.1:111      TIME_WAIT  
tcp        0      0 192.168.0.10:975     192.168.0.1:617      TIME_WAIT  
tcp        0      0 192.168.0.10:969     192.168.0.1:617      TIME_WAIT  
tcp        0      0 192.168.0.10:35903   192.168.0.1:111      TIME_WAIT  
tcp        0      0 192.168.0.10:888     192.168.0.1:617      TIME_WAIT  
...

---------------------------- snip -------------------------------

Onde 192.168.0.10 é o meu servidor e 192.168.0.1 é o servidor NIS.

Quando eu parar o ypbind no meu servidor e executar o sudo , nenhuma ligação mais inútil (2) e nenhum outro TIME_WAIT entre meu servidor e o servidor NIS serão observados.

Não consigo parar o ypbind e quero que meu antigo% ágilsudo volte tão rápido B)

O que posso fazer?

Obrigado

por Taverna Unci 27.04.2016 / 17:02

2 respostas

Sendo iniciado do Ubuntu [fechado] O Ubuntu 16.04 não vê minha interface de áudio externa usb

score 1 · Answer 1

Eu tive o mesmo problema usando grupos e usuários do NIS. Cada autenticação de usuário é dolorosamente lenta. Você também pode tcpdump o tráfego entre o cliente e o servidor NIS e ver uma tempestade incomum de pacotes acontecendo entre os dois por um minuto no meu caso.

fui brincar com a config e tive a ideia de trocar a config a redhat e mudar completamente o comportamento da auth, login, sudo muito rapido. Apenas remova o "+ ::::" do / etc / passwd, / etc / shadow, / etc / group e o arquivo nsswitch.conf para alterar as seguintes linhas:

passwd:         files nis
group:          files nis
shadow:        files nis

Diga-me como é isso.

score 1 · Answer 2

Tivemos o mesmo comportamento após atualizar alguns sistemas para 16.04 LTS. Usamos o modo compat com o NIS para escolher seletivamente via + @ netgroup e + user em / etc / passwd, que do domínio NIS maior pode acessar nossos sistemas.

Meu colega de trabalho - que deve receber todo o crédito, mas não faz o trabalho do StackExchange - encontrou uma solução que permite manter o modo de compatibilidade e a capacidade de usar + @ netgroup e + user em / etc / passwd. Deixe o modo compat para passwd e shadow, mas use "files nis" para o grupo em /etc/nsswitch.conf:

passwd:    compat
shadow:    compat
group:     files nis

"compat" mode para / etc / group é equivalente a "files nis" se tudo que você quer fazer é incluir todo o mapa do grupo NIS.

Estaria interessado em saber se isso funciona para sua situação.