quarta-feira, 30 de dezembro de 2009

Projeto Samba anuncia os planos para a versão 4


Exatamente no dia de Natal, a equipe de desenvolvimento do Samba anunciou seus planos para os novos releases, com ênfase especial ao Samba 4, tão aguardado.

Segue um pequeno resumo do que vem por aí:

Segundo informações dos desenvolvedores, após cinco anos de trabalho, o código de Active Directory do Samba 4 alcançou um estado satisfatório, rodando em produção em vários ambientes.

Já que atualmente o Samba 4 só possui o código do AD implementado, o próximo passo agora é juntar ao mesmo as funcionalidades de servidor de arquivos e o código do winbind, fazendo do mesmo um produto completo. O servidor de arquivos está atualmente sendo extendido para incluir o novo protocolo SMB2 e ter total suporte a ACL do Windows.

Como o trabalho envolvido em tal operação é muito grande, tal processo irá demorar, mas existe a expectativa de que o mesmo seja concluído em 2010. O plano é manter também as atualizações do Samba 3, com novas versões a cada 6 meses (a versão 3.5.0 deve ser lançada em breve, com suporte experimental ao SMB2).

Depois que o trabalho for concluído e houver um código estável, o mesmo será lançado. A grande preocupação dos desenvolvedores é facilitar o upgrade para os usuários do Samba 3, assim como minimizar os impactos das mudanças para os usuários do software.

Leia o anúncio completo aqui.


Samba: adicionando Windows 7 ao domínio


Com o lançamento do Windows 7, logo todos os administradores de domínios Samba irão se deparar com a necessidade de colocar um computador com essa versão do sistema operacional no domínio. Por isso resolvi postar um pequeno tutorial para realizar essa operação.

Para começar, é importante deixar bem claro que o suporte a Windows 7 só existe nas versões 3.3 e 3.4 do Samba. Versões anteriores do Samba não suportam o novo SO. Então se você está rodando o Samba <= 3.2 e sabe que terá que adicionar o novo SO ao seu domínio em breve, já prepare o upgrade do serviço. Mais especificamente, as versões 3.4.0 e 3.3.7 foram testadas com sucesso com o Windows 7 Ultimate (Build 2600). Todas os releases posteriores dessas versões também são compatíveis.

O registro do Windows 7

ATENÇÃO: Antes de mais nada, não edite quaisquer parâmetros do registro (NETLOGON) Se você já efetuou modificações no registro do Windows 7, desfaça as mesmas retornando-as aos valores originais.

Especificamente, se você alterou os parâmetros de NETLOGON, volte-os para '1' como pode ser visto abaixo:
HKLM\System\CCS\Services\Netlogon\Parameters
DWORD RequireSignOrSeal = 1
DWORD RequireStrongKey = 1

Adicionando as configurações corretas ao registro

Antes de colocar o computador no domínio, é necessário adicionar duas configurações no registro do Windows. Elas são:
HKLM\System\CCS\Services\LanmanWorkstation\Parameters
DWORD DomainCompatibilityMode = 1
DWORD DNSNameResolutionRequired = 0

Um arquivo .reg com as alterações necessárias pode ser baixado aqui.

Como de costume, após as alterações no registro, reinicie o computador.

Adicionando o computador ao domínio

Os procedimentos de inclusão do computador no domínio são os usuais. É importante salientar que após adicionar o computador ao domínio, você irá receber a seguinte mensagem:
"Changing the Primary Domain DNS name of this computer to "" failed.
The name will remain "MYDOM". The error was:

The specified domain either does not exist or could not be contacted"

Desconsidere esse aviso, pois a operação foi realizada com sucesso e voilá, seu computador já faz parte de seu domínio.


Leia também:



quarta-feira, 23 de dezembro de 2009

ejabberd 2.1.1 lançado

Pouco mais de um mês após o lançamento da release 2.1.0 do servidor XMPP ejabberd, acaba de ser liberada a primeira versão de correção de bugs (2.1.1) do mesmo.

Apesar de não possuir nenhum bug crítico, se você já está utilizando a versão 2.1.0 a atualização é recomendada pelos desenvolvedores.

Saiba mais acessando o ChangeLog completo da nova versão.

Leia também:

sexta-feira, 18 de dezembro de 2009

Migração do Jabber.org adiada

Após uma semana de intenso trabalho e também de muitos problemas, a migração do domínio Jabber.org para o servidor XMPP M-Link da Isode foi adiada para o início de 2010.

Steve Kille, CEO da Isode, enviou uma mensagem com mais explicações sobre a decisão. A mesma pode ser lida nesse link.

