Escrito por Helio Loureiro
Categoria:

Após o upgrade com sucesso, sempre surgem alguns efeitos colaterais.  Um dos que notei imediatamente foi a perda dos efeitos de compositing, afetando diretamente os efeitos 3D do desktop.

Após uma olhada nos logs do Xorg, notei que o sistema estava usando o driver VESA ao invés do INTEL, referente à minha placa de vídeo, uma Intel 945GM.  O antigo programa para configuração do Xorg, o SAX2, foi removido.  Então fiquei com o mico na mão (ou seria no sistema?).  O glxinfo ajudou a ter certeza que as configurações de OpenGL não estavam sendo carregadas.

helio@musashi:~$ glxinfo | grep -i render
direct rendering: No

Mudei o initlevel do sistema para 1 (modo de single user, ou manutenção), e começei a verificar o que podia estar faltando.  De cara notei que somente existia o arquivo /etc/X11/xorg.conf.install para configuração da parte gráfica, mas nenhum programa para configuração.  Também vi que o Xorg está alterando sua configuração para o estilo de diretório, utilizando o /etc/X11/xorg.conf.d, mas o mesmo estava populado com arquivos vazios ou com configuração genérica.

Acho que esse problema não teria acontecido se eu tivesse feito a instalação via DVD ao invés do modo online com zypper.  Mas nesse momento, já era um pouco tarde demais pra desistir.

Resolvi então usar o modo -configure do servidor X, que gerou uma configuração mínima e básica para mim:

root@musashi:~# X -configure

X.Org X Server 1.8.0
Release Date: 2010-04-02
X Protocol Version 11, Revision 0
Build Operating System: openSUSE SUSE LINUX

[ REMOVIDO PRA EVITAR POLUIÇÃO VISUAL... ]

(++) Using config file: "/root/xorg.conf.new"
(==) Using config directory: "/etc/X11/xorg.conf.d"

Your xorg.conf file is /root/xorg.conf.new

To test the server, run 'X -config /root/xorg.conf.new'

Uma olhada no arquivo gerado, /root/xorg.conf.new, na seção "Device", mostrou que o chipset de vídeo tinha sido corretamente identificado.

Section "Device"
        ### Available Driver options are:-
        ### Values: <i>: integer, <f>: float, <bool>: "True"/"False",
        ### <string>: "String", <freq>: "<f> Hz/kHz/MHz"
        ### [arg]: arg optional
        #Option     "NoAccel"                   # [<bool>]
        #Option     "SWcursor"                  # [<bool>]
        #Option     "ColorKey"                  # <i>
        #Option     "CacheLines"                # <i>
        #Option     "Dac6Bit"                   # [<bool>]
        #Option     "DRI"                       # [<bool>]
        #Option     "NoDDC"                     # [<bool>]
        #Option     "ShowCache"                 # [<bool>]
        #Option     "XvMCSurfaces"              # <i>
        #Option     "PageFlip"                  # [<bool>]
        Identifier  "Card0"
        Driver      "intellegacy"
        VendorName  "Intel Corporation"
        BoardName   "Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller"
        BusID       "PCI:0:2:0"
EndSection

Mesmo com as todas as opções de otimização comentadas, isso foi suficiente para trazer as funcionalidades de OpenGL de volta ao meu desktop.  Bastou então copiar essa configuração para /etc/X11/xorg.conf  e mudar o initlevel para 5 novamente.

helio@musashi:~$ glxinfo | grep -i render
direct rendering: Yes
OpenGL renderer string: Mesa DRI Intel(R) 945GM GEM 20100328 2010Q1 x86/MMX/SSE2
Escrito por Helio Loureiro
Categoria:

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:

  • Atualizar o sistema em 11.2.
  • Remover todos os repositórios referenciados pelo 11.2
  • Inserir os links para 11.3.
  • Atualizar a lista de pacotes e dependências.
  • Atualizar o sistema.

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...

Escrito por Helio Loureiro
Categoria:

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

Escrito por Helio Loureiro
Categoria:

 

Baseado na mesma idéia já publicada pela Debian, Valéssio Britto criou uma versão brasileira do cubo de comandos para Debian.  É para uso de comandos em geral, mas as sequências de <Ctrl>+<algo> são específicas de Bash.

Idéia muito legal.  Além do cubo ser "stylish", deixa sua mesa com aparência legal.  Vai fazer seus amigos babarem.

Eu pretendo editar meu cubo e ainda colocar um RTFM, pra ficar mais a minha cara.

Veja mais sobre cubo Debian aqui.

Escrito por Helio Loureiro
Categoria:

