andrelop’s blog

Gerenciamento de atualizações : uma solução simples e eficaz

Para aqueles, como eu, que precisam administrar dezenas de servidores e mantê-los atualizados em relação a aplicação de atualizações de segurança, a forma mais fácil de cumprir essa tarefa seria automatizá-la ao máximo.

Porém, quando o assunto é aplicação 100% automatizada de novas versões de pacotes de softwares em servidores de produção sem intervenção humana alguma, eu tendo a ter um nível de aceitação bastante baixo para essa idéia, por razões óbvias.

A solução, em meu caso, foi adotar uma solução que automatiza parcialmente o processo de gerenciamento de atualizações. A parte que exige mais participação intelectual, ou seja, a aplicação das atualizações propriamente ditas, eu mesmo prefiro executar manualmente, visto que posso interferir caso qualquer problema maior ocorra.

Como utilizo Debian GNU/Linux na imensa maioria dos servidores que administro, as tarefas de checar pela disponibilidade de atualizações e fazer o download das mesmas são triviais, já que existe suporte para fazê-las de forma bastante simples nas ferramentas de gerenciamento de pacotes nativas do próprio sistema operacional.

Porém, mesmo com a simplicidade e facilidade fornecida por essas ferramentas, quando a quantidade de servidores a ser administrada cresce a tarefa de ter que checar pela disponibilidade das atualizações, verificar a aplicabilidade de cada uma delas a cada um dos servidores administrados e fazer o download das mesmas, deixando as atualizações guardadas em um cache local para posterior aplicação, é algo que começa a consumir um tempo bastante grande.

Para facilitar, adotei já há alguns anos uma solução de gerenciamento de atualizações (que pode ser configurada para aplicar automaticamente as atualizações de maneira relativamente simples, mas não pretendo usar essa funcionalidade) bastante simples que cumpre essas tarefas de forma bastante satisfatória.

Trata-se do apticron, um script shell bem simples e disponível como um pacote Debian nos repositórios oficiais de pacotes Debian. Instalá-lo é tão simples quanto instalar qualquer outro pacote Debian comum, ou seja, ele se encontra somente a um aptitude install de distância

Após instalá-lo, costumo modificar somente duas variáveis no arquivo de configuração /etc/apticron/apticron.conf : a variável de nome EMAIL e a variável de nome LISTCHANGES_PROFILE.

Para a primeira variável, forneço como valor o endereço de e-mail no qual eu desejo receber as mensagens de aviso que serão enviadas pelo apticron quando novas atualizações estiverem disponíveis e, no caso da segunda, simplesmente descomento a linha que define a variável, deixando a mesma com o valor apticron.

Isso faz com que, ao enviar as mensagens de aviso de atualizações aplicáveis aos seus servidores, o apticron obtenha a saída do utilitário apt-listchanges (mais um utilitário interessante disponível também como um pacote Debian nos repositórios oficiais Debian e também somente a um aptitude install de distância) e a envie juntamente as mensagens de aviso, o que lhe permite conhecer, além dos pacotes e versões novas disponíveis para instalação, a lista de mudanças (o changelog) dos pacotes para os quais existam atualizações disponíveis.

Além de lhe avisar sobre as atualizações disponíveis e aplicáveis aos seus servidores, o apticron, por padrão, já faz o download das mesmas e as deixa no cache local de pacotes de seu gerenciador de pacotes, de forma que, posteriormente, você precise somente se conectar ao servidor analisado pelo apticron e executar o comando a seguir :


# aptitude upgrade


Pronto. As atualizações deixadas em seu cache local de pacotes serão utilizadas e aplicadas em seu servidor, da mesma forma como você costuma atualizar seus pacotes Debian em um processo usual, sem o envolvimento de nenhuma ferramenta de gerenciamento de atualizações como o apticron.

A execução do apticron ocorre diariamente (por padrão, mas isso pode ser modificado conforme sua necessidade) junto a execução das tarefas agendadas para execução com periodicidade diária pelo cron, sob o diretório /etc/cron.daily (mais especificamente, no arquivo /etc/cron.daily/apticron).

