quinta-feira, 27 de agosto de 2009

"Resposta" do desenvolvedor do plugin Java-monitor do Openfire

Hoje recebi o seguinte comentário do desenvolvedor do plugin Java-monitor, com relação a meu post sobre o mesmo:

Dear Marcelo,

I just read your comment on my Java-monitor. I agree that many people will be put off by the fact that we collect the data centrally.

For the people who like and use Java-monitor it this is the whole point, though. :) No need to set up a separate monitoring server and spend time on that. Ultimately, it is a choice between convenience and control.

For you, who has the experience and time to set up a Zabbix or Nagios server, that is probably the better choice. It allows you to customise the monitoring in a way that Java-monitor does not offer.

Best of luck with monitoring your servers. If you have any tips about what to monitor in a JVM or an Openfire server, I would love to hear from you. :-)

Kees Jan, operator of Java-monitor

PS. I posted a link-back and some further comments at http://java-monitor.com/forum/showthread.php?t=512

Li a "resposta" e também o post no fórum e só tenho a dizer que apesar de não gostar do modelo adotado pelo plugin acredito que o mesmo possa atender muita gente que talvez não tenha as mesmas preocupações que tenho e a disponibilidade de usar ferramentas próprias para tarefa.

Com relação ao argumento de que me importo em manter meus dados de monitoração fechados, mas não me incomoda manter meus posts num serviço de Blogs (sobre o qual não tenho controle direto), acredito que a importância dos dados e da disponibilidade do monitoramento dos meus serviços e de nossos clientes seja mais relevante do que o meu blog, já que este último é só um hobby. Além disso, creio que não faria muita diferença (do meu ponto de vista), postar aqui no Blogger ou num servidor próprio que rodasse WordPress, por exemplo. O meu objetivo seria atingido de qualquer maneira.

Vou tentar contatar Kees Jan e adicioná-lo na minha conta Jabber.org, pois parece que temos muitas idéias pra trocar e discutir.

;-)


Leia também:

terça-feira, 25 de agosto de 2009

Nova versão do Dspam a caminho

Se tudo ocorrer como planejado, parece que até o final do mês de setembro será lançada a primeira versão do Dspam (3.9.0) desde que o mesmo voltou para a comunidade.

Mas segundo informações de Ion-Mihai Tectu, um dos novos desenvolvedores, a versão 3.9.0 não irá trazer nenhum novo recurso. Segundo ele, essa versão servirá para corrigir uma série de bugs encontrados, melhorar a performance do software e adaptá-lo ao novo modelo de desenvolvimento.

E mais, a expectativa é que em torno de duas semanas após o lançamento da versão 3.9.0, a versão 3.9.1 seja disponibilizada. A versão 3.9.1 terá seu foco na melhoria do suporte a localização da interface web do Dspam, um aspecto desse software que, do meu ponto de vista, nunca recebeu a atenção necessária.

Com base nessas informações podemos esperar por novas features somente a partir da versão 3.9.2, o que não diminiu a importância da realização dos upgrades assim que as novas versões forem sendo lançadas (eu diria que pelo menos o upgrade para a versão 3.9.0 é bastante recomendado).

O Dspam 3.9.0 beta1 está disponível para download e já estou testando-o há vários dias sendo que o mesmo está funcionando perfeitamente. Também segundo informações de Ion, o beta2 estará disponível ainda essa semana com muitas correções em relação ao beta1.


Leia também:

KDE 4.3 no (K)Ubuntu 9.04 - Old news


São notícias velhas, mas como muita gente chega no meu blog procurando informações sobre como instalar o KDE 4.2.3 no (K)Ubuntu 9.04 resolvi lançar esse post "atualizado". ;-)

Os pacotes para a versão 4.3 do KDE estão disponíveis para o Jaunty Jackalope desde o início desse mês. 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.

Os pacotes ainda não são oficiais. O KDE 4.3 será parte do Kubuntu Karmic (9.10) que será lançado no próximo mês de outubro.

Via kubuntu.org.

segunda-feira, 24 de agosto de 2009

M-Link no Jabber.org

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:

Blog da Propus

Depois de contas no Twitter e no Identi.ca, agora a Propus passa a contar também com um Blog.

No estilo planet, o blog da Propus se propõe a agregar os melhores posts dos blogs de seus colaboradores, além de contar eventualmente com um conteúdo exclusivo e direcionado.

Então, se você acompanha meu blog, você está convidado a acompanhar também o Blog da Propus e ficar ligado nas mais variadas notícias e informações sobre Software Livre e Open Source.

