O pessoal do Ubuntu, ou melhor, a empresa do Ubuntu lançou uma página interessante em seu site:
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.
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??
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:
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
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.
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