Resta agora desejar boa sorte aos mantenedores na próxima tentativa de migração e aguardar o serviço rodando sobre o novo servidor.


Leia também:

segunda-feira, 30 de novembro de 2009

Lançada nova versão do servidor XMPP Prosody


A versão 0.6.x do servidor XMPP Prosody foi lançada na última semana.

A nova versão do servidor (que é totalmente desenvolvido em Lua) implementa novas features, muitas das quais já podem ser encontradas nos demais servidores XMPP como Openfire e Ejabberd há algum tempo.

Entre as novas features, destaque para:
  • Console via Telnet (uma carência do Openfire), onde é possível recarregar a configuração do servidor e adicionar/remover virtual hosts sem a reinicialização do serviço. Além disso, uma opção de desligamento amigável do servidor (com envio de mensagens para todos os usuários) foi também implementada;
  • Compressão de dados cliente/servidor para otimização do uso da banda;
  • Conexões S2S criptografadas;
  • Suporte a certificados TLS/SSL por virtual host;
Além das novas features listadas acima, o Prosody também tem suporte a virtual hosts, um recurso que não está disponível no Openfire. Mas, apesar disso, o Prosody (ainda) não possui suporte a plugins, transportes, interface web e tantas outras features que fazem do Openfire um dos servidores XMPP mais populares do momento.

No entanto, como o projeto está bastante ativo, com várias versões lançadas nos últimos meses, isso pode ser um indício de que o mesmo venha a se igualar aos outros servidores existentes em algum tempo.

Outras informações:
Faça o download da última versão estável (0.6.1) aqui.

PS: a versão 0.6.1 é basicamente um bugfix de um problema detectado após o lançamento de 0.6.0.


Pidgin 2.6.4 lançado

Lançado o cliente de IM Pidgin 2.6.4.

A nova versão traz uma série de alterações no aplicativo assim como uma série de melhorias e bugfixes nos protocolos (especial atenção aos crashs causados pelo uso de contas MSN que eventualmente derrubam o aplicativo - espero que isso tenha sido definitivamente solucionado nesse novo release).

Como o lançamento foi realizado na data de ontem, é provável que nas próximas horas já existam pacotes disponíveis para o Ubuntu 9.10 (Karmic Koala).

Leia o Changelog completo aqui.

quinta-feira, 26 de novembro de 2009

Samba 3.5.0 com suporte experimental a SMB2


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.

quinta-feira, 19 de novembro de 2009

Openfire: plugin User Status



Bela dica do Marcos Lucas (membro da lista Openfire-BR), o plugin User Status, desenvolvido por Stefan Reuter, vem ao encontro de uma necessidade de muitos administradores do Openfire: a possibilidade de manter o histórico de acesso dos usuários ao serviço.

O plugin grava os dados em duas tabelas próprias, e possibilita o armazenamento de login, resource, IP e data de login e logoff dos usuários, o que permite a realização de uma auditoria de uso do sistema.

O que muitos administradores irão perceber logo de início é a falta de uma interface de consulta do histórico (que poderia ser adicionada no próprio console admin), mas isso pode ser resolvido com o desenvolvimento de uma simples interface web. Apesar da falta desse recurso, o plugin é um grande aliado aos sysadmins que precisam controlar e inspecionar o uso do serviço XMPP em suas empresas.

Para que ainda não conhece o plugin, consulte o site oficial do projeto.

E, caso o link para download esteja fora do ar, baixe o plugin aqui (versão 1.0.3).


OT: O dado do Pacman


Apesar de não ser FLOSS e ser totalmente off-topic, não poderia deixar de postar as fotos do dado do Pacman que minha esposa Renata fez pra mim.

Só de olhar para o mesmo já me dá vontade de instalar o Stella ou o XMame e jogar um pouco ;-)





sexta-feira, 13 de novembro de 2009

Lançado o ejabberd 2.1.0

Finalmente, após quase dois anos de desenvolvimento, foi lançada a versão 2.1.0 do servidor XMPP ejabberd.

Entre os novos recursos, cabe destacar:
  • Clustering
  • Servidor STUN
  • Melhorias no LDAP
  • Melhorias no MUC
  • Suporte a captcha
  • Adição de suporte a novas XEPs
Veja a lista completa de mudanças aqui. Ou, se preferir, leia a lista completa de novas features, melhorias e bugfixes.

Bastante maduro, e com vários novos recursos, o ejabberd parece ser uma alternativa ao Openfire (apesar do console de administração e do suporte a plugins do Openfire serem até o momento imbatíveis).

Agora é testar e conferir.

terça-feira, 10 de novembro de 2009

Openfire - Plugin clustering agora é Open Source