domingo, 23 de agosto de 2009

Postfix Quota Reject

Quem acompanha meu blog deve ter lido em um dos meus últimos posts sobre a necessidade que tinha de enviar e-mails "em tempo real" informando ao remetente sobre problemas de over quota na caixa postal do destinatário de seu e-mail.

Depois de tentar usar o Postfix com patch VDA para tal realizar tarefa (sem obter sucesso), pesquisei mais e parece que encontrei a ferramenta que vai resolver a situação. A mesma chama-se Postfix quota reject (UPDATE 10/09/2009: a pedido do desenvolvedor já atualizei o link desse post, mas a versão 1.0 está disponível aqui).

O Postfix quota reject é um policy daemon que funciona de forma muito mais eficiente e segura do que o sistema de bounce do patch VDA. Ele barra o e-mail diretamente na porta SMTP, evitando que a mensagem seja recebida, fazendo assim com que o servidor que originou o e-mail gere o bounce para o remetente. Tal abordagem além de economizar banda e processamento ainda reduz a chance de problemas de DoS.

No site do projeto encontrei a versão 1.0 que ainda não atende a minha necessidade, mas ao pesquisar mais encontrei posts falando de uma versão 2.0 que trabalha com maildir usando Cyrus ou Courier.

Entrei então em contato com o desenvolvedor (Egoitz Aurrekoetxea) que foi muito simpático e atencioso, e me prometeu que assim que voltar das férias em setembro irá me enviar o software (que será oficialmente lançado em outubro) para que eu já vá utilizando e possa dar meu feedback .

Então por enquanto só resta aguardar até setembro para colocar o software em produção. Assim que o mesmo estiver instalado postarei minha impressões sobre a ferramenta.


Leia também:

Monitorando a temperatura e fans com o MRTG

Todo ano quando chega o verão me deparo com uma preocupação: a temperatura do meu computador.

Depois de anos "sofrendo" com isso, conversando com o Alberto recebi uma sugestão simples mas que nunca tinha pensado em utilizar: monitorar a temperatura do micro com o MRTG.

Com essa ideia na cabeça, cheguei em casa e me dedique a implementação.

Para começar, instalei o pacote lm_sensors e configurei o computador para ler os sensores, com o comando sensors-detect. Após responder SIM a todas as perguntas, testei se a leitura dos sensores estava funcionando com o comando sensors. A saída recebida foi:
root@hellboy:/# sensors
it8718-isa-0680
Adapter: ISA adapter
in0: +1.15 V (min = +0.00 V, max = +4.08 V)
in1: +2.13 V (min = +0.00 V, max = +4.08 V)
in2: +3.34 V (min = +0.00 V, max = +4.08 V)
in3: +2.98 V (min = +0.00 V, max = +4.08 V)
in4: +3.06 V (min = +0.00 V, max = +4.08 V)
in5: +1.52 V (min = +0.00 V, max = +4.08 V)
in6: +0.00 V (min = +0.00 V, max = +4.08 V) ALARM
in7: +2.96 V (min = +0.00 V, max = +4.08 V)
in8: +3.23 V
fan1: 1027 RPM (min = 0 RPM)
fan2: 0 RPM (min = 0 RPM)
temp1: +18.0°C (low = -1.0°C, high = +127.0°C) sensor = thermal diode
temp2: +25.0°C (low = -1.0°C, high = +127.0°C) sensor = thermistor
temp3: -128.0°C (low = -1.0°C, high = +127.0°C) sensor = disabled
cpu0_vid: +0.000 V

coretemp-isa-0000
Adapter: ISA adapter
Core 0: +36.0°C (high = +86.0°C, crit = +100.0°C)

coretemp-isa-0001
Adapter: ISA adapter
Core 1: +35.0°C (high = +86.0°C, crit = +100.0°C)
De posse dessa informação, comecei a criar os scripts de leitura das temperaturas dos processadores e da velocidade dos fans.

Como tenho 2 processadores, tenho de ler a temperatura do Core 0 e do Core 1. Para isso estou usando o seguinte script (/usr/local/sbin/cputemp.sh):
#!/bin/bash
echo "`/usr/bin/sensors | grep Core\ 0 | awk '{print " " $3}' | cut -c 3-6 `"
echo "`/usr/bin/sensors | grep Core\ 1 | awk '{print " " $3}' | cut -c 3-6 `"
Exemplo da saída do script:
root@hellboy:/# /usr/local/sbin/cputemp.sh
37.0
36.0
Da mesma maneira, tenho 2 fans. Assim, para ler a rotação dos mesmos estou usando o seguinte script (/usr/local/sbin/fans.sh):
#!/bin/bash
echo "`/usr/bin/sensors | grep fan1 | awk '{print " " $2}' | cut -c 2-5 `"
echo "`/usr/bin/sensors | grep fan2 | awk '{print " " $2}' | cut -c 2-5 `"
Exemplo da saída do script:
root@hellboy:/# /usr/local/sbin/fan.sh
1025
0
Esses scripts não são genéricos, e provavelmente terão de ser adaptados para a realidade de cada computador, pois dependem da versão do lm_sensors instalada e de como seus dispositivos serão detectados.

