Em um artigo do site Linux Weekly News (LWN) (desculpe, fechado para não assinantes por uma semana, aberto após esse período), o editor indica que alguns fornecedores de sistemas GNU/Linux embarcados estão usando táticas de proliferação de FUD (fear, uncertainty and doubt, ou, medo, incerteza e dúvida) para tentar convencer seus clientes de que seus serviços ainda são relevantes, visto que qualquer organização com algum dinheiro e conhecimento poderia criar sua própria plataforma de sistema operacional embarcado, inclusive se baseando em soluções já existentes para evitar retrabalho e custos muito altos, evitando o fornecedor de sistemas embarcados, no melhor estilo “faça você mesmo“.

Deu para entender porque eu gosto de chamar isso de software livre e não somente de “open source” ?

Quanto ao quesito inspiração, a melhora na interface de posts que ganhei com a atualização do Wordpress vai meu ajudar, visto que o Safari no MacOSX, mesmo o Safari do Leopard, tinha problemas e não exibia corretamente a barra de widgets de formatação de textos/posts do Wordpress. Agora está bem melhor. Convenhamos : postar tem que ser uma experiência boa completa e olhar para aquela barra mal renderizada, que me obrigava a realizar minha coisa manualmente não contribuía nada para ajudar.

Estranhamente, esse problema não ocorria com os navegadores que eu uso em GNU/Linux. Testei com o meu navegador padrão, o Epiphany, e com o Iceweasel/Firefox e ambos funcionavam corretamente. Porém, apesar de estar usando GNU/Linux no MacBook 90% do tempo ultimamente, eu sempre o utilizo no trabalho e, por lá, não sobra tempo para postar nada.

Mas a atualização teve que acontecer de qualquer forma, pois eu já estava começando a ficar preocupado usando uma versão tão antiga e cheia de vulnerabilidades do Wordpress. Agora posso dormir um pouco mais tranquilo enquanto a próxima vulnerabilidade de amanhã não é descoberta e divulgada. Ah, se alguma coisa tão fácil e amigável como o Wordpress existisse com uma quantidade menor de problemas de segurança …

Estive lendo algumas coisas ultimamente além de minhas habituais leituras online. Sim, falo de leitura em papel mesmo, livros reais. Já tinha me esquecido do quão prazeroso é ler em papel, sem contar que um livro eu posso ler no trem sem que ninguém me ache maluco lendo no iPod ou no Palm, com cara de “perdeu prayboy”.

Isso pode me ajudar a postar algo sobre os assuntos que estou lendo. Não tem nada a ver diretamente (mas indiretamente até que tem alguma ligação interessante) com software livre, mas de certa forma tenta explicar como a tecnologia mudou as maneiras como os negócios são feitos e como as oportunidades aumentaram com os mercados de nicho.

Ok, ao citar mercados de nicho eu tenho certeza que os mais geeks já entenderam sobre qual livro eu estou falando, visto que ele é bem conhecido e veio de um autor que está intimamente ligado a área de tecnologia. Pretendo, quem sabe, escrever algo sobre esse assunto assim que tiver mais um tempinho livre, mas não antes de finalizar a leitura do livro.

Também gostaria de avisar que me cadastrei no Twitter hoje para ver como isso funciona. Gostei e tem potencial de ser atualizado com uma constância bem maior do que esse blog é atualizado, até mesmo pela natureza rápida e limitada (140 caracteres somente) dos posts. Quem quiser me “seguir” no Twitter, meu endereço é esse aqui. Quem de vocês aderiu a brincadeira ? Estou precisando cadastrar algumas pessoas interessantes para acompanhar peripécias alheias

Ah ! E, também, é bem possível que quem esteja seguindo as minhas peripécias pelo Twitter acabe sabendo sobre qual livro eu estou falando bem mais rápido do que quem me lê somente por aqui.

Na época, sempre tive trabalho devido ao Debian e os sistemas baseados em Red Hat utilizarem políticas diferentes para usuários e grupos : em sistemas Red Hat e similares, usuários normais (ou seja, excetuando-se os usuários de sistema e os utilizados por daemons/serviços) iniciam no UID 500 e grupos normais (também com exceção dos grupos de sistema e criados para serem utilizados por daemons/serviços) iniciam no GID 500.

Em sistemas Debian, no entanto, usuários e grupos criados pelo administrador, ou seja, usuários e grupos que não são fornecidos na instalação padrão e que não são criados devido a instalação de algum pacote adicional (como um daemon, por exemplo), devem utilizar UID e GID iniciados a partir de 1000.

