quarta-feira, 30 de setembro de 2009

Nagios Web Config funcionando com Nagios 3.2.0

Para quem ainda não conhece, o Nagios Web Config é uma excelente ferramenta que permite configurar o Nagios através do browser, tornando essa tarefa muito mais rápida e agradável.

Já utilizei o mesmo inúmeras vezes, só que hoje precisei instalá-lo na última versão do Nagios (3.2.0 de 12 de agosto de 2009) e me deparei com a seguinte situação: a partir desse release, o Nagios sofreu algumas mudanças na interface web, o que fez com que parte do tutorial de instalação do Nagios Web Config não correspondesse a nova realidade (especificamente no que diz respeito a alteração do arquivo side.html).

Resolvi então adaptar o mesmo a nova estrutura e fiz contato com o desenvolvedor para que as alterações sejam adicionadas na próxima versão do software(que não é atualizado desde 2006) .Mas, enquanto isso não acontece, se você precisar instalar o Nagios Web Config baixe o arquivo side.php atualizado para o Nagios 3.2.0 aqui.


Leia também:


quarta-feira, 23 de setembro de 2009

Squid e webservers com autenticação NTLM


Outra situação envolvendo o Squid com a qual me deparei foi um problema de autenticação em um determinado website.

Foi observado o seguinte:
  • ao tentar abrir uma página desse site sem fazer uso do Squid, uma janela para autenticação do usuário era exibida, e com isso era possível logar e acessar o mesmo perfeitamente.
  • Ao tentar abrir a mesma página, porém usando o Squid, a janela de autenticação não era exibida, fazendo com que automaticamente o site redirecionasse a navegação para a página de acesso negado.
Depois de muitas pesquisas, visualizações de logs e vários testes com tcpdump, resolvi acessar a página usando o lynx e percebi que a mesma enviava um header que não podia ser processado (Invalid header 'WWW-Authenticate: NTLM'). Pura sorte minha, pois pesquisando por esse problema percebi que o que acontecia no Squid era exatamente o mesmo.

A questão é que o Squid só possui o suporte para autenticação em webservers com NTLM a partir das versões 3.1 (beta) ou 2.6. Como a versão que estava em uso era a 3.0, tal operação não podia ser realizada.

Nesse caso só restou fazer com o que acesso ao site fosse realizado por fora do proxy, usando ferramentas como iptables e o protocolo wpad, mas isso já é assunto para um outro post.

Fica então a dica, e espero que isso ajude outras pessoas a não perderem o tempo que perdi com tal situação.

Squid e Windows Live Messenger 2009


Há algum tempo a Microsoft começou a obrigar os usuários do MSN Messenger (ou Windows Live Messenger) a atualizar seus softwares para a última versão, caso contrário os mesmos não poderiam mais logar no serviço.

Isso acabou gerando uma situação bem desagradável: a última versão do Windows Live Messenger 2009 passou a não funcionar mais com o Squid (enquanto as versões 8.x continuavam conectando perfeitamente).

Depois de muitas pesquisas e tentativas (seguindo inclusive informações do suporte da MS), finalmente encontrei a solução na FAQ do próprio Squid, o que mais uma vez demonstra que normalmente a solução mais simples é a mais correta.

Foi necessário somente adicionar as seguintes linhas ao arquivo /etc/squid/squid.conf :
acl msn urlpath_regex -i gateway.dll
acl msnd dstdomain messenger.msn.com gateway.messenger.hotmail.com
acl msn1 req_mime_type application/x-msn-messenger

http_access allow msnd
http_access allow msn
http_access allow msn1

Obviamente é necessário colocar as permissões (http_access) na ordem correta no seu arquivo de configuração, já que o Squid funciona por ordem de precedência das regras. Mantive também as regras antigas, mas só por precaução. Futuramente irei removê-las e atualizarei esse post com o resultado.

A diferença básica com relação as regras anteriores é que não estava usando uma acl que avaliava o mime type, o que parece ser a grande sacada para o uso do MSN.

UPDATE 25/09/09: Para resolver o problema de não carregar a lista de contatos, basta configurar que a URL contacts.msn.com e seus subdomínios possa ser acessada sem autenticação.

sexta-feira, 18 de setembro de 2009

Post-LA-ng - o início de um novo projeto

Algo que sempre sinto falta quando faço uma nova instalação de um servidor de correio eletrônico é a possibilidade de permitir que o administrador do mesmo possa pesquisar nos logs de e-mails de forma simples e eficaz. Já procurei várias ferramentas, mas não encontrei nada que atendesse minhas expectativas.

Pois parece que essa insatisfação é compartilhada com muitas outras pessoas, pois essa semana fui procurado pelo Fábio Luiz, que me apresentou ao software Post-LA (software para geração de relatórios e análise de logs do Postfix) e me convidou para dar sequência ao projeto.

