claudineimatos.com

Vi na TV que o horário de verão esse ano começa em data diferente só pra variar um pouquinho e portanto precisei atualizar meu arquivo de timezone.

Pesquisando na internet vi que existie um pacote para debian chamado tzdata e resolvi procurar algo parecido para Gentoo, mas infelizmente não tem.

Comecei então a procurar como alterar manualmente e cheguei até esse link onde peguei um arquivo de exemplo.

Com a ajuda da pagina de manual do comando zic criei o seguinte arquivo:

# vim /tmp/updatezone.zic

Rule    America 2007    only    -       Oct     14      00:00   1       D
Rule    America 2008    only    -       Feb     16      24:00   0       S
zone    America/Sao_Paulo       -3:00   America BRT

# zic /tmp/updatezone.zic

Pronto, é possivel confirmar as alterações com o comando zdump

# zdump -v America/Sao_Paulo
America/Sao_Paulo  Sun Oct 14 02:59:59 2007 UTC = Sat Oct 13 23:59:59 2007 BRT isdst=0
America/Sao_Paulo  Sun Oct 14 03:00:00 2007 UTC = Sun Oct 14 01:00:00 2007 BRT isdst=1
America/Sao_Paulo  Sun Feb 17 01:59:59 2008 UTC = Sat Feb 16 23:59:59 2008 BRT isdst=1
America/Sao_Paulo  Sun Feb 17 02:00:00 2008 UTC = Sat Feb 16 23:00:00 2008 BRT isdst=0

Simples e rápido, o relógio vai ser automaticamente alterado na madrugada do dia 14.

Na empresa em que trabalho todos os usuários utilizam o Mozilla Thunderbird como cliente de e-mail. Temos listas de entrega definidas de acordo com setores e funções exercidas pelos usuários e cada usuário tem suas próprias regras configuradas no seu Thunderbird.
Com o diretório Home exportado via NFS fica fácil utilizar a mesma configuração do Thunderbird em qualquer máquina desde que o sistema operacional tenha suporte a NFS. Usuários de estações Windows podem também se beneficiar do Profile remoto do Samba no entanto o problema começa quando o usuário alterna entre estações Windows/Linux ou pior, quando o usuário utiliza outro cliente de e-mail, como por exemplo o webmail.

Para solucionar o problema decidi deixar a responsabilidade das regras direto no servidor, pesquisei no Google e rapidamente re-descobri o Procmail, no entanto seu uso se limita a caixas postais locais do Postfix, e em nosso caso, utilizamos caixas virtuais do postfix, sendo assim a melhor opção foi implantar o Maildrop.

Maildrop

O Maildrop é tão poderoso quanto o Procmail e pode ajudar bastante na filtragem dos e-mails, caso necessário é possível passar o processamento do e-mail para o Procmail sem perder o suporte a domínios virtuais por exemplo. Seus métodos de autenticação podem utilizar base dados LDAP, Mysql, PostgreSQL ou configuração existente da AuthLib.
Cada usuário pode ter seu próprio arquivo de regras em HOME/.mailfilter e sua sintaxe é simples e baseia-se em poucos comandos quando comparada as regras do Procmail.

Instalação

Usuários do gentoo podem instalar o Maildrop direto da árvore do portage. Se necessário especifique o esquema de autenticação a ser utilizado com a useflag correta.

echo "mail-filter/maildrop authlib" >> /etc/portage/package.use
# emerge maildrop

Configuração

A configuração do maildrop é bem simples. Caso seja utiliza a autenticação via AuthLib (recomendado) basta alterar os arquivos master.cf e main.cf do Postfix para habilitá-lo.

Edite o arquivo master.cf e acerte o caminho do binário do maildrop:

# vim /etc/postfix/master.cf
maildrop  unix  -       n       n       -       -       pipe
flags=DRhu user=vmail argv=/usr/bin/maildrop -d ${recipient}

Em seguida edite o arquivo maincf e insira a linha abaixo no final do arquivo.

# vim /etc/postfix/master.cf
maildrop_destination_recipient_limit = 1

Reinicie o postfix e está pronta a configuração.

# /etc/init.d/postfix restart

Regras