Como a conversão de servidores na época era grande, perdi alguns minutos e desenvolvi o script shell que publico abaixo para me auxiliar na tarefa de, com base nos arquivo /etc/passwd (para usuários) e /etc/group (para grupos) do sistema a ser convertido, criar as entradas já adaptadas para serem somente inseridas ao final dos arquivo /etc/passwd e /etc/group do novo sistema Debian.

O script foi criado há muitos anos atrás e agora só coloquei alguns comentários a mais para deixá-lo mais compreensível, mas ainda acho que pode ser de alguma utilidade para quem possa estar passando por uma situação semelhante a que eu passei há alguns anos atrás. Além de possivelmente ser útil para alguém, estou publicando também para ter fácil acesso ao mesmo caso algum dia precise e para que o Google me ajude indexando-o e tornando “encontrável” por qualquer um que necessite de algo parecido.

#!/bin/bash

# Script : gid-uid-rh-to-debian.sh
# Author : André Luís Lopes
# Version : 0.1
# License : GPL (General Public License) version 2 (GPLv2)
# Description : A simple script which takes users and groups
# from a Red-Hat-like (RHEL,Fedora,etc) system and
# adapts them to be used on Debian systems, taking
# care to adapt the UID and the GID numbers to the
# Debian policies (non-sytem/user-created users
# starting from UID 1000 and groups starting from
# GID 1000) or to the user-desired ones.

# Minimun UID used for users in the previous GNU/Linux distribution
# (Red-Hat-like distros uses UID 500, for reference).
minuid=”500″
# Minimun GID for groups in the previous GNU/Linux distribution
# (Red-Hat-like distros uses GID 500, for reference).
mingid=”500″
# A pipe separated list of users not to be included in the output
# (i.e. user blacklisting feature).
uidblacklist=”nobody”
# A pipe separated list of groups not to be included in the output
# (.e. group blacklisting feature).
gidblacklist=”nogroup”
# UID increment strategy (i.e. how much to sum to the current UIDs).
uidplus=”1000″
# GID increment strategy (i.e. how much to sum to the current GIDs)
# It’s not a good idea to choose a GID different from the UID given
# above (Debian’s defaults are 1000 both for UID and GID).
gidplus=”1000″

# Bail out if there’s not enough parameters provided. Also, teach
# the user how we should be used instead.
if [ -z “$1″ ] || [ -z “$2″ ] ; then
echo “”
echo “Usage : $(basename $0) [passwd|group] [passwd file|group file]”
echo “Examples :”
echo “”
echo “$basename $0 passwd passwd-file”
echo “$basename $0 group group-file”
echo “”
echo “Output will be ready to be inserted to the end of your new”
echo “system’s /etc/passwd (when using the ‘passwd’ parameter) or”
echo “/etc/group (when using the ‘group’ parameter).”
echo “”
echo “IMPORTANT :”
echo “———–”
echo “You should provide as the second parameter to this script the”
echo “passwd or group from your current (i.e. Red-Hat-like) system,”
echo “NOT the passwd or group file from your new Debian system.”
echo “”
exit 0
fi

# Check what the user want to work with this time : passwd or group.
# Output only the non-system users so the user will be able to add
# the output of this script to the end of his/her new system’s passwd
# or group file.
case “$1″ in

passwd)

awk -F: ‘($3 >= ‘$minuid’) && ($4 >= ‘$mingid’) {print $1 “:” \
$2 “:” $3+1000 “:” $4+100 “:” $5 “:” $6 “:” $7}’ $1 \
| grep -v -E “$uidblacklist”

;;

group)

awk -F: ‘($3 >= ‘$mingid’) {print $1 “:” $2 “:” $3+1000 “:” $4}’ \
$1 | grep -v -E “$gidblacklist”

;;

esac


Estou aberto a receber comentários e sugestões de possíveis melhorias caso alguém o utilize e queira compartilhar suas impressões. Críticas, caso sejam construtivas, também são bem-vindas. Os comentários deste post estão aí para isso. Somente lembre-se que o script foi criado há anos atrás de maneira rápida para atender a uma necessidade específica antes de destilar o veneno nos comentários. Sejam bonzinhos

Outro detalhe a ser notado é que, por mais que eu tenha tentado, o Wordpress não deixou a formatação do script de maneira idêntica a maneira utilizada em sua cópia original em disco. Por isso, contenham suas críticas sobre identação, já que a mesma não vai existir nessa versão online piorada pelo Wordpress

Trata-se de uma ótima oportunidade para quem tem vontade de contribuir mas não deseja se ligar oficialmente ao projeto passando por todo o processo para se tornar um desenvolvedor Debian. Espero que gostem :

