As emocionantes aventuras de um sysadmin linux na procura pelo uptime perfeito!

VULoad, para observar load average em terminais

Posted: outubro 5th, 2010 | Author: coredump | Filed under: Linux e Open Source, Programação | Tags: , ,

Update: dei uma mexida nele e já coloquei a versão nova no github. Agora ele parece um pouco mais rápido para sair. Atualizei o screenshot também (os mais atentos vão notar que as barras estão sendo desenhadas com dados de teste, bem mais altos que os loads mostrados no cabeçalho).

Nesse final de semana de eleição tivemos de colocar umas coisas no ar na EBC para atender as demandas de infraestrutura dos sistemas suportando as rádios, agência de notícias, apuração em tempo real e tv ao vivo, e para isso fizemos vários testes incluíndo balanceamento e carga. Num desses um dos colegas do desenvolvimento me sacaneou porque eu estava usando os gráficos do Zabbix para monitorar o load dos servidores, enquanto usava o iftop em um terminator todo repartido para ver como andava a rede dos mesmos.

Como nada é mais inspirador que uma boa aporrinhação-construtiva, tirei um tempo nas madrugadas para fazer um trequinho em python-ncurses para a próximas vez que eu precisar monitorar o Load Average de máquinas em modo console. Na verdade, eu imagino que já exista, mas como eu ando precisando reanimar meus skills em python eu nem me esforcei muito para procurar. Abaixo dois screenshots da paradinha em funcionamento:

Essa é minha máquina local, com quatro processadores e pouco load. Não tinha nada a mão para gerar um bom enfileiramento de processos então ficou assim mesmo.

A idéia é a seguinte: até o meio da tela eu mostro uma barra linear que vai até o valor de Load Average igual ao número de CPUs disponíveis na sua máquina (ou seja, até onde o seu Load Average está tranquilo, leia isso aqui para entender). Depois disso eu uso um multiplicador configurável (no código claro) para mostrar a barra de excesso de load. Visualmente é fácil de interpretar, mesmo se estiver com vários abertos na: se a barra passou do meio da tela o load está alto demais e processos estão começando a enfileirar, quanto mais pro final da tela, pior.

Ainda tem algumas coisinhas cosméticas para mexer, e eu ainda tenho de testar em uma máquina com load alto de verdade, para ver como ele se comporta (por exemplo, se ele vai conseguir se atualizar corretamente com um grande enfileiramento acontecendo).

Mais um screenshot, agora usando o terminator para mostrar duas telas simultâneas, no meu VPS que só tem uma CPU:

O código está no Github, você pode baixar direto clicando aqui. Obviamente, é GPL. É um bom exemplo de como usar ncurses com python também, para quem quiser ter um feeling de como era programar na era dos terminais. Por exemplo, eu tinha me esquecido como era ter de se lembrar de re-escrever a tela. Ou fazer barras usando código ASCII. Mas foi bem divertido. Vou dar mais umas hackeadas nele depois se pensar em mais informações ou alguma otimização que for interessante de fazer.

intel.

No Comments »

(quase) Trocando o Prism por um script de 60 linhas

Posted: outubro 6th, 2009 | Author: coredump | Filed under: Linux e Open Source, Programação | Tags: , , , , ,

Quase, mas quase mesmo.

O Prism é o antigo xulrunner da Mozilla. Básicamente é um browser capado para rodar aplicações web em janelas separadas do browser normal. Assim se a aplicação trava você não perde o browser, ou vice e versa. Eu uso bastante para rodar o gmail, o webmail do trabalho e o brizzly. O problema é que o treco é muito bloated. E da uns paus muito bizarros com SSL. E usa Gecko e mais uma estrutura gigante do Firefox por trás que não é bem necessário ao que ele se propõe.

Como o kov é minha musa inspiradora, resolvi dar uma fuçada no PyWebkitGTK e acabei escrevendo uma coisinha semi funcional em 60 linhas de Python :P . Chamei o script de prisw, tipo, Prism com o M invertido vira W de WebKit. Ta-dã.