Como se trata de um script shell simples (em /usr/sbin/apticron), o apticron pode ser modificado facilmente, inclusive para que as atualizações já sejam aplicadas automaticamente após o donwload das mesmas, caso desejado.

Novamente, isso não seria algo que eu recomendaria, visto que existem diversos detalhes a serem observados durante uma atualização e decisões que precisam ser tomadas por um intelecto humano (e não por um script shell simples), as quais, nem sempre, possuem uma resposta padrão válida para todos os casos.

De qualquer forma, acredito que o apticron cumpre realmente as tarefas que se propõe a cumprir, de forma simples e descomplicada. Para outras necessidades mais exóticas, uma possibilidade seria utilizar o cron-apt.

Pessoalmente, posso dizer que já utilizei o cron-apt e acabei optando pelo apticron por esse último ser mais simples, cumprir somente as tarefas que eu realmente precisaria automatizar (sem mais nem menos) e funcionar de forma mais confiável que o cron-apt em meus testes.

Por último, apesar de ser evidente para os leitores que chegaram até aqui, esta é uma solução específica para distribuições GNU/Linux baseadas em pacotes Debian. Qual a solução que vocês utilizam para seus servidores, sejam eles baseados em um sistema de gerenciamento de pacotes Debian ou não ? Deixe suas dicas, experiências e indicações nos comentários.

Masoquismo virtual 102 : configurando um MX secundário (the easy way)

Eu não me canso de ficar espantando com a facilidade de se fazer as coisas com o Postfix se comparando a outras soluções de MTA, sejam elas proprietárias ou livres.

Hoje precisei configurá-lo para que meu servidor de mensagens pudesse temporariamente atuar como MX secundário para alguns domínios de um amigo, de modo que os mesmos não ficassem completamente invisíveis para todo o mundo durante a movimentação de um servidor para outro.

Minha tarefa foi somente fazer a porção que me cabia como administrador do servidor que atuaria como MX secundário e não também configurar o servidor que já atua como MX primário. Para minha surpresa, foi algo extremamente simples de ser feito usando Postfix, como eu já esperava, dadas as minhas experiências anteriores felizes lidando com o mesmo.

Eu simplesmente tive que incluir os domínios em questão no parâmetro relay_domains e me certificar de que o parâmetro smtpd_recipient_restrictions tivesse uma restrição que checasse os domínios anteriormente listados no parâmetro relay_domains. Para isso, a documentação do Postfix indica o uso da restrição check_relay_domains, mas essa restrição ficou obsoleta e foi substituída pela restrição reject_unauth_destination já há alguns anos.

No final, as linhas inseridas/modificadas no arquivo de configuração principal do Postfix (arquivo /etc/postfix/main.cf em meu caso) foram as seguintes :


relay_domains = $mydestination, dominioadicional1.com, dominioadicional2.com, dominioadicional3.com

smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, check_policy_service inet:127.0.0.1:60000, reject_unauth_destination


Para essa tarefa, a única restrição realmente importante a ser inserida no parâmetro smtpd_recipient_restrictions é a restrição reject_unauth_destination. As outras restrições presentes cumprem outras tarefas que não vem ao caso no momento e não são assunto para este post (quem sabe um post futuro).

Isso já foi o bastante para que meu servidor passasse a receber as mensagens destinadas aos domínios adicionais e enfileirá-las localmente, de forma que as mesmas ficassem armazenadas temporariamente até que o servidor MX primário voltasse a ficar operacional posteriormente.

Mas o leitor esperto irá notar que, somente com essa configuração, estamos recebendo toda e qualquer mensagem destinada aos domínios adicionais em questão. Lógico, meu antispam e minha solução de greylisting vão cuidar da maioria da porcaria virtual, mas seria importante receber e manter as mensagens somente para os endereços reais dos domínios adicionais e não para qualquer coisa que termine com os domínios em questão como endereço.