Boas notícias para os usuários do Openfire: foi lançada hoje a versão Open Source do plugin clustering.

Para quem não conhece, o plugin clustering permite rodar múltiplos servidores Openfire juntos em um cluster. Rodando o Openfire em um cluster é possível distribuir a carga entre os servidores e também ter redundância, ou seja, caso algum dos servidores se torne indisponível, o serviço continuará sendo atendido pelos demais participantes do cluster.

Porém (às vezes existe um porém), apesar de ser totalmente open source, para rodar o plugin é preciso obter uma licença do Oracle Coherence que é um produto comercial (ou seja, o plugin é open source, mas a solução completa não é "free as in grátis"). De qualquer forma é possível obter uma licença OTN (Oracle Technology Network Developer License) para testar o plugin e verificar se o investimento necessário compensa e se a solução irá atender as expectativas.

Bons testes e boas implementações :-)

PS: quem testar o plugin e/ou estiver utilizando o mesmo, por favor deixe seus comentários aqui no post.

Via Ignite Realtime.

quarta-feira, 4 de novembro de 2009

KDE 4.3.3 liberado (e KDE 4.4. quase finalizado)

Um dia após o lançamento do novo release do KDE (versão 4.3.3), já se encontram disponíveis os pacotes para o Ubuntu 9.10 (Karmic Koala).

O projeto KDE, que passou a adotar o lançamento de releases mensais, informa que a versão 4.3.3 é basicamente um bugfix e update de traduções e sua instalação é recomendável. Essa release não contém nenhuma nova feature, apesar de trazer algumas melhorias ao sistema (saiba mais no changelog).

E não é só isso: além de disponibilizar a nova versão, o time de desenvolvimento do KDE revelou também novas informações sobre o KDE 4.4 que tem previsão de lançamento para fevereiro de 2010 (o primeiro beta deve estar disponível já no próximo mês).

Usando o QT 4.6, a nova versão do KDE promete uma série de novos recursos e melhorias, inclusive na performance do sistema (veja a lista completa de features planejadas aqui).

Mas enquanto fevereiro não chega, é hora de atualizar seu KDE 4.3. Para instalar a nova versão adicione o seguinte repositório:

deb http://ppa.launchpad.net/kubuntu-ppa/ppa/ubuntu karmic main

Após, basta rodar um apt-get update && apt-get dist-upgrade para atualizar o sistema.

Boa sorte ;-)

quinta-feira, 22 de outubro de 2009

Disponíveis os primeiros mirrors brasileiros do ClamAV

Os primeiros resultados da iniciativa para a criação de mirrors brasileiros para o projeto ClamAV já começaram a aparecer.

Até agora já foram criados três mirrors que estão sendo gentilmente hospedados pelo POP, pela Faculdade Assis Gurcacz e pelo C3SL da UFPR. Além disso, a Unicamp está em processo final de disponibilização do seu mirror.

Quero deixar aqui meus agradecimentos ao professor Paulo Licio de Geus, Allan Carvalho e Miguel Di Ciurcio Filho da Unicamp, ao Vinicius Lage do POP e ao Carlos Carvalho, Andre Luiz Neves e Luis Carlos Erpen de Bona do C3SL. Meu agradecimento também aos demais envolvidos no processo e a todos que de alguma forma apoiaram e incentivaram a idéia.

Agora é hora de fazermos nossa parte: alterem a configuração do freshclam para baixar o CVD (ClamAV Virus Database) de db.br.clamav.net e comecem a usar os novos mirrors.

Veja a lista completa dos mirrors brasileiros aqui.

PS: se você tem disponibilidade e interesse de ser também um mirror do ClamAV, saiba mais aqui.


UPDATE 27/10/09:
Hoje a Unicamp passou a ser também um mirror brasileiro do projeto ClamAV. Obrigado.

sexta-feira, 16 de outubro de 2009

Kraken, o substituto do plugin Gateway IM

Tenho percebido pela lista Openfire-BR que muitas pessoas ainda usam o plugin Gateway-IM, mas o que muitos parecem ainda não saber é que o mesmo foi descontinuado e substituído pelo plugin Kraken.

O plugin Kraken foi criado por Daniel Henninger, o mesmo desenvolvedor do Gateway IM e usa como base o antigo plugin, ou seja, ele segue de onde o Gateway IM parou, com a mesma interface e as mesmas configurações. A principal mudança no projeto é que o Kraken foi criado para ser um plugin que possa ser usado em vários servidores XMPP e não somente no Openfire.

Quem ainda utiliza o antigo plugin deve migrar para o Kraken já, pois as novas versões deste resolvem uma série de bugs do Gateway IM. Veja o changelog completo no final desse post (em inglês).