Depois de verificar que os scripts estão funcionando é hora de instalar o MRTG e o Apache (para poder visualizar os gráficos no browser). No meu caso, como uso Ubuntu, rodar apt-get install mrtg apache2 é o suficiente. Depois de instalados, é necessário criar a pasta /var/www/mrtg.

Edite então o arquivo /etc/mrtg.cfg colocando no mesmo o seguinte conteúdo:
WorkDir: /var/www/mrtg
Language: brazilian

Target[fan]: `/usr/local/sbin/fan.sh`
Title[fan]:"Coolers"
PageTop[fan]:

Coolers


Options[fan]: growright,gauge,noinfo,unknaszero
YLegend[fan]: RPM
ShortLegend[fan]: RPM
MaxBytes[fan]: 8000
Legend1[fan]: Fan1
Legend2[fan]: Fan2
LegendI[fan]: Fan1
LegendO[fan]: Fan2

Target[temp]: `/usr/local/sbin/cputemp.sh`
Title[temp]:"Temperatura da CPU/MB"
PageTop[temp]:

Temperatura CPU/MB


Options[temp]: growright,gauge,noinfo,unknaszero
YLegend[temp]: Graus Celsius
ShortLegend[temp]: Graus
MaxBytes[temp]: 90
Legend1[temp]: Core0
Legend2[temp]: Core1
LegendI[temp]: Core0
LegendO[temp]: Core1

Como uso Ubuntu, o MRTG por padrão já roda no cron a cada 5 minutos. Se não for seu caso, basta criar o arquivo /etc/cron.d/mrtg, com o seguinte conteúdo:
*/5 * * * * root if [ ! -d /var/lock/mrtg ]; then mkdir /var/lock/mrtg; fi; if [ -x /usr/bin/mrtg ] && [ -r /etc/mrtg.cfg ]; then env LANG=C /usr/bin/mrtg /etc/mrtg.cfg 2>&1 | tee -a /var/log/mrtg/mrtg.log ; fi
Para finalizar, crie um index.html para sua página, o que irá facilitar a visualização dos gráficos. Para isso rode o comando indexmaker /etc/mrtg.cfg > /var/www/mrtg/index.html.

Finalmente, após tudo instalado e configurado, aponte seu browser para http://localhost/mrtg para acompanhar os gráficos.



Boa monitoração. :-)

PS: Baixe os scripts e arquivos de configuração aqui.

sexta-feira, 21 de agosto de 2009

Lançado o beta 2 do servidor XMPP ejabberd 2.1.0

Alguns dias depois do lançamento do ejabberd 2.1.0-beta1, os desenvolvedores acabam de lançar a versão beta2.

Cheio de novos recursos e melhorias, a versão 2.1.0 promete tornar o ejabberd um servidor XMPP ainda mais competitivo (é sempre bom lembrar que o ejabberd foi o servidor utilizado pelo Jabber.org por muito tempo).

As mudanças do beta2 para o beta1 são:
  • Adição de um servidor STUN.
  • Atualização de arquivos de tradução de várias linguagens (entre elas o pt_BR).
  • Correções no PubSub
  • Melhorias no MUC
  • E além disso, como de costume, foram corrigidos vários bugs
A expectativa de lançamento da versão final ainda é para o final do mês. Se você quiser ajudar a testar a nova versão, baixe os fontes aqui.


Leia também:

Jabber.org altera seu servidor XMPP

Depois de quase 3 anos utilizando o servidor XMPP ejabberd, a Jabber.org anunciou no último dia 12 de agosto que passará a utilizar o servidor M-Link da Isode pelo próximos dois anos pelo menos.

Pelo menos duas coisas me incomodaram muito nessa troca:
  • O M-Link não parece ser FLOSS. Se for, não achei onde baixar os sources (se é que estão disponíveis).
  • O M-Link usa um LDAP próprio, e parece não ser integrável com outros servidores LDAP, como o OpenLDAP, por exemplo.
