Existem diversos pontos a serem analisados na hora de desenvolver um firewall para seu ambiente de forma que ele obtenha a máxima performance utilizando o hardware da melhor maneira possível, porém existem algumas práticas que são recomendadas para aumentar a performance e otimizar seu proxy durante a configuração do Squid.

Um dos principais fatores a serem considerados é a especificação do hardware utilizado e a preparação do sistema operacional. Ao utilizar RAID no servidor, prefira implementar em RAID0, que apresenta a melhor performance e dê preferência para realizar o armazenamento de cache e dos logs do Squid em um volume (preferencialmente com discos diferentes) separado, como estes dados normalmente são armazenados no /var, crie um ponto de montagem sobre a pasta apontando para seu volume. A escolha do sistema de arquivos também é um fator extremamente importante para otimizar o funcionamento, além do desempenho é necessário ter estabilidade na manipulação dos dados.

Um ponto crítico que pode fazer com que os usuários sintam lentidão ao utilizar a internet através do proxy é a resolução de nomes (DNS), para aumentar o desempenho na resolução de nomes é recomendável configurar um DNS cache na mesma máquina ou em uma máquina conectada diretamente ao proxy.

Existem alguns parâmetros que devem ser corretamente configurados no squid.conf de modo a otimizar o funcionamento. Segue uma breve descrição dos dois principais:

cache_mem

Esta opção informa ao Squid a quantidade de memória dedicada ao processo (podendo aumentar dependendo da demanda), sendo que em máquinas dedicadas à utilização de proxy podemos definir cerca de 80% da memória total da máquina.

maximum_object_size

Com esta diretiva podemos limitar o tamanho máximo dos objetos em cache para que objetos maiores do que o valor máximo aqui informado não sejam enviados para o disco. Um valor alto pode contribuir com uma maior economia de banda, porém pode causar uma utilização maior dos discos podendo aumentar o tempo de resposta em ambientes de alto tráfego. É recomendada a utilização de um valor entre 4 e 16MB (16384 KB).

A utilização de diversos caches separados em volumes diferentes pode contribuir para otimizar o armazenamento de dados e aumentar a performance do acesso a internet porém não interfere diretamente na performance do servidor.

Já a definição do método de acesso ao cache (store type) oferece difereças significativas na forma como o servidor acessa os discos. Os métodos mais utilizados são ufs, aufs, diskd e coss. Sendo que normalmente o sistema aufs apresenta ótima performance e facilidade de implementação (não depende de daemos externos) na maioria dos casos.

Existem ótimas alternativas para configuração de ambientes grandes onde existem milhares de hosts passando pelo proxy ao mesmo tempo para a distribuição de carga (um tipo de clusterização) em diversos servidores interligados entre si através de ICP, mas esse já é um tipo de instalação bem específica onde temos que fazer um levantamento bem detalhado do ambiente na implementação.

Assim como os primeiros filmes da série, Resident Evil Extinction está simplesmente espetácular com um ambiente incrível e cheio de detalhes, história envolvente e como não poderia faltar muitas cenas de ação.

O filme continua a seqüência de liberação do T-vírus, que desta vez aconteceu em escala mundial ao longo do tempo onde apenas poucos sobreviventes ainda não foram infectados e devem permanecer em constante movimentação para não atrair o incrível exercito de mortos-vivos espalhados por todos os lugares.

Com as cidades sem segurança alguma, Carlos Olivera (Oded Fehr) e L.J. (Mike Epps), juntamente com as sobreviventes K-Mart (Spencer Locke) e Betty (Ashanti), reúnem-se em um comboio seguindo pelo deserto de Nevada a procura de sobreviventes, enquanto Alice (Mila Jovovich) continua seguindo seu próprio caminho até que encontra o comboio e decide se juntar a ele com o objetivo de chegar ao Alaska, que de acordo com registros que ela encontrou não possui sinal nenhum de infecção.

Durante esta travessia, além de se preocuparem com os mortos que caminham sobre a terra eles também são seguidos e atacados por uma equipe da Umbrella Corporation a comando do Dr. Isaacs que tem por objetivo analisar o sangue de Alice e aprimorar ainda mais suas pesquisas para dominar os infectados.

A história segue com base neste contexto, porém muitas coisas acontecem durante a travessia, alterando inclusive os objetivos de Alice ao descobrir os principais propósitos da Umbrella e contrinuindo ainda mais para que os sobreviventes cheguem ao seu destino.

