Depois de descobrir que o modem da 3G Huawei, E156B, não funciona bem em Linux (fica criando e removendo os devices /dev/ttyUSB?) por causa de um bug no kernel, resolvi arriscar e fazer o upgrade no OpenSuse 11.2 para 11.3, uma vez que a versão de kernel nesse é mais novo.
Em geral é recomendado o upgrade via CD/DVD, mas resolvi arriscar o upgrade online, usando o zypper. Também encontrei boas referências de como fazer isso:
How to migrate to a new openSUSE version
Upgrade to 11.3 using zypper dup
Fazendo o upgrade do openSUSE 11.2 para o 11.3
Seguindo os passos descritos, que são basicamente:
O último passo é um reboot para garantir que todos os aplicativos estão rodando corretamente e carregar o kernel novo.
Quase não tive problemas, mas após o boot, não conseguia fazer login via KDM. Após uma olhada rápida no ~/.xsession-errors, descobri que o diretório /tmp estava com as permissões erradas, uma vez que tenho o mesmo em uma partição criptografada. Mas um "chmod 1777 /tmp" corrigiu isso e aqui estou eu, feliz no meu novíssimo OpenSuse 11.3.
Linux musashi 2.6.34-12-desktop #1 SMP PREEMPT 2010-06-29 02:39:08 +0200 i686 i686 i386 GNU/Linux
Adicionado em 28 de Agosto: um comentário sobre o modem 3G Huawei E156B, que originou todo esse esse upgrade. O mesmo continua não funcionando corretamente...
Como trabalho com instalação de equipamentos, invariavelmente me vejo com o problema de conectar via SSH a um IP que já existe no meu ".ssh/known_hosts", mas com endereço MAC e hash de host diferentes (fingerprint). As redes internas dos equipamentos que trabalho estão sempre padronizadas em 172.16.0.0/21 e 172.16.8.0/21, com as placas sempre nos mesmos endereços internos, independente de instalação, mapeadas por posição física em relação aos magazine e slot.
Imediatamente o ssh identifica tal endereço como clonado e emite um alerta de erro e tentativa de ataque (man-in-the-middle, alguém no meio do caminho):
helio@musashi:BKP$ ssh -l telorb proc-m1-s1-0
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
72:78:1e:c2:69:f9:a1:55:a0:9c:35:c8:be:6a:40:fb.
Please contact your system administrator.
Add correct host key in /home/helio/.ssh/known_hosts to get rid of this message.
Offending key in /home/helio/.ssh/known_hosts:323
RSA host key for proc-m1-s1-0 has changed and you have requested strict checking.
Host key verification failed.
Nesse caso o destino, proc-m1-s1-0, é o processador do magazine 1, slot 1, interface de rede 0, cujo IP é 172.16.8.129. Já o mantenho em meu /etc/hosts de tanto que preciso usar, deixando o nome assim mais fácil (também uso o alias io1 para acessar) sem precisar decorar o IP.
Voltando ao assunto ssh, é possível remover a entrada no arquivo .ssh/known_hosts com o comando sed e a saída acima, que mostra que o mesmo está registrado na linha 323 desse arquivo (linha do "Offending key..."). Para isso basta:
sed -i "323d" .ssh/known_hosts
Isso funciona corretamente no sed da GNU, mas não no dos BSDs. Para esses, uso o redirecionamento para outro arquivo:
cat .ssh/known_hosts | sed "323d" >.ssh/known_hosts.tmp
mv .ssh/known_hosts.tmp .ssh/known_hosts
O redirecionamento direto para o arquivo de origem costuma não funcionar muito bem com alguns BSDs e Solaris principalmente, apagando o mesmo. Então não economizo em comandos e faço como acima.
Essa é a solução chata, pois exige constantemente a alteração do arquivo .ssh/known_hosts. Sem falar que o mesmo problema também surge quando é realizado algum upgrade, onde geralmente o host de acesso tem seu sistema operacional re-instalado.
Então para evitar esse aborrecimento, existe uma forma de alterar as opções do ssh. Mas isso causa um problema de segurança nos acessos via SSH, pois todo host já autenticado anteriormente poderá ser direcionado para outra máquina sem demais avisos. Isso poderá fazer com que se digite a senha numa máquina qualquer. Mesmo se não for um ataque, existe o risco dos login e senha ficarem disponíveis em algum syslog do sistema contectado. Então... cuidado.
cat << EOF >> ~/.ssh/ssh_config
CheckHostIP=no
StrictHostKeyChecking=no
EOF
A opção "CheckHostIP" é a responsável por fazer a associação de host com fingerprint. Já a opção "StrictHostKeyChecking" cuida para que o arquivo .ssh/known_hosts seja atualizado a cada acesso ao host de destino. Alterando as duas opções para "no", eu evito ter de editar esse arquivo a cada acesso, mas abre uma brecha de segurança enorme em para mim.
Se o seu caso for igual ao meu, que utiliza um laptop para justamente esse tipo de trabalho, os riscos valerão a pena. Na usabilidade x segurança, aqui ganhou o primeiro.
=-=-=-=-=
Powered by Blogilo
Faz tanto tempo que não publico aqui, que agora vi um outro post sobre o uptime do meu laptop, que descrevi logo que mudei pra OpenSuse.
Fiquei tão surpreso de ficar mais de 40 dias sem desligar, que achei o máximo alcançar 46 dias.
O que posso dizer agora?
01:37am up 72 days 11:38, 15 users, load average: 0.47, 0.41, 0.35
Resolvi fazer um upgrade no Ubuntu instalado no meu HD Externo. Afinal o mesmo está com o release 8.10 instalado, mais que desatualizado. Pretendo chegar à versão 10.04, mas a forma de fazer isso já é outro assunto.
Tentei em vão colocar o HD externo, reconhecido como /dev/sdb no OpenSuse 11.2, como um HD, CDROM e FLOPPY para boot. Não consegui diretamente, já que o VirtualBox procurar por um dispositivo com extensão VMDK ou VDI.
Consegui adicionar como dispositivo USB, mas não teve nenhum efeito no boot, que simplesmente falhava (justamente por não ter partição bootável reconhecida).
Googleando pela Internet, encontrei um comando que associa o dispositivo que está em /dev com um arquivo VMDK:
Estava no Fórum do VirtualBox, com uma pergunta relacionada a minha. Era uma dica para MacOSX, mas funcionou perfeitamente para Linux. E deve funcionar também para outros *nix, como FreeBSD e Solaris.
O resultando para mim foi:
{CODE} helio@musashi:Virtualization$ VBoxManage internalcommands createrawvmdk -filename $PWD/Ubuntu-external-disk-sdb.vmdk -rawdisk /dev/sdb -register Sun VirtualBox Command Line Management Interface Version 3.1.6 (C) 2005-2010 Sun Microsystems, Inc. All rights reserved. RAW host disk access VMDK file /usr/local/tmp/Virtualization/Ubuntu-external-disk-sdb.vmdk created successfully. {/CODE}
Após isso, consegui ver a tela de boot (menu do Grub), mas o mesmo parava durante o carregamento do splashscreen.
Resolvi esse problema removendo o suporte à aceleração 3D, depois de uma olhada nos logs. Agora estou rumo ao Ubuntu 10.04!
Já fiz upgrade pra recém lançada versão 11.2. Mas estou gostando do uso do Suse, com zypper. Inclusive consegui uma grande conquista:
7:02pm up 46 days 5:44, 12 users, load average: 0.58, 0.37, 0.16
46 dias sem desligar o sistema...