No início de Agosto, o projeto Debian votou o endorsamento do conceito de “Mantenedores Debian”, o qual permitiria a contribuidores que, apesar de não serem desenvolvedores Debian completos, tivessem o direito de manter seus próprios pacotes no repositório de pacotes Debian sem que fosse necessário um padrinho para cada upload[0].

Desde então, um sistema para manter um chaveiro separado para mantenedores Debian foi implementado[1], junto com mudanças no software que controla os repositórios para suportar uploads restritos assinados por essas chaves[2]. Agradecimentos em particular a Cameron Dale, Miriam Ruiz e Fathi Boudra por servirem de cobaia durante a implementação inicial e durante os testes.

Agora estamos prontos para aceitar um número de candidatos limitado e, devido a isso, estamos entrando em uma fase beta. Isso significa que achamos que temos tudo pronto e funcionando a contento, mas que provavelmente esquecemos algumas coisas e, até que saibamos quais são essas coisas e as corrijamos, nós iremos confiar nos Mantenedores Debian (DM) para nos ajudar a nos certificar que o sistema esteja sendo executado da forma mais suave possível, conforme ele foi planejado.

Caso você seja um não Desenvolvedor Debian que já mantenha softwares dentro do Debian através de um padrinho e tenha um bom conhecimento sobre como trabalhar no Debian, uma chave GPG assinada por alguns Desenvolvedores Debian (DD) e um registro de de bom trabalho comprovado, então você é o tipo de candidato que estamos procurando para nos auxiliar a finalizar os testes. Caso aceito, você será capaz de fazer upload de seus próprios pacotes diretamente sem incomodar seu padrinho.

Para se candidatar, fale com seu padrinho, com seu gerente de aplicação (AM) ou com qualquer outro DD que você conheça e com o qual você trabalhe para verificar se você está pronto para dar esse passo - você precisará que os mesmos escrevam uma mensagem para a lista de discussão debian-newmaint sobre o que você já fez que possa fazê-los pensar que você é um bom mantenedor.

Caso você seja um DD que conhece um não-DD o qual você ache que faria bom uso dos privilégios extras dados a um DM, você talvez queira conversar com ele/ela e encorajá-lo/encorajá-la a se candidatar.

Candidaturas são feitas cadastrando-se um bug no pacote Debian de nome debian-maintainers - por favor, consulte o arquivo README desse pacote para maiores instruções sobre qual informação é necessária e como coletá-la.

Note que, uma vez que você seja aceito como um DM, você ainda só poderá fazer uploads de pacotes que já estejam presentes na suíte unstable dos repositórios Debian com seu nome e endereço de e-mail nos campos Maintainer: ou Uploaders: e que possuam a campo “Dm-Upload-Allowed: yes” definido. Isso significa que você precisará que seu padrinho faça ao menos um upload com a campo Dm-Upload-Allowed definido.

Caso você tenha dúvidas, comentários ou sugestões você pode entrar em contato com a equipe DM no endereço d-m-team@lists.alioth.debian.org (em inglês somente).

Assinado,
Equipe do chaveiro DM,
Joey Hess
Anibal Monsalve Salazar
Anthony Towns

[0] http://www.debian.org/vote/2007/vote_003

Existem deliberadamente uma porção de diferenças entre a proposta
e o que está implementado no momento. As diferenças são :

- A adição de Anibal a equipe do chaveiro (aprovado pelo DPL)

- o chaveiro é mantido usando git ao invés de SVN, em
git://git.debian.org/git/d-m/debian-maintainers.git

- o campo Changed-By: do arquivo .changes é consultado em adição
ao campo Maintainer: para determinar se um upload é patrocinado

- o campo Dm-Upload-Allowed e os campos Maintainer/Uploaders
da última versão do pacote incluído na suíte alvo são usados para
restringir uploads de DM ao invés da última versão enviada via upload
para a suíte unstable (isto principalmente tem efeito para uploads para
proposed-updates e nos casos de mais de um upload entre pulsos)

[1] Consulte o pacote debian-maintainers na unstable
[2] http://lists.debian.org/debian-dak/2007/10/msg00009.html

É isso aí. Para quem estiver interessado, mãos na massa !

O Slashdot nos informou hoje que já existem empresas que estão produzindo discos de estado sólido que ultrapassam a capacidade de armazenamento de 1TB.

Nada mal para nossos padrões de uso doméstico atuais, concorda ? Eu mesmo possuo um disco SATA II de 250GB em meu desktop doméstico que ainda anda pouco utilizado, mas isso é só devido a minha conexão Internet, a qual não pode ser considerada como uma conexão de banda larga. No máximo, um conexão de banda-sofrivelmente-quase-larga.

