O suporte do terminal do servidor de Telnet não funciona

Question

Problema do servidor Telnet

Parece que uma atualização recente da Yum (20 de julho de 2016) quebrou o servidor de telnet em uma de nossas VMs. Usando uma conexão SSH com o mesmo servidor funciona bem . Eu estou tentando descobrir onde o problema é exatamente, mas realmente não sei o que estou fazendo, então qualquer ajuda seria apreciada.

Sintomas

Quando fazemos logon no servidor usando o protocolo telnet, obtemos esse tipo de comportamento:

[uniworks@mort ~]$
                   [uniworks@mort ~]$
                                      [uniworks@mort ~]$
                                                         [uniworks@mort ~]$
                                                                            speed 9600 baud; rows 64; columns 80; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke

Como você pode ver, o comando não está sendo ecoado na tela (como ter "stty -echo" ativado), e nós temos esse efeito de "escadaria" ao pressionar Enter.

Talvez, de forma significativa, tenhamos alguns problemas assim que nos conectamos - antes mesmo de fazer login :

Trying 128.222.3.71...
Connected to mort.
Escape character is '^]'.
Scientific Linux release 6.8 (Carbon)
Kernel 2.6.32-504.16.2.el6.x86_64 on an x86_64
ogin:
      Password:
                ast login: Mon Jul 25 12:15:44 from sam
ress the <Backspace> key now:

Como você pode ver, o primeiro caractere de "login:" está faltando e o nome de usuário que eu digitei não foi exibido.

Diagnosticando

Em primeiro lugar, esses sintomas só aparecem quando estamos usando o telnet. Eu tentei usar uma sessão já conectada para outro servidor RHEL 4.7 antigo, em seguida, a partir dessa sessão telnetted para o servidor com o problema. Eu então saí e na mesma sessão eu então ssh'ed ao servidor do problema usando o mesmo nome de usuário, etc. Eu então repeti o processo algumas vezes e os resultados são os mesmos. Portanto, o emulador de telnet, o usuário e outras configurações não são o problema.

Eu verifiquei as configurações TERM e stty depois de logado e eles são quase os mesmos. Na sessão de telnet, a velocidade é definida para 9600 cf. 38400 quando eu uso uma conexão ssh e "stty lnext" é definido como "^ V" cf. "" - nenhum dos quais parece ser significativo. Eu tentei torná-los idênticos apenas no caso, mas isso não faz qualquer diferença.

Quando eu uso a tecla "seta para cima" + Enter para repetir o último comando, o comando é exibido, mas com o primeiro caractere faltando. Se eu digitar "man stty", a página man parece ser exibida bem.

Eu também tentei executar vim em um arquivo de texto e estou recebendo alguns caracteres estranhos, então o problema parece um problema de terminal, mas não tenho certeza porque funciona para conexões ssh ...

Plataforma

Scientific Linux 6x:

[root@mort ~]# cat /etc/redhat-release
Scientific Linux release 6.8 (Carbon)

Algumas versões do pacote:

[root@mort ~]# rpm -q glibc xinetd telnet-server ncurses ncurses-base ncurses-libs
glibc-2.12-1.192.el6.x86_64
xinetd-2.3.14-40.el6.x86_64
telnet-server-0.17-48.el6.x86_64
ncurses-5.7-4.20090207.el6.x86_64
ncurses-base-5.7-4.20090207.el6.x86_64
ncurses-libs-5.7-4.20090207.el6.x86_64

    

Answer 1

Hmmm ... O problema parece ter desaparecido depois que fiz o seguinte:

1. fez outro yum update que instalou o pacote kernel-2.6.32-642.3.1.el6.x86_64 e seu associado kernel-firmware package
2. aplicou a correção universal da Microsoft de alguns anos atrás - eu chutei todo mundo e reiniciei o servidor (VM)

(Também houve atualizações para os pacotes samba4-libs, xorg-x11-drv-ati-firmware, kernel-devel e kernel-headers, mas duvido que algum deles seja significativo.)

Eu posso ver na saída de "last" que eu já havia reinicializado o servidor na mesma manhã em que escrevi essa pergunta, o que me leva a acreditar que a atualização do kernel corrigiu o problema. Os padrões "kernel*" e "*firmware*" são especificamente excluídos do processo de atualização automática na configuração padrão do pacote (coilde% Scientific Linux)%, portanto, se eu tivesse instalado as atualizações manualmente, talvez eu nunca tenha visto o problema. Eu nunca vi esse tipo de comportamento antes, na verdade não me lembro de ter visto nenhum efeito colateral perceptível das atualizações do kernel antes, então é uma novidade para mim.

    

Answer 2

Parece que você ainda tinha um processo em segundo plano conectado ao tty que estava sendo usado para lidar com o seu (novo) login. A reinicialização teria matado esse processo, corrigindo assim o problema.

Outra solução seria determinar o nome do tty afetado (executar tty ) e usar ps -ft {ttyname} para identificar os processos e kill deles.

ps -t $(tty) | awk 'NR>1 {print $1}' | sudo xargs kill -TERM