Invariavelmente tenho de mexer no xorg e acertar as frequências do monitor. Isso não é tão necessário no Linux, mas em FreeBSD é impossível ter uma tela gráfica usável sem o xorg.conf criado.
E testando no Dell Vostro 3500, só consigo uma tela 1024x768 justamente pela falta das frequências suportadas. Para corrigir isso, criei um script já faz alguns anos, mas não tinha publicado ainda. É baseado no xrandr e deve ser rodado a partir da tela gráfica, por pior que seja sua resolução.
#! /usr/bin/perl
$H_SIZE = 1280; # standard horizontal size
$V_SIZE = 800; # standard vertical size
@SIZES = qw( 1280 1152 1024 800 1200 1400 1600 1800 1900 1920 2048);
print "Section \"Modes\"\n\tIdentifier \"MyModes\"\n";
foreach $hs (@SIZES) {
$rate = $hs / $H_SIZE;
$vs = $V_SIZE * $rate;
foreach $freq qw(60 75) {
print "\t\t# $hs x $vs ($rate - $freq Hz)\n";
$output = `gtf $hs $vs $freq -x`;
foreach $line (split(/\n/, $output)) {
next if ($line !~ /[0-9a-z]/);
$line =~ s/ *//;
print "\t\t".$line."\n";
next if ($line =~ "#");
$line =~ s/\"//g;
$line =~ s/_(\d+)//g;
$line =~ s/Modeline //g;
$cmd = "xrandr --newmode ".$line ;
system($cmd."> /dev/null 2>&1");
#print $cmd."\n";
$modeline = $line;
$modeline =~ s/ .*//g;
#print "Mode: $modeline\n";
$cmd = "xrandr --addmode LVDS $modeline > /dev/null 2>&1";
system($cmd);
}
}
}
print "EndSection\n";
O resultado já sai no formato do xorg.conf:
Section "Modes"
Identifier "MyModes"
# 1280 x 800 (1 - 60 Hz)
# 1280x800 @ 60.00 Hz (GTF) hsync: 49.68 kHz; pclk: 83.46 MHz
Modeline "1280x800_60.00" 83.46 1280 1344 1480 1680 800 801 804 828 -HSync +Vsync
# 1280 x 800 (1 - 75 Hz)
# 1280x800 @ 75.00 Hz (GTF) hsync: 62.62 kHz; pclk: 107.21 MHz
Modeline "1280x800_75.00" 107.21 1280 1360 1496 1712 800 801 804 835 -HSync +Vsync
# 1152 x 720 (0.9 - 60 Hz)
# 1152x720 @ 60.00 Hz (GTF) hsync: 44.76 kHz; pclk: 67.32 MHz
Modeline "1152x720_60.00" 67.32 1152 1208 1328 1504 720 721 724 746 -HSync +Vsync
# 1152 x 720 (0.9 - 75 Hz)
# 1152x720 @ 75.00 Hz (GTF) hsync: 56.40 kHz; pclk: 86.63 MHz
Modeline "1152x720_75.00" 86.63 1152 1224 1344 1536 720 721 724 752 -HSync +Vsync
# 1024 x 640 (0.8 - 60 Hz)
# 1024x640 @ 60.00 Hz (GTF) hsync: 39.78 kHz; pclk: 52.83 MHz
Modeline "1024x640_60.00" 52.83 1024 1072 1176 1328 640 641 644 663 -HSync +Vsync
# 1024 x 640 (0.8 - 75 Hz)
# 1024x640 @ 75.00 Hz (GTF) hsync: 50.17 kHz; pclk: 67.44 MHz
Modeline "1024x640_75.00" 67.44 1024 1080 1184 1344 640 641 644 669 -HSync +Vsync
# 800 x 500 (0.625 - 60 Hz)
# 800x500 @ 60.00 Hz (GTF) hsync: 31.08 kHz; pclk: 31.33 MHz
Modeline "800x500_60.00" 31.33 800 824 904 1008 500 501 504 518 -HSync +Vsync
# 800 x 500 (0.625 - 75 Hz)
# 800x500 @ 75.00 Hz (GTF) hsync: 39.22 kHz; pclk: 40.17 MHz
Modeline "800x500_75.00" 40.17 800 832 912 1024 500 501 504 523 -HSync +Vsync
# 1200 x 750 (0.9375 - 60 Hz)
# 1200x750 @ 60.00 Hz (GTF) hsync: 46.62 kHz; pclk: 73.10 MHz
Modeline "1200x750_60.00" 73.10 1200 1256 1384 1568 750 751 754 777 -HSync +Vsync
# 1200 x 750 (0.9375 - 75 Hz)
# 1200x750 @ 75.00 Hz (GTF) hsync: 58.73 kHz; pclk: 93.96 MHz
Modeline "1200x750_75.00" 93.96 1200 1272 1400 1600 750 751 754 783 -HSync +Vsync
# 1400 x 875 (1.09375 - 60 Hz)
# 1400x875 @ 60.00 Hz (GTF) hsync: 54.36 kHz; pclk: 100.46 MHz
Modeline "1400x875_60.00" 100.46 1400 1480 1624 1848 875 876 879 906 -HSync +Vsync
# 1400 x 875 (1.09375 - 75 Hz)
# 1400x875 @ 75.00 Hz (GTF) hsync: 68.55 kHz; pclk: 128.87 MHz
Modeline "1400x875_75.00" 128.87 1400 1488 1640 1880 875 876 879 914 -HSync +Vsync
# 1600 x 1000 (1.25 - 60 Hz)
# 1600x1000 @ 60.00 Hz (GTF) hsync: 62.10 kHz; pclk: 133.14 MHz
Modeline "1600x1000_60.00" 133.14 1600 1704 1872 2144 1000 1001 1004 1035 -HSync +Vsync
# 1600 x 1000 (1.25 - 75 Hz)
# 1600x1000 @ 75.00 Hz (GTF) hsync: 78.30 kHz; pclk: 169.13 MHz
Modeline "1600x1000_75.00" 169.13 1600 1704 1880 2160 1000 1001 1004 1044 -HSync +Vsync
# 1800 x 1125 (1.40625 - 60 Hz)
# 1800x1125 @ 60.00 Hz (GTF) hsync: 69.84 kHz; pclk: 169.29 MHz
Modeline "1800x1125_60.00" 169.29 1800 1920 2112 2424 1125 1126 1129 1164 -HSync +Vsync
# 1800 x 1125 (1.40625 - 75 Hz)
# 1800x1125 @ 75.00 Hz (GTF) hsync: 88.05 kHz; pclk: 216.25 MHz
Modeline "1800x1125_75.00" 216.25 1800 1928 2128 2456 1125 1126 1129 1174 -HSync +Vsync
# 1900 x 1187.5 (1.484375 - 60 Hz)
# 1904x1187 @ 60.00 Hz (GTF) hsync: 73.74 kHz; pclk: 189.95 MHz
Modeline "1904x1187_60.00" 189.95 1904 2032 2240 2576 1187 1188 1191 1229 -HSync +Vsync
# 1900 x 1187.5 (1.484375 - 75 Hz)
# 1904x1187 @ 75.00 Hz (GTF) hsync: 92.92 kHz; pclk: 242.35 MHz
Modeline "1904x1187_75.00" 242.35 1904 2048 2256 2608 1187 1188 1191 1239 -HSync +Vsync
# 1920 x 1200 (1.5 - 60 Hz)
# 1920x1200 @ 60.00 Hz (GTF) hsync: 74.52 kHz; pclk: 193.16 MHz
Modeline "1920x1200_60.00" 193.16 1920 2048 2256 2592 1200 1201 1204 1242 -HSync +Vsync
# 1920 x 1200 (1.5 - 75 Hz)
# 1920x1200 @ 75.00 Hz (GTF) hsync: 93.97 kHz; pclk: 246.59 MHz
Modeline "1920x1200_75.00" 246.59 1920 2064 2272 2624 1200 1201 1204 1253 -HSync +Vsync
# 2048 x 1280 (1.6 - 60 Hz)
# 2048x1280 @ 60.00 Hz (GTF) hsync: 79.50 kHz; pclk: 221.33 MHz
Modeline "2048x1280_60.00" 221.33 2048 2192 2416 2784 1280 1281 1284 1325 -HSync +Vsync
# 2048 x 1280 (1.6 - 75 Hz)
# 2048x1280 @ 75.00 Hz (GTF) hsync: 100.20 kHz; pclk: 280.56 MHz
Modeline "2048x1280_75.00" 280.56 2048 2200 2424 2800 1280 1281 1284 1336 -HSync +Vsync
EndSection
Bastando somente adicionar os valores de frequência, cujo nome é "MyModes", dentro de "Monitor", como abaixo:
Section "Monitor"
DisplaySize 300 230
HorizSync 28-82
Identifier "Monitor1"
ModelName "1280X1024@60HZ"
Option "DPMS"
VendorName "--> LCD"
VertRefresh 50-60
UseModes "MyModes"
EndSection
Finalmente decidi concretizar meu sonho de consumo e comprei um Dell Vostro, mas o 3500 ao invés do 3300. No momento espero poder realizar a troca por um 3300 pois o mesmo é muito grande em suas dimensões (e peso), mas isso é outro assunto.
Na instalação do sistema, fiquei na dúvida em qual seria o hostname perfeito pro novo laptop. E hostname não é somente um nome: é toda a personalidade do seu sistema.
Meu laptop anterior chamava-se, ou melhor, ainda chama, uma vez que continua comigo, musashi. Uma homenagem ao grande espadachim e mestre da arte da estratégia japonesa. E também porque o batismo dele ocorreu exatamente durante a leitura do livro homônimo.
O meu outro laptop, um iBook branco de 12 polegadas, chama-se xuxu.
Então precisava de um nome pro mais novo membro da família computacional de casa. Adotei inicialmente musashi-v3500, mas confesso que usar números e símbolos é algo tão frio que reservo essa falta de imaginação patogênica para as máquinas do trabalho.
Foi então que decidi usar o nome Bazinga. Seria uma clara homenagem ao seriado "The Big Bang Theory", e me elevaria aos níveis mais nerds possíveis. Mas durante esse pensamento, tive uma epifania: shibboleet.
shibboleet surgiu recentemente num quadrinho do xkcd. Encontrei o mesmo traduzido para português:
Achei fantástica a piada somente pelo "momento" da coisa, pela falta de suporte do help-desk. Como temos o suporte da HP na empresa, pra área de TI, senti o mesmo que o cara acima.
Mas recentemente, buscando essa mesma tira pra lembrar a palavra shibboleet, encontrei um artigo sobre o seu significado. Aparentemente é a fusão de shibboleth, uma palavra hebraica que é usada para distiguir se a pessoa que a pronuncia corretamente é de origem judaica, e leet, que quer dizer na linguagem *hacker* liderar.
XKCD é realmente uma viagem geek. Espero que meu novo laptop também o seja.
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 keyserver.ubuntu.com --recv $key | \
gpg --export --armor | apt-key add -
done
A saída será algo como:
gpg: requesting key 1F41B907 from hkp server keyserver.ubuntu.com
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
Update 2022-08-29: trocado subkeys.pgp.net por keyserver.ubuntu.com uma vez que o primeiro parece estar fora do ar.
O twitter tem sugado tanto minhas energias (e meus posts) que às vezes me sinto como essa tira do Dilbert...
Será que estou ficando tão burro assim?
Muitos dos seguidores no Twitter já sabiam, mas recentemente comprei um Mini Note Dexnet N280 na Saraiva. Uma das minhas preocupações era em relação à falta de referências sobre o mesmo. Mas o preço baixo e tentador superou minhas dúvidas. Enfim comprei o super-netbook, mas não para mim: pra uso da patroa :-).
Aqui segue então uma descrição do mesmo, para os que também estiverem considerando comprar um desses.
É um computador portátil que fica no meio termo entre um Netbook e um Notebook, sendo descrito como um "Mini Notebook". Mas eu diria que está mais pra um "Maxi Netbook", ou um Netbook vitaminado. Vem com uma confortável tela de 12.1 polegadas, muito clara e agradável, 2 GB de RAM, e 320 GB de disco. E processador ARM de 1.6 GHz dual core. O baixo consumo permite a ausência da famigerada "ventoinha", que faz o barulho chato de tempos em tempos. Isso tudo contribui em muito no peso dele: nem parece ter 1KG (1,3 KG descrito no manual).
É bem servida nos quesitos básicos de máquina, mas padece nos periféricos, aliás, sintoma de Netbooks em geral. Não tem unidade de CD/DVD. Somente duas portas USB e saida de som, sem entrada pra microfone. Mas vem com uma webcam embutida e uma porta HDMI. Isso mesmo: HDMI. Essa opção que fez diferença na escolha do equipamento. Mas não tem suporte à bluetooth... Tem também uma porta ethernet, que não testei, e placa wireless. E Linux instalado.
O equipamento tem boa apresentação externa, não aparentando ser um equipamento de segunda categoria, típico de produtos de mais baixo custo.
Eu não removi o plástico que envolve tanto a tampa quanto a tela para ter uma maior durabilidade do mesmo. Mas eventualmente isso deve sair.
A primeira coisa bizarra encontrada foi o teclado, que apesar de ser mencionado como ABNT-2, é na verdade um modelo português de Portugal, com as teclas como "/", "|" ou "-" em lugares estranhos. Mas tem o "ç".
O sistema operacional, que mencionarei mais adiante, não veio com o teclado configurado corretamente, mas uma tentativa-e-erro foi suficiente pra corrigir. Fora o teclado em modo bizarro, e descrito erroneamente - o que permite retorno do produto pela descrição incorreta, as teclas são muito pequenas. Pra quem já tem um Netbook e está acostumado, não sentirá problemas. Pra mim foi uma experiência bem ruim. O tempo todo digitei comandos errados por apertar duas teclas simultaneamente. Lembrei-me da cena de Ben Grimm, quando se torna o "Coisa" no filme do Quarteto Fantástico, e tenta usar um telefone público, destruindo as teclas. Se o computador fosse cor de rosa, eu seria exatamente um ogro no notebook da Barbie.
A saída de som, porta USB secundária e HDMI ficam numa parte embutida do note. Isso torna a aparência dos mesmos muito elegante, pois não ficam expostos quando não estão em uso.
Na caixa vieram mais alguns items, como o cabo de força no padrão novo (e que não tem tomada em casa), um manual, um certificado de garantia e um CD.
O cabo de força foi abandonado já que eu tinha sobrando um outro pelas redondezas. E no padrão das tomadas de casa: padrão americano.
Aliás diga-se de passagem que malditos sejam o pessoal da ABNT, Associação Brasileira de Normas Traduzidas, por não ter se pronunciado por anos sobre o padrão de tomadas, e agora definir um que não é compatível com o que já estava em uso.
O manual não apresenta muita novidade, mas coloca uma descrição geral do equipamento. Não foge muito da falta de informação presente no site da Saraiva.
Já o CD que acompanha o produto é um enigma. Além da cara de ordinário, não tem conteúdo legível. Não sei o que veio nele, nem encontrei referências. Ao menos podiam mandar um CD regravável pra ser mais útil.
A fonte de alimentação é bem leve, mas também tem cara de produto de segunda. Bem ordinário (na aparência) e com 300 W de potência. Mas é a única peça de equipamento que realmente deixa à desejar, não combinando com o restante. Mas me refiro ao equipamento. A fonte de alimentação combina em muito com o CD que veio junto.
Em relação ao sistema operacional, é um Linux que nunca tinha ouvido falar: Keep-OS. Buscando no Google, encontrei o site de referência como "http://www.keepsoftware.com". Eu achei que era um site de Linux chinẽs, mas fui supreendido com um puro produto brazuca.
E imaginei que era chinês pela baixa qualidade de acabamento. Além do teclado, que estava configurado errado, várias outras coisas estavam com aparência ruim. Tanto que inicialmente achei que estava configurado com KDE, mas o sistema é Gnome. Mexendo um pouco, pude ver que é baseado em Debian. Tanto que não tem Firefox, mas o Iceweasel, que é uma versão de Firefox mas que teve de ter o nome mudado (veja mais no site do BR-Linux).
É um Debian Sid, baseado no Squeeze. Veio com a tela sem as configurações pra suavizar as fontes, por isso estava com a aparência tosca. Uma mexida rápida no "Aparẽncia" do Gnome foi suficiente pra corrigir isso. Também mudei o tema para outro, com visual mais clean. Isso tudo deu uma boa renovada no sistema. Engraçado que até os ícones mudaram. A placa de vídeo é Intel, o que garante uma boa qualidade de imagem. Pela rápida olhada no sistema, tudo parece estar bem integrado, permitindo assistir vídeos, sites em flash e coisas que em geral são chatas de configurar no Linux sem mexer em nada.
Outra coisa ruim é em relação aos botões, como para iniciar e, principalmente, parar a rede wireless. É possível fazer isso utilizando a tecla de função, "fn", combinada com uma das teclas "F" mas não tem nada externo pra isso. É uma opção ruim pra quem usa muito avião, pois será necessário desligar o wireless com o equipamento ligado. A mesma coisa pra som.
Enfim parece um bom equipamento. Não é um supra-sumo, mas está bem acima dos Netbooks. Gostaria somente que tivesse vindo com teclado ABNT-2 mesmo e, claro, com bluetooth que faz uma certa falta justamente em máquinas que não tem leitor de CD/DVD.
Pra quem quer apenas visitar sites, olhar Youtube, e ver alguns vídeos é ideal. Pra quem utiliza muito o teclado, escrevendo resenhas, ou em blogs, eu recomendo um equipamento com teclado maior e mais confortável. Ainda mais se for estilo ogro, como eu.
Pode ser preciosismo meu, mas resolvi criar uma chamada em alguns programas para limpar a tela, ao estilo do comando clear.
Não imaginava por quais veredas inóspitas eu iria entrar...
Primeiramente devo dizer que é fácil fazer uma chamada pra um subshell e utilizar o próprio aplicativo clear.
#! /usr/bin/python
from os import system
system("clear")
Funciona, mas é tosco. E eu queria uma solução "unix like", daquelas que a gente tem orgulho de contar na mesa do bar, no encontro com amigos nerds (afinal serão os únicos que entenderão o que você estava dizendo, o que não significa que vão compartilhar o mesmo sentimento de orgulho que você estava sentindo).
Então mergulhei na biblioteca ncurses. Tentei algumas linhas simples, chamando um método curses.clear().
#! /usr/bin/python
import curses
scrn = curses.initscr()
scrn.clear()
curses.endwin()
Realmente funcionou, mas de uma forma indesejada, não restaurando as propriedades do terminal (você perde a alimentação do cursor, que só é restaurada após utililizar o comando reset).
Então resolvi utilizar o módulo termios para salvar o estado do terminal, e recuperar o mesmo após o método curses.clear(). Ficou um pouco maior do que eu imaginava, mas funcionou muito bem. Agora posso fazer meus scripts Python limparem a tela de uma forma muito elegante.
#! /usr/bin/python
import curses
import termios
from sys import stdin
fd = stdin.fileno()
scr = termios.tcgetattr(fd)
scrn = curses.initscr()
scrn.clear()
termios.tcsetattr(fd, termios.TCSADRAIN, scr)
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.
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
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...
Page 28 of 37