Analisando o mesmo percebi que ele é bastante interessante, mas que ainda existe muito para ser melhorado e explorado. Então, percebemos que o interessante mesmo seria pegar a idéia inicial do Post-LA e fazer um fork avançado do mesmo, que acabei batizando de Post-LA-ng (nomes criativos para projetos nunca foram o meu forte).

E parece que iniciamos já com o pé direito, pois o Post-LA-ng já nasce com uma equipe de peso. Contamos com o Fábio Luiz, com o Leandro Mendes, com o Reinaldo de Carvalho (que irá desenvolver o parser em Python), com o Henrique Bueno (desenvolvedor do Post-LA original) e também com a ajuda da equipe de desenvolvimento da Propus, que deverá cuidar da interface web da aplicação (talvez usando Django).

Algumas features planejadas para as primeiras versões:
  • Parser dos logs em "tempo real" com armazenamento em banco de dados (MySQL ou Postgres - a definir);
  • Interface web para geração de relatórios com filtros e ordenamento pelos campos (remetente, destinatário, data, etc..);
  • Geração de gráficos e estatísticas (maiores remetentes, maiores destinatários, maiores mensagens, entre outros);
A expectativa é já ter em algumas semanas uma primeira versão funcional, com recursos básicos de pesquisa.

Aguardem mais notícias e sigam acompanhando o projeto na página do SourceForge. E fiquem de olho porque o projeto promete !

sábado, 12 de setembro de 2009

Utilizando o Postfix Quota Reject 2.0

Implementar o Postfix Quota Reject em um servidor com Postfix + Cyrus/Courier é uma tarefa bastante simples e que agrega muito ao serviço de correio.

O PQR é composto de 2 scripts Perl que rodam como policy daemons no Postfix. Existe uma versão para Cyrus e outra para Courier, mas ambas funcionam de forma análoga. O projeto é bem documentado, e o tarball vem com um pdf que explica mais sobre o software.

Instalando o PQR

Para começar baixe o .tar.gz do PQR e abra-o em um diretório ( por exemplo /usr/local/pqr ). É preciso dar permissão de leitura e de execução nesse diretório e nos scripts para o usuário que for rodar os daemons ( nesse caso, vou usar o usuário vmail ).

Configurando o Postfix

Arquivo /etc/postfix/master.cf:

Adicione as seguintes linhas no arquivo master.cf:
127.0.0.1:2222 inet n n n - 0 spawn user=vmail argv=/usr/local/pqr/postfix-qreject-frontales.pl
127.0.0.1:3333 inet n n n - 0 spawn user=vmail argv=/usr/local/pqr/postfix-qreject-buzones-courier.pl

Se você for usar cyrus, troque o script postfix-qreject-buzones-courier.pl pelo script postfix-qreject-buzones-cyrus.pl.

E não esqueça: é preciso que o usuário que rodará os scripts (configurado no master.cf) tenha permissão de leitura e execução dos mesmos, caso contrário os daemons não serão carregados.

Arquivo de classe de restrição (/etc/postfix/qreject):

É necessário criar um arquivo com os domínios que serão consultados pelo PQR. O conteúdo do arquivo deve ser algo como:
[root@mailserver /etc/postfix]# cat qreject
seudominio.com.br pqr

Após a criação ou modificação desse arquivo, gere a tabela hash com o comando postmap /etc/postfix/qreject.

Explicando de forma bem simples, esse arquivo (juntamente com as demais configurações) garante que qualquer e-mail enviado para o domínio seudominio.com.br deverá consultar a classe de restrição pqr, que será criada no arquivo /etc/postfix/main.cf e que evocará os scripts do Postfix Quota Reject.

Arquivo /etc/postfix/main.cf:
# Classe do pqr
pqr = check_policy_service inet:127.0.0.1:2222

smtpd_restriction_classes = pqr # caso já existam outras classes, basta adicionar a classe pqr a lista

smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
check_recipient_access hash:/etc/postfix/qreject,
...

smtpd_end_of_data_restrictions = check_policy_service inet:127.0.0.1:2222

Criando o banco de dados do PQR


Antes de continuar, é preciso criar o banco de dados do PQR no servidor MySQL.

Para isso crie um database (com nome de qreject, por exemplo) e um usuário (novamente qreject) que tenha permissão total nesse banco. Como não é o objetivo desse post, não irei entrar nos detalhes dessas operações, supondo que o leitor saiba como efetuar tais tarefas.

Depois de criados adicione os dados do script qreject.sql que vem com o tarball do PQR nesse novo DB. Isso pode ser feito com o seguinte comando (logado como root) :
mysql -p -D qreject < /usr/local/pqr/qreject.sql

