Archive for the 'Artigos' category

Controle de acessos no Git simples e seguro com Gitosis

14 de fevereiro de 2010 6:13 pm · Tags: ,,,,,,

Existem algumas formas de se fazer controle de acesso no GitW, a forma mais simples é criar o repositório com acesso a um grupo e adicionar os usuários com acesso a esse grupo. Se um grupo apenas não for suficiente para gerenciar os acessos ao repositório pode ser possível utilizar ACL’s.
O único problema desse esquema é que exige que cada usuário tenha acesso SSHW ao servidor e isso muita das vezes não é interessante para o administrador do servidor.

Outra forma de se fazer o controle de acesso é através de WebDAVW. A vantagem é que nesse caso o gerenciamento dos usuários é feito através de um arquigo que deve ser gerado e atualizado com o utilitário htpasswd (htpasswd2 em algumas distribuições como o Gentoo), porém para executar o WebDAV é preciso um servidor web como o Apache ServerW ou LighttpdW.
Se sua escolha for pelo WebDAV, o HowToW disponível na própria documentação do Git ou em http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt explica como fazer.

Uma forma mais simples e segura é utilizar o Gitosis. Sua principal vantagem é ser executado via ssh através de autenticação via chave pública, porém utilizando uma única conta compartilhada cujos comandos disponíveis são limitados.

Show me more… »

Monitoramento com Zabbix – Parte 2 – Monitorando Hosts e dispositivos

10 de fevereiro de 2010 12:43 am · Tags: ,,,,,,,,,,

Continuando o tutorial de configuração do ZabbixW, o próximo passo é configurar o primeiro host à ser monitorado na rede, o que na maioria dos casos é o próprio servidor do Zabbix.

Agente de Monitoramento

A instalação do agente do Zabbix na maioria das distribuições é bem fácil e envolve poucos passos:

Show me more… »

Monitoramento com Zabbix – Instalação e Configuração

4 de janeiro de 2010 10:39 pm · Tags: ,,,,,,

O ZabbixW é um poderoso sistema de monitoramento de hosts e dispositivos, que pode monitorar desde a própria máquina onde está instalado, a milhares de hosts e dispostivos localizados na rede local ou na mais remota localização geográfica.

Sua estrutura é simples e descentralizada e consiste de um aplicativo denominado servidor que coleta e armazena as informações dos hosts em um banco de dados que pode ser SQLiteW, MySQLW, PostgreSQLW ou OracleW; uma interface web para administração / monitoramento feita em PHP, e os agentes que podem ser desde hosts monitorados pelo aplicativo agente do Zabbix quanto os mais variados serviços e dispositivos, acessíveis das mais diversas formas como SNMPW, TCPW, ICMPW E IPMIW.

Nessa série de artigos comentarei a instalação, configuração e utilização do Zabbix nas distribuições GentooW e UbuntuW.

Show me more… »

Memcached, optimizando aplicações PHP com cache em memória

13 de janeiro de 2008 11:42 am · Tags: ,,,

Aplicações de grande porte tendem a passar por problemas de performance, por N motivos como o crescimento do número de usuários simultâneos, complexidade da lógica, cresicmento da base de dados, dentre outros.

Geralmente o primeiro passo a seguir quando uma aplicação está com a performance degradada é tentar detectar no código os problemas de performance e corrigi-los. Em caso de aplicações WEB um sistema de cache como o do PHP Smarty pode ajudar e quando isso não for o bastante pode ser possível partir para a clusterização dos servidores.

Quando o problema está na base dados, a solução comumente utilizada é clusterizar a base, geralmente adicionando servidores slave que se por um lado melhoram o tempo de resposta de consultas a base, por outro lado perdem no momento da escrita, pois cada nó do cluster deve ser atualizado.

Pensando nesses problemas, Brad Fitzpatrick desenvolveu um sistema de cache em memória distribuido. Fitzpatrick se deparou com o problema de rápido cresicmento da audiência do site LiveJournal.com. Ao chegar a casa dos 20 milhões de usuários por dia, clusters de servidores web e de banco de dados já não eram mais suficientes, e então o Memcached surgiu garantindo rápido acesso aos dados e melhor utilização de recursos.