Mais estável, parece que o Kraken veio mesmo para ficar pois o projeto está em constante desenvolvimento (já foram lançadas 4 releases desde sua criação em fevereiro desse ano), sendo que a última (1.1.2) data de 4 de setembro passado. Além disso, no seu roadmap podemos perceber que muitas outras features estão previstas, como:
  • Plugin para o servidor XMPP Tigase
  • Transferência de arquivos
  • Suporte a MUC
  • Suporte a VCard
  • Suporte a pesquisa
Veja o Changelog completo, desde o lançamento:
1.1.2 -- September 3, 2009
Issues Resolved
  • 2849285 - java6 packing of java5 bytecode
  • 2843526 - Can't change contact alias
  • 2843403 - failed logins during jabber:iq:register should return error
  • 2839490 - MSN nickname not update to current.
  • 2833421 - Chat notification (xep-0085 vs xep-0022)
1.1.1 -- September 1, 2009
Issues Resolved
  • 2848127 - Duplicate messages received from Yahoo (sometimes)
  • 2848125 - Facebook transport stopped working
  • 2844097 - Cannot subscribe to a Yahoo account presence
  • 2831758 - Handle "susbcribe" and "subscribed" requests from/to Yahoo
  • 2831758 - Gateway returns malformed message stanzas on registration er
1.1.0 -- August 2, 2009
Issues Resolved
  • 2826177 - Facebook transport causing cpu usage overload
  • 2580754 - XML-RPC Interface
  • 2819012 - Can't log on
  • 2809576 - MSN setting of XMPP avatar not working
  • 2809577 - GTalk statuses not syncing properly
  • 2724131 - Problem sending messages to other domains (eg. rocketmail)
  • 2684526 - incorrect links in kraken-registrations.jsp
  • 2505876 - Personal Message of MSN should be unescaped according to html
  • 2317907 - Can not authenticate to jabber.org
  • 2317879 - MSN disconnecting after 20 minutes
  • 2316446 - Status icon does not change properly
  • 2316417 - Avatar loading timeout with gateway contacts
  • 2814933 - Compile broken
  • 2813271 - Contacts' status is always offline
  • 2810485 - Building failure
  • 2805974 - Building failure
  • 2787891 - /plugins/kraken/xml-rpc
  • 2740016 - "Update available" when using a different translation
  • 2671590 - Error when paging msn registrations
  • 2657400 - Connection Timeout
  • 2655458 - XMPP transport
  • 2636608 - GaduGadu: encoding problems
  • 2543459 - MSN constantly disconnecting
  • 2317906 - Sometimes folk can send messages but not receive
  • 2317831 - Some folk are having connection issues with MSN
  • 2603935 - Facebook Transport
  • 2368670 - MySpaceIM transport
  • 2316441 - Sametime Transport
1.0.0 -- February 8, 2009 -- Initial release
Issues Fixed Since IM Gateway 1.2.4d
  • 2531221 - Russian ICQ users can not connect
  • 2317818 - MSN transport seems to be leaving a lot of session listeners
  • 2317915 - XmppConnections are left behind
  • 2317739 - vCard PHOTO element has empty namespace?
  • 2317862 - MSN Transport is stop working after ~ 1 day

Leia também:


UPDATE 17/06/2012: Saiba mais sobre o Spectrum IM, o projeto atual do desenvolvedor do Kraken e do Gateway IM (ambos descontinuados).

quarta-feira, 7 de outubro de 2009

Mirror brasileiro para o ClamAV

Durante o FISL 10 tive uma conversa com Tomasz Kojm, criador do ClamAV (antivírus FLOSS), que me disse que apesar de existerem entre 150-200 mil instalações do ClamAV na América do Sul (a maioria delas no Brasil), o projeto não possui um mirror em nosso país para distribuir seu CVD (ClamAV Virus Database).

Pois hoje, passados mais de 3 meses do término FISL, conversei novamente com ele e ele me informou que a situação é a mesma, e que novos mirrors estão sendo necessários, o que me fez pensar que talvez seja a hora de alguém com estrutura suficiente disponibilizar tal recurso para o projeto no país.

Por isso, se alguém tiver disponibilidade para tal, ou souber de algum provedor/universidade/empresa que disponha de recursos, peço que me contate para que possamos encaminhar e criar o primeiro mirror brasileiro do ClamAV.

Conto com todos.

Requisitos mínimos necessários
  • 100 Mb de espaço para armazenamento dos dados
  • aproximadamente 1 TB de transferência mensal de dados