Para isso, simplesmente utilize o parâmetro relay_recipient_maps e aponte para um mapa de lookup do Postfix que contenha os endereços os quais você saiba que são endereços realmente válidos. Um exemplo de configuração desse parâmetro seria, no arquivo de configuração principal do Postfix, o seguinte :


relay_recipients_maps = hash:/etc/postfix/relay_recipients


O próximo passo é criar o arquivo apontado pelo parâmetro relay_recipients_maps, ou seja, no caso, o arquivo /etc/postfix/relay_recipients. Esse arquivo irá conter os endereços válidos dos domínios adicionais da seguinte forma :


usuario1@dominioadicional1.com OK
usuario2@dominioadicional1.com OK
usuario1@dominioadicional2.com OK
usuario2@dominioadicional2.com OK
usuario1@dominioadicional3.com OK
usuario2@dominioadicional3.com OK


Para finalizar, criamos o arquivo /etc/postfix/relay_recipients.db usando o comando o comando postmap e forçamos a releitura do arquivo de configuração principal do Postfix recém modificado, usando os comandos a seguir :


# postmap /etc/postfix/relay_recipients
# postfix reload


Pronto. A partir de agora, quando o servidor de mensagens que atua como MX primário dos domínios adicionais em questão for colocado fora de funcionamento temporariamente, as mensagens que antes seriam entregues ao mesmo serão recebidas por meu servidor, enfileiradas temporariamente no disco local e entregues de volta ao servidor que atua como MX primário quando este voltar a operar novamente.

Com a vantagem de que mensagens destinadas a endereços inválidos ou inexistentes destes domínios adicionais serão rejeitadas por meu servidor atuando como MX secundário, o que evitará que tais mensagens ocupem recursos do servidor (como espaço em disco, por exemplo) para depois serem sumariamente apagadas quando forem repassadas ao MX primário.

Prevenção virtual 102 : usando backups pessoais versionados (the even cheaper way)

Não, ao contrário do que você pensa, esse não é mais um daqueles posts chatos que falam sobre a importância de backups, puxa suas orelhas por você não estar em dia com eles e lhe deixa com uma sensação de estar fazendo algo errado e de que, a qualquer momento, poderá sofrer com isso.

Mesmo você sabendo que isso tudo é a mais pura verdade, ninguém precisa ficar lhe lembrando sobre isso a todo momento e lhe aporrinhando com esse assunto. Backup sempre é e sempre será esquecido. É comum (ou, ao menos, deveria ser) não esquecermos dos backups de nossos clientes, nossos servidores e de nossos sistemas mais importantes, mas nossos backups pessoais sempre acabam ficando esquecidos.

Por quê ? Simples : porque soluções que você simplesmente coloca para funcionar uma única vez e esquece, deixando que tudo seja feito de forma transparente, são difíceis de serem encontradas e, quando o são, não são das mais fáceis para serem implementadas nem compreeendidas.

Para resolver esse problema, eu escrevi um pequeno script shell simples que uso para meus backups pessoais. Funciona de maneira estremamente simples e me permite ter backups diários ou com periodicidades ainda menores (diversas vezes por dia, por exemplo) ocupando um espaço desprezível em relação ao que seria ocupado caso backups completos fossem utilizados e, de quebra, me permite restaurar a cópia de qualquer arquivo desejado, de uma data específica desejada, sem que seja necessário sair por aí procurando por inúmeras fitas ou sem que seja necessário que eu seja obrigado a usar soluções de backup que criam catálogos de backup e que possuam um uso mais complexo.

Facilidade, esse é o objetivo. Minha solução usa o famoso rsync para implementar backups diferenciais e, mais especificamente, faz uso da opção –link-dest do rsync para criar cópias posteriores dos backups utilizando hardlinks para os arquivos originais da primeira cópia do backup.