Adicionei mais uma feature no Joomla, para atualizar automaticamente os posts daqui no twitter.

Twitter Post

Espero conseguir fazer mais rápido o sincronismo da página com o Twitter, já que esse tem *roubado* boa parte do meu tempo e meus posts.

Tenho muitas idéias sobre o que escrever, mas acabo perdendo muito tempo com Twitter.  Então, se não pode com ele, tweet-se à ele.

Escrito por Helio Loureiro
Categoria:

Durante uma conversa com um colega de trabalho, onde ele mostrou um artigo seu no Dicas-L, mostrei minha única aparição por lá (se tem outra, nem estou sabendo).  

Comentei que infelizmente o link estava quebrado e que não tinha mais a página referida.  Mas isso queimou profundamente em minha alma, se é que tenho uma, ou se ainda restar alguma.

Sai pelo google a fora buscando por um simples "rtfm.html", e não encontrei nada.  Então fui no modo difícil.

Busquei o pacote do "funny-manpages".  Instalei e verifiquei que tudo estava certo com um "man rtfm".  Depois procurei o pacote do "man2html", e o instalei.

Feito isso, bastou um:


cat /usr/share/man/man1/rtfm.1fun.gz |\
   gunzip - |\
   nroff -man -c |\
   man2html > /tmp/rtfm.html


seguido de um upload pro site, o que fez com que tudo voltasse ao normal.  

Podem conferir:

http://helio.loureiro.eng.br/rtfm.html

Escrito por Helio Loureiro
Categoria:

Na lista Debian-BR, foi enviado uma chamada para ajudar num descritivo sobre Debian, para pedir voluntários dentro de um projeto da SERPRO.  Era pra ser um texto simples e explicativo.  Eu fiz minha parte e enviei a sugestão abaixo:

Você suspira pelos bons tempos do Linux, quando os homens eram homens e escreviam seus próprios "device drivers"? Você está sem um bom projecto em mãos e deseja trabalhar num S.O. que possa modificar de acordo com as suas necessidades? Acha frustrante quando tudo funciona no Ubuntu? Chega de noite ao computador para conseguir que os programas funcionem? Então esta mensagem pode ser exactamente para você. Como eu mencionei há um mês atrás, estou trabalhando numa versão independente de uma distro similar ao Ubuntu para computadores AT-386. Ele está, finalmente, próximo do estado em que poderá ser utilizado (embora possa não ser o que você espera), e eu estou disposto a disponibilizar o código-fonte para ampla distribuição. Ele está na versão lenny... contudo eu tive sucesso ao executar bash, gcc, gnu-make, gnu-sed, compressão etc. nele.

Não sei por qual motivo, o pessoal não gostou... mas eu fiz a minha parte.

Escrito por Helio Loureiro
Categoria:

Em várias ocasiões, preciso de alguma automação via script que utilize um comando telnet. Existem vários problemas de segurança em relação ao uso do telnet, mas vários equipamentos de rede, entre switches e roteadores, fazem uso dele (se bem que é possível substituir por ssh).

 

Para usar em scripts, uma das formas mais fáceis de fazer isso é concatenando comandos. É possível fazer login, entrar com a senha, e enviar os comandos necessários.

Como exemplo, uma conexão telnet normalmente seria da seguinte forma:

  • Nome do servidor destino: server
  • Login: user
  • Senha: user
[helio@linux ~]$ telnet server 
Trying 10.10.7.4...
Connected to server.
Escape character is '^]'.
login: user
Password:
user@server> exit
logout
Connection to server closed by foreign host.

Agora no formato para scripts, utilizando o pipe:

[helio@linux ~]$ (echo "user"; sleep 1; echo "user"; sleep 1;echo "date"; sleep 1) | telnet server 
Trying 10.10.7.4...
Connected to server.
Escape character is '^]'.
login:
Password:
user@server>date
Thursday, July 29, 2010 8:11:52 PM BRT
user@server>
Connection to server closed by foreign host.

 

Cada comando echo envia para o telnet os comandos que seriam digitados. Utilizei um comando date como exemplo, mas é possível enviar outros comandos e até mesmo ler a saída do comando, redirecionando para um arquivo.

Escrito por Helio Loureiro
Categoria:

Depois de mais de 3 anos com o bom e companheiro HP nc6400, acho que está chegando a hora de um refresh. Não que a máquina seja minha, muito pelo contrário. Ela pertence à empresa. Mas isso nunca influenciou nos cuidados com a mesma.

