Do nosso lado também é bom, pois fica mais fácil garantir a qualidade do hardware, acesso fácil aos servidores e sem nenhum nego fução mexendo em configuração e fazendo caquinha.

Um dos problemas de gerenciamento, porém, é quando você tem diversos clientes diferentes na mesma máquina e um deles monopoliza o tempo de processador. Isso acontece muitas vezes devido a  clientes fazendo teste em ambiente de produção, relatórios enormes sendo rodados em dias críticos ou simplesmente por bugs no software que fazem um processo chupar 100% de CPU.

Uma solução que achei recentemente foi o cpulimit, que consegue limitar o tanto de CPU que um processo usa diminuindo o problema causado por ele em caso dele começar a descer a ladeira sem freio.

O chato dele é o fato de que você precisa especificar qual processo deseja limitar e num ambiente como o nosso, onde novos processos aparecem e morrem o tempo todo, é preciso automatizar.

Acabei criando o script abaixo, que ainda precisa ser muito trabalhado, mas estou já publicando na esperança de conseguir algum bom feedback em como melhorá-lo. Não me entendam errado: ele já funciona.

Download aqui: limitcpu.py

UPDATE2: Mudei o Trac de lugar.

Já que estou aprendendo a programar mesmo pensei em colocar algumas das coisas que estou vendo para ajudar no que eu realmente trabalho: administração de sistemas.

Um problema que já vi N vezes é manutenção de uma base de dados com subnets, ips, switches, portas e hosts dentro da empresa. Mesmo no meu emprego atual alocação de IP é feito na base do “pingou, não respondeu, tá vago”. E não só lá, mas diversos outros lugares por onde passei era a mesma história.

E nos switches a mesma coisa. “Fulano, que host é esse na porta X que tá dando erro de CRC pra caramba? Não sabe? Perai que vou ver o MAC dele… ” E ai começam os 15 minutos de arp/ping/nslookup pra descobrir que host era…

Pior quando a equipe de redes e a equipe de sistema operacionais não se entende e rola um troubleshooting de 2 horas para descobrir que o host certo, com o ip certo estava na porta certa do switch certo, mas com a vlan errada. Tenho pesadelos com isso até hoje.

Felizmente alguém pensou nisso no meu último trampo no Brasil e tentou resolver o problema. Mas a tentativa era apenas uma planilha Excel com todas as informações necessárias. O que funcionaria bem, se todo mundo tivesse sempre a mesma versão. O que não acontecia nunca, pois sempre alguém tinha um email velho, uma cópia salva no desktop ou, pior ainda, uma versão impressa de 2 semanas atrás.

Eu sempre quis criar uma versão web desse negócio, mas a falta de conhecimento sempre foi um problema e agora que tá sendo goela abaixo mesmo, vou aproveitar.

Além disso todo nerd precisa de um pet-project, certo?

Então tentei começar já do jeito certo, usando Python/Django (afinal não quero ficar me repetindo). Ainda assim está sendo mais complicado do que eu imaginei, já que a cada poucas linhas de código tenho que parar para ler umas 10 páginas de documentação até achar o que eu quero. Isso sem contar que criar os modelos me deu nó no cérebro.

De qualquer forma, convido a todos os meus (3) leitores a dar uma olhada no projeto e adicionar umas linhas de código nele. Criei um repositório SVN de onde você pode importar usando:

svn co http://svn.linuxman.pro.br/nettrack

E ainda está bem crú, mas logo dou uma incrementada no Trac.

Fato: Eu sou preguiçoso pra cacete e odeio trabalho repetitivo. Logo, automatizar é preciso. As coisas que automatizei eu raramente precisaria fazer eu mesmo, já que tem o pessoal mais júnior pra fazer. Porém se eles estiverem fazendo esse trabalho chato e tedioso, outras coisas chatas e tediosas iam sobrar pra mim. E projeto, que é legal, vai ficando pra depois. Entenderam onde quero chegar?

O problema é que a empresa é pequena. Com 2 semanas de casa automatizando coisas já corria o boato que “o cara novo manja muito de script”. E ai, como diria o Dilbert, bate a maldição de ser competente.

90% dos negócios da empresa estão em cima do principal software, logo tem uma equipe de desenvolvedores que é praticamente metade dos funcionário da empresa. E eles estão atolados até a alma de coisa para fazer. Mas surgiu uma necessidade urgente (uns 3 meses atrás) de fazer parse em uns arquivos para analisar os dados e até então ninguém tinha nem olhado. E deram previsão de mais 6 meses antes de ter tempo de olhar.

O gerente de contas do cliente então chega pro cara novo (aka esse que vos fala) e pede: Será que você pode dar uma olhada? Hum… desenferrujei um pouco do Python e fiz o treco pro nego. A lógica é de pobre, mas é limpinha. Funciona e é o que interessa.

Mas e ai? Ai que ele ficou tão feliz que foi falar com o meu chefe se ele não me “emprestava” pra expandir o projeto, fazer sistema de relatorio, analise anti-fraude, transferência de arquivo…

Resumindo… caiu a casa pro meu lado. Vou passar um bom tempo agora em projeto de desenvolvimento. Mas eu vou armado, parceiro. E de farda preta:

Python

Meus caros leitores desenvolvedores, se preparem… porquê vou encher o saco de vocês com perguntas. Posso não ser programador, mas conheço um monte deles. E, pelo menos eu espero, vou conseguir tocar um projeto inteiro sozinho. Quem diria… Eu, programador.

Eu cai na seguinte situação: Tenho um número X de servidores que tem um usuário que eu posso utilizar para dar login. Existem 4 senhas possíveis para este usuário, mas eu não sei qual senha está em qual servidor, de forma que eu tenho que ir tentando até conseguir quando tento conectar no mesmo.

