Lots of friends gave me good recommendations for Linode and the price was tempting so I thought : “Why not ?”.  The most noticeable advantage, apart from the price reduction, was the speed improvement, as I got myself a more powerful VPS and then now I have more room for new experiments.

Later I also noticed some little but very welcome improvements. These are just minor details, but together they account for a great experience. So, I’m here to let you guys now that if you want a good, reliable, speedy, and still cheap hosting provider for your VPS, just give Linode a try.

I’m sure you won’t be disappointed.

Aparentemente, tudo foi bastante tranquilo. Demorei mais para fazer backups (como medida de precaução, não que fosse algo estritamente necessário) do que para concluir totalmente o processo de atualização. A equipe do WordPress está de parabéns por tornar a experiência de atualização algo bastante suave, ainda mais em meu caso, com um pulo de uma versão jurássica diretamente para a última.

Agora que o WordPress está usando e abusando de conceitos Web 2.0/AJAX tudo ficou mais intutito. A interface de postagens, por exemplo, ficou bem mais amigável em minha opinião. Outra novidade foi que o ScribeFire voltou a funcionar 100% agora, mas com as melhorias sensíveis na interface de postagens provavelmente vou acabar abandonando-o.

Quem sabe agora com as novas facilidades eu não me anime a voltar a postar com maior frequência ?

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.

Agora, qualquer doido que por um desastre da natureza gostar do que escreve e quiser votar nos meus posts, fazendo com que os mesmos subam de posição no Rec6, ou ao menos apareçam por lá, é só clicar no botão Rec6 que aparecerá abaixo de cada um dos posts em meu blog.

Depois de alguns testes, também acabei percebendo que, além do problema de falta de acessibildade, o plugin de captcha que eu estava usando estava impedindo que trackbacks para meus posts funcionassem. Decidi que deveria mudar e acabei desabilitando o plugin que implementava captcha que usava até então.

Por enquanto, deixei habilitado somente o Akismet, um plugin que usa uma espécie de blacklist online para afastar spam em comentários. Sei que definitivamente não será tão eficiente quanto o plugin usado anteriormente, mas posso aceitar ter um pouco mais de trabalho administrativo para deixar meu blog mais acessível e não perder comentários potencialmente interessantes.

E, como nenhuma tecnologia que faz tudo 100% de forma automatizada é 100% perfeita, permite que você revise tudo antes de dar seu aceite final. Vou testá-lo por uns dias, já que não custa nada (literalmente) e estou mesmo querendo começar a atender e explorar as capacidades do Technorati.

Quem sabe não fico mais na moda usando tecnologias Web 2.0 ?

Existem opções que acrescentam sistemas antispam ao mecanismo de comentários do WordPress, inclusive plugins que o conectam com o SpamAssassin (SA). Apesar de utilizar o SA em inúmeros sistemas de combate a spam em MTAs, meu servidor pessoal ainda é muito modesto em termos de memória disponível para poder se dar ao luxo de utilizar o SA.

Ou seja, por enquanto, mesmo sabendo que utilizar um esquema de Captcha não é a melhor opção, infelizmente é o que tenho que utilizar. Recomendações de opções mais acessíveis e não tão memory-hungry são bem-vindas.

É impressionante ver a quantidade de código decente que ele produz e como depois de tanto tempo contribuíndo ele ainda tem motivação suficiente para continuar contribuíndo como se tivesse iniciado hoje. O debhelper é algo fantástico, o debian-installer nunca seria o mesmo sem ele e muitas outras áreas do Debian se beneficiam da genialidade do joeyh.

Agora que tenho meu próprio servidor, estive procurando por alternativas para manter um site pessoal. Minhas exigências é que a ferramenta de auxílio a esta tarefa fosse simples, me permitisse atualizar o site sem que para isso eu precisasse utilizar uma interface Web (apesar de eu estar me acostumando mal com essa interface de posts do WordPress) e que, preferencialmente, me possibilitasse utilizar controle de versão para manter o conteúdo e poder recuperá-lo de qualquer versão anterior caso alguma catástrofe acontecesse.

Acabei decidindo que um Wiki seria a ferramenta ideal e, em minha procura, encontrei o ikiwiki, criado por nada mais nada menos que o Joey Hess. O ikiwki é simples e me permite manter meu site/Wiki pessoal com simplicidade, usando meu editor de textos preferido e enviar as atualizações através de um commit num repositório Subversion que configurei para armazenar o site.

Perfeito O ikiwiki não está disponível para stable, mas está disponível para unstable e testing. Como não queria manter um sistema misto e meu servidor usa somente stable. Verifiquei as dependências do ikiwiki e notei que a única dependência não satisfeita do mesmo na stable é o pacote libcgi-formbuilder-perl, que existe na stable mas em uma versão mais antiga do que a versão mínima necessária.

Fiz um backport do pacote para uso local e reconstruí o pacote do ikiwiki para uso pessoal no servidor e ambos parecem estar funcionando bem. Agora é só começar a explorar as possibildades fornecidas pelo ikiwiki. Já estou usando um script post-commit gerado pelo ikiwiki.setup que reconstrói as páginas do site automaticamente após os commits no repositório Subversion.

Agora só falta configurar o ambiente de forma decente para que eu possa fazer commits de outros locais diferentes do console do servidor de forma segura, via svn+ssh. Esta parcialmente feito, na verdade. Só faltam alguns detalhes.

Caso alguém tenha interesse, expresse nos comentários ou me envie um e-mail que ficarei feliz em disponibilizar os backports do libcgi-formbuilder-perl e do ikiwiki. Só não os fiz ainda porque não achei que fosse algo que seria de interesse geral.

It’s very nice because they give you full root access so you can install whatever you want to install. Also, it’s Debian based and even the control panel they provide is as I like things to be : minimalist and easy to use. Sure, it works like a charm also.

I’m tired because I was fighting the blog system I installed for a long time trying to convince it to get installed in a proper VirtualHost but it kept giving me trouble everytime I tried to access its root page. I gave up and installed it in a directory under my default page and then it worked as expected.

Someday I need to take a closer look at it and find out what really went wrong. Well, actually, I know what went wrong and I even knew how one could fix the issue as I already fixed issues like this one lots of time in the past, but this time my tricks didn’t helped.

Anyway, mail setup is already working, complete with SSL-based IMAP/POP, SMTP-AUTH through SASL and all the basic services I wanted to have are already working. Now I think I can have some sleep a it’s past 4:00AM.

Well, enough for a first post.