A parte mais importante tá aí: ele lê arquivos de configuração e roda em janelas separadas. Eu só não parei de usar o Prism ainda porquê preciso:

  1. Colocar o código para que links clicados sejam passados para o OS (eu não quero abrir janelas e urls dentro da mesma app)
  2. Tratar o título da janela com relação a mudanças que acontecem no TITLE das páginas (gmail e brizzly fazem isso)
  3. Talvez colocar uma opção para mostrar uma barra de status, nem que seja para mostrar se o SSL está ativo
  4. Lidar com cookies. Atualmente, mesmo que eu peça para guardar informações de login/etc, essas infos não tem onde serem salvas.

O WebKit que eu estou usando tem alguns probleminhas também com dimensionamento de janela, mas parece que já estão resolvendo no upstream. Daqui umas 2 semanas eu revisito o código e quem sabe eu posso parar de usar Prism, e ainda ganhar as vantagens do WebKit (velocidade, javascript violentamente rápido, etc…).

Aliás, tenho de dizer que optparser e configparser fazem a vida ficar extremamente simples ao se lidar com linhas de comando e arquivos de configuração em python viu.

Sintam-se livres para baixar e fuçar o script, ele é GPL, claro.

intel

No Comments »

Os 25 erros de programação mais perigosos segundo a SANS

Posted: janeiro 22nd, 2009 | Author: coredump | Filed under: segurança | Tags: , ,

Saiu no site da SANS a lista criada com o consenso entre varios profissionais e empresas do ramo de segurança e desenvolvimento descrevendo os 25 erros de programação mais perigosos para o desenvolvimento seguro. Eu vou traduzir os nomes e informação básicos mas o melhor é ler o artigo na íntegra, em inglês.

Os erros estão separados em três categorias: Interação insegura entre componentes, Gerenciamento arriscado de recursos, Defensas porosas.

Categoria: Interação insegura entre componentes

  1. Validação Imprópria de Entradas: Entradas que recebem dados e os aceitam mesmo sem certificar que eles são do tipo/formato esperado.
  2. Codificação ou Escape Impróprios de Saída: Saídas que não são codificadas ou escapadas corretamente são a maior fonte de ataques de injeção de código.
  3. Falha ao Preservar a Estrutura da Busca SQL (conhecido como Injeção de SQL): Se os atacantes podem influenciar as procuras SQL do seu programa, então eles podem controlar o seu banco de dados.
  4. Falha ao Preservar a Estrutura do Código da Página (conhecido como “Cross-site Scripting”): Assim como o anterior, se os atacantes podem injetar código ou scripts em sua página, eles podem controlar a página.
  5. Falha ao Preservar a Estrutura de Comandos do Sistema Operacional: Se você permitir que entradas ilegais sejam passadas para aplicativos do sistema operacional, o atacante pode controlar o servidor.
  6. Transmissão de Dados Sensíveis em Texto Puro: Senhas, dados de cartão e qualquer informação considerada sensível deve ser criptografada.
  7. Falsificação de Requisição Entre Sites: Um atacante pode criar uma requisição que é enviada a outro site forjando a origem e fazendo o mesmo partir de um usuário inocente, aproveitando credenciais de autenticação e acessos.
  8. Condição de Corrida: Atacantes vão sempre procurar por condições de corrida no software para conferir se alguma informação importante não é obtida no processo.
  9. Vazamento de Informações em Mensagens de Erro: Atacantes vão procurar por mensagens de erro que descrevam mais que o necessário, como nomes de campos SQL, objetos e bibliotecas sendo utilizadas.

Categoria: Gerenciamento arriscado de recursos:

  1. Falha ao Limitar Operações aos Limites de um Buffer de Memória: O conhecido buffer overflow.
  2. Controle Externo de Dados Sensíveis: Informações críticas que são mantidas fora de um banco de dados por questões de performance não deviam ser facilmente acessíveis por atacantes.
  3. Controle Externo de de Caminho ou Nome de Arquivo: Quando você usa dados externos para montar um nome de arquivo ou caminho de gravação, você está se arriscando a ser atacado.
  4. Caminho de Procura Inseguro: Se o caminho de procura de recursos estiver em algum lugar sob controle de um atacante, bibliotecas ou código pode ser inserido a revelia.
  5. Falha ao Controlar a Geração de Código: Caso o atacante consiga influenciar a geração de código dinâmico (se geração de código dinâmico for utilizada no programa) ele poderá controlar todo seu código.
  6. Download de Código sem Verificação de Integridade: Se você executa código obtido por download, você confia na fonte. Atacantes podem aproveitar esta confiança.
  7. Desligamento ou Liberação Impróprias de Recursos: Arquivos, conexões e classes precisam ser corretamente encerradas.
  8. Inicialização Imprópria: Dados, bibliotecas e sistemas inicializados incorretamente podem abrir margens para problemas.
  9. Cálculos Incorretos: Quando o atacante tem algum controle sobre as entradas usadas em operações matemáticas, isso pode gerar vulnerabilidades.