Desde o início rodei Unix nela. Comecei com FreeBSD, mas acabei migrando pra Linux, OpenSuse mais especificamente. Os motivos na época, são praticamente os mesmos pra manter Linux atualmente: funciona muito bem no modo de hibernação (já cheguei a quase 100 dias de uptime), sem problemas com as placas 3G (essencial atualmente) e fácil suporte à criptografia de disco. Não que o FreeBSD não tenha parte desses, mas o conjunto todo funciona melhor no Linux. Atualmente.

E na empresa está chegando o momento de refresh de hardware. Eu devia estar animado, mas o sistema padrão por lá é Windão. E vai ser novamente um problema rodar meu Linux, ali, no meu cantinho. Por isso acho que vou devolver o equipamento pra empresa e finalmente adquirir o meu próprio.

Pra isso, pedi algumas recomendações de laptop, via twitter mesmo. Uma das recomendações que recebi e gostei foi em relação à Dell, modelo vostro 3300.

 

 

 

 

Fino acabamento em alumínio, tela de 13 pol (prefiro as telas menores), placa nvidia... é uma tentação. Preciso então olhar as finanças pra ver se cabe mesmo no meu bolso. Afinal, já comprei um zilhão de quinquilharias pra pagar 50 reais por mês. Esses montes de 50 reais já estão pesando atualmente. Mas que é uma tentação, isso é...

Escrito por Helio Loureiro
Categoria:

Finalmente parece que o novo site está de pé, 100%, e com poucos problemas.

A migração de Mamboserver pra Joomla não foi tão fácil quanto eu imaginava. A princípio parecia que existiam várias ferramentas prontas pra "clicar, importar, exportar", mas não foi bem assim.

Deve ser o costume Google de achar que basta clicar e tudo está pronto, mas com certeza foi longe disso.

Tentei fazer a migração sugerida, do Mamboserver para Joomla 1.0, para depois fazer outro upgrade para Joomla 1.5, mas não fui feliz em nenhuma tentativa.

Por fim resolvi baixar um dump em SQL do banco de dados e fazer o upload das partes realmente importantes manualmente, olhando as diferenças entre Joomla 1.5 e Mamboserver 4.6.2. Trabalho de presidiário, mas deu certo. Carreguei todos os artigos, as categorias, fiz uns acertos aqui e ali e... tudo apareceu online.

Aparecer online não significa isenção de problemas. Tive de abrir mão do lay-out e visual do site antigo. Não que seja ruim, pois com um novo motor Joomla no site, nada melhor que mudar o visual também. Mas a parte de organização, menus, posicionamento, tudo isso for pras cucuias.

Tive de refazer as categorias e seções, o que deu bastante trabalho pros 140 artigos existentes, e correr atrás de problemas de versão, que removeram os "mambots" que eu usava bastante: moscode e mosimage.

Do mosimage, consegui encontrar um plugin pra fazer funcionar tudo novamente. Deu certo de primeira, o que me deixou muito feliz (editar todos os artigos ia dar um baita trabalhão). Mas não tive tanta sorte com o moscode. Porém encontrei um outro plugin para adicionar suporte à codificação mesmo, usando coisas muito parecidas com o que fazia antes. Então bastou um:

 sed -i "s/moscode/CODE/g" loureiro.eng.br_dump.sql  

Apanhei também, e bastante, com o uso de cache do Joomla, que é muito mais intenso que no Mambo (que nem usava isso tanto assim). Deve dar uma performance muito melhor em websites com grande volume de acessos, mas para mim não deve mudar tanto assim.

Mas por fim está o site novo no ar. Talvez com alguns bugs ainda, mas devo ir corrigindo aos poucos. O lado bom da coisa é que o Joomla é realmente muito superior ao Mamboserver, inclusive com suporte à XMLRPC, que me permite escrever esse artigo num client no KDE4, Blogilo, sem precisar estar conectado. Muito conveniente e provavelmente uma mão na roda pra melhorar a taxa da atualização do site. Sem falar na integração com Twitter, que ainda não é totalmente a que eu queria, mas que uma hora vai chegar lá, com certeza.

Escrito por Helio Loureiro
Categoria:

Testando a interface via XMLRPC, utilizando o client Blogilo, pra KDE4.

=-=-=-=-=
Powered by Blogilo

Escrito por Helio Loureiro
Categoria:

Já nas fases finais de migração para o Joomla, esse é o primeiro post de teste.

Infelizmente meus "mosimage" e "moscode" deixaram de funcionar, o que vai me obrigar a fazer uma grande revisão em tudo que foi postado.

Vai ser um grande exercício de nostalgia....

Escrito por Helio Loureiro
Categoria:

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