Depois de conseguir dar login na máquina eu tenho que virar root. Eu sei que cada servidor tem uma senha de root diferente, mas sempre que eu usar a senha de usuário X a senha de root vai ser Y, senha de usuário A, senha de root B.

Até o momento só consegui semi-automatizar o processo, mostrando na tela qual senha funcionou para o usuário, de forma que eu vou saber qual senha de root usar. O ideal é automatizar o login de forma que eu só precise bater o nome da máquina e já caia no prompt de root.

O que fiz foi:

#!/bin/bash
 
senhas="senha1 senha2 senha3 senha4"
 
SERVER=$1
 
for senha in $senhas
do
    export SSHPASS=$senha
    echo "Tentando $senha"
    sshpass -e ssh user@$SERVER
    [ $? -eq 0 ] && exit
done

O Pascal me sugeriu o paramiko, mas acho que ele não tem a funcionalidade de me entregar o prompt de comando. Estou tentando também usar o Pexpect, mas sem muita sorte.

É uma suite com lice[cs]iamento duplo, com uma versão open-source utilizando Yahoo! Public License (ah, sim… o Zimbra pertence ao Yahoo!) e uma versão comercial. Desta forma o core do projeto é aberto e as modificações mais interessantes para as empresas são fechadas. Um modelo que eu gosto.

Nas últimas semanas, mesmo ainda estando rodando apenas um piloto, fomos bem atendidos pelo suporte técnico, pelo gerente de vendas e até por um senior engineer, que me ajudou a a fazer o sizing do hardware.

Já temos o Zimbra instalado numa faculdade associada, cuja migração comentei recentemente, e lá descobrimos um bug no outlook connector. Seguindo o modelo open-source utilizei o bugzilla deles, onde alguém já havia reportado o problema, votei no bug, descrevi o problema e eles reproduziram localmente, arrumaram o código e já colocaram no CVS pra sair no próximo release da suite. Sensacional. Experimenta tentar isso com a Microsoft – cuja suite, o Exchange, também estamos analisando.

Entre as features que me atraíram para o Zimbra está a CLI deles. Tudo pode ser feito via shell e, consequentemente, tudo pode ser automatizado ou transformado em script.  Nossos usuários vão ser provisionado à partir de uma base LDAP e não precisei mais do que uns 30 minutos para fazer um script em Python pra fazer isso.

Não que a interface de administração seja ruim, mas pra que usar mouse se posso usar só o teclado?

Ainda estamos analisando outras possiblidades, mas até o momento o Zimbra parece ser um forte candidato e se você está procurando uma ferramenta de colaboração de qualidade, por um preço razoavelmente bom (não muito mais barato do que um Exchange na verdade) e com bastante facilidade para administrar vale a pena analisar o Zimbra.

C seria Judaismo: É antiga e restritiva, mas a maior parte do mundo está familiarizada com suas leis e as respeita. A pegadinha é que você não pode se converter para ela – ou está lá desde o início ou vai pensar que é insanidade pura. Além disso, quando as coisas dão errado, muitas pessoas estão dispostas a colocar nela todos os problema do mundo.

O texto completo, em inglês, aqui.

Para facilitar minha busca fiz um script que disponibilizo aqui para quem tiver interesse.

Além do script vai precisar também do arquivo contendo a lista de IP vs País que pode ser baixado aqui.

Pior ainda quando você precisa que alguém com menos experiência ou conhecimento (aka suporte nível 1) verifique para você o estado do servidor.

A idéia é então centralizar essa checagem num único script, simples e funcional, para facilitar a sua vida e a dos outros admins.

Tenho certeza que já existem por ai trocentos scripts/programas/whatever para fazer isso, mas eu estava entediado e precisava usar um pouco de Perl para não enferrujar completamente (É… ando usando só Python e Bash).

O script está disponível aqui e está bem documentado e é de simples entendimento.

Basta criar um arquivo /etc/checks.txt contendo o que você esperaria ver rodando normalmente e está feito.

Ai te ligam no meio do seu final de semana na praia precisando que você faça alguma coisa e adivinhe: Tudo que você tem é um acesso tosco do hotel, que permite apenas HTTP no seu laptop. Ou ainda pior: Você não tem laptop e seu único acesso é numa lanhouse ruim, que te permite apenas abrir o IE6 e nem pensar em instalar o putty.

Como seria bom um estagiário, um auxilar ou um mordomo para resolver a sua vida.

Pois seus problemas se acabaram-se!

Usando o JabberBot, que é uma implementação de um robô Jabber baseado em Python, você pode fazer um bocado de coisa interessante.

Dê uma olhada lá e use a imaginação para criar as funcionalidades que quiser.

Olha o meu ai:

Sou apenas um sysadmin metido a besta que gosta de fazer uns scripts de vez em quando. No meu antigo emprego eu fazia muitos, mas sempre para aplicações específicas, que não teriam uso para mais ninguém fora da empresa.

Mas no atual emprego estou fazendo coisas mais genéricas e resolvi compartilhar este script que fiz estes dias. Ainda está bem verde e mostra claramente minha falta de finesse como programador.

Se você utiliza Ubuntu e tem o UFW ativado já deve ter reparado que os logs que ele gera não são exatamente fáceis de ler. Nada que um bando de pipes, greps, seds e cuts encadeados não resolva, mas como o UFW em si é feito em Python e eu ando querendo melhorar meus conhecimentos nesta linguagem, resolvi fazer meu parser também em Python.

Se alguém eventualmente baixar e usuar este treco, depois me fala o que achou e me mande patches.

Download aqui.