Categoria: Defensas porosas:

  1. Controle de Acesso Impróprio: Se você não garante que seus usuários estão fazendo apenas o que deviam, os atacantes irão se aproveitar de sua autenticação.
  2. Uso de um Algoritmo Criptográfico Quebrado ou Vulnerável: Utilização de algoritmos fracos ou comprometidos levam a falhas de criptografia e vulnerabilidades.
  3. Senha no Código: deixar um usuário e uma senha no próprio código traz inúmeros problemas.
  4. Permissão de Acesso Insegura para Recurso Crítico: Configurações, arquivos de dados e bancos de dados devem ter suas permissões de acesso protegidas.
  5. Uso de Valores Insuficientemente Aleatórios: Se você usa tipos de segurança que dependem de aleatoriedade, usar um gerador aleatório insuficiente só vai causar problemas.
  6. Execução com Privilégios Desnecessários: Se seu programa precisa de privilégios elevados para executar suas funções, ele deve abrir mão destes direitos assim que ele termina de executar as ações que precisavam dos privilégios.
  7. Aplicação de Segurança do Lado do Servidor pelo Cliente: Atacantes podem usar engenharia reversa em um cliente de software e escrever seus próprios clientes removendo testes e aplicações de segurança.

Algumas coisas foram realmente chatas de traduzir, sinta-se livre para sugerir correções.

intel

PS: Lembre-se sempre “os 25 mais” não quer dizer “os 25 únicos”. Grain of Salt faz bem.

8 Comments »

Meus Projetos Parados

Posted: setembro 15th, 2007 | Author: coredump | Filed under: Linux e Open Source, Programação | Tags: ,

Costumo plagiar meu amigo Bruno lá de Divinópolis: “Eu tenho uma pilha de projetos, os projetos novos vão pro alto da pilha e os antigos ficam parados, embaixo”.

A verdade é que minhas grandes idéias acabam sendo implementadas antes, ou já existem :)

Recebi um email de um cara que viu meu post sobre os testes do Cavando! e que gostaria de ver o código e tal. Então abri o acesso ao trac dos projetos para que os interessados vejam alguns exemplos (eu espero que bons) de programação python/turbogears. Imagino que seja aconselhado dizer que mesmo que não existam cabeçalhos especificando, o código é GPL e se alguém quiser continuar/utilizar, vai fundo. Eu vou ver se na semana que vem coloco os cabeçalhos e a licença.

https://devel.core.eti.br/

intel.

PS: Mas existe um projeto meu que pode retornar do fundo da pilha! Vamo ver se na semana que vem eu mexo com mais análise de logs!

No Comments »

Python: Chega de enviar email sem acento!

Posted: agosto 7th, 2007 | Author: coredump | Filed under: Programação | Tags: ,

Então, quem já escreveu um script Bash ou mesmo PHP já entendeu os problemas que acontecem ao tentar enviar acentos e arquivos, sem contar tentar montar uma mensagem HTML para enviar via email.

Felizmente Python já tem a solução:

from email.MIMEText import MIMEText
from email.Header import Header

texto = “Um texto qualquer com acentos a ser enviado.”
mensagem = MIMEText(texto)
remetente = ‘endereco@dequem.envia’
destino = ‘endereco@dequem.recebe’

# Eu sempre uso utf-8, mas pode ser qualquer charset

mensagem.set_charset(‘utf-8′)
assunto = Header(‘Assunto com acentos’, ‘utf-8′)
mensagem['Subject'] = assunto
mensagem['From'] = remetente
mensagem['To'] = destino

E pronto. Você consegue uma cópia prontinha en ascii da mensagem para colocar como corpo do seu email usando mensagem.as_string(), pode ser usando inclusive no método sendmail da classe smtplib.SMTP (que é o ideal).

Para fazer uma mensagem HTML basta criar uma mensagem Multipart e adicionar um MIME de HTML e quem sabe de imagens. Mais informações e exemplo em: http://docs.python.org/lib/node162.html

Python comanda.

intel

2 Comments »