Leia o howto completo aqui (de 2006, mas ainda válido). Versão pdf aqui.



Leia também:

terça-feira, 6 de outubro de 2009

Mudança no sistema de assinaturas do ClamAV e desativação das versões < 0.95

Recebi um comunicado hoje na lista de announces do ClamAV com um aviso importante e vou tentar reproduzí-lo de forma reduzida e objetiva:

Sabe-se que todas as versões do ClamAV anteriores a 0.95 são afetadas por um bug que não permite que os updates incrementais funcionem de forma eficiente (essas versões não aceitam assinaturas que tenham mais do que 980 bytes). Esse bug impossibilita a distribuição de assinaturas mais complexas (assinaturas lógicas) na forma de updates incrementais, o que acaba obrigando aos usuários a baixarem o CVD (ClamAV Virus Database) completo em muitas ocasiões.

Até esse momento a equipe do ClamAV não lançou nenhuma assinatura que excedesse esse limite, pois aguardava que os usuários atualizassem o software para as versões mais atuais, mas pelo que foi constatado, muitos ainda estão usando versões antigas do mesmo.

Então como forma de forçar os usuários a atualizarem o ClamAV, a partir do dia 15 de abril de 2010 o CVD passará a contar com uma assinatura especial que irá desabilitar todas as instalações do clamd mais antigas que a versão 0.95.

Apesar de radical, essa atitude será extremamente necessária, pois os mirrors do ClamAV estão chegando ao seu limite e não podem mais suportar todo o tráfego gerado pelo download completo do CVD, o que não ocorre com os updates incrementais, que obviamente são muito menores.

O anúncio também informa que os updates incrementais com mais 980 bytes começarão a serem lançados em maio de 2010.

Por isso se você é sysadmin e tem alguma instalação do ClamAV desatualizada em produção não perca tempo e atualize o mesmo logo.

Bom trabalho !

UPDATE 31/03/2010: não perca tempo e instale a nova versão do ClamAV. Saiba mais sobre a versão 0.96 aqui.

KDE 4.3.2 lançado

Mais uma atualização do KDE, a versão 4.3.2 acaba de ser lançada e como de costume já existem pacotes para o (K)Ubuntu 9.04, que foram disponibilizados pelo projeto Kubuntu.org.

Para instalar a nova versão basta adicionar o seguinte repositório a sua lista (/etc/apt/sources.list):
  • deb http://ppa.launchpad.net/kubuntu-ppa/backports/ubuntu jaunty main

Depois de adicionar o novo repositório rode um apt-get update && apt-get dist-upgrade. Se preferir, utilize as ferramentas gráficas (adept updater ou equivalente) para realizar a operação.

OBS: Usuários do Kubuntu 9.10 Karmic Koala Beta já podem também usar a nova versão, bastando para isso somente atualizar o seu sistema (apt-get update && apt-get dist-upgrade).

Leia o changelog completo aqui.

quinta-feira, 1 de outubro de 2009

Distro Linux que vem com Asus EeePC 701 não criptografa senhas das redes


Lendo esse post sobre a falta de criptografia no armazenamento das senhas das contas do Pidgin, me lembrei de algo crítico sobre o qual ainda não postei.

Estive esses tempos de posse de alguns netbooks Asus modelo EeePC 701, e descobri algo no mínimo lamentável. Em sua distribuição Linux original (que vem instalada), todas as senhas das redes usadas ficam armazenadas abertas (sem criptografia) no arquivo /etc/network/interfaces.

Confesso que realmente não pude acreditar, mas em um dos netbooks que usei haviam mais de 5 redes wifi configuradas e todas as senhas WPA e WPA2 estavam ali abertas no arquivo.

Por isso, se você for proprietário de um EeePC, não deixe de remover o SO original e instalar um Debian EeePC ou Ubuntu Netbook Remix. Vai dar um pouco de trabalho, mas vai garantir a segurança das suas senhas.

Já diz o logo: Fácil de Estudar, Trabalhar e Brincar.

Pena que é pouco seguro :-)

Ubuntu 9.10 (Karmic Koala) Beta disponível


A versão beta do próximo Ubuntu, 9.10 Karmic Koala, foi disponibilizada.

Saiba mais detalhes sobre as novidades da mesma e também como instalá-la em seu computador aqui. Ou, se você prefere usar KDE (assim como eu), saiba mais sobre a nova versão do Kubuntu aqui.

Ainda não é possível solicitar os CDs dessa versão, mas fiquem de olho em https://shipit.kubuntu.org/ e https://shipit.ubuntu.com/ pois a pré-ordem deve estar disponível em breve.

28 dias e contando...

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 ;-)

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. ;-)