Quando li a notícia da troca, na hora fiquei interessado em efetuar alguns testes com esse servidor, mas após ler mais sobre o M-Link fiquei realmente decepcionado. É bastante possível que seja um produto comercial e proprietário.

Vou tentar um contato com stpeter pra tentar esclarecer melhor esses pontos e posto aqui o que descobrir.

UPDATE: Segundo informações do Thiago Rocha Camargo: "Infelizmente não é FLOSS. Mas é uma boa estratégia para consolidar Open Standards, a Isode é séria e utilizada até por militares."

quarta-feira, 19 de agosto de 2009

Pidgin agora com suporte a voz e vídeo

Boas notícias. Foi lançada hoje a versão 2.6.1 do cliente de mensagens instantâneas Pidgin.

Cheia de novas features e muitas correções, o destaque principal dessa versão é sem dúvida os recursos de voz e vídeo disponíveis. São eles:
  • suporte a voz e vídeo com Jingle
  • suporte a voz com GTalk
  • suporte a voz e vídeo com o cliente web Gmail.
Não perca tempo e atualize o mesmo agora. Baixe a versão 2.6.1 aqui ou aqui (usuários de Ubuntu).

Leia o ChangeLog completo e veja as novidades da nova versão.

terça-feira, 18 de agosto de 2009

Novo plugin de monitoramento para o Openfire

Depois de meses sem atividade (desde o ano passado), hoje me deparei com um novo post no site do Openfire.

O mesmo trata de um novo plugin de monitoramento, desenvolvido pela empresa (na realidade não fica claro se é desenvolvido por uma empresa, projeto ou comunidade) Java-monitor.com, que permite ao administrador monitorar seu servidor via web, com facilidade e maior conveniência (será ?).

Até aí muito bacana, a não ser pelo fato indigesto (na minha opinião) de que para usufruir do plugin você terá de usar a infraestrutura da empresa desenvolvedora, além de mandar estatísticas de seu servidor para a mesma.

E agora? Bom, infelizmente (pelo menos para a Java-monitor), eu me importo demais com a independência e privacidade (nossa e de nossos clientes), e não vejo motivo para depender de uma empresa (por maior que seja) para dispor de tais serviços, por melhor que eles sejam.

Ainda prefiro monitorar os servidores usando uma combinação dos plugins já disponíveis com outras ferramentas como Nagios ou Zabbix rodando em nossos servidores. Isso me dá controle e maior disponibilidade.

Por isso, cartão amarelo para o novo plugin. No meu ponto de vista, não vale a instalação.

Agora, não querendo ser chato nem rabugento, mas depois do site da Ignite Realtime ficar tanto tempo inativo, eu sinceramente esperava que o próximo post publicado fosse tratar de uma nova versão ou novo recurso do servidor e não de uma "pseudo propaganda" de um plugin que na minha opinião não trará vantagens pra ninguém além da empresa desenvolvedora.

Meus dois centavos.

sábado, 15 de agosto de 2009

O Flash player 64 no Ubuntu 9.04 parou de funcionar, e agora ?

Depois de meses usando a versão 64 bits do plugin do flash player (inclusive com Firefox 3.5) no Ubuntu 9.04, lamentavelmente alguma atualização de pacotes fez com que erroneamente o mesmo fosse substituído pela antiga versão 9.

Percebi tal fato ontem pois as páginas apresentavam uma seta (play) no local onde deveriam ser exibidos os objetos flash. Ao consultar o about:plugins me deparei com a situação que me causou bastante surpresa.

Pesquisando os arquivos constatei o seguinte:

A biblioteca instalada era:
1957a3414dfbfe5f7de000ae72da4cb6 ./usr/lib/firefox/plugins/libflashplayer.so
Já a versão disponibilizada pela Adobe é:
3433f503261d4c7f622be4d74ab10c9a ./tmp/adobe-flashplugin-10.0.32.18.orig/libflashplayer.so
Ou seja, são arquivos distintos, o que me faz pensar que poderia haver algo errado no meu sistema de pacotes (será algum repositório adicional que uso ?).

Tentei então reinstalar o pacote flashplugin-nonfree (Version: 10.0.32.18ubuntu0.9.04.1) e não obtive êxito, pois a situação se manteve igual. Poderia haver algo errado no pacote? Isso não é comum, mas não seria a primeira vez que lançam pacotes bugados para Ubuntu.

Bem, como a reinstalação não funcionou, decidi então pesquisar no Google e me deparei com um post que resolveu meu problema (mesmo que de forma "manual").

