Configurações APACHE (Parte I)

Creio que o maior calcanhar de aquiles de qualquer servidor de hospedagem que se preze é realmente o WebServer (no meu caso o Apache). Principalmente após o lançamento definitivo do Apache 2.0 e depois suas versões correlatas, devido a suas mudanças (é praticamente um outro sistema totalmente diferente) e possibilidades de configuração.

Muitos acham que o Servidor de Email é o que dá mais trabalho, mas basicamente o trabalho em um MTA é a luta contar o SPAM. O resto é de funcionamento e configuração bem simples, desde que você entenda a "linguagem" de configuração que praticamente terá de aprender para configurar corretamente um Sendmail da vida.

Mas eu acho que você "tunar" corretamnente o Apache é muito mais complicado, devido a suas possibilidades e diferentes configurações.

Este post pretende ser o primeiro de uma série exatamente sobre o Apache.

Primeiro, alguns passos básicos sobre a configuração. eu achei o artigo (muito bom) em http://www.howtoforge.com/configuring_apache_for_maximum_performance (ingles) e (com algumas alterações minhas) o traduzi. É um texto bastante explicativo.

Devido ao tamanho eu o dividi em 2 partes distintas. A primeira parte segue logo abaixo:

Carregue apenas os módulos necessários

O servidor Apache é um programa modular onde o administrador pode escolher entre as funcinalidade que deseja incluir no servidor selecionando um pacote de módukis. Os módulos podem ser compilados estaticamente no binário httpd ou dinamicamente como DSOs(Dynamic Shared Objects). Módulos DSO podem ser compilados quando o servidor for compilado ou poem ser compilados utilizando o apxs para adicioná-los mais tarde. O modulo mod_so deve ser compilado estaticamente no Apache para que o suporte a DSO seja ativo.

Execute o apache apenas com os módulos necessários. Isto reduz o consumo de memória aumenta a performance do servidor. Compilar os módulos estaticamente irá reduzir o consumo de RAM que é utilizado para suportar módulos compilados dinamicamente, mas será necessário recompilar o apache toda vez que um módulo for adicionado ou removido. È aqui que o DSO se torna útil. Uma vez que o modulo mod_so seja compilado estaticamente, qualquer outro módulo pode ser inserido ou removido utilizando o comando LoadModule no arquivo httpd.conf - , mas você terá que compilar os módulos utilizando apxs se ele não foi compilado quando o servidor foi feito.

Escolha o MPM apropriado

O apache vem com uma selação de Módulos Multi-Processadores (MPMs) que são responsáveis por abrir as portas de rede na máquina, aceitando requisições, e despachando processos para cuidar das requisições. Apenas um MPM pode ser carregado por vez.

Escolher o MPM depende de vários fatores, por exemplo se o SO suporta threads, quanta memória está disponível, escalabilidade versus estabilidade, modulos externos,etc .. Sistemas Linux podem escolher entr utilizar um MPM com suporte (worker) a threads ou um prefork sem threads:

O MPM Worker utiliza múltiplos processos. Ele é multi-threaded com cada processo e cada thread cuidando de uma única conexão. Esté é mais rápido e mais escalável e a memória consumida e relativamente baixa. Funciona bem com múltiplos processadores. Porém, o worker é menos tolerante a módulos defeituosos, e threads defeituosas podem afetar todas as outras threads de um processo.

O MPM Prefork utiliza múltiplos processos filhos, cada filho cuidad de apenas uma conexão por vez. Prefork é muito bem gerenciada por processadores simples ou múlitplos, a velocidade é comparável ao worker e é mais tolerante a falhas em modulos e processos que terminam inesperadamente. Mas o consumo de memória é alto, mais tráfego leva a mais consumo de memória.

Opções de Configuração em Tempo de Execução

DNS lookup

A diretiva HostnameLookips habilita a consulta de DNS, então os hostnames podem ser logados ao invés de endereços IP. Isto adiciona latência em cada requisição desde que a consulta do DNS tem que ser completada antes que a requisição seja terminada. Esta opção é desabilitada por padrão no Apache 1.3 e superiores. Deixe isto inativo e utilize programas pós-processamento como o logresolve para determinar os IPs dos logs. Logresolve vem com Apache.

Quando utilizar as diretivas Allow from ou Deny from, utilize endereços IP ao invés de nomes de domínios. Caso contrário uma consulta dupla ao DNS será executada para ter certeza de que o domínio ou host não está sendo spoofado.

AllowOverride

Se o AllowOverride está setado para 'None', então o Apache irá tentar abrir o arquivo .htaccess (especificada pela diretiva AccessFileName) em cada diretório que for acessado. Por exemplo:

DocumentRoot /var/www/html

AllowOverride all

Se uma requisição for feita para acessar /index.html, o Apache irá tentar abrir /.htaccess, /var/.htaccess, /var/www/.htaccess, and /var/www/html/.htaccess. Estas tentativas aumentam a latência. Se o arquivo .htaccess for necessário para um diretório, habilite apenas para este diretório.

FollowSymLinks e SymLinksIfOwnerMatch

Se a opção FollowSymLinks estiver setada, então o servidor permitirá que links simbólicos possam ser seguidos neste diretório. Se a opção SymLinksIfOwnerMatch estiver setada, então o servidor permitirá acessar o link apenas se o destino dele bater com o dono do link.

