image1 image2 image3 image4 image5 image6 image7 image8 image9 image10

Goosfraba

Autor:
Data de criação:
Data de publicado:
Acessos: 4377

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)


Data de criação:
Data de publicado:
Acessos: 4059

Hoje, no meio das minhas férias, dei uma conectada na rede da empresa pra verificar uns mails (de uns amigos perdidos que mandaram pro endereço errado).

Por lá o comunicador oficial é o Lotus Sametime, da IBM.  Sempre conectei utilizando o Pidgin, um dos melhores clientes multi-serviço para IMs que conheço, e utilizando o módulo meanwhile pra conectar no servidor de sametime.  Qual não foi minha surpresa ao descobrir que o mesmo não funcionava mais.  Apenas recebia uma mensagem de "Version Mismatch" no rodapé do Pidgin e a conexão se encerrava.


Felizmente encontrei fácil uma solução no site do Pidgin, no TT#12623.  A solução sugere que o meanwhile seja configurado pra esconder sua identificação (hide), o que já era feito.  Então editei o arquivo ~/.purple/accounts.xml e adicionei somente uma linha com a informação abaixo:

                <settings>
                        <setting name='fake_client_id' type='bool'>1</setting>
                        <setting name='client_minor' type='int'>8511</setting>
                        <setting name='port' type='int'>1533</setting>
                        <setting name='force_login' type='bool'>1</setting>
                        <setting name='server' type='string'>sametime.internal.server.com</setting>
                </settings>

Funcionou xuxu beleza.  Reiniciei o Pidgin e imediatamente conectei e pude ver os contatos online.

Data de criação:
Data de publicado:
Acessos: 5261

Como já tinha comentado no post anterior, adquiri um laptop novo. Decidi fazer isso pra me livrar da chateação corporativa do laptop da empresa. Agora posso utilizar Linux ou FreeBSD, ou o que eu quiser, incondicionalmente, sem amolação. No momento estou com Linux, Ubuntu pra ser mais preciso, mas com certeza gostaria de rodar FreeBSD nele, o que não farei até que o suporte pra suspend/hibernate esteja mais maduro.

Devido às restrições dos aplicativos da empresa, que estão empacados em 32 bits, optei por utilizar Ubuntu X86 ao invés do AMD64. Se perdi desempenho, nem percebi. Habilitei o kernel com PAE, pra endereçar os 4 GB de memória e tudo está funcionando bem.

 

TPL_COM_CONTENT_READ_MOREAnálise do Sony Vaio VPC S110GB
Data de criação:
Data de publicado:
Acessos: 5296


Usuários Debian ou Ubuntu, ou um de seus derivados, frequentemente encontram problema de chave ao realizar um "apt-get update", como abaixo:

root@musashi:DEBIAN# apt-get update
Get:1 http://dl.google.com stable Release.gpg [189 B]
Ign http://dl.google.com/linux/chrome/deb/ stable/main Translation-en
Hit http://ftp.de.debian.org squeeze Release.gpg
[... várias linhas suprimidas ...]
Hit ftp://debian.oregonstate.edu testing/main i386 Packages/DiffIndex
Hit ftp://debian.oregonstate.edu testing/contrib i386 Packages/DiffIndex
Hit ftp://debian.oregonstate.edu testing/non-free i386 Packages/DiffIndex
Fetched 5,197 B in 49s (104 B/s)
Reading package lists... Done

W: GPG error: http://deb.opera.com squeeze Release: The following signatures
couldn't be verified because the public key is not available: NO_PUBKEY F9A2F76A9D1A0061
W: GPG error: http://mirror.home-dn.net squeeze Release: The following signatures
couldn't be verified because the public key is not available: NO_PUBKEY 07DC563D1F41B907
W: GPG error: http://www.lamaresh.net squeeze Release: The following signatures
couldn't be verified because the public key is not available: NO_PUBKEY 905C75258D4B24D2
W: GPG error: http://mirror.home-dn.net testing Release: The following signatures
couldn't be verified because the public key is not available: NO_PUBKEY 07DC563D1F41B907
W: GPG error: http://www.debian-multimedia.org testing Release: The following signatures
couldn't be verified because the public key is not available: NO_PUBKEY 07DC563D1F41B907
W: GPG error: http://debian-multimedia.org squeeze Release: The following signatures
couldn't be verified because the public key is not available: NO_PUBKEY 07DC563D1F41B907

O erro de GPG mostrado é causado pela falta dessas chaves no sistema de controle do apt, o chamado chaveiro GPG (em geral localizado em "/etc/apt/trusted.gpg"). Essas chaves assinam os pacotes DEB instalados, garantido que os mesmos não foram modificados no repositório, evitando a instalação de "cavalos de tróia" e coisas de gênero (note que isso não garante a origem do pacote, por isso sempre use repositórios confiáveis).