O arquivo de regras do Maildrop é bem fácil de configurar e dispõe de poucos comandos que resolvem a grande maioria dos casos. As páginas de manual do maildrop (man maildropfilter) lista os comandos disponíveis e alguns exemplos de uso.
Um arquivo simples armazena os e-mails oriundos de uma lista de discussão na pasta Lista e os demails e-mails na Caixa de Entrada (Inbox) do usuário. Caso a pasta não exista o comando maildirmake se encarrega de criá-la.

$ vim ~/.mailfilter

FOLDER="${DEFAULT}"

if(/^(To|Cc): .*lista_de_discussao@dominio.com.br*/)
{
	FOLDER="${DEFAULT}/.lista_de_discussao"
	SUBSCRIPTION="INBOX.lista_de_discussao"
}

to `teste -d ${FOLDER} || maildirmake ${FOLDER} && echo ${SUBSCRIPTION} >> ${DEFAULT}/courierimapsubscribed` ${FOLDER} 

Vale lembrar que o arquivo .mailfilter deve ter permissão 600 ou o maildrop não fará a entrega da mensagem retornando-a para a fila.
$ chmod 600 ~/.mailfilter

Referências

• HOWTO Email Virtual Server Maildrop and Spam Assasin – Gentoo Linux Wiki
• Maildrop configuration – Gentoo Linux Wiki

Se sua rede tem 1 ou mais estação(ões)/servidore(s) Gentoo, está mais do que na hora de acelerar a compilação dos softwares. Duas opções estão disponíveis para rapida instalação, são elas: distcc e ccache.

ccache

O ccache, como o próprio nome já diz, tem por objetivo fazer cache de código C compilado durante uma instalação de software, para que numa próxima compilação ele possa ser reutilizado, economizando assim tempo e processamento. Seu funcionamento é análogo aos servidores proxys mais fomosos como o squid por exemplo.

Instalação

A instalação do ccache é bem simples e exige apenas 3 passos que são respectivamente, instalar o ccache, definir o tamanho máximo do diretório de cache e editar o arquivo make.conf adicionando a palavra ccache no parâmetro FEATURES.

# emerge ccache
# ccache -m 2G (define o tamanho máximo de 2 Gigabytes para o diretório do ccache)
# vim /etc/make.conf

FEATURES="ccache"

Uso

Uma vez instalado, basta começar a instalar novos programas para se beneficiar do uso do ccache. Vale observar que a primeira compilação após instalação do ccache pode demorar um pouco mais do que o normal já que o cache está sendo iniciado, no entanto as compilações seguintes deverão ser graduativamente aceleradas conforme o conteúdo do cache for sendo gerado.
Para certificar-se de que o ccache está sendo utilizado, basta executar o comando ccache -s e verificar se o mesmo está sendo utilizado.

# CCACHE_DIR=/var/tmp/ccache ccache -s (o diretório do cache do portage deve ser especificado)

distcc

A distcc distribui a compilação do código C entre hosts participantes da rede, acelerando assim o processo de compilação. A distcc faz uso do recurso de compilação pararela distribuindo cada “trabalho” entre os diversos hosts de compilação disponíveis. Sendo assim, programas que não podem ser compilados pararelamente não podem fazer uso da distcc, ao menos não sem nenhum trabalho adicional.

Instalação

A instalação da distcc é simples e exige basicamente a instalação do pacote distcc. Esse pacote deve ser instalado em todas as máquinas, sejam elas clientes ou servidores do serviço.
As maquinas que forem atuar como compiladores da rede devem ter o daemon da distcc rodando em background.

# emerge distcc
# rc-update add distccd default

As maquinas clientes precisam de um pacote a mais para gerenciar o uso da distcc, além de configuração adicional no arquivo make.conf

# emerge distcc
# emerge distcc-config
# vim /etc/make.conf

MAKEOPTS="-jN"  (onde N é o número de CPUs compiladoras + 1, é comum usar esse número X 2)
FEATURES="distcc"

# distcc-config --set-hosts "localhost maquina1 maquina2" (define as maquinas participantes da compilação, inclusive a maquina local se desejado)

É altamente recomendado que as maquinas participantes utilizem a mesma versão da GCC. Não há problemas em misturar versões como 4.1.x e 4.1.y, no entanto misturar versões como 4.x.y e 4.z.w, 3.x.y e 4.z.w ou outras combinações pode gerar diversos problemas ou até mesmo impossibilitar a compilação do software.

Uso

