Jingle Nodes – o substituto Open Source do Skype ?

Marcelo Terres
23 de fevereiro de 2010
Há muito tempo espera-se que o protocolo Jingle seja a solução para comunicação internet P2P (mais especificamente, leia-se VoIP). Infelizmente, nada muito concreto e inovador foi implementado ao longo dos anos que fizesse com que o Jingle decolasse. Alguns clientes e softwares bastante utilizados até suportam o protocolo (como o Pidgin, Asterisk e inclusive o Google Talk), mas o uso em massa (como no caso do Skype) nunca foi alcançado.

Depois de anos sem evolução, eis que surge uma nova idéia, idealizada por Thiago Camargo, que parece ser a solução para disseminação do Jingle: trata-se do Jingle Nodes. O Jingle Nodes, que ainda é uma XEP proposta (leia a mesma aqui), promete ser a nova sensação da comunicação via internet, pois permite transformar qualquer cliente XMPP em um nó público, estendendo assim a rede P2P a qualquer usuário (no melhor estilo P2P dos compartilhadores de arquivos) que pode determinar como e com quem irá compartilhar o recurso, o que não acontece por exemplo com a rede Skype. Além disso, por ser um protocolo aberto, ele pode ser estendido e melhorado pela própria comunidade, o que permite uma maior velocidade na evolução do mesmo.

E a boa notícia é que após meses de desenvolvimento, os primeiros servidores com suporte ao Jingle Nodes começam a aparecer. Como o ejabberd já suporta Jingle Nodes, a ProcessOne disponibilizou o primeiro servidor com suporte a nova feature: o talkr.IM. E tem mais: ainda em fase de desenvolvimento, um cliente para uso do Jingle Nodes (que nada mais é do que um addon para o Firefox) já está em sua versão beta e deve ser lançado no futuro próximo.

Além disso, para os administradores do Openfire, um boa notícia também está no ar: um plugin para esse servidor também está em desenvolvimento e deve ser disponibilizado em alguns meses.

Ou seja, nem bem começou o ano (afinal o Carnaval recém acabou) e já temos grandes promessas e expectativas para 2010, que pode vir a ser o ano do VoIP P2P Open Source.

É esperar pra ver...

Samba 3.5.0 com suporte experimental a SMB2

Marcelo Terres
26 de novembro de 2009

O time de desenvolvimento do Samba anunciou hoje o lançamento da versão 3.5.0pre1 do software e o grande destaque dessa nova release com certeza é o suporte (ainda que experimental) ao protocolo SMB2.

O SMB2, desenvolvido pela Microsoft, possui várias modificações em comparação a seu antecessor, entre as quais cabe citar:
  • Melhorias na perfomance da comunicação entre cliente e servidor;
  • Melhorias na performance da transferência de arquivos grandes;
  • Menor overhead do protocolo (número de comandos e subcomandos reduzido de mais de 100 para apenas 19);
  • Melhor escalabilidade;
O SMB2 foi implementado inicialmente no Windows Vista mas já está disponível em todas as versões mais recentes dos sistemas operacionais da Microsoft. Windows 7 e Windows 2008 R2 já utilizam o SMB2.1, que segundo informações é ainda mais performático. Apesar de ser proprietário, a especificação do protocolo foi publicada para permitir que outros sistemas possam interagir com os SOs da Microsoft que usam essa nova versão.

Ainda em caráter experimental no Samba, o uso do SMB2 além de aumentar a performance de maneira geral promete diminuir a quantidade de "lixo" que circula na LAN e que é gerada pelo protocolo SMB versão 1.

Outras fontes de informação sobre o SMB2:

UPDATE 30/12/2009: a equipe de desenvolvimento do Samba anunciou que a versão 3.6.0 deverá ter suporte total ao protocolo SMB2.

Leia o Changelog completo da nova versão do samba aqui.


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

Marcelo Terres
18 de setembro de 2009
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 !

Palestra no Encontro VoIPCenter 2009

Marlon Dutra
16 de setembro de 2009

A seguir os slides da palestra que eu apresento hoje na 4a edição do Encontro VoIPCenter, em São Paulo.

Python Brasil

Marlon Dutra
13 de setembro de 2009

Estive esta semana, com meus colegas Felipe Mobus e Marcio Silva, na 5a edição do Python Brasil, na cidade de Caxias do Sul, serra gaúcha. O evento foi organizado pela Associação Python Brasil e é o maior evento sobre a linguagem de programação no Brasil. É um evento itinerante e o Rio Grande do Sul o sediou pela primeira vez.