Basicamente, a solução consiste de 3 passos:
Dica: o script irá remover alguns pacotes do seu micro como os plugins do flash (óbvio) e o acroread. Se você desejar, pode instalar o acroread novamente após a instalação do plugin.

Essa solução instala a última versão 64 alpha do plugin (10.0.32.18), a mesma que deveria ser instalada pelo pacote. Então se você passar pelo mesmo problema que eu passei pode usar essa mesma abordagem.

Ah, e se descobrir o motivo do downgrade, poste aqui a explicação. :-)


quinta-feira, 13 de agosto de 2009

Postfix + VDA Patch - problemas no envio de bounces por over quota

Um pouco diferente do que dos outros posts desse blog, onde normalmente eu costumo postar dicas e notícias, esse tem o objetivo de solicitar a ajuda de meus leitores.

Estou com um problema estranho no Postfix (versão 2.2.10 + VDA patch). Com o uso desse patch todo o sistema de quotas funciona perfeitamente (há uns 2 anos pra ser preciso). Acontece que agora preciso configurar o postfix para dar bounce nos e-mails enviados quando o destinatário estiver com over quota (ao invés de manter os mesmos na fila pra tentar realizar a entrega), e parece que o patch nesse ponto está com algum problema.

Exemplificando:

Usando o parâmetro virtual_overquota_bounce = no (default do postfix)

Se envio uma mensagem de marcelo@dominio1.com.br para marcelo@dominio2.com.br encontro nos logs do servidor do dominio2 (onde está meu Postfix) a seguinte informação:
Aug 13 16:11:57 mail postfix/virtual[25327]: A992B5E478E: to=<marcelo@dominio2.com.br>, relay=virtual, delay=1, status=deferred (maildir delivery failed: Sorry, the user's maildir has overdrawn his diskspace quota, please try again later.)
Sendo que a mensagem continua na fila para entrega:
mailq | grep -i -A 2 A992B5E478E
A992B5E478E 3464 Thu Aug 13 16:11:56 MAILER-DAEMON
(maildir delivery failed: Sorry, the user's maildir has overdrawn his diskspace quota, please try again later.)
Perfeito: como esperado a mensagem continua na fila para entrega, até que seja descartada pelo tempo máximo.

Usando o parâmetro virtual_overquota_bounce = yes

No caso do mesmo e-mail enviado acima, encontro nos logs a seguinte informação:
Aug 13 16:14:27 mail postfix/virtual[28430]: B6FD45E4799: to=<marcelo@dominio2.com.br>, relay=virtual, delay=1, status=bounced (maildir delivery failed: Sorry, the user's maildir has overdrawn his diskspace quota, please try again later.)
É possível ver que o status mudou de deferred para bounced, sendo que a mensagem não fica mais na fila, como esperado:
mailq | grep -i -A 2 A992B5E478E
Infelizmente, apesar dos logs reportarem que o status foi bounced, o bounce não chega para o remetente (marcelo@dominio1.com.br). Além disso, nada mais é encontrado nos logs, a não ser a mensagem de que o e-mail de queue id A992B5E478E foi removido da fila.

Conclusão

Apesar dos logs estarem reportando a mudança do status, aparentemente o postfix nada faz com a mensagem, simplesmente removendo-a da fila. Poderia ser um erro de configuração (eu não consegui identificar o que pode estar errado e nem onde), mas também desconfio de que possa ser um erro no postfix+patch, pois as versões de ambos são bastante antigas.

Alguém tem alguma idéia do que pode estar errado ?

PS: assim que descobrir o problema e a solução posto aqui no blog. ;-)

quarta-feira, 12 de agosto de 2009

Gnarwl agora com suporte TLS para o LDAP

Se você usa o Gnarwl mas estava tendo dificuldades em configurá-lo em ambientes que usam LDAP com TLS, saiba que a solução foi lançada.

Foi disponibilizado no site do projeto um patch para a versão 3.6 que ativa o suporte TLS na conexão ao LDAP, resolvendo essa deficiência do software.

Não perca tempo, baixe o patch aqui. Testado e aprovado ! :-)

PS: dica do Alberto Bengoa.


Leia também:

Ejabberd 2.1 a caminho


Nota rápida: acaba de ser lançado o ejabberd 2.1.0-beta1.

Se você gosta de testar novas versões de softwares essa é sua chance. A comunidade ejabberd precisa de beta testers para avaliar e reportar possíveis bugs dessa versão.

A previsão é que a versão final seja lançada no final desse mês. Vários novos recursos e opções estão disponíveis nesse novo release. Leia o Changelog completo aqui.