Se a opção SymLinksIfOwnerMatch estiver setada, então o Apache terá que realizar consultas adicionais ao sistema para verificar se os donos coincidem. Chamadas adicionais também são necessárias quando a opção FollowSymLinks NÃO está setada. Por exemplo:

DocumentRoot /vaw/www/html

Options SymLinksIfOwnerMatch

Para uma requisição feita para /index.html, o Apache irá executar lstat() em /var, /var/www, /var/www/html, and /var/www/html/index.html. Estas requisições adicionais também irão aumentar a lantência. Os resultados do lstat não são cacheados, então as consultas irão ocorrer em cada requisição.

Para uma máxima performance, sete FollowSymLinks em cada lugar e nunca sete SymLinksIfOwnerMatch. Ou então, se SymLinksIfOwnerMatch for necessário para um diretório, sete ele para apenas este diretório.

FIM DA PRIMEIRA PARTE

Aviso: Todos os tutoriais postados pelo autor foram testados em ambiente de produção. Porem o mesmo não se responsabiliza por problemas ou bugs existentes nos sistemas usados de terceiros ou por erros durante a instalação dos recursos/scripts testados - o uso dos mesmos é por conta e risco de seus usuários

>br>

Erro na atualização do sistema FANTASTCO

Sobre erros na atualização do sistema FANTASTCO, eu identifiquei alguns problemas com as atualizações o sistema FANTASTICO em alguns servidores. Futucando um pouco na net eu encontrei a solução e principalmente a explicação da origem do problema.

O problema ocorre principalmente na versão LINUX CentOs 5, Fedora Core 7 e Red Hat Enterprise 5 (versões red hat e derivadas), que por sua vez, apresentam o WGET (utilitário de download de arquivos) incompatível com a ferramenta de autoinstall do Fantastico De Luxe 2.10.4 r10 (LATEST and STABLE releases), sendo uma das saídas atualizar o Wget ou fazer DownGrade de Versão, e lembrando que não baixe uma versão muito antiga pois pode tornar-se ineficiente para futuras operações de Administração do Servidor.

O tutorial segue logo abaixo (já testado) Antes de mais nada baixe o Wget com os passos abaixo. No ajuste feito Hoje em Um servidor Dedicado Opteron 1200 series apliquei a seguinte versão do Wget -> ftp://ftp.gnu.org/gnu/wget/wget-1.10.1.tar.gz. REMOVA O WGET “BUGGADO”, com o comando abaixo:

yum remove wget (quando ele pedir confirmação confirme com “Y”)

Esta versão (que citei acima), apesar de ser ”obsoleta” é bastante estável.Para instalar use os seguintes comandos (Após baixar):

tar -zxvf wget-1.10.2.tar.gz

cd wget (ou use o comando a direita para entrar na pasta -> cd pastaqueOtargzGEROU).Em seguida use os comandos:

./configure –prefix=/usr/local/

Depois:

make && make all && make install

Por último, localize o wget com o comando abaixo:

find / -name wget

Acesse a pasta aonde ele se encontra. Ao Acessar copie o arquivo para o diretório /usr/bin com o comando abaixo:

cp wget /usr/bin/

Feito isto, basta tentar Reinstalar o Fantastico De Luxe 2.10.4 r10

Aviso: Todos os tutoriais postados pelo autor foram testados em ambiente de produção. Porem o mesmo não se responsabiliza por problemas ou bugs existentes nos sistemas usados de terceiros ou por erros durante a instalação dos recursos/scripts testados - o uso dos mesmos é por conta e risco de seus usuários

Upgrade do CPANEL/WHM

Eu tenho recebido alguns emails falando sobre problemas de upgrade do CPANEL/WHM para a nova versão lançada a alguns meses (CPANEL11). O problema (para variar) é sempre em relação ao upgrade automático do CPANEL. Até hoje não entendo porque um upgrade com 4 níveis de verões e distros dá tanto problema.

Antes de efetuar o upgrade é necessário que o admin do servidor execute alguns procedimentos para não dar xabu, principalmente com a versão do PERL instalada. Por algum mistério insondável o CPANEL NÂO faz o update do PERL, provavelmente por causa dos módulos que são compilados com ele (módulos necessários par ao correto funcionamento do CPANEL e que demoram algum tempo para serem compilados).

Para ver se você necessita fazer este update manualmente acesse seu servidor via SHH e execute:

perl -v

A versão do perl correta é a 5.8.8 – qualquer versão anterior a esta será necessário ser atualizada. Para isso execute:

wget http://layer2.cpanel.net/perl588installer.tar.gz
tar zxvf perl588installer.tar.gz
cd perl588installer
perl install

Estes comandos acima baixam o pacote PERL já pre-compilado com todos os módulos necessários. Agora saia do micro e beba um café e leia um livro. O bicho demora um pouco (embora não gere muito load/processamento da máquina, é de bom tom executar apenas de madrugada ou em outro horário de menor uso do servidor).

Após finalizado execute:

/usr/local/cpanel/bin/checkperlmodules

Isso atualiza e reintegra os pacotes com os módulos PERL recém instalados no CPANEL. Existem outros dois módulso que você deve instalar manualmente:

/scripts/realperlinstaller YAML::Syck
/scripts/realperlinstaller File::Copy::Recursive

Pronto, CPANEL pronto para atualização para o CPANEL11:

/scripts/upcp –force (para atualizar o CPANEL completamente – por favor usem as distros REALEASE ou STABLE apenas)

Este pequeno tutorial também serve caso você já esteja usando a versão 11, não sendo necessário o /scripts/upcp –force.