Arquivo /usr/local/pqr/postfix-qreject-frontales.pl
(obs. do Allan Carvalho)

Abra o arquivo /usr/local/pqr/postfix-qreject-frontales.pl e altere as variáveis do banco de dados, com os dados do seu servidor.

No meu exemplo, tenho o seguinte:
our $mysql_server = "127.0.0.1";
our $mysql_port = 3306;
our $database = "qreject";
our $usu_mysql = "qreject";
our $clave_mysql = "password";

Inserção de usuários no DB


Como já explanado em meu post anterior, o mais trabalhoso na configuração do PQR é a necessidade de cadastrar no banco de dados cada conta que deverá ser verificada (o que por outro lado também torna a ferramenta mais flexível, pois permite que você verifique somente as contas desejadas).

Para facilitar essa tarefa (pelo menos nos casos onde todas as contas do servidor devem ser consultadas), adaptei alguns scripts (baseados nos originais sugeridos por Egoitz Aurrekoetxea Aurre, desenvolvedor do Postfix Quota Reject) e os mesmos podem ser baixados aqui. É bem provável que sejam necessárias pequenas adaptações para fazê-los funcionarem no seu ambiente, mas nada que seja complexo.

DICA: caso existam contas com quota ilimitada (ou sem quota), não adicione estas no DB, pois o sistema irá negar todas as mensagens destinadas as mesmas por overquota (experiência própria).

Concluindo

O PQR é uma ferramenta eficiente que permite o bloqueio de mensagens destinadas a usuários com caixas postais lotadas diretamente no SMTP. Tal abordagem além de não gerar tráfego desnecessário, reduz as filas no seu servidor e garante que o remetente tenha consciência de que a mensagem não foi entregue logo após enviá-la, o que em muitos casos é algo fundamental. Sua instalação é simples e sua performance é muito boa, o que me faz recomendar sua instalação sem receios em qualquer servidor que necessite desse recurso.


Leia também:Link

sexta-feira, 11 de setembro de 2009

Lançado o RC1 do servidor XMPP ejabberd 2.1.0

Três semanas após o lançamento do beta2, acaba de ser liberado o RC1 do servidor XMPP ejabberd 2.1.0.

A nova release traz vários bugfixes, melhorias nas traduções e alguns novos recursos em relação ao beta2.

Faça o download da versão e ajude a testar o software. Se não houver mais nenhum bug crítico, a versão final deverá ser liberada no fim da próxima semana.

Leia a notícia oficial aqui.


Leia também:

quinta-feira, 10 de setembro de 2009

Lançado o Postfix Quota Reject 2.0

No início dessa semana foi disponibilizada a versão 2.0 do Postfix Quota Reject. O PQR é um policy daemon do Postfix que permite a rejeição diretamente no SMTP de mensagens enviadas para caixas postais que estejam lotadas (consultando em tempo real o status da quota).

Já baixei a nova versão e estou testando-a. A configuração foi muito simples, mas encontrei uma situação que parece "engessar" a ferramenta: a obrigatoriedade de cadastramento das contas que serão consultadas pela ferramenta em um DB. Por isso já entrei em contato com o desenvolvedor pra esclarecer essa questão e sugerir a criação de uma feature que permita consultar todas as contas de um servidor, sem necessidade de uso do DB.

Estou ainda no início dos testes, mas assim que tiver mais dados farei um post completo sobre a ferramenta.


Leia também:

segunda-feira, 7 de setembro de 2009

Pidgin 2.6.2

Sei que hoje é feriadão, mas não poderia deixar de postar essa dica rápida:

Saiu o Pidgin 2.6.2. ChangeLog aqui e pacotes para Ubuntu (9.04) aqui.

terça-feira, 1 de setembro de 2009

Lançado o KDE 4.3.1


Passado quase um mês do lançamento do KDE 4.3.0, a versão 4.3.1 acaba de ser liberada.

A nova versão é um release de bugfixes, traduções e manutenção. Ou como informado no próprio site do KDE, é um update mensal do KDE 4.3 (o que pode vir a ser algo interessante). Apesar de não trazer novos recursos e ferramentas, a atualização é recomendada. Leia o anúncio oficial ou o ChangeLog completo.

Se você for usuário de Ubuntu 9.04 e suas variações (Edubuntu, Xubuntu, Kubuntu), saiba que os pacotes para a nova versão já estão disponíveis. Para instalá-los adicione a seguinte linha a seus repositórios (/etc/apt/sources.list):
  • deb http://ppa.launchpad.net/kubuntu-ppa/backports/ubuntu jaunty main
Depois de adicionar o novo repositório basta rodar um apt-get update && apt-get dist-upgrade. Se preferir, utilize as ferramentas gráficas (adept updater ou equivalente) para realizar a operação.

Boa sorte ;-)