Assim como o ccache, a distcc é usada transparemente pelo portage e uma vez que estiver instalada basta começar a compilar software para se beneficiar de seu uso. O status atual da distribuição da compilação pode ser verificado com o comando distccmon-text na maquina cliente.

# DISTCC_DIR="/var/tmp/portage/.distcc/" distccmon-text N (onde N é o número de segundos de atualização da tela)

Se a distcc for usada junto com o ccache é necessário especificar o ccache antes da distcc no parâmetro FEATURES

Compilação cruzada

Na configuração padrão da distcc não é possível compilar para arquiteturas diferentes da utilizada pela máquina onde está instalada distcc, se você quiser compilar código para amd64 é necessário que todas as máquinas participantes da compilação utilizem arquitetura amd64 por exemplo. Uma forma de contornar essa limitação é a compilação cruzada, ou seja, compilar para uma arquitetura diferente da arquitetura do compilador utilizado. Dessa forma é possível utilizar uma estação x86 para compilar programas para uma estação ppc ou sparc.

Instalação

Instalar um ambiente de compilação cruzada é fácil no entanto um pouco demorado. O pacote crossdev cuida do recado e basta indicar a arquitetura desejada para que ele gere todos os programas necessários para a compilação (binutils, gcc, glibc, etc).
No caso abaixo, uma estação i686 é configurada para compilar software para arquitetura amd64.

# emerge crossdev
# crossdev -t x86_64 (onde x86_64 é a arquitetura em que os programas devem ser gerados)

Desative o ccache e a distcc para compilar os compiladores

A instalação da distcc cria um diretório com links dos compiladores para o binário da distcc que cuida de distribuir os processos, no entanto como muitos programas chamam os compiladores diretamente por c++, gcc, etc ao invés de x86_64-pc-linux-gnu-gcc é necessário acertar os links de modo a apontar para o compilador da arquitetura correta. Um simples script e alguns links resolvem o problema.
Crie um novo script com o nome equivalente a variavel CHOST da arquitetura desejada, por exemplo x86_64-pc-linux-gnu-wrapper pra amd64 ou sparc-unknown-linux-gnu-wrapper para arquitetura sparc, e insira as linhas abaixo lembrando-se de alterar os valores para a arquitetura correta:

# cd /usr/lib/distcc/bin
# rm c++ g++ gcc cc
# vim x86_64-pc-linux-gnu-wrapper

#!/bin/bash
exec /usr/lib/distcc/bin/x86_64-pc-linux-gnu-g${0:$[-2]} "$@"

Em seguida, dê permissão de execução no script e refaça os links.

# chmod a+x x86_64-pc-linux-gnu-wrapper

# ln -s x86_64-pc-linux-gnu-wrapper c++
# ln -s x86_64-pc-linux-gnu-wrapper cc
# ln -s x86_64-pc-linux-gnu-wrapper g++
# ln -s x86_64-pc-linux-gnu-wrapper gcc

Pronto, agora é só adicionar o host na lista de hosts da distcc das demais máquinas e começar a compilação.
Caso necessário compilar para outra arquitetura basta instalar os novos compiladores e refazer os links para a nova arquitetura.

Referências

• Ccache – Gentoo Linux Wiki
• Gentoo Distcc Documentation
• distcc
• Gentoo DistCC Cross-compiling Guide

A rede da empresa em que trabalho já há muito tempo autentica os usuários em um banco de dados Mysql, no entanto devido ao processo de migração de nosso sistema interno, decidimos que o PostgreSQL será o banco oficial com que iremos trabalhar e portanto nosso banco de usuários deveria ser migrado para o mesmo.
Como eu já havia visto algumas poucas coisas a respeito de autenticação de usuários com Postgres na época em que configurei a autenticação com Mysql, imaginei que hoje em dia o suporte ao PostgreSQL estaria melhor e disponível em uma variedade maior de softwares, o que pra minha alegria é uma verdade.
Com o objetivo de centralizar a maior quantidade de sistemas de autenticação disponíveis na rede, comecei a pesquisar a respeito do assunto.
Nesse primeiro artigo exemplifico a configuração da libnss e do pam em conjunto com o PostgreSQL.
Futuramente publicarei também a minha experiência com o Samba, Postfix e outros serviços disponíveis na rede que administro.

Continue Reading »