O script cria um diretório para cada uma de suas invocações, contendo o dia, mês, ano, hora, minuto e segundo de sua execução e inclui o backup nesse diretório. Dessa forma, você possui uma visão completa de todo o seu conteúdo de backup sob esse diretório representando esse momento no tempo. Sim, o conteúdo completo, tudo, sem mais nem menos, com a diferença de que não é a cada execução que tudo é realmente copiado para o novo diretório criado.

Somente os arquivos/diretórios modificados são criados e, para o restante, somente hardlinks para os arquivos originais criados como resultado da primeira execução do script são criados. O script mantém um arquivo de controle para saber qual o momento no tempo da última execução e ter uma base para saber a partir de qual ponto deve checar por modificações em suas próximas invocações.

O único detalhe é que, como hardlinks não funcionam entre dispositivos (ou seja, entre partições ou discos diferentes), todos os backups devem ser armazenados no mesmo disco ou partição de disco. Sempre, sem fugir dessa regra para não ter uma bela surpresa com espaço em disco astronômico sendo consumido sem necessidade.

Se interessou ? Ok, mão na massa então. Simplesmente copie o script postado em sua íntegra abaixo e grave-o com um nome qualquer desejado, torne-o executável e preencha o valor das variáveis target, sources e lastrunfile, ou seja, o local onde os backups serão criados, qual o conteúdo que será alvo de backup e qual a localizaçao do arquivo que conterá a informação do último momento no tempo em que a última execução do backup foi feita (ele é criado automaticamente na primeira execução do script), respectivamente.

O conteúdo completo do script é o seguinte :


#!/bin/bash

# Store the identification of our last run into a non-volatile
# place so we can use it on further runs
echo $pit > $lastrunfile


Simplesmente execute o script de tempos em tempos, provavelmente agendado no crontab de um usuário que tenha permissões de ler os arquivos que sofrerão o backup e gravar no local onde o backup deverá ser armazenado (o root serve, mas não necessariamente precisa ser ele). É isso. Simples e fácil. Deixe o cron, o anacron ou seu agendador de tarefas preferido sendo executado e esqueça de suas preocupações com backup.

Lógico que o script pode melhorar bastante. Na verdade, tenho algumas idéias para melhorá-lo já a algum tempo, mas venho usando essa mesma solução a alguns meses sem maiores problemas e ela vem me atendendo bem, por isso nunca achei que fosse necessário melhorá-lo.

Funciona tão bem que algumas pessoas na empresa onde trabalho utilizam uma versão modificada dele, a qual eu modifiquei levemente para que o transporte ssh do rsync fosse utilizado, de forma que eu tivesse a mesma funcionalidade, mas em um ambiente em que o dispositivo que recebe o backup é uma partição de disco em um servidor remoto.

A imaginação é o limite. O que achou da solução ? Gostou ? Comente suas impressões e me deixe feliz ou profundamente triste caso minha solução seja muito tosca

Masoquismo virtual 101 : mantendo lixo fora de sua caixa-postal (the cheap way)

Com exceção das pessoas que não estão ligadas a área de tecnlogia e, por isso, para as quais não consigo explicar o que faço, a maioria absoluta das pessoas com as quais comento sobre o fato de eu gostar de lidar com implantação e configuração de servidores de e-mail me acham no mínimo ligeiramente lesado mentalmente.

Eu posso entender o que elas sentem. Hoje em dia, com serviços de múltiplos gigabytes de espaço sendo oferecidos gratuitamente (caramba, mais de 4GB no Gmail é um bom espaço só para mensagens), a utilização cada vez maior de webmails e a complexidade de se manter um servidor de e-mail próprio saudável devido as inúmeras pragas virtuais que se propagam como, bem … pragas, ninguém em sã consciência optaria por manter seu próprio servidor de e-mails.

