andrelop’s blog

Obsolescência de fornecedores é igual a liberdade ?

Estive lendo esses últimos dias um artigo sobre o fato de alguns usuários (entenda-se por usuário não somente o usuário individual doméstico, mas qualquer tipo de usuário, inclusive os grandes usuários corporativos) se mostrarem tão satisfeitos com soluções abertas/livres que, quando questionados sobre seus investimentos em soluções livres, se mostraram a favor de manter ou, em grande parte, até mesmo aumentar os investimentos nesse tipo de solução.

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

Atualização do Wordpress e Twitter

Eu sei. Eu deveria postar com uma frequência bem maior e não somente simplesmente para avisar que eu atualizei a instalação Wordpress que gerencia este blog. Desculpe, mas ainda estou com dois problemas para que isso aconteça. O primeiro é tempo e o segundo é falta de inspiração suficiente.

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.

Migrando usuários e grupos para sistemas Debian

Hoje em dia nem tanto porque a maioria dos sistemas que administro já estão todos convertidos para Debian GNU/Linux (e os que não estão não foram convertidos por não poderem ser convertidos devido a razões políticas), mas na época em que entrei na empresa onde trabalho atualmente passei um bom tempo migrando servidores Red Hat e similares (antigo Red Hat, Fedora, etc) para Debian.

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

Debian Maintainers : sua chance de contribuir sem precisar passar por burocracia

Abaixo estou reproduzindo a mensagem que acabou de ser enviada para a lista de discussão debian-devel-annouce@lists.debian.org sobre a abertura, ainda em caráter beta, do programa de Mantenedores Debian.

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 !

SSD : a solução para o gargalo atual em nossos sistemas ?

As indicações estão em todos os lugares : primeiro nos players portáteis e telefones de luxo que andam aparecendo aos montes e, ultimamente, com a indicação de grandes nomes do mercado, como a Apple, que, segundo as notícias que circulam por aí, vai lançar um ultra-portátil que utilizará tecnologia SSD, em seu evento anual MacWorld Expo and Conference, por volta de janeiro do próximo ano.

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.

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.

Leopard vs Java : o perigo de se espalhar informações incorretas

Estive lendo algumas notícias e me deparei com um post que critica o fato da Apple não ter incluído suporte a Java em sua nova versão do Mac OSX, a versão 10.5, também conhecida pelo codinome de Leopard. Tico e teco se bateram por um milésimo de segundo e logo pensei : Opa, perái! Não existe nada de fato nessa história toda.

O fato real é que a Apple não inseriu suporte a Java 1.6 no Leopard, mas o suporte a Java 1.5 está incluso. E algumas pessoas inclusive acreditam realmente que o suporte incluso foi um avanço se comparado ao suporte anteriormente existente na versão anterior do Mac OSX, a versão 10.4, codinome Tiger.

E isso me custou apenas dois minutos de pesquisas no grande oráculo pai dos burros e a leitura dos primeiros comentários do post em questão já demonstraram que, hoje em dia, postar algo para conseguir audiência sem checar os fatos realmente não é lá uma boa estratégia. Seus leitores rapidamente vão desbancar qualquer fato incorreto em seus textos, tenha certeza.

Os desenvolvedores Java podem sim estar descontentes com a Apple devido a mesma não ter incluído suporte para o que há de mais atual relacionado a tecnologia Java na última versão de seu sistema operacional, mas daí a dizer que nenhum suporte a Java foi incluído é um estrada com centenas de milhares de quilômetros de distância.

O artigo em questão inclusive diz que seria bom se a Apple mudasse sua atitude e suas relações com a comunidade de desenvolvedores e incluísse suporte oficialmente a outras linguagens além de sua preferida, Objective-C. O que o autor do post não percebeu é que, além de ter errado no caso do Java, ele errou feio nesse caso também.

Novamente, dois minutos de pesquisa nos leva a suscinta (mas informativa o bastante para nossos propósitos) seção sobre tecnologias Unix existentes por baixo da interface polida do Leopard. Lá, podemos conferir que, iniciando com o Leopard, existe agora suporte oficial, fornecido junto ao sistema operacional, para linguagens de script como Ruby e Python, inclusive com suporte específico nas ferramentas de desenvolvilmento da Apple, como o Xcode, por exemplo.

Não, eu não sou um fanboy da Apple e não, não recebi nenhum pagamento para escrever em defesa da mesma. Longe disso, eu não concordo com um caminhão de coisas que a Apple faz e estou longe de passar a sequer centenas de quilômetros perto da folha de pagamento da Apple, mas eu simplesmente me dei ao trabalho de pesquisar algo em torno de dez minutos antes de escrever esse post e checar alguns fatos antes de escrevê-lo.

Moral da história : cuidado com o que você lê por aí. Cheque os fatos e não saia por aí reproduzindo histórias sem antes checar realmente se elas condizem com a verdade. Você pode estar, menos sem ter a intenção, queimando sua credibilidade junto a seus leitores.

