Pesquisar este blog

quarta-feira, 28 de novembro de 2007

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>

terça-feira, 27 de novembro de 2007

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

sexta-feira, 23 de novembro de 2007

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.

quarta-feira, 1 de agosto de 2007

Vulnerabilidade do CPANEL

Esta é antiga (setembro de 2006), mas fiz questão de deixar reforçado aqui para todos e para mostrar que muitas vezes o nosso cPanel também é uma bela dor de cabeça. Eu upei o vídeo que o artigo informa para o http://www.youtube.com.br para posta-lo aqui diretamente.


É interessante você testar se seu sistema realmente esta seguro e sem esta falha (se bem que esta é bem antiga, mas nunca se sabe). aliás um ótimo site que todos devem acessar periodicamente é o WebSense


Esta notícia fez muito "sucesso" no meio pois afetou um dos grandes (talvez o maior) host que usa o cPanel profissionalmente.


Eu retirei o artigo do portal MeioBit


Uma vulnerabilidade antiga do cPanel, mas que só foi descoberta agora, que permite a um usuário local ganhar privilégios de root, foi descoberto após a infecção de centenas (ou milhares, as informações são vagas) de sites hospedados no HostGator.


Um script não compilado utilizado do MySqlAdmin permitiria que um usuário, com acesso local, sobrescrevesse este arquivo e esta cópia teria precedência sobre o MySqlAdmin correto, em função da ordem de preferência da pesquisa por módulos do perl.


Com esse script seria possível escalar privilégios, inclusive ganhando acessos de root.


A vulnerabilidade afeta todas as versões do cPanel tanto Stable, Release, Current quanto Edge lançadas até o dia 23/09/2006.


Rodar o script de atualização do cpanel (/scripts/upcp), após o dia 23/09/2006, é o suficiente para resolver o problema, caso o cPanel não esteja configurado para atualização automática.


No caso específico da HostGator, esse exploit foi usado para deformar 650 sites e redirecionar os usuários para páginas que se aproveitavam de uma brecha de segurança no VML do Internet Explorer para instalar um trojan que enviaria qualquer dado digitado em qualquer formulário para os e-mails dos crackers.


Este Vídeo demonstra claramente como funciona o trojan.


ATENÇÃO: Não acesse o site que aparece no vídeo, sua máquina será infectada, o site exibido explora várias brechas de segurança, mesmo acessando – o com o Firefox, você não estará seguro.


O cPanel vem apresentando algumas falhas esquisitas nestas últimas semanas, recomendo fortemente que a atualização automática esteja sempre ativa.


O cPanel é, muito provavelmente, o painel de controle mais utilizado em hospedagem de sites e muitos administradores (inclusive alguns que eu conheço) não gostam de deixar a atualização no automático, ou seja, mesmo com a atualização disponível não garante que estamos totalmente seguros.


Mas o mais impressionante desta história (além, é claro, de um problema como estes nunca deveria ter chegado em um produto final), são as novas formas que os crackers estão usando para fazer suas vítimas.


Cruzar bugs de dois sistemas diferentes é bastante engenhoso e que mesmo tomando os devidos cuidados, não estamos seguros.


Dica: É Importante deixar a opção de "Update de segurança" do WHM habilitada no automático. Embora o sistema de update do cPanel seja um verdadeiro caos - eu ainda posto aqui minhas experiências a respeito, acho que é por isso que estou perdendo o cabelo.

domingo, 29 de julho de 2007

Sistema de Atendimento ao Cliente

Eu recebo sempre pedidos de usuários e clientes nossos de revenda sobre sistemas de atendimento automatizado a clientes (ticket de atendimento). O melhor que já usamos (e por isso mesmo usamos até hoje) é o KAYAKO - http://www.kayako.com/

O problema do KAYAKO é que o mesmo é caro, mas na minha humilde opinião este sistema é o que os americanos definem como "estado da arte" em sistemas de atendimento.

Existem outros sistemas menos completos entre gratuitos e pagos eu destacaria o http://osticket.com/ (licença GPL), onde vc tem a possibilidade de (como qualquer scritp GPL) modificar o código de acordo com a sua necessidade e para atendimento específico via chat online temos o http://www.craftysyntax.com/ também sob licença GPL, ambos disponíveis no FANTASTICO em seu CPANEL.

Procurando links com informações na rede encontrei algumas soluções de atendimento via chat online que merecem ser testadas:
Agora sem sombra de dúvida o campeão de sistemas de atendimento via chat é o PHPliveSupport (http://www.phplivesupport.com/), que inclusive usamos (mesmo a KAYAKO tendo um sistema de chat junto com o seu poderoso sistema de atendimento via ticket).

Bom, gastei este texto todo apenas para passar um link de DOWNLOAD do sistema comercial livre para uso que já usamos - este é infinitamente superior a qualquer sistema de atendimento GPL (livre) existente.

Podem instalar e testar a vontade : Sistema de atendimento InverseFlow

Esta é a mesma versão que usávamos antes de comprarmos a KAYAKO.

Divirtam-se !!! Aos que desejarem testar as outras soluções ou que tenham conhecimento de outros sistemas e quiserem compartilhar fiquem a vontade.