Isso pode ser material para análise futura, quando quiserem identificar quando meus problemas mentais começaram a me afetar de forma mais intensa, mas eu tenho que dizer : eu mantenho meu próprio servidor de e-mails. E, pasmem, eu me divirto fazendo isso. Na verdade, estava dias desses mesmo pensando sobre como diminuir meus gastos com hospedagem de meu servidor virtual, mas quando cheguei a conclusão de que teria que abrir mão de ter meu próprio servidor de e-mails, tive que adiar a decisão para um futuro distante, lá para perto da época em que eu tiver que fazer a renovação de meu plano de hospedagem, só no próximo ano.

Uma das coisas mais interessantes em manter servidores de e-mails (eu mantenho alguns além do meu próprio, principalmente servidores de diversos clientes) é ter que sempre se atualizar para estar por dentro das técnicas e ferramentas que podem ser utilizadas para combater a sempre crescente mania de malucos que acham que você está interessado em adquirir viagra diariamente tem de tentar lhe convencer a comprar alguma coisa inútil.

Uma das formais mais fáceis e eficientes (por enquanto, isso pode mudar rápido) de se evitar receber muito lixo virtual é usando alguma solução de greylisting, em adição a outras técnicas de combate a lixo eletrônico circulando via e-mail.

A técnica de greylisting se aproveita do fato de que uma grande parcela dos spammers não tentam reenviar as mensagens após a primeira tentativa de envio ter gerado uma falha de entrega. Logicamente, eles vão aprender a fazer isso mais cedo ou mais tarde e alguns com menor índice de dislexia mental já aprenderam. Mas, até que a maioria aprenda, é um boa técnica que, em meu caso, chega a evitar que eu sequer repasse spam legítimo para meu sistema antispam checar, o que também auxilia na economia de recursos de processamento e memória.

Como utilizo o famoso MTA Postfix, utilizo também uma solução que se integra facilmente ao mesmo : o Postgrey, sendo executado como um servidor de políticas.

A teoria é simples : o Postgrey fica em execução constantemente como um daemon, ouvindo em uma porta TCP local específica, através da qual o Postfix irá se comunicar com o mesmo. Sempre que uma mensagem nova chegar, antes de decidir entregá-la, o Postfix irá consultar o Postgrey, que irá checar se a mensagem pode ou não ser entregue. Para isso, ele pode checar sua whitelist própria (o que lhe permite excluir servidores ou endereços de destinatários dessa checagem) ou verificar se o destinatário já recebeu alguma mensagem do remetente ou do servidor remoto em questão.

Caso o mesmo já tenho recebido, o Postgrey não rejeita a mensagem e a devolve para o Postfix, para que o mesmo possa fazer o que for necessário com a mesma : geralmente entregá-la ao usuário final, mas, dependendo de como seu servidor está configurado, também seria possível repassá-la a qualquer outro sistema antispam que você possua já configurado (o meu caso).

Caso seja a primeira vez que a mensagem em questão esteja sendo recebida do remetente ou do servidor remoto em questão, a mensagem é temporariamente rejeitada. Mas a rejeição se dá devido ao Postfix responder com um código de retorno do protocolo SMTP que indica que a mensagem foi rejeitada temporariamente e não permanemtemente.

Para qualquer MTA minimamente bem configurado, isso signifca : ok, o servidor na outra ponta parece estar impossibilitado de receber minhas mensagens neste exato momento, então depois tento novamente. E, logicamente, quando a nova tentativa é feita, a mensagem é aceita. Lógico, você pode configurar o tempo necessário para aceitar uma nova tentativa, de forma que somente após esse tempo passado a mensagem seja aceita. Geralmente, são utilizados apenas alguns minutos (5 minutos, por exemplo), o que não implica em um atraso tão grande na entrega das mensagens e, mesmo assim, esse atraso só acontece no primeiro envio.

Ok, explicada a utilidade, vamos botar a mão na massa. Antes de mais nada, instale o Postgrey em seu servidor de e-mails baseado no Postfix. Não vou citar aqui como fazê-lo porque cada Unix ou mesmo cada distribuição Linux possui sua própria forma de instalação de software, mas posso citar que, usando Debian, o software está apenas a um aptitude de distância.