De qualquer forma, com o aumento das ofertas de opções de acesso a Internet em conexões banda larga, o aumento da oferta de soluções que nos permita armazenar uma maior quantidade de informações também tende a aumentar. Anteriormente, nos contentávamos em armazenar nossos e-mails, documentos e arquivos que, na maioria das vezes, se tratavam de dados em texto puro ou em algum formato parecido, que não demandava tanto espaço em disco.

Hoje em dia, é extremamente comum encontrarmos colegas que possuem dezenas ou até mesmo centenas de gigabytes de arquivos de música ou vídeo digitais (nem sempre conseguidos de forma legal, mas isso é outra história). Cada vez mais precisamos de mais espaço para armazenar nossas preciosas coleções virtuais/digitais de arte e conhecimento que tanto prezamos e que tanto insistem em lotar nossos discos.

O problema é que, aparentemente, a tecnologia utiilizada nos discos rígidos, conforme a conhecemos atualmente, parece não ter evoluído tanto quanto outras tecnologias irmãs (como processadores e memórias) tem evoluído nos últimos tempos. O post do kernel hacker Robert Love sobre o assunto, sindicalizado no Kernel Planet, exemplifica bem o problema que estamos enfrentando atualmente.

Segundo ele, desde que compilou seu primeiro kernel (versão 1.1 ou 1.2), a velocidade de transferência de dados em sua conexão Internet já aumentou 11.500 vezes se comparada ao modem 2400 que ele utilizava na época, a velocidade de acesso a memória aumentou 2.000 vezes e a disponibilidade de espaço em disco aumentou 3.000 vezes.

Porém, a velocidade de acesso a dados em discos rígidos ainda continua essencialmente a mesma. Ele ainda aponta como fonte sua palestra na GUADEC de 2005, onde ele diz que acesso a disco é 25.000 vezes mais lento do que o acesso a um registrador de propósito geral e termina dando a entender que as coisas não estão evoluíndo de acordo na indústria de armazenamento doméstico.

Segundo a definição na Wikipedia, o acesso a discos que utilizam a tecnologia SSD é mais do que 250 vezes mais rápido do que os discos rígidos mais rápidos da época em que a entrada na Wikipedia foi escrita, em 2004. E, de lá para cá, aparentemente, não tivemos mudanças sensíveis na tecnologia de discos rígidos que fizessem com que essa diferença caísse drasticamente, infelizmente.

As principais razões (existem outras) que ainda impedem que computadores oferecidos ao mercado doméstico sejam equipados com discos que utilizam a tecnologia SSD são o preço elevado (também segundo a mesma definição na Wikipedia citada acima, perto de US$ 8 por GB em discos SSD comparados a US$ 0.25 por GB nos discos mecânicos atuais) e o fato de discos SSD terem uma expectativa de vida bem menor do que os discos rígidos atuais, já que os discos SSD possuem uma quantidade máxima de operações de gravação limitadas se comparadas a discos rígidos usuais.

De qualquer forma, existem sistemas de arquivos especiais para discos SSD (como os sistemas de arquivos JFFS e JFSS2, no caso de kernels Linux) que diminuem um pouco esse problema, sendo mais inteligentes na forma que gravam os dados em disco e diminuindo a frequência das gravações para evitar o desgaste além do necessário.

A notícia que saiu no Slashdot hoje, citado no início deste post, também informa que um dos modelos de discos SSD oferecidos por um dos fabricantes citados suporta taxas de transferência de 4Gbps. Um dos discos em questão suporta 55.000 operações de I/O por segundo e atinge uma taxa de transferência de dados sustentada de 230MB por segundo. Em comparação, um disco rígido rápido atual atinge por volta de somente 300 operações de I/O por segundo.

Parece que, assim que os preços de soluções baseadas em SSD começarem a diminuir um pouco mais (obrigado Apple por estar popularizando essa tecnologia com o uso da mesma nos novos IPod e em seu iPhone), teremos encontrado nosso sucessor dos discos rígidos mecânicos atuais.

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.

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.

A idéia é não somente se preocupar com sistemas melhores, mais rápidos e mais baratos, mas também com sistemas com responsabilidade ambiental. Dê uma lida no link citado anteriormente, a idéia é interessante e qualquer iniciativa no sentido de economia de energia, recursos naturais, evitar a produção de lixo eletrônico, que leve em consideração os efeitos na saúde e na produtividade dos usuários, em tempos de discussões sobre aquecimento global acaloradas, é louvável. O planeta agradece.