Show me more… »

Configurando filtros de e-mail no servidor com Postfix e Maildrop.

14 de setembro de 2007 2:01 pm · Tags: ,,

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

Optimizando a compilação com ccache e distcc

27 de junho de 2007 9:35 pm · Tags: ,,,

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

Autenticação Centralizada com Postgres – NSS e PAM

13 de março de 2007 5:29 pm · Tags: ,,,,

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.

Show me more… »

Autenticação SMTP no Postfix com pop-before-smtp

29 de janeiro de 2007 9:11 pm · Tags: ,,,,

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

Show me more… »

Instalando o AWStats na Dreamhost

18 de novembro de 2006 11:49 am · Tags: ,

O AWStats é um excelente software para análise de logs e geração de estatísticas. Ele trabalha muito bem com os principais web servers (principalmente o Apache) e também pode ser usado para analisar logs de ftp, e deservidores de e-mail segundo informação dos desenvolvedores.

Na empresa onde trabalho, utilizamos o AWStats junto com outras soluções como extreme tracking e google analytics, porém acho o AWStats o mais objetivo de todos no sentido de apresentar as estatísticas coletadas do log.

Essa semana resolvi instalar o AWStats na minha conta da DreamHost, uma vez que eu não gostei muito do Analog que eles disponibilizam e além do mais eu já instalei o AWStats antes, então agora não devo encontrar dificuldades.

Para facillitar o processo, dei uma olhada no Wiki da DreamHost e achei um passo a passo de como instalar o AWStats.
O AWStats pode funcionar de 2 formas: com páginas estaticas ou através do cgi. Particularmente eu prefiro utilizar como CGI pois possibilita a atualização dos dados apartir do browser. No Wiki da DreamHost esse método é chamado de rápido (Quick).

Show me more… »

Roteando múltiplos links de internet

27 de outubro de 2006 2:18 pm · Tags: ,,

A empresa onde trabalho depende 100% da internet para seu funcionamento, devido a isso procurei escolher uma boa opção de link de internet levando em consideração o melhor preço X a melhor qualidade de serviço.
É claro que as melhores opções são sempre os links dedicados, no entanto esses serviços são caros se comparados aos serviços DSL disponíveis.

Depois de um bom tempo usando o Velox da Telemar, fui apresentado a MundiVox que até que tem um serviço de boa qualidade, só deixando a desejar no primeiro mês de uso.

Apesar da boa qualidade do serviço, inevitavelmente acontecem algumas pequenas interrupções que as vezes não passam de 1 minuto, mas as vezes pode passar dos 10. Sendo assim decidi contratar mais um link de internet de outro fornecedor para efeitos de backup.

Uma vez que o outro link já estava instalado e funcionando surgiu o desafio: Como inserir o novo link na rede de modo a garantir que a internet não pare nunca (failover), e como combinar os 2 links para aumentar a velocidade de acesso a internet (load balancing)?

Inicialmente pensei que a solução fosse utilizar o recurso de “bonding” do kernel, no entanto após ler bem a pouca documentação disponível descobri que o bonding só funciona com links que façam parte de uma mesma rede (lógica).

Pesquisando mais a fundo descobri que a solução está nas tabelas de roteamento do sistema, na verdade na parte Avançada de Roteamento do sistema (o conhecido Linux Advanced Routing and Traffic Control)

A idéia básica do sistema é de criar tabelas de roteamento separadas para cada link e utilizar um gateway multipath ( com rotas alternativas ) como rota padrão. Para isso é necessário utilizar o pacote iproute2, disponível em http://linux-net.osdl.org/index.php/Iproute2

O pacote iproute2 fornece ferramentas avançadas para a configuração de interfaces, endereços, rotas e filtros e pode substituir as ferramentas padrões já conhecidas: ifconfig, route, arp.
No kernel, a opção IP: advanced router provê o suporte necessário para o recurso.

A configuração é simples e basicamente se dá em configurar o kernel e adicionar algumas tabelas de roteamento.

Show me more… »