Já há algum tempo sou proprietário de um Palm LifeDrive. Apesar de satisfeito não sou totalmente feliz com o aparelho devido as limitações e problemas que só o Palm OS pode proporcionar (acreditem em certas situações ele é mais problemático que o Windows). É claro que seguindo as recomendações da Palm de só utilizar os softwares originais e/ou recomendados por eles o nível de problemas cai para quase 0 (zero) mas quem consegue viver assim?

Apesar de tudo, o Palm OS é bem suportado pelo Software Livre e inclusive existem muitos aplicativos Livres para o sistema operacional da Palm.
No linux contamos com boas opções para manter o Palm sincronizado e também para integrar a transferência de dados entre aplicativos.

Continue Reading »

Recentemente um cliente precisou realizar uma atualização no seu servidor para atender as exigências de um sistema novo. A princípio a tarefa parecia ser simples, atualizar o Mysql e PHP para a versão 5 de ambos no Fedora Core 4.
Depois de pesquisar no google percebi que eu precisaria de um pouco mais do que “yum update && yum install mysql” para fazer as coisas funcionarem.

Continue Reading »

Postfix + pop-before-smtp

Recentemente tive que implementar alguma forma de autenticação no servidor de um cliente para envio de e-mail uma vez que ele decidiu utilizar um cliente de e-mail ao invés de webmail.
De cara pensei em SASL pois a configuração com Postfix não custuma ser muito trabalhosa, ao menos não no Gentoo. Infelizmente a distribuição do servidor de meu client é Fedora Core, uma distribuição com a qual não tenho nenhuma intimidade.
Procurei na internet alguma forma de fazer isso mas não fui muito feliz em minhas buscas. Como eu já tinha compilado o postfix com suporte ao mysql pois nãoa havia achado uma solução “pronta” na época da configuração do servidor, resolvi fazer o mesmo recompilando o postfix com suporte ao Mysql e SASL. Infelizmente a tentativa não deu certo e o postfix sempre morria após a primeira conexão na porta 25.
Cansado e sem paciência de tentar resolver esse problema achei melhor tentar algo mais prático, pensei então no pop-before-smtp (pop antes do smtp).

Continue Reading »

Então Ano Novo, vida nova e mil e um trabalhos atrasados pra terminar.

Estou em falta com o site, no último mês tenho trabalhado em dobro pra juntar dinheiro pra viagem que vou fazer esse ano pra Europa.
Tenho feito alguns sisteminhas em PHP que têm consumido meu tempo que deveria ser de lazer (e de escrever artigos) mas vai valer a pena.

Espero em breve postar mais artigos interessantes sobre os recuros e tecnologias com que tenho trabalhado.

Abraços a todos e feliz ano novo

Claudinei Matos

Começou hoje o PHP Conference 2006 em São Paulo na Universidade São Marcos. O evento que já conta com mais de 500 cadastrados é inédito no Brasil e o conteúdo das palestras promete ser excelente.

A primeira palestra que assisti foi sobre PhpGtk2 e diga-se de passagem foi muito boa pois não tinha idéia de que o GTK tinha amadurecido tanto.

O PhpGtk é uma biblioteca para integrar o GTK ao PHP de modo a criar aplicativos reais (não WEB).

A criação de formulários (telas) é bem simples, embora um pouquinho trabalhosa se for feita diretamente “na mão”, no entanto é possivel usar o Glade, que por sinal também melhorou e muito.

Com o PhpGtk é possível por exemplo abstrair toda a interface gráfica gerando através do glade (ou “na mão” se preferir) um arquivo xml que posteriormente será carregado pela classe GtkGlade durante a sua inicialização, possibilitando inclusive uma fácil modificação posterior.

Particularmente, já experimentei usar a biblioteca Gtk alguns anos atŕas em conjunto com a linguagem python (pygtk), no entanto naquela época era bem chatinho criar as telas, posicionar os objetos, etc,…, mas é claro, nada que atrapalhasse/dificultasse o desenvolvimento.

Hoje, com o excelente suporte a OO (Orientação a Objetos) do PHP5 e a facilidade de criação de “telas” com o Glade/Gtk é possível criar aplicativos atraentes e funcionais de maneira fácil e rápida como era (e ainda é para alguns) feito em IDEs de desenvolvimento como Delphi e Visual Basic (argh!), sem contar na vantagem da portabilidade uma vez que o PhpGtk está disponível para os mais importantes SO’s como Linux, MacOS, BeOs e claro, o ainda usado Windows (argh outra vez).

Vida longa para o PhpGtk!