Mas o que o software livre pode fazer para ajudar ? Como citei em um post anterior, minha experiência com um ponto bastante prático e visível para o usuário relacionado a esse assunto, o tempo de duração de bateria de notebooks, não foi muito feliz. Consegui um tempo de duração de bateria bem inferior em GNU/Linux se comparado ao uso do MacOSX no mesmo hardware. Pouco mais de 5 horas em MacOSX e pouco mais de 3 horas em GNU/Linux.

Porém, logicamente, isso já era de se esperar, uma vez que, no caso do MacOSX, o hardware e o software foram feitos um para o outro, pelo mesmo fabricante/desenvolvedor. Seria espantoso ter um tempo de duração de bateria maior em GNU/Linux, nesse caso. Mas não custa sonhar, certo ?

Felizmente, o sonho pode se tornar realidade em um futuro não muito distante. Algo me diz que daqui há um ou dois anos será engraçado ler esse post e imaginar que tínhamos um rendimento tão inferior em softwares livres se comparado aos softwares proprietários em relação e economia de energia. Por quê digo isso ? Ora, é óbvio Veja os sinais que estão surgindo por todos os cantos.

Repare nos inúmeros projetos relacionados a economia de energia que andam pipocando em todos os cantos. Apesar de ainda existir muito a ser melhorado, uma boa parte do que é necessário nas camadas mais baixas, lá nas entranhas do kernel, já está implementado com o suporte a dynticks e kernels tickless, que permitem que, dados softwares bem comportados, a CPU seja acordada uma quantidade de vezes bem menor do que o habitual.

Com uma quantidade menor de interrupções ocorrendo, o sistema como um todo tem a oportunidade de ficar mais tempo no estado idle (lá paradão, desocupado) e, consequentemente, podemos dispor de vários recursos para fazer com que a CPU passe de um estado ACPI para outro, no qual uma quantidade menor de energia seja consumida.

Ted Tso, conhecido kernel hacker conhecido por desenvolver, entre outras coisas (incluíndo estar envolvido na equipe original que projetou o Kerberos no MIT), os sistemas de arquivos ext2 e ext3 (e estar trabalhando no ext4), blogou sobre a questão da economia de energia para usuários de laptops usuários de GNU/Linux. Vale a pena a leitura.

Em seu post, Ted nos fornece uma visão geral de como está atualmente a questão do gerenciamento de energia no kernel Linux, compara a situação atual com o estado desse suporte no kernel há poucos anos atrás e indica que o futuro parece promissor, apesar de ainda faltar muito para ser feito para que consigamos ter um subsistema de gerenciamento de energia invejável aos sistemas operacionais proprietários.

É interesse ler também as reações ao post de Ted. Pavel Machek, outro kernel hacker, em um post curto em seu blog responde a alguns dos pontos levantados por Ted em seu post original e nos informa que diversos problemas apontados por Ted já estão em vias de serem resolvidos e alguns desses problemas, como a questão da suspensão de dispositivos USB e o problema dos mesmos relacionado ao consumo elevado de ciclos de processador, já estão resolvidos em kernels mais recentes.

Pavel também fornece várias dicas de como economizar ainda mais energia com algumas configurações simples. Aliás, por falar em dicas para economia de energia, como Ted citou em seu post original, a referência mais importante atualmente é o site lesswatts.org, site oficial do utilitário powertop, lançado pela Intel para auxiliar usuários e desenvolvedores a descobrir quais aplicações consomem mais energia em seus sistemas, fornecendo dicas de configurações que podem ser aplicadas para diminuir o consume de energia de sistemas baseados no kernel Linux.

Lógico que, como Ted citou em seu post, hoje em dia ainda são necessários muitos passos e muitas configurações manuais para conseguir um bom índice de economia de energia. Mas com o tempo e com a infraestrutura para gerenciamento de energia no kernel sendo melhorada, além dos drivers/módulos para dispositivos sendo atualizados para fazer uso dessa infraestrutra, a tendência é que a quantidade de configurações manuais requeridas diminua e esse tipo de ajustes provavelmente seja mais simples de ser feito, possivelmente com alguns deles até mesmo sendo feitos automaticamente pelo próprio kernel em conjunto com drivers/módulos mais inteligentes.

Eu torço para que isso aconteça e, pessoalmente, não vejo a hora de testar o futuro kernel 2.6.24, por enquanto ainda em desenvolvimento, que trará suporte a dynticks para arquitetura x86-64 e provavelmente fara meu MacBook rodando GNU/Linux competir de igual para igual com o MacOSX no mesmo hardware

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

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 ?