Other posts related to gentoo

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… »

Erro ao compilar o kernel 2.6.31: implicit declaration of function ‘_cpu_down’

16 de janeiro de 2010 12:58 pm · Tags: ,,,

Ao tentar compilar a versão 2.6.31 do kernel linux (com suporte ao Xen) obtive a seguinte mensagem de erro:

kernel/cpu.c: In function 'disable_nonboot_cpus':
kernel/cpu.c:394: error: implicit declaration of function '_cpu_down'
make[1]: *** [kernel/cpu.o] Error 1
make: *** [kernel] Error 2

Uma rápida pesquisa no google me revelou que o problema se encontrava na falta do suporte a hot-pluggable cpu’s. Este recurso permite que CPU’s possam ser ligadas/desligadas durante a execução da máquina, possibilitando a economia de energia e a própria inclusão de novas CPU’s em sistemas multi-processados.
Esse recurso já vem habilitado por padrão caso você esteja configurando o kernel pela primeira vez, mas no meu caso, copiei o arquivo .config de outro kernel que não tinha esse suporte habilitado.

A solução é simples e envolve executar novamente o configurador do kernel para habilitar a opção pertinente ou editar diretamente o arquivo .config, sendo mais aconselhável executar o o configurador (make menuconfig).

A opção que precisa ser habilitada é CONFIG_HOTPLUG_CPU e pode ser encontrada em:

Processor type and features --->
[*] Support for hot-pluggable CPUs

Pronto, agora é só executar o make novamente e aguardar o fim da compilação.

Referências

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… »

Usando kernel vanilla como domU no Xen

16 de dezembro de 2009 8:57 am · Tags: ,,,

O Xen é um dos paravirtualizadores mais famosos do mercado e seu uso está cada vez mais difundido a cada dia que se passa.

Configurar uma instalação básica do Xen nas principais distribuções não é muito difícil e no Gentoo não é diferente. Em geral o processo envolve instalar um kernel customizado no dom0 (a “máquina real”), e instalar os utilitários do Xen também no dom0. Se a CPU em questão tiver suporte a virtualização (flag  svm em arquitetura AMD, ou vmx em arquitetura Intel) é possível utilizar para os domU’s (as “máquinas virtuais”) qualquer versão de Kernel ou de Sistema Operacinal, não necessitando que o mesmo tenha sido previamente preparado (patch) para utilização sob o Xen.

Caso a CPU não tenha suporte a virtualização, é necessário utilizar um Sistema Operacinal ou Kernel devidamente adaptado, o que não costuma ser uma tarefa muito complicada visto que as principais distribuições já orefecem pacotes prontos. No Gentoo apenas é necessário compilar uma versão do mesmo kernel utilizado no dom0 porém com os devidos recursos que dão suporte a inicialização e execução do domU.

Até ai, tudo corre muito bem, sem muitos problemas, no entanto, quando é necessário utilizar uma versão específica de kernel para o domU é que o problema começa, principalmente se for necessário utillizar uma das versões mais recentes do kernel, visto que os patches de suporte ao Xen não costumam ser disponibilizados com a mesma frequência que novas versões do kernel.

Felizmente desde a versão 2.6.23 o kernel vanilla (padrão) do Linux conta com suporte nativo a virtualização, possibilitando que o mesmo seja iniciado como um domU sob o Xen. Para tanto é necessário habilitar no kernel as seguintes opções:

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… »

Acertando o horário de verão no Gentoo

12 de outubro de 2007 6:17 pm · Tags:

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.

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… »