Recentemente instalei o Zabbix no servidor da minha rede para monitorar algumas máquinas, inclusive ele próprio. Ontem passei o dia configurando os itens a serem monitorados das minhas máquinas e tudo estava funcionando perfeitamente bem, com todos os gráficos sendo gerados e todas as estatísticas computadas.

Hoje ao chegar na empresa, fui direto ver a tela de gráficos que configurei e qual não foi minha surpresa ao verificar que os gráficos estavam todos em branco. Como por padrão o zabbix exibe o gráfico com período de 1 hora, alterei para 24 horas e pude notar que a última atualização no gráfico ocorreu ontem por volta das 23hrs, no entanto as estatísticas continuavam sendo coletadas. Seria esse um erro no serviço zabbix? Felizmente não existe nenhum problema com o Zabbix pelo que pude verificar ao reinicia-lo, no entanto continuo sem geração dos gráficos.

Alterei o nível de debug no arquivo zabbix-server.conf para 4 na linha com o parâmetro DebugLevel e reiniciei novamente o serviço. Dessa forma consegui verificar no log do servidor o problema que estava acontecendo:

# tail -f /var/log/zabbix/zabbix_server.log
013359:20061124:105552 Query::insert into trends \\
(clock,itemid,num,value_min,value_avg,value_max) values \\
(1164369600,17543,1,1041.594705,1041.594705,1041.594705)
013359:20061124:105552 Query failed:The table 'trends' is full [1114]

Table is full? Como isso pode acontecer? Como utilizo o Mysql para o Zabbix imaginei logo que o banco devia ter crescido demasiadamente e dessa forma teria enchido a partição /var. Uma rápida consulta ao espaço livre em disco (df) me mostrou que ainda existe muito espaço livre na partição /var então isso não pode ser um problema de espaço em disco para o Mysql.

Verifiquei que a tabela trends só tem cerca de 1 milhão de registros, o que não é muito pois já tive tabelas em algumas base de dados com muito mais do que essa quantidade de registros.
Resolvi tentar executar a query direto no mysql para ver o que acontecia

# mysql -p
Enter password:
Database changed

mysql> use zabbix
mysql> insert into trends (clock,itemid,num,value_min,value_avg,value_max) \\
values (1164369600,17539,1,112.790411,112.790411,112.790411);
ERROR 1114: The table 'trends' is full

Procurar no google por “mysql error 1114 table is full” não me retornou resultados satisfatórios então resolvi pesquisar no mysql mesmo a raiz do problema.
Imaginei que deveria existir alguma variável limitando o tamanho da tabela ou algo parecido. Com o comando show variables é possível verificar as variáveis atuais do mysql.
Como não existia nenhuma variável que aparentemente estivesse limitando o tamanho das tabelas, resolvi verificar as variáveis pertinentes ao tipo de tabela innodb uma vez que esse é o tipo das tabelas usadas pelo zabbix.

A variável que me pareceu mais passível de estar limitando o tamanho das tabelas foi a “innodb_data_file_path” cujo valor estava definido como ibdata1:10M:autoextend:max:128M (provavelmente o padrão do mysql), no entanto o nome da variável não indicava exatamente limitação de tamanho da tabela, mas de qualquer forma era bom verificar.

Procurando no google por esse valor achei um blog onde o autor do post relatava o mesmo problema que o meu com o zabbix e tableas do tipo innodb e coincidentemente a mesma distribuição Linux estava sendo usada: Gentoo.
Pelo que entendi o problema realmente estava na definição do tamanho máximo definido pro arquivo InnoDB (ibdata1). O autor do post indica o endereço http://www.browardphp.com/mysql_manual_en/manual_InnoDB.html onde a configuração do InnoDB é explicada.

De acordo com as especificações do site, alterei o parâmetro innodb_data_file_path para ibdata1:10M:autoextend, reiniciei o mysql e o zabbix, e pronto, o zabbix voltou a gerar os gráficos novamente.

# vi /etc/my/mysql.cnf

innodb_data_file_path = ibdata1:10M:autoextend

# /etc/init.d/mysql restart
# /etc/init.d/zabbix-server restart

Não esqueça de alterar novamente o nível de debug no arquivo zabbix-server.conf

Referências

• The Geekery » Open Source
• MySQL Reference Manual for version 5.0.3-alpha – 15 The InnoDB Storage Engine