Helio Loureiro

Hoje fui brindado com essa mensagem ao tentar acessar por ssh uma workstation Sun Ultra 10 que tenho por aqui.  Simplesmente não conseguia conectar por ssh.

helio@shibboleet:~$ ssh ultra10

  Received disconnect from 1.2.3.241: 2: Too many authentication failures for helio

Felizmente o acesso por telnet estava disponível.  Não encontrei nada relacionado à ssh que pudesse estar bloqueando meu acesso.  Mas como estava rodando um programa que testava acesso via ssh para outra máquina, que abria várias threads, imaginei que isso tivesse matado todo os meus max_files_open disponíveis.

Mas mesmo matando todos os processos ssh, continuei com esse problema.

ultra10{root} #: ps -ef | grep -i ssh | awk '{print $2}' | xargs kill -9

Tentei parar o serviço e abrir o ssh em modo de debug: 

ultra10{root} #: svcadm disable ssh

ultra10{root} #: /usr/lib/ssh/sshd -f -dd

Mas também sem nenhuma ajuda claro.  Olhando na Internet achei que era possível arrumar isso alterando o parâmetro " MaxAuthTries".  Editei então o arquivo "/etc/ssh/sshd_config" e deixei as entrada da seguinte forma:

MaxAuthTries    60

MaxAuthTriesLog 30

O ssh voltou a funcionar.  Resta agora descobrir como meu programa com expect e threads causou isso.

Tweet this

Não tem nada mais chato que sistema lento.  Atualmente não dá pra aguentar um sistema que fica cortando a música que se está ouvindo só porque o Firefox consumiu 2 GB de memória, a máquina virtual no VirtualBox tá com mais 2 GB alocados e ainda tá compilando um kernel.

Pois é exatamente o que tem acontecido e muito em Linux.  Não sei de outras distribuições, mas especificamente em Ubuntu.

Como os patches de tempo real foram incluídos na árvore principal do kernel já faz algum tempo, isso deveria estar bem mais amenizado.  Fui em busca de informação sobre como ativar tal função e encontrei o comando "chrt" (change realtime talvez).

Lendo o manual do chrt, é possível ver uma gama de opções sem muitas explicações, nem comparativos de resultados.  Isso não ajuda muito na ampla adoção do mesmo.  Eu acabei fazendo alguns experimentos tanto em Intel 32 bits quanto em 64 e consegui um resultado supreendemente bom e bem fácil.  Apenas adicionei prioridade de tempo real ao processo init.

chrt -r -p 1 1

Esse comando adiciona a política de escalonamento SCHED_RR ao processo ID 1 (init) com prioridade 1. 

A política default do init é SCHED_OTHER, que de acordo com manual - SCHED_SETSCHEDULER(2) - significa:

SCHED_OTHER   política padrão de round-robin baseado em compartilhamento de tempo

SCHED_RR      política round-robin

Olhando mais a fundo o manual do escalonador, é possível ver que somente o SCHED_RR ativa a funcionalidade de tempo real.

Então basta adicionar esse comando no "/etc/rc.local" do Ubuntu/Debian para ter um sistema sem problemas de "travadinhas" quando sobrecarregado.  Eu fiquei mesmo surpreso em como foi fácil melhorar o desempenho do sistema e como isso não é incluído por padrão nos sistemas.

Tweet this

Faz alguns dias, começei a ter o prazer de assistir os vídeos do YouTube em cor-de-rosa:

Principalmente no recente instalado Ubuntu 64 bits.  A princípio achei que era um dos tão mencionados problemas de flash em Linux 64, mas pude ver em alguns fóruns que isso tem afetado todos as versões de Linux pra Intel, tanto de 32 quanto 64 bits.

Consegui amenizar um pouco o problema com as dicas que encontrei aqui:

http://www.webupd8.org/2011/03/fix-pinkred-youtube-videos-bug-using.html

Mas o problema persiste.  Mais uma boa razão pra abandonar logo o flash, que é proprietário e depende unicamente da Adobe pra corrigir.

Tweet this

Já faz algum tempo que comprei uma máquina da STI, Semp Toshiba, do tipo "computador popular". Comprei pelo preço baixo e pelo fato de vir com Linux instalado (um é causa o outro, efeito, mas não sei qual é qual). Isso uns 3 anos atrás. Nunca fui muito adepto de equipamento pré-montado, mas nessa época já estava meio cansado de ficar entrando em boca-de-hardware na Santa Ifigênia pra montar um computador decente.

A grande surpresa foi a qualidade do acabamento do computador: teclado excelente e macio, mouse ótico, entradas de leitor pra cartões de memória (todos os tipos até onde testei), caixas de som com amplificador energizado via USB, 2 GB de RAM, 250 GB de disco SATA e drive gravador de DVD. Realmente um hardware legal (lembre-se que isso foi há 3 anos atrás).

Na época veio com Insigne Linux instalado. Acho que durou uns 5 minutos rodando, o tempo de olhar a cara do sistema, até eu instalar um Ubuntu por cima. Desde então tenho usado o mesmo com Linux 32 bits.

No final do ano passado, por volta de meados de dezembro, só então notei uma mensagem de hardware no boot: EM64T. Sabia que era um Core 2 duo, mas achei que era só isso.  Com algumas mensagens no Twitter, algums amigos confirmaram que a CPU era mesmo 64 bits, mas recebi muitas críticas negativas sobre o mesmo em Linux, principalmente em relação à crashes de aplicativos, principalmente em sites com flash. Resolvi então manter os 32 bits.

Recentemente li um  artigo dizendo que o Linux fracassou miseravelmente na arquitetura 64 bits. O texto realmente está certo na abordagem do Linux em relação à nova arquitetura: dizia-se que o Windows estava fadado ao esquecimento dos 32 bits e que Linux iria dominar o desktop pois sua migração era tão fácil quanto a instalação em uma torradeira. E o que vemos atualmente é exatamente o oposto disso: várias recomendações pra se manter Linux em 32 bits por questões de estabilidade. No ponto em que li essa frase, confesso que senti uma pontada de culpa, pra não dizer vergonha.

Por um problema com um aplicativo de VPN da empresa, não posso migrar meu laptop pra 64 bits (processador Intel Core i3) e tenho de continuar envergonhado, mas já o meu desktop... resolvi arregaçar as mangas e instalar. Parti pra instalação do Ubuntu 10.10 em arquitetura AMD64.

Como sempre, dpkg salvou o dia com a lista de aplicativos previamente instalados (dpkg --get-selections >myselections). A migração, ou reinstalação, ocorreu sem demais problemas. Um backup do /etc, bases do mysql e do diretório /root e rapidamente tive o sistema restaurado, e em 64 bits.

Para batizar a *nova* máquina dei o nome de goosfraba, em homenagem ao filme do "tratamento de choque" com Jack Nicholson e Adam Sandler (final meio infeliz, mas em geral é engraçado).

Até o momento a goosfraba tem funcionado melhor que na arquitetura 32 bits: mais rápido. Tenho a sensação de que estava dirigindo uma Audi A3 turbo, mas que antes só colocava até a 4a marcha. E agora vou até a 7a. Mas espero problemas com o Flash Player, pois sei que apesar do Linux não ter fracassado em 64 bits, também não foi o sucesso desejado.

Referências:

[1] What happened to "World Domination 201"? (ou Linux fracassou miseravelmente em 64 bits)

Tweet this