Normalmente, ao iniciar um projeto com base em software livre temos dúvida sobre qual gerenciador de banco de dados utilizar, e quais são as reais diferenças e particularidades de cada um deles. Neste artigo vou avaliar os dois principais gerenciadores, porém existem outras alternativas de código aberto que devem ser analisadas, como o Firebird. Apesar de existirem muitas diferenças que devem ser levadas em consideração entre os gerenciadores, farei um levantamento das principais diferenças encontradas e as principais características apresentadas na hora de desenvolver seu sistema, preparar o ambiente e colocá-lo em produção.

De forma geral, o PostgreSQL segue a risca os padrões para banco de dados (assim como o Oracle, por isso existe uma certa familiaridade na utilização entre eles), já o MySQL possui algumas particularidades mistas em seu funcionamento e esse é o principal motivo pelo qual os usuários vindos do MySQL podem achar os comandos e a utilização do PostgreSQL “estranha” a primeira vista.

Existe um certo mito que passa entre os desenvolvedores de que o MySQL é mais rápido, porém menos estável que o PostgreSQL na manipulação de dados, porém isso deixou de ser verdade a partir das últimas versões, que apresentam praticamente a mesma velocidade e apresentam grande estabilidade na manipulação dos dados.

Um ponto muito importante a ser analisado é a performance do servidor responsável pelo banco, de maneira geral o MySQL exige um maior consumo de recursos da máquina em sua utilização padrão para apresentar maior performance enquanto o PostgreSQL é mais escalonável em termos de controle de recursos e pode ser mais bem dimensionado e modelado independente da arquitetura ou servidor utilizado.

Um dos principais diferenciais do PostgreSQL está na manipulação de “transactions” de forma padrão, enquanto para que o MySQL possa realizar este tipo de operação deve ser utilizada a engine InnoDB (enquanto o padrão do banco e a engine que apreseta maior performance é MyISAM), sendo que outra particularidade da engine InnoDB é o suporte a “foreign keys”que também é padrão no PostgreSQL.

Em termos de clusterização, ambos os gerenciadores apresentam recursos muito interessantes para ambientes grandes e de alta disponibilidade, porém em ambientes onde existe um alto volume de transações por segundo o PostgreSQL apresenta uma escalabilidade maior amenizando assim o impacto na performance do sistema, já o MySQL trata todas as requisições de forma bastante robusta porém apresentando uma carga um pouco maior no servidor utilizando InnoDB como engine, já com MyISAM a performance aumenta considerávelmente consumindo os mesmos recursos da máquina.

De modo geral, em sistemas transacionais com consultas complexas e alto nível de processamento o PostgreSQL é uma solução mais robusta que apresenta alta performance e escalabilidade. Já o MySQL é recomendável para sistemas com consultas mais simples e com alto número de consultas, apresentando alta performance e com administração mais simplificada.

Não se esqueça que este é o meu ponto de vista feito com base nos ambientes que minha equipe administra e podem existir ambientes ou configurações que apresentem resultados diferentes dos apresentados. Existem diversas fontes de informações técnicas disponíveis para os gerenciadores de banco de dados sendo que a maior parte está disponível nos próprios sites oficiais, e estão disponíveis também diversos benchmarks que podem ser úteis para ter uma base de seu funcionamento em ambiente crítico.

Hoje a tarde tomei conhecimento através do BR-Linux a notícia do falecimento de um dos principais tradutores do Gnome e desenvolvedor, Raphael Higino.

Tenho muito respeito pelo seu trabalho com as traduções e em sua forma de contribuir com todos. Grande parte das traduções do Gnome se devem a ele, e mesmo com sua partida com certeza as contribuições dele continuarão sendo de extrema importância para todos nós.

Dedico este post a família do Raphael, deixando meu abraço a eles e desejando que Deus esteja com todos eles abençoando e confortando toda a família.

Em nome do time dos usuários do Gnome, muito obrigado Raphael Higino pelo seu trabalho, dedicação e atenção. A comunidade de software livre tem muito a agradecer!

Suhosin é um avançado sistema de proteção que foi desenvolvido com o objetivo de proteger servidores e usuários de falhas nas aplicações escritas em PHP e implementar correções à própria base da linguagem. É separado em duas partes independentes que podem ser utilizadas em conjunto ou individualmente, sendo que uma delas é um patch a ser aplicado no core do PHP que implementa proteção contra vulnerabilidades do sistema (Engine Protection) e a outra parte é uma extensão que coloca em funcionamento todas as outras proteções e implementações de segurança.

Para aplicar o patch Suhosin será necessário recompilar o PHP do servidor!

Para descrever os processos de instalação estarei me baseando em sistemas RedHat (RPM), porém os procedimentos principais são os mesmos em qualquer distribuição…

Aplicando Suhosin Patch

Primeiramente faça o download do pacote Suhosin, da signature key da release a partir do site oficial e os fontes do PHP que utilizaremos para embutir o patch, e não se esqueça de verificar o md5 em todos os arquivos após o download para garantir que os fontes estão intactos.

Baixando a signature key e importando para nosso GNU Privacy Guard keychain:

wget http://www.hardened-php.net/hardened-php-signature-key.asc
gpg –import < hardened-php-signature-key.asc

Como este tutorial está baseado em RedHat, baixe e instale o pacote source da sua versão do php (ie. rpm -ivh php-5.1.6-12.el5.src.rpm) e entre em seu diretório source do rpmbuild (ie. /usr/src/redhat/SOURCES), lembrando que em outras distribuições é necessário entrar no diretório onde o fonte do PHP se encontra.

Agora, faça a checagem da gpg no arquivo .sig baixado:

gpg suhosin-patch-5.1.6-0.9.6.patch.gz.sig

Descompacte o patch do Suhosin na pasta dos sources e renomeie o patch nos padrões RedHat (é mais frescura mesmo, somente para quem usa distro RPM based) , e então entre na pasta dos SPECs e edite o arquivo referente ao PHP:

mv suhosin-patch-5.1.6-0.9.6.patch
php-5.1.6-suhosin.patchcd /usr/src/redhat/SPECS/
vi php.spec

Adicione “Patch0: php-5.1.6-suhosin.patch” no bloco onde são definidos os patches a serem aplicados, mas lembre-se que caso o patch “ecalloc” estiver presente no spec ele deve ser desativado por apresentar conflitos com suhosin.

Adicione também a linha “%patch0 -p1 -b .suhosin” ao bloco %setup -q para entrar na compilação, segue exemplo:

[...]
Source51: php.ini

Patch0: php-5.1.6-suhosin.patch
Patch1: php-5.1.4-gnusrc.patch
Patch2: php-5.1.4-warnings.patch
Patch5: php-4.3.3-install.patch
Patch6: php-5.0.4-norpath.patch
Patch7: php-4.3.2-libtool15.patch
Patch13: php-5.0.2-phpize64.patch
# Patch14: php-5.1.6-ecalloc.patch
[...]
%setup -q
%patch0 -p1 -b .suhosin
%patch1 -p1 -b .gnusrc
%patch2 -p1 -b .warnings
%patch5 -p1 -b .install
%patch6 -p1 -b .norpath
%patch7 -p1 -b .libtool15
%patch13 -p1 -b .phpize64
# %patch14 -p1 -b .ecalloc
[...]

Após as modificações recompile o PHP com:

rpmbuild -ba php.spec

Podem ser apresentadas diversas dependências que necessáriamente devem ser instaladas no sistema antes da compilação, para usuários RHEL, Fedora e CentOS podem utilizar o yum ou up2date. Para instalação a partir dos fontes ou em outras distribuições, instale todos os pacotes necessários antes de iniciar o processo de compilação.

Após o final da compilação e empacotamento os pacotes estarão disponíveis em /usr/src/redhat/RPMS/i386 e já podem ser instalados com o suhosin-patch embutido.

Instalando a extensão Suhosin

Descompacte os fontes e compile com:

tar xvfz suhosin-0.9.20.tgz
cd suhosin-0.9.20
phpize
./configure
make
make install

Para habilitar a extensão vamos incluir um novo arquivo de include para o PHP com o conteúdo “extension=suhosin.so“, ou adicione a linha diretamente ao php.ini. Para ativar o novo módulo apenas reinicie o Apache.

Apesar da instalação padrão já atender a maioria dos usuários, você pode personalizar as configurações do Suhosin para atender as necessidades de seu ambiente, para isso é disponível um manual diretamente no site oficial.