Foram três dias de palestras bastante técnicas e deu para aprender  coisas bem interessantes, clarear algumas dúvidas e conversar com bastante gente legal.

Um dos temas mais fortes no evento foi Django, como já era de se esperar. Django está em alta na comunidade Python, e certamente com muitos méritos. É um excelente framework e estamos estudando ele para adotar em alguns projetos na Propus. Seu ORM (Object-relational mapping) é sensacional, entre outras funcionalidades muito interessantes. Um dos criadores do Django, o americano Jacob Kaplan-Moss, esteva presente no evento e fez uma palestra muito interessante sobre desenvolvimento web. Para quem não conhece Django, vale a pena perder um pouquinho de tempo a ler a respeito.

Quem não pôde ficar de fora foi o super polêmico GIL (Global Interpreter Lock) do interpretador CPython. Parece que esse é o ponto mais negativo do Python (na verdade do CPython), uma vez que ele não permite que duas threads acessem a memória ao mesmo tempo, jogando assim no lixo todo o ganho de performance que um programa multi-thread poderia ter com máquinas multi processadas, o que é muito comum hoje em dia e já se mostrou ser o futuro mesmo. Enfim, isso é uma discussão tremenda e existe vários argumentos positivos e negativos em relação ao tão odiado GIL. Basta procurar por “Python GIL” no google e se divertir com o assunto. Tem muito pano pra manga.

Outro americano, Collin Winter, funcionário do Google, palestrou no evento também. Collin falou sobre o Unladen Swallow, um projeto do Google focado em otimizar o interpretador CPython. Eles criaram um fork do projeto CPython, mas a ideia é retornar todas as melhorias que eles puderem fazer ao projeto principal. Ele apresentou vários exemplos onde o interpretador é muito ineficiente e poderia ser melhorado. O Google possui muita coisa escrita em Python, uma vez que Python é uma de suas linguagens oficiais. Devido à grande escala do Google, eles têm todo o interesse em tornar o interpretador mais eficiente.

O keynote speaker do último dia foi o Gustavo Niemeyer, da Canonical. Ele fez uma palestra bastante interessante comparando friamente Python e Java. Existe uma certa rivalidade entre as duas linguagens, então é difícil encontrar boas comparações imparciais. Gostei do tom da palestra do Gustavo, que procurou ser muito imparcial. Ele fez várias provocações ao Python e defendeu que, para um projeto grande, com muitos desenvolvedores, Java parece ser a melhor opção, por ser mais organizado. A permissividade e alta flexibilidade do Python são indiscutivelmente fantásticas, porém isso pode atrapalhar quando a coisa cresce.

Enfim, foi um bom evento e certamente agregou muito. Sendo Python uma das linguagens oficiais na Propus, é de fundamental importância estarmos o mais sintonizados possível no que está acontecendo na comunidade em volta da linguagem. Mesmo ouvindo alguns pontos fortes de Java, vamos continuar programando muito em Python, porque colocando as duas linguagens na balança, Java fica pra trás, considerando as demandas que temos. Python é extremamente produtivo e sua flexibilidade é algo chave para a Propus, pois trabalhamos com projetos bastante específicos, e muitas vezes precisamos de uma interação muito íntima com outros sistemas e com o sistema operacional.

Uma das coisas que prezamos na Propus é que temos que ser profundos conhecedores das tecnologias envolvidas no nosso trabalho. Infelizmente vemos muita gente prestando serviço em áreas onde os técnicos têm um conhecimento muito superficial das coisas, e muitas vezes nenhum conhecimento teórico. Não é esse serviço que queremos vender. Somos incansáveis estudantes, primeiro porque gostamos muito do que fazemos, segundo porque queremos que nossos clientes se sintam à vontade de nos confiar alguma missão importante.

Utilizando o Postfix Quota Reject 2.0

Marcelo Terres
12 de setembro de 2009
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

Apresentando XMPP4R-Observable

Pablo Lorenzzoni
7 de setembro de 2009

Há apenas alguns dias fiz uma apresentação no FISL10 sobre a utilização de XMPP PubSub com Ruby e sobre um fork de uma biblioteca popular à qual acrescentei os rudimentos do PubSub. Naquela mesma apresentação listei uma série de problemas que aquela abordagem tem e falei sobre um roadmap para o futuro…