Para corrigir, nada mais fácil que um scriptzinho, utilizando as chaves mostradas na saída de erro:

for key in F9A2F76A9D1A0061 07DC563D1F41B907 905C75258D4B24D2 \
07DC563D1F41B907 07DC563D1F41B907 07DC563D1F41B907
do
gpg --keyserver subkeys.pgp.net --recv $key | \
gpg --export --armor | apt-key add -
done

A saída será algo como:

gpg: requesting key 1F41B907 from hkp server subkeys.pgp.net
gpg: key 1F41B907: "Christian Marillat " not changed
gpg: Total number processed: 1
gpg: unchanged: 1
OK

para cada chave. O próximo "apt-get update" já não apresentará os mesmos problemas.

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

Data de criação:
Data de publicado:
Acessos: 2725



Depois de uma rápida discussão no Twitter sobre treinamento em VoIP, lembrei que tinha esse documento perdido em algum lugar do meu HD.  É uma explicaçã beeeeeeeeeeem superficial de VoIP e configuração básica do Asterisk. 

Foi apresentado no Maratona HOWTO e também numa das oficinas Debian-SP.

PABX IP utilizando Asterisk

Data de criação:
Data de publicado:
Acessos: 2442

O pessoal do Ubuntu, ou melhor, a empresa do Ubuntu lançou uma página interessante em seu site:

Ubuntu-certified hardware

Apesar de ter aparecido tímido, sem muito estardalhaço, é um grande avanço.  Vai permitir que todos verifiquem qual computador e principalmente laptop que pode funcionar com Ubuntu sem dores de cabeça.

Eu mesmo já estou me sentindo beneficiando por isso, pois continuo com o desejo de comprar "aquele laptop" da Dell, o Vostro 3300, mas as buscas que realizei anteriormente não mostraram claramente se o suporte estava bom.  Não que isso me preocupasse, mas já tinha visto que a placa wi-fi dele não era uma Intel, mas uma "Dell", o que poderia me levar a ter de arrumar alguma solução do tipo NDISwrapper.  Mas o mesmo está lá na lista de hardware compatível do Ubuntu!

Isso não significa somente que o Ubuntu está aprovado, mas que qualquer outra distribuição Linux poderá funcionar nesse hardware.  Mesmo Debian se beneficiará muito disso.


DNS na Net

Autor:
Data de criação:
Data de publicado:
Acessos: 2814

Faz algum tempo, troquei meus apontamentos de DNS pra Google. Uso indiscriminadamente os servidores 8.8.8.8 e 8.8.8.9, pois funcionavam muito bem.

Funcionavam. Ultimamente tenho notado uma grande perda de qualidade. Como teste, eu podia ver que "ping helio.loureiro.eng.br" respondia muito lentamente.

helio@musashi:~$ ping -c 9 helio.loureiro.eng.br
PING helio.loureiro.eng.br (200.160.196.23) 56(84) bytes of data.
64 bytes from uplk02-tvt-spo.fly.com.br (200.160.196.23): icmp_req=1 ttl=57 time=10.8 ms
64 bytes from uplk02-tvt-spo.fly.com.br (200.160.196.23): icmp_req=2 ttl=57 time=9.11 ms
64 bytes from uplk02-tvt-spo.fly.com.br (200.160.196.23): icmp_req=3 ttl=57 time=11.4 ms
64 bytes from uplk02-tvt-spo.fly.com.br (200.160.196.23): icmp_req=4 ttl=57 time=10.5 ms
64 bytes from uplk02-tvt-spo.fly.com.br (200.160.196.23): icmp_req=5 ttl=57 time=9.81 ms
64 bytes from uplk02-tvt-spo.fly.com.br (200.160.196.23): icmp_req=6 ttl=57 time=10.8 ms
64 bytes from uplk02-tvt-spo.fly.com.br (200.160.196.23): icmp_req=7 ttl=57 time=9.46 ms
64 bytes from uplk02-tvt-spo.fly.com.br (200.160.196.23): icmp_req=8 ttl=57 time=10.5 ms
64 bytes from uplk02-tvt-spo.fly.com.br (200.160.196.23): icmp_req=9 ttl=57 time=10.4 ms

--- helio.loureiro.eng.br ping statistics ---
9 packets transmitted, 9 received, 0% packet loss, time 50338ms
rtt min/avg/max/mdev = 9.119/10.352/11.443/0.705 ms

Quase 50 segundos para resposta. E os tempos de retorno do ICMP em torno de 10 milissegundos. Isso estava refletindo em todos os aplicativos, desde páginas Web até o Choqok.

Então troquei os servidores DNS para os servidores do OpenDSN (obrigado pela correção @CSPrivat): 208.67.222.222 e 208.67.220.220. A melhoria foi imediata:

helio@musashi:~$ ping -c 10 helio.loureiro.eng.br
PING helio.loureiro.eng.br (200.160.196.23) 56(84) bytes of data.
64 bytes from uplk02-tvt-spo.fly.com.br (200.160.196.23): icmp_req=1 ttl=57 time=19.7 ms
64 bytes from uplk02-tvt-spo.fly.com.br (200.160.196.23): icmp_req=2 ttl=57 time=9.90 ms
64 bytes from uplk02-tvt-spo.fly.com.br (200.160.196.23): icmp_req=3 ttl=57 time=10.9 ms
64 bytes from uplk02-tvt-spo.fly.com.br (200.160.196.23): icmp_req=4 ttl=57 time=11.5 ms
64 bytes from uplk02-tvt-spo.fly.com.br (200.160.196.23): icmp_req=5 ttl=57 time=12.1 ms
64 bytes from uplk02-tvt-spo.fly.com.br (200.160.196.23): icmp_req=6 ttl=57 time=18.9 ms
64 bytes from uplk02-tvt-spo.fly.com.br (200.160.196.23): icmp_req=7 ttl=57 time=10.7 ms
64 bytes from uplk02-tvt-spo.fly.com.br (200.160.196.23): icmp_req=8 ttl=57 time=10.1 ms
64 bytes from uplk02-tvt-spo.fly.com.br (200.160.196.23): icmp_req=9 ttl=57 time=10.4 ms
64 bytes from uplk02-tvt-spo.fly.com.br (200.160.196.23): icmp_req=10 ttl=57 time=16.3 ms

--- helio.loureiro.eng.br ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9011ms
rtt min/avg/max/mdev = 9.908/13.090/19.728/3.585 ms

10 pings em 9 segundos contra 50 segundos do teste anterior.

Será que estão boicotando os servidores da Google? Isso tem cara de baixa prioridade em pacotes UDP, mas logo os de DNS??

Data de criação:
Data de publicado:
Acessos: 6051

De tempos em tempos me vejo obrigado a coletar dados sobre uso de CPU e memória de várias máquinas. Muita coisa é facilitada quando se usa Nagios ou aplicativos parecidos.


Infeilzmente esse não é o meu caso. Sempre preciso preparar a coleta de dados pra um outro processamento, em geral externo (e em geral via planilha). Então constatemente faço uso de arquivos CSV, com seus conteúdos em formato texto, separados por vírgulas.


E para buscar esses dados, uma forma muito simples é utilizando SNMP, Simple Network Management Protocol. O SNMP é um protocolo baseado em UDP, portanto não existe muita garantia do recebimento desse dado, mas por ser "simples", facilita em muito a aquisição deles.


No meu caso, conectando em diversas plataformas, muitas delas Sun com Solaris 10, precisei enviar o comando como abaixo.


helio@musashi:~$ snmpget -c public -v 2c 10.110.6.24 .1.3.6.1.4.1.2021.11.11.0
iso.3.6.1.4.1.2021.11.11.0 = INTEGER: 98

O OID, Object IDentifier, 1.3.6.1.4.1.2021.11.11.0 diz ao sistema que busco a informação de porcentagem de CPU ociosa. Eu poderia buscar a quantidade CPU em uso, mas seria preciso enviar dois comandos: um para a quantidade de CPU usada pelos usuários, outro para quantidade CPU usada pelo sistema. Então prefiro pegar o montante ocioso e calcular o utilizado a partir desse.


Para saber quais objetos são possíveis, como memória, uso de disco, etc, encontrei uma boa referência no site:

http://www.debianhelp.co.uk/linuxoids.htm

Alguns objetos úteis são:


Estatísticas de CPU

  • Carga em 1 minuto: .1.3.6.1.4.1.2021.10.1.3.1
  • Carga em 5 minute Load: .1.3.6.1.4.1.2021.10.1.3.2
  • Carga em 15 minute Load: .1.3.6.1.4.1.2021.10.1.3.3
  • Porcentagem de uso de CPU pelos usuários: .1.3.6.1.4.1.2021.11.9.0
  • Tempo absoluto de uso de CPU pelos usuários: .1.3.6.1.4.1.2021.11.50.0
  • Porcentagem de uso de CPU pelo sistema: .1.3.6.1.4.1.2021.11.10.0
  • Tempo absoluto de uso de CPU pelo sistema: .1.3.6.1.4.1.2021.11.52.0
  • Porcentagem de CPU ociosa: .1.3.6.1.4.1.2021.11.11.0
  • Tempo absoluto de CPU ociosa: .1.3.6.1.4.1.2021.11.53.0

Estatísticas de memória

  • Tamanho total da memória de troca (SWAP): .1.3.6.1.4.1.2021.4.3.0
  • Espaço disponível na memória de troca (SWAP): .1.3.6.1.4.1.2021.4.4.0
  • Total de memória RAM: .1.3.6.1.4.1.2021.4.5.0
  • Total de memória RAM utilizada: .1.3.6.1.4.1.2021.4.6.0
  • Total de memória RAM disponível: .1.3.6.1.4.1.2021.4.11.0
  • Total de memória RAM compartilhada: .1.3.6.1.4.1.2021.4.13.0
  • Total de memória RAM armazenada (buffer): .1.3.6.1.4.1.2021.4.14.0
  • Total de memória CACHE: .1.3.6.1.4.1.2021.4.15.0


Eu não testei todos os OIDs, mas utilizei o de CPU ociosa e os de memória RAM. Com isso consegui montar um monitoramento manual sem precisar de ferramentas externas, apenas alguns scripts em Perl.

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

Data de criação:
Data de publicado:
Acessos: 3608

E mais uma supresa com o meu OpenSuse 11.3.  Dessa vez em relação à criptografia de disco.

Tenho tanto meus discos internos do sistema (um laptop) quanto do meu HD externo criptografados.  Na verdade não uma partição criptografada pro sistema inteiro, mas somente os diretórios onde escrevo dados sensíveis, como /home, /tmp e /usr/local, nesse último onde coloco meus aplicativos externos como os de pré-pago, com que trabalho, e não podem ser distribuídos abertamente.

Meu HD externo é mais ou menos a mesma coisa, com uma partição primária para boot com Ubuntu (que não preciso arrumar pra voltar a funcionar corretamente).  Então acesso o HD externo através de um script, que solicita a senha das partições externas e tenta acessar as mesmas.

Pois durante a montagem do disco, o mesmo cuspiu um erro e abortou o procedimento, desmontando automaticamente as partições externas.  Nos logs do sistema, só encontrei a informação abaixo:

[46386.860780] EXT3-fs error (device dm-2): ext3_check_descriptors: Block bitmap for
group 0 not in group (block 3983602646)!
[46387.182487] EXT3-fs (dm-2): error: group descriptors corrupted
[46436.626828] EXT2-fs (dm-2): error: ext2_check_descriptors: Block bitmap for group 0 not
in group (block 3983602646)!
[46436.626841] EXT2-fs (dm-2): group descriptors corrupted

Lendo essas mensagens, meus pensamentos foram de desespero total.  Já perdi vários dados importante com o mesmo problema, causado por uma falha física do disco externo.  Na época o utilizava sem criptografia, mas as memórias amargas da perda de gigabytes de fotos, músicas e outros dados me fizeram engolir seco nesse momento.

Em total desespero, tentei montar a partição manualmente para verificação:

root@musashi:~# mount /dev/mapper/cr_ots_ext /mnt/dest
mount: wrong fs type, bad option, bad superblock on /dev/mapper/cr_ots_ext,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so

Tentei forçar um fsck.ext3, tentando utilizar outro super-bloco, mas tudo sem sucesso...

Tentei então acessar o mesmo disco numa máquina Ubuntu que tenho em casa e... sucesso!!!  Isso me aliviou bastante, pois já sabia que tinha sido mais um efeito colateral do upgrade para OpenSuse 11.3.  Então resolvi buscar soluções na Internet sobre o mesmo problema.  Assim encontrei o link abaixo: 

Bug#579162: cryptsetup: Error mounting device: EXT3-fs: group descriptors corrupted

Basicamente havia uma explicação sobre alteração nos parâmetros padrões do aplicativo cryptsetup, que é usado pra acessar a partição criptografada.  Os parâmetros de algoritmo e criptografia precisam ser passados como argumento na nova versão.

Fiz um teste para verificar se funcionariam para mim, adicionando os parâmetros "-c aes-cbc-plain -h ripemd 160 -s 256", como sugerido no problema do bug.  E deu certo:

root@musashi:~# cryptsetup -c aes-cbc-plain -h ripemd160 -s 256 create cr_ots_ext /dev/sdb7
Enter passphrase:
root@musashi:~# mount /dev/mapper/cr_ots_ext /mnt/dest

Bastou então criar um $CRYPTOPTS com esses valores e adicionar ao meu script para ter tudo funcionando corretamente de novo.


Data de criação:
Data de publicado:
Acessos: 2935

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
Data de criação:
Data de publicado:
Acessos: 2840

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

Data de criação:
Data de publicado:
Acessos: 3316

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

Data de criação:
Data de publicado:
Acessos: 2249

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 
Data de criação:
Data de publicado:
Acessos: 7013

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:

{CODE} VBoxManage internalcommands createrawvmdk -filename /tmp/dev1.vmdk -rawdisk /dev/disk -register {/CODE}

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!

Data de criação:
Data de publicado:
Acessos: 2632

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

2017  helio.loureiro.eng.br   globbersthemes joomla templates