Adicionando chave PGP/GPG de seus repositórios

Categoria: Linux Publicado: Sábado, 06 Novembro 2010 Escrito por Helio Loureiro

 

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.

PABX IP utilizando Asterisk

Categoria: Linux Publicado: Quinta, 23 Setembro 2010 Escrito por Helio Loureiro



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

Ubuntu-certified hardware

Categoria: Linux Publicado: Quinta, 23 Setembro 2010 Escrito por Helio Loureiro

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

Categoria: Linux Publicado: Domingo, 19 Setembro 2010 Escrito por Helio Loureiro

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

Buscando dados de CPU e memória via SNMP

Categoria: Linux Publicado: Sexta, 10 Setembro 2010 Escrito por Helio Loureiro

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