Software instalado e o daemon em execução (o que é o padrão após a instalação do pacote Debian), nos resta apenas configurar a integração do Postfix com o mesmo. Para isso, simplesmente vamos inserir a chamada ao uso do Postgrey como um servidor de políticas como um dos valores do parâmetro smtpd_recipient_restrictions no arquivo de configuração principal do Postfix, o main.cf (em Debian, ficam em /etc/postfix/main.cf).

Mnha configuração básica para esse parâmetro era a seguinte :

smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

Após a inserção do parâmetro para a integração com o Postgrey, esse parâmetro ficou da seguinte forma :

smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, check_policy_service inet:127.0.0.1:60000, reject_unauth_destination

Por último, simplesmente fiz um reload no Postfix para que a nova configuração passasse a ser válida :

# postfix reload

Pronto! Deste ponto em diante, todas as mensagens que chegaram em seu servidor passaram pela checagem feita pelo Postgrey, a solucáo de greylisting pela qual eu optei. Venho usando o Postgrey há mais de um ano e meio com sucesso e posso dizer que, empiricamente falando, algo entre 80% e 90% dos spam legítimos são parados por esse sistema antes mesmo de meu servidor ter que gastar ciclos de processador e memória tentando checar esse lixo todo para classificá-lo como spam.

O que vocês acharam deste post ? Devo começar a postar conteúdo mais técnico como esse ou devo me ater estritamente ao formato anterior do blog, com análise de diversos acontecimentos ocorridos na cena de software livre mundial e expressar minha opinião sobre os mesmos ? Você, leitor, é o chefe. O que manda ?

Atualizando uma imagem ISO semanal do Debian

Se você é como eu, está sempre (ou melhor, sempre que tem tempo) testando as imagens semanais do Debian. Toda semana são geradas imagens ISO em formato de CD e DVD da próxima versão a ser lançada do Debian, no caso, o Etch.

Como eu ainda não tenho nenhuma máquina com leitor de DVD, uso a imagem ISO no formato de CD e somente a imagem para o primeiro CD. No caso dessa imagem, a mesma é gerada toda segunda-feira (portanto, melhor procurá-la na terça-feira dependendo do seu fuso horário) e disponibilizada junto às outras 20 imagens, completando um conjunto de 21 imagens de binários disponíveis (por isso só uso a primeira).

É meio insano ter que fazer o download de todos os (aproximadamente) 650MB toda a semana sendo que na verdade pouca coisa muda de uma semana para outra. Por isso, me acostumei a usar o rsync para atualizar a imagem da última semana para a imagem da semana em vigor.

Dessa forma, aproveita-se todo o conteúdo da última semana que não foi modificado na imagem da semana atual e o que é trazido são somente as diferenças entre as duas imagens. Resolvi colocar isso aqui para que as pessoas fiquem sabendo como isso pode ser feito e também porque eu vivo esquecendo como isso pode ser feito, o que me obriga a reaprender a cada semana.

Ok, sem mais delongas, o truque é, estando no diretório onde a imagem da última semana foi colocada, executar o comando a seguir, com um usuário que tenha permissões de gravação no arquivo que representa a imagem ISO já existente :

rsync -avz –progress –inplace rsync://cdimage.debian.org/cdimage/weekly-builds/i386/iso-cd/debian-testing-i386-binary-1.iso .

Importante : O comando acima deve ser executado em uma única linha. Reparem também o ponto no final do comando, ele é necessário.

Após executar o comando acima, um acompanhador de progresso será exibido para que você possa ter uma idéia de como o processo de atualização anda. Esse método economiza banda de rede e tempo.

Pequenas coisas que fazem o seu dia : screen

Você não quer xingar o mundo toda vez que usa o screen e não consegue usar as teclas Shift + PageUp ou PageDown ? Bom, eu quero, mas o mundo ainda tem  salvação :

# Allow Shift + PgUp/PgDown
termcapinfo xterm ti@:te@

Simplesmente coloque a linha abaixo em seu arquivo ~/.screenrc e seja feliz