Mais valioso do que dinheiro

Hoje, conferindo os feeds dos sites de notícias que costumo acompanhar, me deparei com um post interessante que apareceu no Liferea, vindo do agregador Planet Debian.

Na verdade, o post em si não é lá muito interessante, mas sim um link para um antigo artigo (datado de 1987) sobre o impacto de recompensas como fontes de motivação, citado no post em questão.

O interessante é que o artigo, mesmo sendo bastante antigo (20 anos), confirma alguns sentimentos que eu tenho sobre essa questão. Não que eu seja anti-capitalista ou que não goste de dinheiro (pelo contrário, vide meu post anterior) mas acredito que compensação financeira nem sempre seja a única ou até mesmo a melhor fonte de geração de incentivos.

Logicamente, um aumento de salário deixa qualquer um contente mas muitas vezes um elogio pode ter um efeito incentivador muito maior do que algumas moedas a mais entrando em seu bolso. Em meu caso, um elogio vindo de pessoas certas então é algo ainda mais incentivador e gratificante. As pessoas certas, em meu caso, são pessoas que, por algum motivo qualquer, eu admiro.

Receber um elogio de um de seus ídolos ou daquela pessoa na qual você sempre se espelhou é um sentimento indescritível e faz muito bem ao ego. Contribuir com um projeto de software livre é algo muito interessante porque lhe permite, com uma dose cavalar de esforços aplicada, experimentar esse tipo de sentimento e, ao mesmo tempo, ser útil para uma população muito maior de indivíduos do que você, seu chefe e seu próprio umbigo.

O artigo em questão também cita que a criatividade e o interesse intrínseco diminuem caso a tarefa a ser cumprida seja feita somente visando um ganho ou retorno específico. Isso eu posso confirmar, com certeza. Se você trabalha em algo somente por estar interessado em quanto aquilo vai lhe render financeiramente, mesmo sendo capaz de produzir algo bom ao final, certamente você não vai produzir algo maior do que isso, algo grande que possa ser notado, lembrado e admirado por muitos, algo do que você realmente se orgulhe.

O sentimento de fazer parte de algo maior (uma comunidade mundial de pessoas unidas por um objetivo em comum no caso do software livre), de poder ser útil para uma grande quantidade de pessoas, de fazer aquilo que você gosta e receber um pagamento muitas vezes ainda mais valioso do que dinheiro por isso é altamente gratificante.

Isso certamente explica o que impulsiona e motiva alguns colaboradores de projetos de software livre a participar de algo que não lhes rende lucro direto, mas que lhes proporciona um sentimento de dever cumprido, de estar fazendo a coisa certa. Algo que muitos não conseguem enxergar, talvez por estarem viciados em ser recompensados através de ganhos financeiros por tudo que fazem e somente serem motivados a percorrer aquela milha a mais caso exista um retorno direto garantido.

Vendendo a alma (ou, opcionalmente, pagando a hospedagem)

Olá pessoal,

Os mais atenciosos (ou qualquer um que leia os posts diretamente no blog e não somente assinando o feed) irão perceber que algumas mudanças ocorreram no blog desde o meu último post.

Mudei novamente o tema utilizado pelo blog. Acho que desta vez encontrei um tema bacana e simples, que não prejudica a leitura dos posts e não deixa uma boa parte dos posts desalinhados e com problemas de exibição em alguns navegadores, como era o caso do tema anterior.

Além da mudança no tema, vocês vão notar que eu passei a usar o AdSense do Google no blog. Não é que eu queira parar de trabalhar e viver somente de renda gerada do AdSense (até porque não tenho calibre para isso), mas uma pequena (e bota pequena nisso, no caso do AdSense) fonte de renda adicional não é nada ruim.

Se eu conseguir pagar as despesas de hospedagem do servidor virtual que hospeda este blog já está valendo, mas se alguns centavos a mais aparecerem, também prometo que não fico chateado Achei que seria importante avisar aos leitores do blog sobre essa minha decisão e deixá-los cientes de que não vendi a alma ao diabo e nem me tornei um porco capitalista, como todo blogueiro que resolve começar a monetizar seu blog parece ser percebido hoje em dia.

Tentei deixar uma quantidade pequena de anúncios e vou me esforçar nos próximos dias para acertar o AdSense no intuito de exibir ao máximo possível somente anúncios relacionados aos temos dos textos sendo escritos no blog, apesar de eu acreditar que isso o AdSense vai aprendendo aos poucos conforme os posts forem aparecendo e ele for compreendendo minha forma de escrever.

O que vocês acharam ? Ficou muito intrusivo ou é suportável ? Deixe suas opiniões sobre esse questão nos comentários. É importante notar que os anúncios sendo exibidos no momento eram os anúncios do menor tamanho existente dentre as escolhas de banners horizontais na lista de banners para uso disponibilizada dentro da interface de administração do AdSense.

Obrigado pela leitura e até o próximo post.