Acontece que acabei me convencendo de que não posso utilizar o PubSub no lado XMPP da biblioteca e uma forma de periodical pooling no lado Ruby. Resolvi, então, substituir a biblioteca que havia forkado por uma versão Observable, preservando as coisas boas do XMPP4R-Simple. O resultado chamei de XMPP4R-Observable, e acabo de publicar no GitHub.

Uma boa parte do código está coberta por testes (e “roubei” alguns dos testes da própria XMPP4R-Simple)... pretendo cobrir o restante ao longo do tempo (contribuições são bem-vindas). Por hora, chamei esse primeiro release de versão 0.5.1 e acrescentei um .gemspec para gerar um .gem automaticamente… No entanto, o GitHub ainda não publicou o .gem… Quando publicar, para instalá-lo deve ser tão simples quanto:


bash# gem sources -a http://gems.github.com
bash# gem install spectra-xmpp4r-observable

Não deixem de reportar qualquer erro. Happy hacking.

Update 2009-09-13 10:29:00: Acabo de confirmar que o .gem foi publicado pelo GitHub.

Update 2009-10-10 20:21:00: O .gem do XMPP4R-Observable vai ser mantido no GemCutter, a partir de hoje.

Encontro VoIPCenter

Marlon Dutra
4 de setembro de 2009

Acontece nos próximos dias 16, 17 e 18 de setembro o IV Encontro VoIPCenter, na cidade de São Paulo. O Encontro VoIPCenter é um evento focado em soluções VoIP com software livre, realizado pela empresa Innovus.

Estarei palestrando pela terceira vez nesse evento este ano. Nesta edição, apresentarei a palestra “VoIP e mitos: por que a voz picota, atrasa… QoS e seus desafios”, apresentada também no último Fórum Internacional Software Livre.

O evento será no Hotel Century Paulista, no bairro Paraíso, em São Paulo – SP. Para quem está interessado em ver boas palestras sobre o tema, recomendo. A programação está bastante interessante.

Dívidas e nova seção

Pablo Lorenzzoni
31 de agosto de 2009

Eu sei, eu sei. Há muito que estou devendo uns posts aqui, principalmente de uma série que deixei inacabada, mas sabem como é… voltei de férias mas todo o resto continuou andando… Recém consegui colocar as coisas em dia e, para piorar, descobri problemas em alguns dos meus códigos que necessitaram atenção imediata (sobre isso farei um post em breve)...

Então esse post é para dizer que reconheço essas dívidas, e que estarei saldando elas em breve. Mas também, com esse post, inauguro uma nova seção nesse blog: a seção Propus. Os posts dessa seção serão agregados no blog da Propus, junto com as postagens dos outros diretores e dos funcionários da Propus.

Happy hacking / blogging.

M-Link no Jabber.org

Marcelo Terres
24 de agosto de 2009
A troca do servidor XMPP do domínio Jabber.org de ejabberd (software livre) para M-Link (que é um projeto comercial) me deixou preocupado. Encontrei o stpeter (Peter Saint-Andre, diretor executivo da XMPP Standards Foundation (XSF)) online e conversei com ele para tentar esclarecer minhas dúvidas sobre o ocorrido.

Questionado sobre a troca realizada, stpeter esclareceu que o Jabber.org ainda está rodando sobre ejabberd e que eles ainda estão planejando o processo de migração, que deve ocorrer no final de setembro.

Com relação a escolha do M-Link, ele explicou que a última troca de servidor realizada (jabberd 1.x para ejabberd em 2006) foi feita de uma maneira não muito aberta. Então, para tornar o processo público, foi criado o Server RFP, que foi atendido somente por dois projetos: M-Link e Tigase. O projeto ejabberd não enviou proposta (talvez os desenvolvedores estivessem envolvidos demais no lançamento da versão 2.1). E, como todos já sabem, o escolhido entre os dois projetos foi o M-Link, que de um ponto de vista FLOSS é um retrocesso pois trata-se de um projeto comercial.

Apesar desse "retrocesso" (na minha opinião), é preciso seguir em frente, pois como o próprio stpeter disse, quem sabe daqui há dois anos o escolhido não seja o Tigade ou o Prosody (ou até mesmo o ejabberd novamente).

Depois de esclarecida a questão confesso que fiquei menos incomodado e aproveito para desejar boa sorte ao Jabber.org nesse nova etapa. E já que estamos falando de um novo servidor, solicitei a stpeter que quando o serviço for migrado e estiver funcional ele escreva um post com suas impressões sobre o mesmo.

PS: aproveitei a oportunidade e pedi para que a URL de status do serviço fosse reativada, e ele me garantiu que eles já estão trabalhando nisso também.


Leia também: