Instalando o Apache
O Apache pode ser dividido em duas grandes famílias: o Apache 2.x e o Apache 1.3 que, apesar de muito antigo, ainda é usado em muitos servidores. O Apache 2 trouxe muitas vantagens, sobretudo do ponto de vista do desempenho, além de oferecer novos módulos e mais opções de segurança, mas sua adoção foi retardada nos primeiros anos por um detalhe muito simples: o fato de ele ser incompatível com os módulos compilados para o Apache 1.3. Como os módulos são a alma do servidor web, muitos administradores ficavam amarrados ao Apache 1.3 devido à falta de disponibilidade de alguns módulos específicos para o Apache 2.

Conforme o tempo foi passando, mais e mais módulos foram portados, sem falar de novos módulos desenvolvidos diretamente para uso em conjunto com o Apache 2. Hoje em dia, o Apache 1.3 ainda sobrevive em muitas instalações devido à inércia natural que temos dentro do ramo de servidores, mas não existe nenhum bom motivo para usá-lo em uma nova instalação. O Apache 2 é simplesmente melhor em todos os quesitos.

Apesar disso, ainda existem casos de distribuições que continuam oferecendo as duas versões, de forma a satisfazer os dois públicos. No Debian Etch, por exemplo, o Apache 1.3 é instalado através do pacote “apache”, enquanto o Apache 2 (a versão recomendada) é instalado através do “apache2″. Entretanto, no Debian Lenny já está disponível apenas o Apache 2, assim como no CentOS, no Fedora e em outras distribuições.

Ao instalar o Apache 2, o suporte a SSL é instalado automaticamente junto com o pacote principal (mas ainda é preciso ativá-lo na configuração, como veremos a seguir). Instale também o pacote apache2-utils, que contém diversos utilitários de gerenciamento que usaremos a seguir:

# apt-get install apache2 apache2-utils

Se desejar ativar o suporte a páginas seguras, você vai precisar também do pacote “ssl-cert”, necessário para ativar o suporte a SSL e gerar os certificados. Ele não é instalado por padrão ao fazer uma instalação enxuta do Debian ou do Ubuntu:

# apt-get install ssl-cert

Se você estiver utilizando o CentOS ou o Fedora, instale o pacote “httpd”, que contém o Apache 2 e os utilitários:

# yum install httpd

Diferente do Debian, o serviço não será configurado para ser ativado no boot por padrão e nem mesmo inicializado automaticamente após a instalação. Para ativá-lo, é necessário ativar o serviço e, em seguida, criar os links para início automático usando o chkconfig

# service httpd start
# chkconfig httpd on

Seguindo os nomes dos pacotes, no Debian o serviço se chama “apache2″, enquanto no Fedora e no CentOS ele se chama “httpd”. Para reiniciar o servidor você usa, respectivamente, os comandos “/etc/init.d/apache2 restart” e “service httpd restart”.

Acessando o endereço “http://127.0.0.1″, você verá uma página de boas-vindas, que indica que o servidor está funcionando. Se não houver nenhum firewall no caminho, ele já estará acessível a partir de outros micros da rede local ou da internet:

Por enquanto, temos apenas uma versão básica do Apache, que simplesmente exibe arquivos html e executa scripts CGI. Por padrão, o diretório raiz do servidor Web é “/var/www” (no Debian) ou “/var/www/html” (no Fedora). Com isso, a página “http://seu.servidor/index.html” é, na verdade, o arquivo “/var/www/index.html” ou “/var/www/html/index.html”.

Como de praxe, o diretório raiz é definido através de uma opção dentro do arquivo principal de configuração (a opção “DocumentRoot”) e pode ser alterado caso desejado. Ao hospedar diversos sites no mesmo servidor, você define uma pasta raiz diferente para cada um. Como pode ver, a instalação do Apache propriamente dita é bastante simples, o grande desafio é configurar e otimizar o servidor, como veremos ao longo do restante deste capítulo.

Instalação a partir do código fonte: Muitos administradores preferem instalar o Apache a partir dos fontes, o que oferece um controle maior sobre os recursos que ficarão ou não ativos.

De uma forma geral, instalar a partir do código fonte só é uma boa idéia se você conhece muito bem o software e não está satisfeito com as opções de compilação usadas nos pacotes incluídos na distribuição. Além da instalação e da configuração inicial, você precisará também se preocupar com patches e atualizações de segurança, já que você não poderá contar com as atualizações disponibilizadas através do apt-get ou do yum. Ou seja, se você não está confiante de que vai ter o tempo e o conhecimento necessários para realizar um trabalho de manutenção melhor do que o realizado pelos mantenedores do Debian, Ubuntu, CentOS ou do Fedora, você estará melhor servido simplesmente usado os pacotes pré-compilados.

De qualquer forma, se você quer encarar o desafio, pode baixar o código fonte no: http://httpd.apache.org/. Lembre-se de que para instalar qualquer aplicativo a partir dos fontes, você precisa ter instalados os compiladores e bibliotecas de desenvolvimento.

Os passos básicos são descompactar o pacote, acessar a pasta que será criada e executar o trio “./configure”, “make” e “make install”, este último como root. Isso resultará em uma instalação padrão, onde todos os arquivos são instalados no diretório “/usr/local/apache2″. Para personalizar as opções (que seria o principal motivo de instalar a partir dos fontes, afinal), você deve passar as opções desejadas ao executar o “./configure”, como em:

$ ./configure –prefix=/etc/apache2 –exec-prefix=/usr –bindir=/usr/bin \
–sbindir=/usr/sbin –mandir=/usr/share/man –sysconfdir=/etc/apache2/conf \
–includedir=/usr/include/httpd –libexecdir=/usr/lib/httpd/modules \
–datadir=/var/www/ –with-mpm=prefork –enable-mods-shared=”rewrite”

Como pode ver, as opções incluem não apenas os diretórios de instalação, mas também os módulos que serão ativados e diversas outras opções de configuração. Ao instalar a partir do código fonte, a ativação e a desativação do servidor é feita usando o script “apachectl”, que substitui o “/etc/init.d/apache2″ ou o “service httpd”, como em:

# apachectl start

ou:
# apachectl restart

Nas distribuições derivadas do Debian, a arquitetura modular do Apache é extendida também aos arquivos de configuração. Tradicionalmente, a configuração do Apache é centralizada em um único arquivo, o “httpd.conf“, que pode opcionalmente incluir referências a arquivos externos (includes) que permitem segmentar e organizar a configuração. Aproveitando esta possibilidade, a equipe do Debian desenvolveu uma organização bastante prática, que é usada também no Ubuntu e em outras distribuições derivadas dele.

À primeira vista, a organização do Apache 2 nas distribuições derivadas do Debian parece muito mais complicada, mas, depois de entender, a coisa se revela bastante simples e lógica:

Todos os arquivos de configuração estão organizados dentro do diretório “/etc/apache2″. Dentro dele, temos as pastas “sites-available” e “sites-enabled”, que contêm a configuração dos sites hospedados; as pastas “mods-available” e “mods-enabled”, que armazenam a configuração dos módulos; o arquivo “ports.conf”, onde vai a configuração das portas TCP que o servidor vai escutar; o arquivo “apache2.conf”, que armazena configurações diversas relacionadas ao funcionamento do servidor e a pasta “conf.d”, que armazena arquivos com configurações adicionais.

O Apache é capaz de hospedar simultaneamente vários sites, cada um representado por um arquivo de configuração diferente. Imagine o caso de uma empresa de hosting que mantém um servidor com 2.000 pequenos sites. Quando cada cliente registra seu site e assina o plano de hospedagem, você cria um novo arquivo dentro da pasta “sites-available” com as configurações necessárias e um link para ele na pasta “sites-enabled”.

Como os nomes sugerem, a primeira pasta armazena a configuração de todos os sites (virtual hosts) hospedados no servidor, mas apenas os sites que estiverem presentes na pasta “sites-enabled” ficam disponíveis. Quando é necessário suspender temporariamente um site por falta de pagamento, por exemplo, você simplesmente remove o link na pasta “sites-enabled”, sem precisar mexer na configuração.

Ao invés de criar e remover os links manualmente, você pode usar os comandos “a2ensite” e “a2dissite“, que fazem isso para você. Para ativar e desativar um site configurado no arquivo “/etc/apache2/sites-available/gdhn”, por exemplo, os comandos seriam:

# a2ensite gdhn
(ativa)

# a2dissite gdhn
(desativa)

Quando o Apache é instalado, é criado por padrão o arquivo “/etc/apache2/sites-available/default”, que contém a configuração de um site “raiz”, que usa (por padrão) a pasta “/var/www” como diretório de páginas. Se o seu servidor web vai hospedar um único site, então essa configuração é suficiente, mas, caso você queira hospedar vários sites no mesmo servidor, é necessário criar uma pasta e um arquivo de configuração para cada site adicional.

Seu servidor pode, por exemplo, hospedar o “joao.com.br” e o “maria.com.br”. Um servidor DNS, mantido por você, é configurado para responder pelos dois domínios, em ambos os casos fornecendo o endereço IP do seu servidor web aos clientes. Na configuração do apache, criamos os arquivos “/etc/apache2/sites-available/joao” e “/etc/apache2/sites-available/maria”, cada um configurado para utilizar uma pasta diferente. De acordo com sua preferência, podem ser usadas pastas dentro do diretório home de cada usuário, como em “/home/joao/html” e “/home/maria/html”, ou subpastas dentro do diretório “/var/www”, como em “/var/www/joao” e “/var/www/maria”.

Quando um visitante digita “http://joao.com.br”, o servidor do Registro.br (que responde pelos domínios .br) vai passar a requisição para seu servidor DNS, que responde com o endereço do seu servidor web. Ao acessar o servidor, o navegador solicita o site “joao.com.br” e o servidor responde enviando o arquivo “/var/www/joao/index.html” ou “index.php” ao cliente.

Esta configuração parece bem complicada à primeira vista, mas na prática é relativamente simples. Veremos mais detalhes sobre a configuração de servidores Apache com vários domínios mais adiante.

Continuando, a mesma idéia das duas pastas separadas se aplica aos módulos. A pasta “mods-available” contém a configuração e scripts de inicialização para todos os módulos disponíveis, mas apenas os módulos referenciados (através de um link) na pasta “mods-enabled” são realmente carregados.

Muita gente simplesmente cria e deleta os links manualmente, mas isso pode ser feito mais rapidamente usando os comandos “a2enmod” e “a2dismod”, que ativam e desativam módulos específicos. Para desativar o suporte a PHP, por exemplo, você usaria o comando:

# a2dismod php5

Para ativá-lo novamente, usaria:

# a2enmod php5

Uma vez que um determinado módulo é ativado, ele fica automaticamente disponível para todos os sites hospedados no servidor.

Para que a alteração entre em vigor, é necessário reiniciar o serviço, usando o comando “/etc/init.d/apache2 force-reload” ou o “/etc/init.d/apache2 restart” (no Debian os dois comandos fazem exatamente a mesma coisa):

# /etc/init.d/apache2 force-reload

Por outro lado, ao ativar ou desativar sites, ou ao fazer alterações simples na configuração, você pode utilizar o comando “/etc/init.d/apache2 reload” (sem o “force”), que apenas atualiza a configuração, sem reiniciar o serviço:

# /etc/init.d/apache2 reload

A vantagem de usar o reload em vez do force-reload é que ele não precisa finalizar os processos do Apache, o que evita que o servidor fique indisponível durante a reinicialização do serviço. Em um servidor movimentado, com um grande volume de sites hospedados e um grande volume de acessos, reiniciar o servidor web é um processo caro, que causa interrupção do serviço e perda de acessos, daí as duas opções.

Outra configuração que foi desmembrada é a configuração de portas, que foi para o arquivo “ports.conf“. Originalmente o arquivo vem com uma única linha:

Listen 80

É aqui que você altera a porta padrão do seu servidor ou adiciona novas portas, como faremos mais adiante ao ativar o SSL, por exemplo.

Você pode também usar portas diferentes caso precise manter mais de um servidor web ativo na mesma máquina (muitos administradores usam este truque para testar novas versões do Apache, ou para combiná-lo com um segundo servidor web, como o lighttpd, configurado para servir arquivos e páginas estáticas). Outro uso comum para a opção é (em casos em que você quer disponibilizar um servidor web doméstico) para burlar as restrições das operadoras de planos de acesso, que geralmente bloqueiam conexões na porta 80, de forma a dificultar o uso de servidores web nas conexões domésticas.

Para fazer com que seu servidor escute também na porta 443 (a porta do HTTPS) e na porta 8080, por exemplo, você adicionaria duas novas linhas, como em:

Listen 80
Listen 443
Listen 8080

Finalmente, chegamos ao arquivo “apache2.conf“, que agrupa o “resto” das configurações. É ele que você vai alterar quando, por exemplo, precisar ajustar o número de processos usados pelo Apache ou aumentar o número de conexões simultâneas permitidas pelo servidor, como veremos em detalhes mais adiante.

Instalando o suporte a PHP

No início, existiam apenas páginas html estáticas, com links atualizados manualmente. Depois, surgiram os scripts CGI (geralmente escritos em Perl), que permitiram criar vários tipos de formulários e automatizar funções. Finalmente, surgiu o PHP, adotado rapidamente como a linguagem padrão para criação de todo tipo de página dinâmica, fórum ou gerenciador de conteúdo.

Além da linguagem ser bastante flexível, um script em PHP chega a ser mais de 100 vezes mais rápido que um script CGI equivalente, além de mais seguro. Em resumo, um script CGI é um executável, que precisa ser carregado na memória, executado e descarregado cada vez que é feita uma requisição. No caso do PHP, o interpretador fica carregado continuamente e simplesmente vai executando de forma contínua os comandos recebidos dos scripts incluídos nas páginas.

Para quem programa em Perl, existe a possibilidade de utilizar o mod-perl, instalável através do pacote “apache-mod-perl” ou “libapache2-mod-perl2″. Assim como o PHP, o mod-perl é um módulo do Apache que fica continuamente carregado na memória, executando os scripts Perl de uma forma bem mais rápida e segura que os scripts CGI.

Voltando ao assunto principal, no Debian o suporte a PHP é instalado através do pacote “php5” (ou “php4″, de acordo com a versão escolhida). Para instalá-lo, basta usar o gerenciador de pacotes da distribuição em uso, como em:

# apt-get install php5

No caso do CentOS e do Fedora, é usado um pacote unificado, o “php”, que inclui a versão mais recente do interpretador, eliminando a confusão:

# yum install php

Com o interpretador PHP instalado, falta instalar o módulo do Apache 2, que no Debian está disponível através do pacote “libapache2-mod-php5″ (ou “libapache2-mod-php4″, de acordo com a versão desejada):

# apt-get install libapache2-mod-php5

O módulo “libapache2-mod-php5″ é instalado dentro da pasta “/usr/lib/apache2/modules/” e é ativado de uma forma diferente que no Apache 1.3. Ao invés de adicionar as linhas que ativam o módulo e criam as associações de arquivos no final do arquivo httpd.conf, são criados dois arquivos dentro da pasta “/etc/apache2/mods-available/”, com, respectivamente, a ativação do módulo e as associações de arquivos. Os links são criados automaticamente ao instalar o pacote, mas você pode tirar qualquer dúvida usando o comando a2enmod:

# a2enmod php5

Não esqueça de reiniciar o serviço para que o módulo seja carregado e a configuração entre em vigor:

# /etc/init.d/apache2 force-reload

ou:
# service httpd restart

Com o suporte a PHP ativado, o Apache continua exibindo diretamente páginas com extensão .htm ou .html, mas passa a entregar as páginas .php ou .phps ao interpretador php, que faz o processamento necessário e devolve uma página html simples ao Apache, que se encarrega de enviá-la ao cliente.

Estas páginas processadas são “descartáveis”: cada vez que um cliente acessa a página, ela é processada novamente, mesmo que as informações não tenham sido alteradas. Dependendo do número de funções usadas e da complexidade do código, as páginas em PHP podem ser bastante pesadas. Não é incomum que um site com 100.000 pageviews diários (o que corresponde a umas 5 a 8 requisições por segundo nos horários de pico) precise de um servidor dedicado, de configuração razoável.

Quase sempre, os sistemas desenvolvidos em PHP utilizam também um banco de dados MySQL ou Postgre SQL. Naturalmente, é perfeitamente possível que os scripts simplesmente salvem as informações em arquivos de texto dentro do diretório do site, mas isso resultaria em um desempenho muito ruim, sem falar em eventuais brechas de segurança. Utilizar um banco de dados permite armazenar um volume muito maior de informações, acessíveis de forma mais segura.

Para que o interpretador PHP seja capaz de acessar o banco de dados, é necessário ter instalado (além do servidor MySQL propriamente dito) o módulo “php5-mysql” (ou “php4-mysql”), que faz a junção entre os dois componentes:

# apt-get install php5-mysql

No caso do PostgreSQL, é utilizado o módulo “php5-pgsql”, que tem a mesma função:

# apt-get install php5-pgsql

Não se esqueça de reiniciar o Apache, para que as alterações entrem em vigor:

# /etc/init.d/apache force-reload

No caso do Fedora e do CentOS, muda apenas o nome do pacote, que passa a se chamar simplesmente “php-mysql”:

# yum install php-mysql

Para verificar se o suporte a PHP está realmente ativo, crie um arquivo de texto chamado “info.php” (ou outro nome qualquer, seguido da extensão .php) dentro da pasta do servidor web, contendo apenas a linha abaixo:

<?php phpinfo( ); ?>

Salve o arquivo e abra a página através do navegador. A função “phpinfo”, que usamos no arquivo, faz com que o servidor exiba uma página com detalhes da configuração do PHP e dos módulos ativos:

Depois de verificar, remova o arquivo, pois não é interessante que essas informações fiquem disponíveis ao público.

Dicas de segurança

O interpretador php é configurado através do arquivo “php.ini“, um longo arquivo de configuração que permite ativar ou desativar opções diversas da linguagem como, por exemplo, a possibilidade de fazer upload de arquivos através de scripts colocados nas páginas.

A localização do arquivo pode variar de acordo com a distribuição, mas você pode encontrá-lo rapidamente usando o comando “locate”. No caso do CentOS, o arquivo é o “/etc/php.ini“, enquanto nas distribuições derivadas do Debian é usado o arquivo “/etc/php5/apache2/php.ini“.

Para melhorar a segurança, é recomendável desativar as funções “show_source”, “system”, “shell_exec”, “passthru”, “exec”, “popen”, “proc_open”, “symlink”, o que pode ser feito através da opção “disable_functions =”, disponível (no Debian Etch) na linha 224 do arquivo. Basta adicionar a lista das funções, como em:

disable_functions = show_source, system, shell_exec, passthru, exec, popen, proc_open, symlink

Outras opções que é recomendável manter desativadas dentro do arquivo são:

expose_php = Off
register_globals = Off
allow_url_fopen = Off
allow_url_include = Off

A opção “allow_url_fopen” permite abrir ou processar uma página ou arquivo externo dentro do script php. Embora ela seja uma função útil, usada por scripts que geram uma lista de links a partir de um feed, por exemplo, ela pode ser usada para diversos tipos de abusos, o que faz com que seja desativada em diversos serviços de hospedagem, como no caso do Dreamhost.

Ao tentar executar algum script em PHP que dependa da função, você receberá um erro similar a:

Warning: file_get_contents() [function.file-get-contents]: URL file-access is disabled in the server configuration in /var/ww/site/rss.php on line 59

Nesse caso, você tem duas opções. Ou volta a ativar a opção dentro do arquivo, substituindo a linha “allow_url_fopen = Off” por “allow_url_fopen = On” (é necessário reiniciar o serviço do Apache para que a alteração entre em vigor) ou reescreve o script usando a função “cURL”, para que o script baixe o arquivo antes de processá-lo.

Outra dica é que além do pacote básico, existem diversos módulos e add-ons para o PHP, disponíveis através de pacotes complementares, como o “php5-gd” (usado por diversos scripts de CAPTCHA, os verificadores onde o usuário precisa digitar o texto contido na imagem) e o “php5-mcrypt” (uma biblioteca com funções de encriptação e desencriptação). Você pode começar com o pacote básico e ir instalando os pacotes adicionais conforme for precisando deles.

Instalando o MySQL

O MySQL é um banco de dados extremamente versátil, usado para os mais diversos fins. Você pode acessar o banco de dados a partir de um script em PHP, através de um aplicativo desenvolvido em C ou C++, ou praticamente qualquer outra linguagem (até mesmo através de um shell script! .

Existem vários livros publicados sobre ele, por isso vou me limitar a falar sobre a instalação e a configuração necessária para utilizá-lo em um servidor LAMP, em conjunto com o Apache e o PHP.

O primeiro passo é instalar o servidor MySQL propriamente dito. Nas distribuições derivadas do Debian precisamos instalar apenas o pacote “mysql-server” usando o apt-get:

# apt-get install mysql-server

No CentOS ou Fedora, instalamos os pacotes “mysql” e “mysql-server”, usando o yum:

# yum install mysql mysql-server

Você pode instalar também os pacotes “mysql-client” (o cliente que permite acessar os dados e fazer modificações no banco de dados) e o “mysql-navigator” (uma interface gráfica para ele).

Para que o serviço seja configurado para ser carregado durante o boot, ative-o usando o chkconfig:

# chkconfig mysqld on

Antes de iniciar o serviço, rode o comando “mysql_install_db“. Ele prepara o terreno, criando a base de dados “mysql” (usada para armazenar a configuração do servidor MySQL, incluindo informações sobre os usuários e sobre as demais bases de dados) e também uma base de dados chamada “test”, que pode ser usada para testar o servidor:

# mysql_install_db

O passo seguinte é ativar o servidor MySQL:

# /etc/init.d/mysql start

No caso do Fedora e do CentOS, o serviço se chama “mysqld”, ao invés de simplesmente “mysql”, como no caso do Debian:

# service mysqld start

O MySQL possui um usuário padrão chamado “root”, que, assim como o root do sistema, tem acesso completo a todas as bases de dados e é usado para fazer a configuração inicial do sistema, assim como tarefas de manutenção. Esta conta inicialmente não tem senha, por isso você deve definir uma logo depois de iniciar o serviço, usando o comando “mysqladmin -u root password senha”, incluindo a senha desejada diretamente no comando, como em:

# mysqladmin -u root password psUT7wq01

Se você precisar trocar a senha posteriormente, é necessário acrescentar o parâmetro “-p” antes do “password” e, em seguida, especificar a nova senha, como em:

# mysqladmin -u root -p password psUT7wq01

Enter password: ********

Veja que nesse caso é necessário incluir a senha antiga ao executar o comando, antes de continuar, já que do contrário teríamos uma brecha óbvia de segurança.

Continuando, depois de definir a senha, o próximo passo é criar uma base de dados. Você pode instalar vários scripts diferentes (um fórum, um chat e um gestor de conteúdo, por exemplo) no mesmo servidor e, inclusive, várias cópias de cada um. Isso é cada vez mais utilizado, tanto dentro de sites que oferecem diversos serviços, quanto em servidores compartilhados, onde os responsáveis por cada site têm a liberdade de instalar os sistemas de sua preferência.

Administração básica do banco de dados

Existem muitas interfaces de administração para o MySQL, mas a forma mais elementar é usar o prompt de comando. Para acessá-lo, use o comando:

# mysql -u root -p <enter>

Enter password: <senha>

Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 43 to server version: 4.0.15-log
Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the buffer.
mysql>

Veja que o cabeçalho normal do bash foi substituído por um “mysql>”, que lembra onde você está. Para sair, pressione “Ctrl+C” ou execute o comando “quit“.

Dentro do prompt do MySQL, use o comando “CREATE DATABASE” (criar base de dados), seguido pelo nome desejado. Neste exemplo, estou criando uma base de dados para usar na instalação do phpBB, que veremos a seguir. Um detalhe importante é que todos os comandos dados dentro do prompt do MySQL devem terminar com ponto-e-vírgula:

mysql> CREATE DATABASE phpbb;
Query OK, 1 row affected (0.04 sec)

Para confirmar, use o comando “SHOW DATABASES”, que lista as bases de dados criadas no servidor, como em:

mysql> SHOW DATABASES;

+——————–+ | Database | +——————–+ | information_schema | | mysql | | phpbb | | test | +——————–+

Note que além da base “phpbb” que criamos, existem mais três bases de dados, criadas durante a instalação. As bases “mysql” e “information_schema” são para uso interno do MySQL, incluindo o armazenamento das configurações (sendo um banco de dados, o MySQL usa a si mesmo para armazenar suas configurações , enquanto a base “test” é uma DB vazia, que pode ser usada para fins de teste.

Temos em seguida a questão das permissões de acesso. Nada impede que você sempre utilize a conta “root” do MySQL e inclusive configure os scripts instalados para a utilizarem. Entretanto, isso é extremamente inseguro, principalmente se você pretende instalar vários scripts e aplicativos no mesmo servidor, ou se as bases de dados serão acessadas por vários usuários.

O ideal é que cada base de dados tenha um usuário próprio e seja acessível apenas por ele. Se você vai instalar o phpBB (fórum) e o WordPress (gerenciador de conteúdo), por exemplo, crie duas bases de dados (“phpbb” e “wordpress”, por exemplo) e dois usuários separados, cada um com permissão para acessar uma das duas bases.

Na configuração de cada um dos gestores, informe a base de dados que será usada e o usuário e senha correspondente. Isso evita que eventuais problemas de segurança em um coloquem em risco também os dados referentes ao outro.

Outra situação comum é ao configurar um servidor com vários virtual hosts. Nesse caso, o webmaster de cada site vai precisar de uma ou mais bases de dados e, naturalmente, cada um vai precisar de um login próprio, com acesso apenas às suas próprias bases de dados.

Para criar um usuário “phpbb”, com senha “nDPIcqq9″ e dar a ele acesso à base de dados “phpbb” que criamos, use (dentro do prompt do MySQL) o comando:

mysql> GRANT ALL ON phpbb.* TO phpbb IDENTIFIED BY ‘nDPIcqq9‘;
(permita tudo na base phpbb para o usuário phpbb, identificado pela senha nDPIcqq9)

mysql> FLUSH PRIVILEGES;

O comando “FLUSH PRIVILEGES” faz com que o servidor MySQL atualize as tabelas de permissões, fazendo com que a alteração entre em vigor automaticamente, ao invés de apenas na próxima vez que o servidor for reinicializado. Na verdade, ele não é necessário ao adicionar usuários usando o comando “GRANT” (como no nosso caso), mas é saudável se acostumar a utilizá-lo sempre que usar comandos que modifiquem as permissões de acesso. Você vai notar que a maioria dos tutoriais inclui o comando depois das operações relacionadas a alterações nas permissões de acesso.

Continuando, para trocar a senha posteriormente, use o comando:

mysql> SET PASSWORD FOR phpbb = PASSWORD(‘JSAm950A‘);
(defina senha para o usuário phpbb, onde a senha é JSAm950A)

Este mesmo comando pode ser usado para trocar a senha do root, como em:

mysql> SET PASSWORD FOR root = PASSWORD(‘V5LQSxqL‘);

Se mais tarde você precisar remover as permissões de acesso de um usuário anteriormente criado (em um site com vários webmasters, onde um se desligou da equipe, por exemplo) use o comando:

mysql> REVOKE ALL ON phpbb.* FROM phpbb;
(remova todos os direitos para a base phpbb, para o usuário phpbb)

mysql> FLUSH PRIVILEGES;

Com isso, o usuário deixará de ter acesso à base de dados especificada, mas ainda continuará existindo no sistema e poderá acessar outras bases de dados a que tenha acesso. Para realmente remover o usuário, usamos o comando “DROP USER”, como em:

mysql> DROP USER phpbb

O comando “DROP USER” é suportado apenas pelas versões recentes do MySQL. Caso você esteja usando uma versão antiga, onde ele ainda não seja suportado, pode usar o comando “DELETE FROM mysql.user WHERE User=”, como em:

mysql> DELETE FROM mysql.user WHERE User=’phpbb’;

Para remover uma base de dados, use o comando “DROP DATABASE”, como em:

mysql> DROP DATABASE phpbb;

Todos estes comandos devem ser dados dentro da base de dados “mysql”, a base de dados interna usada pelo MySQL, acessada por default ao abrir a interface. Se, por acaso, você tiver mudado a base de dados de trabalho anteriormente (usando o comando USE), use o comando abaixo para voltar à base administrativa:

mysql> USE mysql;

Veja que os comandos usados dentro do prompt do MySQL seguem uma linguagem literal, usando palavras do inglês. Quem tem uma boa familiaridade com a língua tem bem mais facilidade em dominar os comandos.

Outra observação é que os comandos não são case sensitive. Tanto faz escrever “CREATE DATABASE phpbb;” ou “create database phpbb;”. Escrever os comandos em maiúsculas é apenas uma forma de dar mais destaque a eles.

Instalando o phpMyAdmin

Depois dessa configuração inicial, você pode experimentar instalar um gerenciador gráfico para facilitar a manutenção do seu servidor MySQL. Uma boa opção neste caso é o phpMyAdmin.

Para instalá-lo, basta instalar o pacote “phpmyadmin”, como em:

# apt-get install phpmyadmin

ou:
# yum install phpmyadmin

O pacote para instalação em outras distribuições, que não incluam o pacote por padrão, pode ser encontrado no: http://www.phpmyadmin.net/.

O phpMyAdmin é um gestor de configuração escrito em PHP que trabalha em conjunto com o Apache. Ele permite que você crie bases de dados, ajuste as permissões de acesso dos usuários, faça backup, e diversas outras atividades administrativas de uma forma mais simples que através do prompt de comando.

Uma vez instalado, ele pode ser acessado através do endereço “http://servidor/phpmyadmin/” ou “https://servidor/phpmyadmin/“. Na tela inicial, você pode se logar usando qualquer uma das contas registradas no MySQL. Use o root para tarefas administrativas, quando for necessário ter acesso a todas as bases ou fazer backup de tudo, e uma das contas restritas para acessar uma base específica:

O acesso via HTTPS é preferível para acessos feitos via web, já que evita que as senhas de acesso e outras informações fiquem circulando em texto puro por aí. O pacote do Debian se encarrega de ativar o suporte a SSL no phpMyAdmin automaticamente, mas para usá-lo é necessário também ativar o suporte a SSL na configuração do Apache, como veremos no tópico seguinte.

Caso, mesmo depois de gerar o certificado e ativar o SSL no Apache, você continue recebendo um erro ao tentar acessar a interface do phpMyAdmin via SSL, experimente reconfigurar o pacote usando o dpkg-reconfigure, como em:

# dpkg-reconfigure phpmyadmin

Selecione a opção “apache2″ quando o script perguntar sobre o servidor web usado e responda “sim” quando ele perguntar se você deseja reiniciar o serviço:

 

No CentOS e em diversas outras distribuições o phpMyAdmin vem configurado por padrão para permitir conexões apenas a partir da máquina local, uma precaução de segurança. Com isso, ao tentar acessar a interface remotamente, você recebe um “Forbidden. You don’t have permission to access /phpmyadmin/ on this server”. Para solucionar o problema, edite o arquivo “/etc/httpd/conf.d/phpmyadmin.conf” e comente a linha “Deny from All”, dentro da seção “<Directory “/usr/share/phpmyadmin”>”, como em:

<Directory “/usr/share/phpmyadmin”>
Order Deny,Allow
# Deny from all
Allow from 127.0.0.1
</Directory>

Uma observação importante é que ao ser usado em conjunto com o Apache, instalado no mesmo servidor que ele, o MySQL é acessado apenas localmente, através da interface de loopback. O Apache envia a requisição ao módulo PHP que faz o acesso ao banco de dados, tudo localmente. Nessa configuração, o servidor MySQL não deve ficar disponível para a Internet. Configure o firewall para bloquear a porta 3306 usada pelo servidor MySQL, além de todas as outras portas que não forem explicitamente necessárias.

Caso o servidor MySQL precise ficar acessível para outros servidores (você pode configurar o phpBB e outros scripts para utilizarem um servidor MySQL externo), configure o firewall para deixar a porta aberta apenas para os endereços IP dos servidores que forem ter acesso. Como os servidores dedicados sempre utilizam endereços fixos (ao contrário dos servidores domésticos), esta configuração fica mais simples.

Para administrar seu servidor MySQL remotamente, o ideal é que se conecte ao servidor via SSH e faça todo o trabalho através dele. Se precisar acessar diretamente alguma ferramenta de configuração, como o Webmin ou o phpMyAdmin, você pode criar um túnel (novamente usando o SSH) ligando a porta correspondente do servidor a uma porta da sua máquina e fazer o acesso através dela. Veremos em detalhes como usar o SSH e criar túneis encriptados no capítulo dedicado a ele.

Ativando o SSL

O SSL (Secure Socket Layer) é o protocolo usado para criar páginas seguras, encriptando toda a transmissão entre o cliente e o servidor. Os dois usos mais comuns são em páginas de comércio eletrônico, onde é necessário oferecer um ambiente seguro para concluir a transação e transmitir dados confidenciais e também na criação de ambientes administrativos, como os usados pela maioria dos gestores de conteúdo, que permitem que você gerencie o conteúdo do site.

Na grande maioria das distribuições, o pacote com o mod_ssl é instalado juntamente com o pacote principal do Apache, ou é pelo menos disponibilizado como um pacote separado, instalável através do gerenciador de pacotes.

No caso das distribuições derivadas do Debian, você precisa apenas ativar o módulo usando o comando “a2enmod”. Reinicie o serviço para que a alteração entre em vigor:

# a2enmod ssl
# /etc/init.d/apache2 force-reload

No caso do CentOS, é necessário instalar o pacote “mod_ssl” usando o yum. O script de pós-instalação se encarrega de adicionar o script de carregamento na pasta “/etc/httpd/conf.d” automaticamente, concluindo a instalação. Não se esqueça de reiniciar o serviço para que a alteração entre em vigor:

# yum install mod_ssl
# service httpd restart

Com o módulo carregado, fica faltando apenas o componente mais importante, que é o certificado SSL propriamente dito.

Se você quer ativar o SSL para testes ou para uso interno (para acessar alguma ferramenta administrativa instalada no servidor, ou para uso em uma página disponibilizada apenas para um grupo de amigos, por exemplo), você pode simplesmente gerar seu próprio certificado, o que é rápido, grátis e indolor. Se, por outro lado, você está ativando o SSL para uso em um site de comércio eletrônico, é necessário obter um certificado reconhecido através da Verisign ou outra entidade certificadora.

Os certificados caseiros são chamados de certificados self-signed (auto-assinados), já que você mesmo faz o papel de entidade certificadora, gerando e assinando o certificado. O algoritmo de encriptação usado é o mesmo, de forma que um certificado self-signed corretamente gerado oferece a mesma segurança que um certificado reconhecido. O grande problema é que os navegadores nos clientes não serão capazes de verificar a autenticidade do certificado, de forma que os visitantes receberão um aviso de “certificado não reconhecido” ao acessarem a página:

O propósito de entidades certificadoras, como a Verisign, é confirmar a titularidade dos certificados, confirmando que o certificado recebido ao acessar determinado site pertence realmente à entidade que o está fornecendo. É isso que garante que você está mesmo acessando o home banking do banco em que tem conta e não o site de um script kiddie qualquer. Certificados assinados por entidades certificadoras são automaticamente aceitos pelos navegadores (já que sua identidade já foi confirmada pela entidade certificadora), o que evita a exibição da mensagem.

Vamos então começar com a configuração de um certificado self-signed, e em seguida entender o que muda ao utilizar um certificado reconhecido.

 

Usando um certificado self-signed

No Debian e derivados você pode gerar um certificado caseiro utilizando o script “make-ssl-cert”, instalado através do pacote “ssl-cert”:

# apt-get install ssl-cert

Ao usar o script, você deve especificar o arquivo com o template (/usr/share/ssl-cert/ssleay.cnf) e o arquivo onde o certificado será salvo (/etc/apache2/ssl/apache.pem, para gerar um certificado padrão para o servidor), como em:

# mkdir /etc/apache2/ssl/
# cd /etc/apache2/ssl/
# make-ssl-cert /usr/share/ssl-cert/ssleay.cnf apache.pem -days 1095

A opção “-days” especifica a validade do certificado, que no exemplo será de 3 anos. O script solicitará as informações sobre a organização que serão incluídas no certificado, incluindo o código de país, estado, cidade e o nome da empresa. Estes são dados públicos, que serão exibidos aos clientes como parte das propriedades do certificado. O mais importante vem no final, quando o script pergunta:

Common Name (eg, your name or your server’s hostname) []:

Nesse ponto, você deve sempre fornecer a URL completa do servidor onde o certificado será usado, como em “www.gdhpress.com.br” ou “ssl.gdhn.com.br”. Se você especificar um domínio diferente, o cliente receberá um aviso adicional ao se conectar, avisando do problema. Isso afastará visitantes, já que muitos pensarão tratar-se de uma fraude.

Com o certificado gerado, abra agora o arquivo “/etc/apache2/ports.conf” e adicione a linha “Listen 443″ (a porta usada pelo https), como em:

Port 80
Listen 443

Com isso, o Apache 2 já está configurado. Falta apenas ativar o uso do SSL dentro da configuração do(s) virtual host(s) onde ele for ser utilizado. Para testar, vamos ativá-lo na página padrão que usamos para testar o servidor.

Abra o arquivo “/etc/apache2/sites-available/default“. No início do arquivo, substitua a linha “NameVirtualHost *”, por:

NameVirtualHost *:443
NameVirtualHost *:80

Isso explica que o Apache deve escutar tanto a porta 80 padrão, quanto a porta 443, usada pelo SSL. Logo em seguida, substitua a linha “<VirtualHost *>”, por:

<VirtualHost *:80>

Até aqui, dividimos a configuração em duas seções, uma para a porta 80, outra para a porta 443, usada pelo SSL. Falta agora adicionar a seção referente à configuração do SSL no final do arquivo:

<VirtualHost *:443>
DocumentRoot /var/www/
ErrorLog /var/log/apache2/error.log
CustomLog /var/log/apache2/access.log combined
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/apache.pem
</VirtualHost>

Reinicie o servidor (/etc/init.d/apache2 restart) e acesse o endereço “https://127.0.0.1” para testar a configuração. Ao conectar, o navegador exibe um aviso “O certificado do servidor falhou no teste de autenticidade” ou similar, o que é normal ao usar um certificado caseiro.

O CentOS não inclui o make-ssl-cert, mas inclui um outro script bastante prático, disponível dentro da pasta “/etc/pki/tls/certs”:

# cd /etc/pki/tls/certs

Uma vez dentro da pasta, use o comando “make” seguido pelo nome do arquivo que será gerado, como em:

# make apache.pem

Por default, a validade do certificado gerado pelo script será de 365 dias. Para usar outro valor, edite o arquivo “make-dummy-cert” dentro da pasta, substituindo o “-days 365″ na quinta linha de baixo para cima pelo valor desejado antes de gerar o certificado.

Isso gerará o arquivo “/etc/pki/tls/certs/apache.pem“, contendo o certificado. Para que ele seja usado, abra o arquivo “/etc/httpd/conf.d/ssl.conf” e localize a linha:

#SSLCACertificateFile /etc/pki/tls/certs/ca-bundle.crt

Descomente-a e indique a localização do arquivo gerado, como em:

SSLCACertificateFile /etc/pki/tls/certs/apache.pem

A partir daí, você pode reiniciar o serviço httpd e testar a configuração acessando o endereço “https://servidor”.

Diferente do Debian, não é necessário adicionar a linha “Listen 443″ na configuração do Apache, pois a linha faz parte do arquivo “/etc/httpd/conf.d/ssl.conf”, que é criado automaticamente ao instalar o pacote mod_ssl. Dentro do arquivo, você encontra as linhas:

# When we also provide SSL we have to listen to the
# the HTTPS port in addition.
#
Listen 443

Em outras distribuições, você pode usar diretamente o openssl para gerar o certificado. Nesse caso, o comando é maior, já que precisamos especificar manualmente um volume maior de parâmetros. Scripts como o make-ssl-cert são desenvolvidos justamente para tornar a geração do certificado mais simples.

# openssl req -new -x509 -days 1095 -sha1 -newkey rsa:1024 -nodes \
-keyout server.key -out meuservidor.csr

Este comando gera dois arquivos separados, o “server.key”, que contém a chave criptográfica e o “meuservidor.csr”, que contém o certificado que será fornecido aos clientes. Estes dois arquivos tem a mesma função do arquivo “.pem” que é gerado pelos scripts do Debian e do CentOS, apenas desmembrado em dois arquivos separados. Para usá-los, você precisa apenas adicionar duas linhas separadas dentro do arquivo de configuração principal do Apache (“/etc/apache2/httpd.conf” no caso do Debian ou “/etc/httpd/conf/httpd.conf”, no caso do CentOS), especificando as localizações dos dois arquivos:

SSLCertificateFile /etc/apache2/ssl/meuservidor.csr
SSLCertificateKeyFile /etc/apache2/ssl/server.key

Não esqueça de ativar o mod_ssl e incluir a linha “Listen 443″ na configuração do Apache, para que ele passe a escutar a porta do SSL. Certifique-se também de que a porta 443 está aberta na configuração do firewall.

Usando um certificado reconhecido

Finalmente, temos a configuração para um certificado reconhecido, que será assinado por uma entidade certificadora, que você utilizaria em um site de comércio eletrônico aberto ao público.

Uma das entidades certificadoras mais tradicionais é a Verisign (http://www.verisign.com/), que oferece uma série de garantias sobre os certificados emitidos. O grande problema com relação à Verisign é o preço: o certificado de validação mais simples custa nada menos de US$ 499 anuais, com opções de até US$ 1499. Com preços tão altos, não é de se estranhar que existam inúmeras outras entidades certificadoras, que oferecem preços mais competitivos.

Alguns exemplos são a Thawte (http://www.thawte.com) a GeoTrust (http://www.geotrust.com), a NetworkSolutions (http://www.networksolutions.com), a Digicert (http://www.digicert.com/) e a Comodo (http://www.instantssl.com), que possui opções a partir de US$ 79 anuais.

A Comodo é a mesma empresa que desenvolve o Comodo Firewall, distribuído gratuitamente como uma forma de divulgação dos serviços de certificação. No site está disponível também a opção de gerar um certificado de teste (válido por 90 dias) gratuitamente, que você pode usar para fins de teste, ou quando quiser colocar uma loja virtual no ar rapidamente, deixando para aderir a um dos planos pagos mais tarde:

Existem ainda casos de empresas que oferecem certificados de baixo custo, como a Godaddy (http://www.godaddy.com, a mesma que faz registro de domínios), que oferece certificados a partir de US$ 29.90.

Em termos de segurança, não existe muita diferença entre um certificado emitido pela Godaddy ou pela Verisign, as principais diferenças são o nível de validação e as garantias oferecidas por cada uma em caso de fraude ou de quebra da chave criptográfica. Assim como em outras áreas, o principal fator na decisão acaba sendo a questão da confiança.

Muitos serviços de hospedagem oferecem a possibilidade de utilizar um certificado compartilhado, onde a empresa responsável “empresta” seu próprio certificado para uso dos clientes, em troca de uma taxa de manutenção anual. Esta opção pode parecer interessante devido ao baixo custo e à facilidade de implementação, mas não é o mesmo que obter seu próprio certificado, já que muito provavelmente você precisará hospedar seu site em um subdomínio e os clientes verão o nome da empresa de hospedagem e não o nome da sua empresa ao examinarem as propriedades do certificado.

Existe ainda a possibilidade de obter um certificado gratuito no http://www.cacert.org/. Ele é reconhecido pela CAcert, mas o certificado raiz deles não vem pré-instalado na maioria dos navegadores, o que faz com que os clientes continuem recebendo a mensagem de certificado não válido ao acessar o servidor, de forma similar ao que temos ao usar um certificado self-signed.

Ao contratar os serviços de uma entidade certificadora, sua parte no trabalho é a de gerar uma chave de encriptação e uma requisição de certificado, o que é novamente feito usando o openssl:

# openssl req -new -nodes -keyout gdhn.key -out gdhn.csr

O “gdhn.key” e o “gdhn.csr” indicam os arquivos com a chave e com a requisição do certificado que serão gerados. Você precisará responder as mesmas perguntas sobre o país, estado, cidade, nome da empresa, etc., que precisam ser respondidas corretamente, já que as informações serão examinadas não apenas pela entidade certificadora, mas também pelos clientes:

Country Name (2 letter code) [AU]: BR
State or Province Name (full name) [Some-State]: Estado
Locality Name (eg, city) []: Cidade
Organization Name (eg, company) []: Minha Empresa LTDA
Organizational Unit Name (eg, section) []: Vendas
Common Name (eg, YOUR name) []: ssl.minhaempresa.com.br

Como comentei anteriormente, o campo “Common Name” deve ser preenchido com o domínio onde o certificado será usado (incluindo o “www” ou o subdomínio usado), caso contrário os clientes receberão um aviso ao acessarem o site:

Em geral, as entidades certificadoras oferecem a opção de obter um certificado curinga (wildcard), que cobre automaticamente todos os subdomínios usados no site. Entretanto, como eles abrem a possibilidade de usar vários subdomínios usando um único certificado, as certificadoras cobram bem mais caro por eles. A Comodo, por exemplo, cobra nada menos do que US$ 449.95 anuais, mais de 5 vezes o valor do certificado regular:

No final do processo, o openssl oferece a opção de especificar uma senha (challenge password) para o certificado. É importante deixá-la em branco, caso contrário você precisará fornecê-la cada vez que o servidor web for iniciado, incluindo casos de reboots acidentais. O arquivo do certificado é armazenado em uma pasta protegida do servidor, fora do diretório disponível para a web, de forma que se um atacante chega ao ponto de obter acesso a ele, significa que o problema é mais embaixo e ele muito provavelmente já obteve acesso completo ao servidor de qualquer forma.

Depois de gerar a requisição, o próximo passo é enviar o arquivo .csr para a entidade certificadora, que o usará para gerar o certificado. O arquivo .csr é na verdade um arquivo de texto plano, cujo conteúdo pode ser copiado e colado em um formulário web. Depois de confirmada sua identidade e feito o pagamento, você receberá de volta o certificado assinado, que pode ser então usado na configuração do Apache.

A configuração consiste em adicionar as linhas “SSLCertificateFile” e “SSLCertificateKeyFile”, indicando a localização dos arquivos .crt e .key recebidos. Em muitos casos, você receberá também um terceiro arquivo, com extensão “ca-bundle” ou similar, que é usado em conjunto com uma terceira opção, a “SSLCertificateChainFile”.

Este terceiro arquivo contém uma combinação de certificados, que permitem aos clientes chegarem até o certificado raiz da entidade certificadora, de forma a comprovarem a autenticidade do seu certificado. Devido a isso, ele é também chamado de certificado intermediário (Intermediate Certificate). Temos aqui um exemplo de configuração com as três opções:

<VirtualHost *:443>
DocumentRoot /var/www/gdhn
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/ssl_gdhn_com_br.crt
SSLCertificateKeyFile /etc/apache2/ssl/gdhn_com_br.key
SSLCertificateChainFile /etc/apache2/ssl/ssl_gdhn_com_br.ca-bundle
</VirtualHost>

O processo de emissão do certificado inclui uma verificação de identidade, que é justamente um dos principais papéis da entidade certificadora, já que se qualquer um pudesse gerar certificados válidos no nome de qualquer outro, o sistema perderia completamente o sentido. Nos planos mais simples, como no certificado gratuito oferecido pela Comodo, é feita uma simples verificação de titularidade via e-mail, onde você deve confirmar um código enviado para uma conta administrativa, como “admin@meudominio” ou “hostmaster@meudominio”. Nos planos mais caros (onde a entidade certificadora realmente oferece garantias, inclusive financeiras sobre o certificado emitido), o processo é mais burocrático, incluindo o envio de documentos.

Usando o SSL para pastas específicas

Em geral, você vai desejar usar o SSL apenas para seções específicas do site, como no caso de páginas de cadastro e de vendas, por exemplo. Na maioria dos casos, o cliente navega livremente pelo site, usando o protocolo HTTP não encriptado e acessa uma área protegida pelo SSL ao concretizar a compra ou ao acessar uma área onde precisa fornecer dados pessoais. Isso acontece por um motivo muito simples: servir páginas em HTTPS é caro em termos de processamento, de forma que encriptar o acesso a todo o site acabaria gerando um grande desperdício de recursos.

Você tem então duas opções. Usar um domínio separado para a área protegida, como “ssl.minhaempresa.com”, de forma que ela fique completamente separada do restante do site, ou proteger apenas uma pasta específica do site, tornando mandatário o uso do HTTPS ao acessá-la.

Para a primeira solução, você usaria uma configuração similar a essa dentro da configuração do Apache:

<VirtualHost *:80>
ServerName www.gdhn.com.br
DocumentRoot /var/www/gdhn
</VirtualHost>

<VirtualHost *:443>
ServerName ssl.gdhn.com.br
DocumentRoot /var/www/gdhn-ssl
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/ssl_gdhn_com_br.crt
SSLCertificateKeyFile /etc/apache2/ssl/gdhn_com_br.key
SSLCertificateChainFile /etc/apache2/ssl/ssl_gdhn_com_br.ca-bundle
</VirtualHost>

Veja que, nesse caso, temos essencialmente dois sites separados, um acessível apenas via HTTP e outro apenas via HTTPS. Ao acessar o “http://www.gdhn.com.br” o visitante acessaria a pasta “/var/www/gdhn”, que conteria o conteúdo geral do site, enquanto ao acessar o “https://ssl.gdhn.com.br” ele acessaria as páginas da seção segura, armazenadas na pasta “/var/www/gdhn-ssl”. A interligação entre as duas partes seria então feita através de links, que levariam o visitante de uma seção à outra do site.

A segunda opção, usar uma pasta para o SSL, é um pouco mais elegante, mas demanda uma configuração um pouco mais cuidadosa. Imagine que a seção segura do site será armazenada dentro da pasta “/var/www/gdhn/loja”, que deverá ser acessada apenas via HTTPS.

Ao acessar o “https://www.gdhn.com.br” o visitante cairá direto na pasta segura e, ao tentar acessar o “http://www.gdhn.com.br/loja” ele será automaticamente redirecionado ao “https://www.gdhn.com.br“. Nesse caso, você utilizaria uma configuração similar a essa:

<VirtualHost *:80>
ServerName www.gdhn.com.br
DocumentRoot /var/www/gdhn
<Directory /var/www/gdhn/loja>
SSLRequireSSL
</Directory>
Redirect /loja https://www.gdhn.com.br
</VirtualHost>

<VirtualHost *:443>
ServerName www.gdhn.com.br
DocumentRoot /var/www/gdhn/loja
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/ssl_gdhn_com_br.crt
SSLCertificateKeyFile /etc/apache2/ssl/gdhn_com_br.key
SSLCertificateChainFile /etc/apache2/ssl/ssl_gdhn_com_br.ca-bundle
</VirtualHost>

Veja que agora, usamos o domínio “www.gdhn.com.br” nas duas seções da configuração, tanto para HTTP quanto para HTTPS, entretanto, a seção com a configuração do HTTPS aponta para a pasta “/var/www/gdhn/loja”.

Como a idéia é que os arquivos da pasta possam ser acessados apenas usando o SSL, adicionamos uma diretiva para a pasta (<Directory /var/www/gdhn/loja>), dizendo que ela só pode ser acessada via HTTPS (SSLRequireSSL).

Para que os visitantes que tentarem acessar a pasta via HTTP sejam encaminhados para a área protegida, usamos uma regra de encaminhamento (Redirect /loja https://www.gdhn.com.br). Esta regra utiliza o módulo “rewrite”, que precisa estar ativo na configuração do Apache. Caso necessário, ative-o usando o comando “a2enmod rewrite”.

Finalmente, caso você queira que todo o conteúdo do site fique disponível via HTTPS e que os visitantes que tentarem acessar o http://www.gdhn.com.br/ sejam encaminhados para o https://www.gdhn.com.br, a configuração seria similar a essa:

<VirtualHost *:80>
ServerName www.gdhn.com.br
DocumentRoot /var/www/gdhn
<Directory /var/www/gdhn/>
SSLRequireSSL
</Directory>
Redirect / https://www.gdhn.com.br
</VirtualHost>

<VirtualHost *:443>
ServerName www.gdhn.com.br
DocumentRoot /var/www/gdhn/
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/ssl_gdhn_com_br.crt
SSLCertificateKeyFile /etc/apache2/ssl/gdhn_com_br.key
SSLCertificateChainFile /etc/apache2/ssl/ssl_gdhn_com_br.ca-bundle
</VirtualHost>

Como pode ver, a configuração é quase idêntica à do exemplo anterior. As únicas diferenças são que agora a seção com a configuração do HTTPS aponta para o diretório raiz do site e a regra de redirecionamento encaminha todos os acessos feitos feitos via HTTP para o https://www.gdhn.com.br, fazendo com que o acesso a qualquer página do site seja feito via SSL.

Ativando o uso de Virtual Hosts

O suporte a virtual hosts é um daqueles recursos fundamentais, que possibilitaram o surgimento da Internet da forma como a conhecemos hoje. Ele permite hospedar diversos sites, com domínios ou subdomínios diferentes usando um único servidor e um único endereço IP. Os únicos limitantes com relação ao volume de sites que é possível hospedar são os recursos de hardware do servidor e a banda disponível.

Serviços de hospedagem compartilhada (os planos de shared hosting) utilizam este recurso de forma intensiva, de forma a espremer o maior número possível de clientes em cada servidor, sem falar nos serviços de hospedagem gratuita onde, em muitos casos, um único servidor pode hospedar dezenas de milhares de sites diferentes.

Ao usar virtual hosts, os arquivos de cada site ficam guardados em uma pasta diferente e o servidor se encarrega de direcionar cada visitante à pasta correta. Os recursos do servidor (HD, memória, processamento e link) são divididos entre os sites hospedados, assim como vários programas abertos simultaneamente disputam os recursos da máquina. Isso faz muito sentido no caso de sites pequenos ou médios, que não possuem um número suficiente de visitas para saturarem, sozinhos, o servidor.

Em geral, o servidor é configurado de forma que os usuários tenham direito a uma determinada quota de espaço em disco, possam acessar os arquivos do site via FTP ou SFTP e tenham acesso a uma ou mais bases de dados do servidor MySQL, o que permite a instalação de gestores de conteúdo como o WordPress. Entretanto, eles não podem instalar novos pacotes nem alterar a configuração do servidor. Feitas as apresentações, vamos à configuração.

Invariavelmente, ao hospedar vários domínios, você precisa configurar um servidor DNS para responder por todos os domínios hospedados no servidor, entregando o endereço IP do seu servidor Apache. O cliente acessa então o servidor, solicitando o site desejado, como em “joao.com.br”; o servidor web verifica a configuração e entrega os arquivos apropriados ao cliente.

A configuração do servidor DNS é pouco intuitiva, mas não chega a ser tão complicada quanto muitos dizem. Em resumo, você precisaria instalar o bind no servidor e editar a configuração, adicionando uma nova configuração de zona para cada domínio hospedado. Isso é feito em duas etapas. Na primeira, você edita o arquivo named.conf, adicionando uma entrada com esta, especificando o domínio e o arquivo com a configuração:

zone “joao.com.br” IN {
type master;
file “/etc/bind/db.joao”;
allow-transfer { 64.234.23.13; };
};

Dentro do arquivo “/etc/bind/db.joao”, especificado no arquivo, iria uma configuração similar a esta, especificando o domínio, o nome do servidor e o endereço IP usado por ele, assim como o nome e o endereço IP do servidor DNS secundário:

@ IN SOA servidor.joao.com.br. hostmaster.joao.com.br. (
2008061645 3H 15M 1W 1D )
NS servidor.joao.com.br.
NS ns2.joao.com.br.
IN MX 10 servidor.joao.com.br.
joao.com.br. A 64.234.23.12
www A 64.234.23.12
ns1 A 64.234.23.13

Não é necessário que o DNS esteja instalado no mesmo servidor que o Apache, a função dele será unicamente responder às requisições dos clientes, fornecendo o IP correto. Vamos estudar a configuração do DNS em detalhes no próximo capítulo, dedicado unicamente ao assunto. Este foi apenas um exemplo rápido para que você tenha uma idéia geral sobre a configuração. Por enquanto, vamos nos concentrar na configuração do Apache propriamente dito.

Para ativar o uso dos virtual hosts, o primeiro passo é criar uma pasta separada para cada site que será hospedado. Você pode usar a própria pasta “/var/www”, como em:

# mkdir /var/www/joao
# mkdir /var/www/maria

Em seguida, é necessário adicionar uma nova seção dentro da configuração do Apache para cada um, logo depois da configuração do site default.

Nas distribuições derivadas do Debian, são usados arquivos de configuração separados para cada site, armazenados na pasta “/etc/apache2/sites-available”. Imagine que vamos hospedar os sites “www.joao.com.br” e “www.maria.com.br”, usando as duas pastas criadas anteriormente. Criaríamos, então, um arquivo para cada site, contendo o seguinte:

- /etc/apache2/sites-available/joao:

<VirtualHost *:80>
ServerAdmin joao@joao.com.br
ServerName www.joao.com.br
ServerAlias joao.com.br www.joao.com.br
DocumentRoot /var/www/joao
</VirtualHost>

- /etc/apache2/sites-available/maria:

<VirtualHost *:80>
ServerAdmin maria@gmail.com
ServerName www.maria.com.br
ServerAlias maria.com.br www.maria.com.br
DocumentRoot /var/www/maria
</VirtualHost>

Note que adicionei uma nova diretiva, a “ServerAlias”, que permite que o site seja acessado tanto com, quanto sem o “www”. A linha “ServerAdmin” é, na verdade, opcional, contém apenas o e-mail de contato do administrador do site.

A mesma configuração é usada se você quiser hospedar os sites usando subdomínios, como em “joao.gdhn.com.br” e “maria.gdhn.com.br”. Nesse caso, não usamos o “www” e, por isso, não precisamos da linha “ServerAlias”:

<VirtualHost *:80>
ServerAdmin hostmaster@gdhn.com.br
ServerName maria.gdhn.com.br
DocumentRoot /var/www/maria
</VirtualHost>

Depois de feita a configuração, ative ambos os sites usando o comando a2ensite, o que criará links para eles na pasta “/etc/apache2/sites-enabled”:

# a2ensite joao
# a2ensite maria

Para que a configuração funcione, é necessário editar também o arquivo “/etc/apache2/sites-available/default“, substituindo as linhas:

NameVirtualHost *
<VirtualHost *>

Por:

NameVirtualHost *:80
<VirtualHost *:80>

Essa configuração é necessária para que você possa ativar o suporte a SSL para os virtual hosts. Sem ela, além do SSL não funcionar, você precisaria modificar a configuração de cada um, usando sempre “<VirtualHost *>” ao invés de “<VirtualHost *:80>”.

Você pode adicionar quantos sites quiser usando esses mesmos passos. Sempre que alterar a configuração, é necessário atualizar a configuração do Apache. Nesse caso, o parâmetro “reload” é suficiente (o “force-reload” é necessário apenas ao ativar ou desativar módulos):

# /etc/init.d/apache2 reload

Além de configurar o servidor web, é preciso configurar também um servidor FTP ou SFTP, para que os usuários possam acessar os arquivos de suas respectivas pastas, a fim de atualizarem seus sites. A forma mais simples de fazer isso é criar um usuário para cada um e dar acesso a eles via FTP (mais adiante veremos como configurar o servidor FTP com o Proftpd). Outra opção é utilizar o SFTP, que permite acesso seguro. Veremos mais detalhes sobre ele no capítulo sobre o SSH.

Veja que as três coisas acabam se integrando: o Bind resolve os nomes de domínio, o Apache fornece as páginas e o FTP ou SFTP permite que os webmasters atualizem os sites.

Continuando, ao utilizar o Fedora, CentOS ou outra distribuição derivada do Red Hat, a configuração de todos os virtual hosts é adicionada na seção final do arquivo “/etc/httpd/conf/httpd.conf“, depois do “# Section 3: Virtual Hosts”. Procure pela seção “Virtual Hosts”, perto do final do arquivo, e descomente a linha:

NameVirtualHost *:80

A partir daí, você pode adicionar cada um dos sites hospedados no servidor usando a mesma configuração que vimos anteriormente, como em:

<VirtualHost *:80>
ServerName www.joao.com.br
ServerAlias joao.com.br www.joao.com.br
DocumentRoot /var/www/joao
</VirtualHost>

<VirtualHost *:80>
ServerName www.maria.com.br
ServerAlias maria.com.br www.maria.com.br
DocumentRoot /var/www/maria
</VirtualHost>

A principal diferença nesse caso é que para desativar um determinado site você precisa abrir novamente o arquivo de configuração e remover (ou comentar) a seção referente a ele, em vez de utilizar o “a2dissite”, como no Debian.

Depois de fazer alterações no arquivo, é necessário recarregar a configuração para que elas entrem em vigor:

# service httpd reload

Fazendo dessa forma, os logs de acessos serão misturados no log principal do Apache, o “/var/log/apache2/access.log”. Isso não é problema se você está utilizando o Google Analytics ou outra ferramenta externa para auditar os acessos dos sites (ou se simplesmente você não está preocupado em medir os acessos), mas é um grande obstáculo se você pretende usar o webalizer para gerar os relatórios de acesso.

Para que cada site tenha seus logs separados, você deve adicionar duas linhas adicionais, na configuração de cada virtual host, especificando a localização do arquivo que será usado. Você com certeza não gostaria que os logs ficassem disponíveis ao público, por isso é importante usar diretórios diferentes para os arquivos do site e para os logs, como em:

<VirtualHost *:80>
ServerAdmin joao@joao.com.br
ServerName www.joao.com.br
ServerAlias joao.com.br www.joao.com.br
DocumentRoot /var/www/joao/html
ErrorLog /var/www/joao/logs/error.log
CustomLog /var/www/joao/logs/access.log combined
</VirtualHost>

Você pode também salvar os logs na pasta de logs padrão do Apache, de forma a se beneficiar do rotacionamento automático de logs oferecido pelo logrotate. Nesse caso, você precisa apenas especificar um arquivo de log diferente para cada site, todos salvos dentro da pasta padrão, como em:

<VirtualHost *:80>
ServerAdmin joao@joao.com.br
ServerName www.joao.com.br
ServerAlias joao.com.br www.joao.com.br
DocumentRoot /var/www/joao/html
ErrorLog /var/log/apache2/joao.error.log
CustomLog /var/log/apache2/joao.access.log combined
</VirtualHost>

Note que, como todos os sites ficam hospedados no mesmo servidor, a única forma de chegar ao site desejado é fazendo o acesso através do domínio. Se você tentar acessar diretamente o IP do servidor, vai cair no site padrão (configurado através do arquivo “/etc/apache2/sites-available/default”), que, por padrão, usa o raiz da pasta “/var/www”. Esta página default pode ser usada para mostrar alguma publicidade da empresa responsável pelo servidor, ou uma lista dos sites hospedados, por exemplo.

Concluindo, caso queira ativar o suporte a SSL para algum dos virtual hosts, adicione a sessão referente ao SSL dentro da configuração de cada site, indicando corretamente a pasta do site e os arquivos de log. O SSL pode ser tanto ativado para o raiz do site, permitindo que os visitantes visualizem qualquer parte do site usando o “https://”, ou utilizar uma pasta separada, onde está a parte de comércio eletrônico do site, por exemplo, como em:

<VirtualHost *:443>
ServerName www.joao.com.br
DocumentRoot /var/www/joao/ssl
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/apache.pem
</VirtualHost>

Neste caso, ao acessar o “http://www.joao.com.br“, o visitante visualizará o conteúdo da pasta “/var/www/joao/html”, enquanto ao acessar o “https://www.joao.com.br“, visualizará a “/var/www/joao/ssl”.

Como vimos no tópico anterior, certificados SSL são válidos apenas para um domínio específico. Se você deseja oferecer suporte a SSL para vários subdomínios hospedados no servidor, a melhor opção é adquirir um certificado wildcard, que é valido para qualquer subdomínio dentro do domínio principal da sua empresa. Isso permite que você crie diversos virtual hosts, como “loja1.minhaempresa.com” e “loja2.minhaempresa.com”, utilizando o mesmo certificado.

Essa configuração manual funciona para pequenos servidores, que hospedam algumas dezenas ou centenas de páginas. Grandes serviços de hospedagem geralmente acabam desenvolvendo algum tipo de sistema para automatizar a tarefa. Nos serviços de hospedagem gratuita, por exemplo, onde o número de clientes é assustadoramente grande, as alterações são feitas de forma automática quando o visitante faz seu cadastro, geralmente através de um sistema escrito em PHP ou Java.

Conforme o número de usuários cresce e o espaço em disco no servidor começa a ficar escasso, você começará a sentir falta de um sistema de quotas, que limite o espaço que cada usuário pode usar. Para isso, consulte o tópico sobre quotas de disco, mais adiante.

 

 

Gerando estatísticas

O Webalizer é um gerador de estatísticas de acesso para o servidor web. O Apache, por si só, loga todos os acessos feitos ao servidor, incluindo as páginas acessadas, o tráfego gerado, os navegadores e os sistemas operacionais usados pelos clientes, entre outras informações úteis para entender os hábitos e interesses de seus visitantes.

Com o Apache funcionando, é simples instalar o Webalizer: procure pelo pacote “webalizer” dentro do gerenciador de pacotes. Ele é incluído em todas as principais distribuições. Nas derivadas do Debian, você pode instalá-lo via apt-get:

# apt-get install webalizer

Ao contrário do Apache, o Webalizer não é um serviço que fica residente, mas sim um executável que precisa ser chamado cada vez que quiser ver a página de estatísticas atualizada (assim como o Sarg, que vimos no capítulo sobre o Squid). Basta chamá-lo como root:

# webalizer

Por padrão, a página de estatísticas é armazenada na pasta “webalizer/”, dentro do seu servidor web. Se o Apache estiver configurado para armazenar as páginas dentro do diretório “/var/www”, então as estatísticas vão para a pasta “/var/www/webalizer”.

O arquivo de configuração do Webalizer é o “/etc/webalizer.conf“. É importante que você revise o arquivo de configuração, indicando pelo menos a localização correta do arquivo de log do Apache e alterando a pasta onde as estatísticas ficarão armazenadas, caso não queira que elas fiquem disponíveis ao público. Você pode armazená-las em uma pasta isolada no servidor web, como, por exemplo, “/var/webalizer”, de forma que elas fiquem disponíveis apenas localmente ou através de um script. As duas opções “essenciais” dentro do arquivo são:

LogFile /var/log/apache/access.log
OutputDir /var/www/webalizer

Para não precisar executar o comando “webalizer” manualmente sempre que precisar atualizar as estatísticas, você pode configurar o cron para executá-lo automaticamente uma vez por dia ou uma vez por hora. Para isso, basta criar um script dentro da pasta “/etc/cron.daily/” ou “/etc/cron.hourly/“, contendo o comando “webalizer“.

Todos os scripts colocados dentro dessas pastas são, respectivamente, executados todos os dias de manhã, ou uma vez por hora. Para que funcione, é importante verificar se o serviço “cron” ou “crond” está ativo. No caso do Debian, o script para execução do webalizer através do cron é criado automaticamente e configurado para ser executado uma vez por dia.

Em um servidor Apache com vários virtual hosts, é possível fazer com que o Webalizer gere estatísticas separadas para cada um, com uma configuração um pouco mais cuidadosa. Em primeiro lugar, você deve configurar o Apache para gerar arquivos de log separados para cada site hospedado, como no exemplo que vimos há pouco:

<VirtualHost *:80>
ServerAdmin joao@joao.com.br
ServerName www.joao.com.br
ServerAlias joao.com.br
DocumentRoot /var/www/joao/html
ErrorLog /var/www/joao/logs/error.log
CustomLog /var/www/joao/logs/access.log combined
</VirtualHost>

Configurando dessa forma, os logs do site “joao.com.br” ficarão armazenados no arquivo “/var/www/joao/logs/access.log”, os do “maria.com.br” no “/var/www/maria/logs/access.log” e assim por diante, sempre separados dos arquivos disponíveis ao público, que vão na pasta “html”.

O próximo passo é criar um arquivo de configuração do Webalizer separado para cada um. Para manter as coisas organizadas, crie o diretório “/etc/webalizer” e crie uma cópia do arquivo webalizer.conf original para cada site, dentro da pasta, como em:

# mkdir /etc/webalizer
# cd /etc/webalizer
# cp webalizer.conf joao.conf
# cp webalizer.conf maria.conf

Precisamos agora editar cada um dos arquivos, informando o arquivo de log, domínio e diretório onde ficarão armazenados os relatórios de cada site. No arquivo “/etc/webalizer/joao.conf”, por exemplo, você teria (além das outras linhas do arquivo padrão) as linhas:

LogFile /var/www/joao/logs/access.log
OutputDir /var/www/joao/html/webalizer
HostName joao.com.br

Depois de gerar os arquivos de configuração para todos os sites, falta fazer com que o Webalizer processe todos automaticamente. Uma forma rápida de fazer isso (dica do próprio FAQ do webalizer) é usar o comando:

# for i in /etc/webalizer/*.conf; do webalizer -c $i -q; done

Esse é, na verdade, um mini-script, que vai executar o Webalizer uma vez para cada arquivo “.conf” encontrado no diretório “/etc/webalizer”, gerando todas as estatísticas em uma tacada só. Para que o comando seja executado todos os dias automaticamente, coloque-o dentro de um script no diretório “/etc/cron.daily“.

No Debian, temos o script “/etc/cron.daily/webalizer“, que é criado automaticamente durante a instalação do pacote e se encarrega de gerar as estatísticas diariamente, lendo o arquivo “/etc/webalizer.conf”. Podemos modificá-lo para que ele leia também os arquivos dentro do diretório “/etc/webalizer”. Para isso, edite o arquivo e substitua as linhas:

# Run webalizer quietly
${WEBALIZER_BIN} -c ${WEBALIZER_CONF} -q
${WEBALIZER_BIN} -c ${WEBALIZER_CONF} -q ${nonrotatedlog}

Por:

# Run webalizer quietly
${WEBALIZER_BIN} -c ${WEBALIZER_CONF} -q
${WEBALIZER_BIN} -c ${WEBALIZER_CONF} -q ${nonrotatedlog}

for i in /etc/webalizer/*.conf; do ${WEBALIZER_BIN} -c $i -q; done
for i in /etc/webalizer/*.conf; do ${WEBALIZER_BIN} -c $i -q ${nonrotatedlog}; done

Um problema comum é como restringir o acesso às estatísticas, afinal, na maioria dos casos, elas não devem ficar disponíveis ao público. A solução mais simples nesse caso é usar um arquivo .htaccess, que permite restringir o acesso ao diretório, exigindo login e senha.

O primeiro passo é criar um arquivo de senhas, usando o comando “htpasswd“, que faz parte do pacote “apache2-utils” (o mesmo que utilizamos para gerar as senhas do Squid). O arquivo de senhas deve, preferencialmente, ser armazenado em uma pasta fora do diretório com os arquivos do site. Se possível, use um arquivo separado para cada site hospedado. Vou usar como exemplo a pasta “/etc/apache2/auth”:

# mkdir /etc/apache2/auth
# cd /etc/apache2/auth
# touch joao.auth
# htpasswd joao.auth joao

New password:
Re-type new password:

Aqui, criamos o arquivo “/etc/apache2/auth/joao.auth”, contendo o usuário “joao” e a senha digitada, armazenada de forma encriptada. Você pode armazenar vários logins no mesmo arquivo, executando o comando uma vez para cada usuário.

Com o arquivo de senhas criado, crie um arquivo de texto chamando “.htaccess” no raiz do diretório das estatísticas, contendo o seguinte:

AuthName “Acesso Restrito”
AuthType Basic
AuthUserFile /etc/apache2/auth/joao.auth
require valid-user

A linha “AuthName” contém o texto que será mostrado na tela de login exibida para o cliente, enquanto o “AuthUserFile” contém o arquivo de senhas gerado.

Concluindo, embora o webalizer ofereça bons recursos, o uso de relatórios de estatísticas locais está saindo um pouco de moda devido à popularização do Google Analytics, o serviço de geração de estatísticas oferecido pelo Google, que permite gerar estatísticas muito mais detalhadas e pode ser integrado ao AdSense e ao AdWords: http://www.google.com/analytics/.

Enquanto o Webalizer trabalha gerando os relatórios a partir das estatísticas do Apache, o Analytics os gera a partir de um pequeno javascript que é incluído nas páginas e executado diretamente pelos clientes. Isso faz com que os relatórios do Analytics acabem oferecendo números mais próximos da realidade, já que excluem o tráfego gerado pelos crawlers dos mecanismos de busca e outros tipos de tráfego automatizado, que acabam inflando bastante as estatísticas do Webalizer.

Um ponto negativo do Analytics é que ele não computa acessos de visitantes que bloqueiam a execução de javascript no navegador (como os visitantes usando a extensão NoScript do Firefox) ou que acessam o site usando navegadores primitivos, sem suporte a javascript, como no caso de muitos navegadores móveis.

Com isso, os números mostrados pelo Webalizer acabam sempre ficando bem acima dos acessos reais, enquanto os do Analytics ficam sempre um pouco abaixo. Como nenhuma das duas ferramentas é perfeita, muitos preferem simplesmente usar as duas.

Gestores de conteúdo e add-ons

Agora que já estudamos sobre a instalação do servidor LAMP e sobre a configuração dos virtual hosts, vamos a alguns exemplos de instalação de gestores de conteúdo que você pode instalar no servidor.

Com o MySQL instalado e o suporte a PHP ativo, você tem pronta a estrutura necessária para instalar os diversos scripts de fórum, chat, gestores de conteúdo e outros. A maioria destes scripts é simples de instalar, você precisa apenas criar uma base de dados no MySQL ou Postgre, copiar os arquivos para uma pasta dentro do servidor web e editar um arquivo (ou acessar uma página de configuração através do navegador) para incluir as informações sobre o servidor (base de dados a ser usada, login e senha, etc.) e concluir a configuração.

Note que, embora o Apache e o MySQL sejam bastante seguros, nada garante que os scripts desenvolvidos por terceiros também serão. De nada adianta ter um servidor web extremamente seguro, se o script de gerenciamento de conteúdo que você instalou tem um buffer overflow no campo de login que permite executar comandos arbitrários, obter a senha do servidor MySQL (que o script usa para fazer seu trabalho) ou fazer alterações no conteúdo do site.

O ponto fraco na segurança de qualquer site ou fórum é quase sempre a segurança do script usado. Não escolha qual usar pensando apenas na facilidade de uso. Investigue o histórico de segurança e, uma vez escolhido qual usar, fique de olho nas atualizações de segurança.

Para os exemplos, escolhi o phpBB, o WordPress e o Ruby on Rails. O phpBB é um sistema de fórum open-source que além de muito usado é surpreendentemente robusto e expansível; o WordPress é uma solução bastante flexível de gestor de conteúdo, que além de ser usado em blogs, pode ser adaptado para uso em diversas outras frentes, enquanto o Ruby on Rails é um meta-framework com muitos recursos, usado em um volume cada vez maior de sites com páginas dinâmicas e aplicativos web em geral.

Solucionando problemas com o charset

Um problema muito comum ao utilizar o Apache 2 sobre uma distribuição Linux recente é os caracteres acentuados das páginas hospedadas aparecerem trocados por interrogações, quadrados ou vírgulas em alguns navegadores, como nesse screenshot:

Isso acontece em situações onde os arquivos das páginas hospedadas no servidor foram salvos usando o charset ISO-8859-1 (ou outro dos charsets pré-unicode) e o servidor Apache está configurado para usar UTF-8, que é o default no Ubuntu e na maioria das distribuições atuais.

Para solucionar o impasse, você tem basicamente três opções. A primeira é especificar o charset correto no header de cada página do site, o que é feito adicionando uma tag “meta” dentro da seção “head” da página, como em:

<meta http-equiv=”Content-Type” content=”text/html; charset=UTF-8″ />
ou:
<meta http-equiv=”Content-Type” content=”text/html; charset=ISO-8859-1″ />

Algumas versões antigas do Internet Explorer entendem apenas a tag “http-equiv…”. Você pode adicioná-la também, de forma a manter compatibilidade com elas, como em:

<http-equiv=”Content-Type” content=”text/html; charset=utf-8″>

Continuando, a segunda opção é mudar a configuração do Apache para que ele passe a utilizar o ISO-8859-1 como charset padrão, em vez do UTF-8. Nas distribuições derivadas do Debian, isso é definido no arquivo “/etc/apache2/conf.d/charset“. Edite o arquivo, substituindo a linha:

AddDefaultCharset UTF-8

por:

AddDefaultCharset ISO-8859-1

Se, por acaso, o arquivo “/etc/apache2/conf.d/charset” não estiver disponível (ou a configuração não surtir efeito), edite o arquivo “/etc/apache2/apache2.conf“, descomentando (ou adicionando) a mesma linha.

No Fedora/CentOS a opção é incluída diretamente no arquivo “/etc/httpd/conf/httpd.conf” (perto do final do arquivo), basta substituir a linha “AddDefaultCharset UTF-8″ por “AddDefaultCharset ISO-8859-1″, assim como no Debian.

Se o servidor hospeda páginas escritas em português, é recomendável editar também a linha:

LanguagePriority en da nl et fr de el it ja ko no pl pt pt-br ltz ca es sv tw

… no “/etc/apache2/apache2.conf”, mudando a ordem das linguagens, de forma que o pt-br e o pt fiquem no início:

LanguagePriority pt-br pt en da nl et fr de el it ja ko no pl ltz ca es sv tw

Para que a configuração entre em vigor, é preciso fazer com que o Apache 2 recarregue a configuração:

# /etc/init.d/apache2 reload

ou:
# service httpd reload

O charset padrão do servidor é aplicado a todas as páginas onde o charset não é diretamente especificado na seção <head>, ajudando em casos em que você tem um grande volume de páginas antigas, onde o charset não é especificado.

Uma terceira opção, mais radical, seria mudar o charset de todas as páginas hospedadas (se você usa um gestor de conteúdo, muitas vezes esta opção estará disponível nas configurações) de “ISO-8859-1″ para “UTF-8″. Diversos editores de texto, incluindo o kwrite e o gedit, permitem trocar o charset usado, basta especificar qual quer usar nas configurações.

É possível também converter os arquivos diretamente, usando o comando “recode“, que está disponível nos repositórios de praticamente todas as distribuições que adotaram o uso do UTF8. Comece instalando o pacote, como em:

# apt-get install recode

ou:
# yum install recode

Para converter um arquivo, use o comando “recode -d ISO-8859-1..UTF-8″ seguido pelo arquivo a ser convertido, como em:

$ recode -d ISO-8859-1..UTF-8 arquivo.txt

Você pode também converter de uma vez diversos arquivos, como em:

$ recode -d ISO-8859-1..UTF-8 *.html

ou:
$ recode -d ISO-8859-1..UTF-8 *.php

O recode não salva cópias dos arquivos originais, por isso é importante que você sempre execute o comando sobre uma cópia dos arquivos, substituindo os arquivos originais só depois de verificar e testar. Concluindo, é possível também fazer o caminho inverso, convertendo arquivos de UTF-8 para ISO-8859-1, invertendo a sintaxe do comando, como em:

$ recode -d UTF-8..ISO-8859-1 *.html

A principal observação nesse caso é que o recode só consegue converter caracteres UTF-8 que possuem um correspondente dentro da codificação ISO-8859-1, por isso não deve ser usado em textos que incluam caracteres de línguas asiáticas, por exemplo.

Otimizando a configuração do Apache

Ao colocar um site no ar, seu objetivo é quase sempre fazer com que ele seja acessado pelo maior volume possível de visitantes. Entretanto, o sucesso tem um preço: o maior volume de requisições faz com que seu servidor web seja mais exigido e ele passe a consumir mais recursos da máquina. A partir de um certo ponto, o servidor passará a ficar saturado nos horários de maior acesso, tornando o acesso ao site lento e fazendo com que o site comece a perder visitantes.

Uma das soluções seria simplesmente atualizar o hardware do servidor, resolvendo o problema na base da força bruta. A segunda seria otimizar a configuração do Apache, fazendo com que ele trabalhe de forma mais eficiente. Não existe uma “configuração perfeita” para o Apache, já que a configuração ideal varia de acordo com o tipo de tráfego do site, mas aqui vão algumas dicas que podem ajudar.

Uma das configurações mais diretamente relacionadas à performance do servidor e ao consumo de memória é o número de instâncias do servidor httpd. O Apache é capaz de responder a um número indefinido de acessos simultâneos, de acordo com a velocidade do link e dos recursos da máquina. Para cada requisição simultânea, é necessário que exista uma instância do Apache carregada na memória.

Quando o cliente acessa uma página, ele monopoliza uma dessas instâncias abertas até que a requisição seja concluída, ou seja, até que a página seja carregada ou o arquivo baixado. Em horários de alta demanda, são abertas mais instâncias do servidor Apache, que vão sendo fechadas (para economizar memória) conforme os acessos diminuem.

Nos momentos de pico, o Apache precisa manter mais processos ativos, o que aumenta o consumo de memória no servidor. O uso de processamento, por sua vez, varia bastante de acordo com o tipo de páginas servidas. Páginas em PHP com código não otimizado, scripts em CGI ou servlets Java, por exemplo, podem consumir bastante processamento, fazendo com que o processador se torne um gargalo muito antes da memória RAM, enquanto páginas estáticas ou arquivos disponibilizados para download consomem pouco processamento, fazendo com que a memória RAM e a otimização do servidor sejam as principais prioridades.

Ajustando o número de processos

O primeiro passo é verificar se está sendo usado o módulo mpm-prefork (usado por default na maioria das distribuições) ou o módulo mpm-worker, já que ambos são configurados em seções diferentes do arquivo.

No caso das distribuições derivadas do Debian, as duas versões são disponibilizadas através de pacotes separados, de forma que você precisa apenas verificar qual dois dois está instalado, usando o comando “dpkg -l | grep apache”. Ele retornará uma lista como:

# dpkg -l | grep apache

ii apache2 2.2.3-4+etch4 Next generation, scalable, extendable web se
ii apache2-mpm-prefork 2.2.3-4+etch4 Traditional model for Apache HTTPD 2.1
ii apache2-utils 2.2.3-4+etch4 utility programs for webservers
ii apache2.2-common 2.2.3-4+etch4 Next generation, scalable, exten
ii libapache2-mod-fcgid 1.10-2 an alternative module compat with mod_fastcg
ii libapache2-mod-php5 5.2.0-8+etch11 server-side, HTML-embedded scri

No exemplo, podemos ver que está sendo usado o pacote “apache2-mpm-prefork”, que é justamente a versão usada por padrão.

O mpm-prefork é a versão tradicional do Apache, onde cada instância inicia um único thread e atende a uma única requisição por vez, isolando o processamento de cada página servida. Isso torna a operação do servidor mais estável e menos vulnerável a módulos ou páginas mal escritas, mas, em compensação, consome um pouco mais de memória RAM que o mpm-worker, onde cada instância do Apache pode abrir vários threads, de acordo com a necessidade.

Para pequenos servidores, onde você não precise necessariamente extrair cada gota de desempenho do servidor, o mpm-prefork é a escolha mais segura, mas em casos em que o servidor precise operar no limite, você pode realizar testes com o mpm-worker de forma a avaliar se a redução no consumo de memória é significativa.

Voltando à configuração, o número de instâncias abertas (ao usar o mpm-prefork) é determinada pela seção abaixo dentro do arquivo “/etc/apache2/apache2.conf“:

# prefork MPM
<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 150
MaxRequestsPerChild 0
</IfModule>

A opção “StartServers” determina o número padrão de instâncias do Apache que ficarão carregadas na memória, respondendo a requisições. Cada instância ocupa cerca de 7 MB de memória (variando de acordo com as opções de compilação usadas ao gerar o pacote e os módulos carregados), de forma que 5 instâncias consomem cerca de 35 MB de memória do servidor.

Além das instâncias principais, temos instâncias “reservas” (spares), que ficam disponíveis para absorver rapidamente picos de acesso, sem que o Apache tenha que perder tempo carregando mais instâncias para só depois começar a responder às requisições. As opções “MinSpareServers” e “MaxSpareServers” determinam o número mínimo e máximo de “reservas”, sendo que o número real flutua entre os dois parâmetros, de acordo com a demanda.

A opção “MaxClients” é a parede de concreto, o número máximo de conexões simultâneas que o Apache aceita manter abertas, independentemente da demanda. Quando esse número é atingido, o acesso ao site fica cada vez mais lento, pois cada novo visitante “entra na fila” e precisa esperar que uma das instâncias do Apache fique livre, antes de conseguir carregar cada página.

Essa configuração default do Apache é adequada a um site de baixa demanda, onde o servidor passa a maior parte do tempo atendendo a um pequeno volume de requisições simultâneas, mas recebe picos de tráfego esporadicamente. Por padrão, o servidor carregará apenas 5 processos, manterá mais 5 a 10 spares ativos e poderá carregar mais instâncias conforme necessário, até o limite máximo de 150 instâncias permitidas.

Para um servidor dedicado, que hospede um site com muitas visitas, é interessante ajustar estes valores de acordo com a demanda. Uma forma fácil de verificar o status do servidor é ativar a diretiva “server-status” dentro do arquivo “/etc/apache2/apache2.conf”. Adicione as linhas abaixo no final do arquivo:

<Location /server-status>
SetHandler server-status
Order deny,allow
Deny from all
Allow from 200.234.23.233
# (onde o 200.234.23.233 é o IP de onde o relatório será acessado)
</Location>

Ative a configuração usando o comando “/etc/init.d/apache2 reload”. A partir daí, você pode ver um instantâneo do status do servidor acessando a pasta “server-status”, como em “http://www.gdhn.com.br/server-status“, a partir do navegador.

A oitava linha indica o número de instâncias abertas, como em:

8 requests currently being processed, 5 idle workers

Nesse exemplo temos 8 conexões abertas e 5 instâncias reservas do Apache abertas, prontas para receber novas conexões. A velocidade do acesso ao site está normal. Mas, o que acontece no caso de um pico de acesso, com mais do que 150 acessos simultâneos? Na configuração padrão você teria:

150 requests currently being processed, 0 idle workers

Ou seja, o Apache responde às primeiras 150 conexões e coloca as demais na fila, fazendo com que os visitantes precisem esperar até que algum dos processos abertos termine de atender o visitante anterior antes de servirem a requisição. Nesse ponto o acesso ao site começa a ficar lento, com as páginas demorando mais e mais para começarem a ser carregadas. Em casos mais extremos, o tempo de espera poderia ser tamanho que o site ficaria virtualmente fora do ar. É o que muitas vezes acontece com links publicados em sites muito acessados, como o slashdot.org.

Isso pode ser minimizado de duas formas. A primeira é aumentando o número de instâncias ativas do Apache (de forma que o servidor tenha instâncias suficientes para atender a todas as requisições sem precisar abrir novos processos) e aumentando o valor configurado na opção “MaxClients”, de forma que o servidor possa atender a um volume maior de requisições nos horários de pico.

Os valores ideais variam de acordo com o volume de memória disponível no servidor e a quantidade de memória usada por cada processo do Apache. Comece usando o comando “ps -ylC apache2 –sort:rss” (no Debian/Ubuntu) ou “ps -ylC httpd –sort:rss” (no Fedora/CentOS) para verificar o volume de memória usado por cada instância do Apache:

# ps -ylC apache2 –sort:rss

O comando exibe uma linha para cada processo do Apache ativo, de forma que a lista pode ser longa. O volume de memória gasto por cada um (em kbytes) é mostrado na oitava coluna. Descartando as primeiras e as últimas linhas, você tem uma boa aproximação dos valores médios, como em:

S 33 17530 16102 0 78 0 6008 5038 341548 ? 00:00:00 apache2
S 33 17491 16102 0 75 0 6036 5036 354540 ? 00:00:00 apache2
S 33 17529 16102 0 75 0 6036 5038 357283 ? 00:00:00 apache2
S 33 17472 16102 0 75 0 6044 5038 359161 ? 00:00:00 apache2
S 33 17438 16102 0 75 0 6056 5036 351130 ? 00:00:00 apache2

Veja que no exemplo cada processo consome aproximadamente 6 MB de memória RAM. Estes valores não devem ser levados ao pé da letra, pois o ps não leva em conta as áreas de memória compartilhadas entre os processos (como vimos no capítulo 1), de forma que na prática o consumo total é sempre um pouco mais baixo. De qualquer forma, estes são os melhores números que temos.

O próximo passo é verificar quanto os demais serviços ativos no servidor (MySQL, servidor de e-mails, etc.) consomem, de forma a ter uma estimativa de quanta memória está disponível para uso do Apache. Uma forma simples de fazer isso é desativar temporariamente o Apache (/etc/init.d/apache2 stop) e usar o comando “free” para ver a memória disponível, como em:

# free

total used free shared buffers cached
Mem: 127132 124640 2492 0 40732 45236
-/+ buffers/cache: 35804 91328
Swap: 409616 48 409568

A linha “Mem” mostra o total de memória usada, incluindo o cache de disco. Ela sempre mostra que quase toda a memória está ocupada, pois é normal que o sistema utilize a memória disponível para fazer cache de disco. O que realmente nos interessa é a segunda linha (-/+ buffers/cache), que no exemplo mostra que o servidor possui cerca de 90 MB de memória disponível (nesse exemplo estou usando um VPS com apenas 128 MB de memória, que serve como exemplo de servidor com poucos recursos).

Se cada processo do Apache ocupa cerca de 6 MB de memória, significa que o servidor poderia manter de 15 a 18 instâncias carregadas na memória (levando em conta que o consumo real é sempre um pouco inferior ao mostrado pelo ps) antes de começar a usar um volume significativo de memória swap. Uma boa configuração nesse caso seria:

# prefork MPM
<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 18
MaxRequestsPerChild 0
</IfModule>

Permitir que o Apache abra mais instâncias acabaria sendo contra produtivo, pois o uso de muita memória swap derrubaria o desempenho do servidor, fazendo com que cada instância demorasse mais para processar cada página. Com isso, o número total de páginas servidas acabaria sendo menor do que usando apenas 18 processos.

No caso de um servidor com 1 GB de memória RAM, por outro lado, provavelmente teríamos 900 MB ou mais de memória disponível para o Apache, de forma que uma configuração mais adequada seria:

# prefork MPM
<IfModule mpm_prefork_module>
StartServers 25
MinSpareServers 25
MaxSpareServers 50
MaxClients 200
MaxRequestsPerChild 0
</IfModule>

Com isso, teríamos 25 processos “fixos” do Apache, complementados por mais 25 a 50 spares, número que pode crescer até um máximo de 200 processos simultâneos nos horários de pico. A partir daí, você poderia monitorar o volume de memória livre no servidor (através do comando “free”) e o volume de acessos através da página de estatísticas e ajustar as opções “StartServers” e “MinSpareServers” de acordo com o número médio de acessos simultâneos, de forma que o número de processos do Apache e de spares disponíveis seja sempre um pouco maior do que o número médio de conexões ao servidor:

 

 

 

 

Outras opções

A opção “MaxRequestsPerChild”, incluída logo depois no arquivo, limita o número de requisições que cada processo do Apache pode responder antes de ser encerrado e substituído por outro. Ela não tem um efeito direto sobre o desempenho, servindo apenas como uma proteção contra eventuais vazamentos de memória, que pudessem fazer o processo crescer até ocupar toda a memória do servidor. Uma boa configuração é o valor “1000″, que evita que os processos sejam fechados muito freqüentemente (o que prejudicaria o desempenho), mas ao mesmo tempo faz com que a opção atenda a seu propósito:

MaxRequestsPerChild 1000

Como de praxe, a solução definitiva para melhorar o desempenho do servidor, permitindo que ele atenda a mais requisições simultâneas, é instalar mais memória RAM, de forma que ele possa manter mais instâncias do Apache carregadas na memória e possa fazer mais cache de disco (reduzindo o volume de operações de leitura no HD). É importante monitorar constantemente o uso de memória do servidor e atualizar o servidor conforme necessário.

Outra opção que afeta negativamente o desempenho é a “HostNameLookups”, que faz com que o Apache verifique a origem de cada acesso, fazendo uma busca de domínio. Ativar essa opção permite criar estatísticas de acesso mais detalhadas, incluindo os países e provedores de acesso usados pelos visitantes, mas tem um impacto negativo muito grande na performance de um servidor congestionado. No Apache 2 ela já vem desativada por padrão, mas em versões antigas era necessário desativá-la manualmente:

HostNameLookups Off

Se você faz questão de gerar estatísticas de acesso detalhadas, pode obter o mesmo resultado usando o “logresolve”, um aplicativo que realiza as operações de resolução de nomes diretamente nos arquivos de log. Você pode criar um script para fazer com que ele seja executado uma vez por dia, por exemplo. A sintaxe do comando é a seguinte:

# logresolve -s access.stats -c < access.log > access_log.new

No exemplo, o “access.log” é o arquivo original de log, o “access_log.new” é o arquivo modificado que será gerado e o “access.stats” é o arquivo onde serão salvas as estatísticas.

Continuando, se o seu servidor já está operando no limite, recebendo mais requisições do que consegue atender nos horários de pico, uma foma simples de reduzir o carregamento do servidor é ajustar a opção “KeepAliveTimeout”, que determina o tempo que os processos do Apache devem aguardar por novas requisições do mesmo cliente antes de serem finalizadas.

A idéia por trás dessa opção é permitir que a mesma conexão TCP seja usada para enviar diversos arquivos, se possível toda a página que está sendo carregada, incluindo as imagens. Com isso, o tempo de carregamento é reduzido (já que não é mais necessário abrir uma nova conexão para cada elemento da página a ser carregado) e os processos do Apache ficam logo livres para responder a outras requisições.

O default são 15 segundos, o que é um valor seguro, já que mesmo as conexões mais lentas não chegam a ter um tempo de latência tão alto. O problema é que o tempo de espera faz com que os processos fiquem ativos na memória por até 15 segundos a mais do que realmente precisariam, consumindo memória e reduzindo o número de clientes simultâneos que o servidor pode atender.

Você pode aumentar de forma considerável o volume de requisições atendidas pelo servidor reduzindo o valor de 15 para 3 segundos. Um exemplo de configuração completa é:

KeepAlive On
MaxKeepAliveRequests 180
KeepAliveTimeout 3

A opção “KeepAlive On” deve estar presente, já que é ela a responsável por ativar o recurso. A opção “MaxKeepAliveRequests” determina o número máximo de conexões que devem ser mantidas ativas. Ela deve ser setada com um valor um pouco mais baixo que o da opção “MaxClients”, que vimos anteriormente.

Concluindo, você pode simular tráfego no seu servidor, verificando como ele se comporta com níveis variados de tráfego usando o comando “ab”, que faz parte do pacote “apache2-utils”. Chame-o indicando o número de requisições simultâneas e a página que será carregada, como em:

$ ab -n 1000 -c 20 http://www.meusite.com/teste.php

 

Nesse exemplo, estamos fazendo 1000 acessos à página, mantendo 20 requisições simultâneas. Se possível, lance o teste a partir de outro servidor com link rápido, ou peça para vários amigos rodarem o comando simultaneamente, cada um usando sua própria conexão. Isso transformará o teste em algo mais parecido com uma situação normal, onde o servidor receba um pico de acessos.

Uma opção que não tem a ver com o desempenho, mas que ajuda a reduzir o volume de ataques casuais contra o seu servidor é a opção “ServerTokens”. Na maioria das distribuições, ela vem configurada com o valor “Full”, que faz com que seu servidor disponibilize informações detalhadas sobre a versão do apache e os módulos utilizados, como “Apache/2.2.3 Debian PHP/5.2.0-8etch11″, o que facilita bastante o trabalho dos atacantes. Você pode evitar isso configurando a opção com o valor “Prod”, que faz com que o servidor responda apenas “Apache”, sem nenhum detalhe adicional (caso a linha não esteja presente, basta adicioná-la no final do arquivo):

ServerTokens Prod

Outra configuração importante é bloquear o acesso a includes e arquivos de configuração em geral colocados dentro dos diretórios de dados do site. Isso evitará que arquivos .inc, .tpl, .sql e de outras extensões tipicamente usadas em arquivos de configuração e em includes usados na montagem das páginas possam ser acessados diretamente pelos visitantes. Para isso, inclua na configuração uma seção “filesmatch”, especificando as extensões cuja exibição deve ser bloqueada, como em:

<filesmatch “\.(inc|tpl|h|ihtml|sql|ini|conf|bin|spd|sh|theme|module)$”>
Deny from all
</filesmatch>

Depois de terminar a edição do arquivo “/etc/apache2/apache2.conf”, não se esqueça de aplicar as alterações usando o comando:

# /etc/init.d/apache2 reload

ou:
# service httpd reload

Módulos do Apache e add-ons

Como comentei no início do capítulo, o principal ponto forte do Apache é o grande volume de módulos disponíveis para ele. Sempre que você precisa de algum recurso em especial, o primeiro passo é fazer uma pesquisa na web por algum módulo que desempenhe a função desejada. Se o recurso que precisa for uma necessidade comum, muito provavelmente você encontrará um módulo já pronto que se propõe a resolver o problema.

Como tanto o servidor Apache quanto a maior parte dos módulos disponíveis são open-source, existe também a possibilidade de modificar módulos já existentes, adicionando novas funções ou adaptando-os ao que precisa, ou mesmo desenvolver novos módulos do zero. Aqui vão alguns exemplos de módulos comumente usados, que você provavelmente vai querer manter ativos no servidor:

 

mod_rewrite

O mod_rewrite tem a função de reescrever URLs a partir de um conjunto de parâmetros especificado por você. O uso mais simples para ele é quando você muda o domínio de acesso do site e quer que todos os links sejam redirecionados para o novo endereço.

Imagine, por exemplo, que você migrou do http://dominio.provedor.com.br para http://www.dominio.com.br. Você poderia simplesmente criar um arquivo “index.php” no diretório raiz do antigo endereço com o seguinte conteúdo:

<?php
header(“HTTP/1.1 301 Moved Permanently”);
header(“location:http://www.dominio.com.br“);
exit;
?>

Este é um modelo simples de redirecionamento, que faz com que o servidor passe a encaminhar os acessos para o endereço especificado, usando o código 301, que indica que a página mudou permanentemente de endereço.

O problema é que fazendo isso o redirecionamento funcionaria apenas para os visitantes que acessassem a página principal do site. Um visitante que tentasse acessar o “http://dominio.provedor.com.br/produtos/index.php?id=312“, por exemplo, receberia um erro 404.

Usando o mod_rewrite, você poderia solucionar isso de forma muito simples. O primeiro passo é verificar se o módulo está carregado na configuração do Apache 2. No caso das distribuições derivadas do Debian, você pode ativá-lo usando o comando a2enmod:

# a2enmod rewrite

Muito provavelmente você receberá um “This module is already enabled!” como resposta, já que ele vem ativo por padrão na maioria das instalações. No caso do Fedora, CentOS e outras distribuições derivadas do Red Hat, verifique o arquivo “/etc/httpd/conf/httpd.conf” e, caso necessário, descomente as linhas:

LoadModule rewrite_module modules/mod_rewrite.so
AddModule mod_rewrite.c

Depois de checar a ativação do módulo, falta apenas a configuração, que é feita através do arquivo “.htaccess“, criado no diretório raiz do site antigo (ou seja, na pasta de arquivos do “http://dominio.provedor.com.br”). Embora o .htaccess seja geralmente associado com o uso de senhas, ele na verdade tem diversos outros usos, incluindo a configuração do mod_rewrite.

Para que o mod_rewrite passe a encaminhar todas as requisições automaticamente, o conteúdo do arquivo “.htaccess” seria:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule (.*) http://www.dominio.com.br/$1 [R=301,L]
</IfModule>

A linha “RewriteEngine On” é a responsável por encaminhar as requisições ao mod_rewrite, enquanto a linha “RewriteRule (.*) http://www.dominio.com.br/$1 [R=301,L]” explica o que deve ser feito.

Apesar de parecer estranha à primeira vista, ela segue na verdade uma lógica bastante simples. O “(.*)” cria uma regra de encaminhamento, que será aplicada a qualquer URL dentro do domínio. A página especificada pelo visitante ao acessar o site vira uma variável ($1), que é então usada no parâmetro seguinte, o “http://www.dominio.com.br/$1” onde é indicado o novo domínio do site.

Com isso, se o visitante tentar acessar o “http://dominio.provedor.com.br/produtos/index.php?id=312” do exemplo anterior, a variável “$1″ será carregada com o valor “produtos/index.php?id=312″ e ele será encaminhado ao “http://www.dominio.com.br/produtos/index.php?id=312“. O mesmo se aplica a qualquer outra URL que ele vier a tentar acessar.

Concluindo, o “[R=301,L]” é o código de retorno que será enviado ao cliente. No caso estamos usando o código 301, que é o código de redirecionamento permanente. Além de encaminhar os visitantes, ele faz com que o Google indexe a nova página e transfira o pagerank da página antiga para ela. Normalmente, a atualização do pagerank demora cerca de 3 meses, mas depois de feita a atualização o novo endereço deverá receber o mesmo pagerank do antigo.

Outro uso comum para o mod_rewrite é a simplificação dos links, transformando URLs de páginas dinâmicas, como, por exemplo, “http://www.dominio.com.br/produtos/index.php?id=312” em URLs mais simples, como “http://www.dominio.com.br/produtos/312/” ou “http://www.dominio.com.br/312.htm“

Nesse caso, criamos regras do rewrite que o orientam a detectar acessos à URL simplificada e encaminhar as requisições para a URL “real” de forma transparente, novamente através do uso de variáveis.

Para converter as URLs do formato “http://www.dominio.com.br/index.php?id=numero” para “http://www.dominio.com.br/numero/”, você usaria o seguinte modelo de arquivo .htaccess:

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteRule (.*)/$ /index.php?id=$1
</IfModule>

Com isso, ao acessar o “http://www.dominio.com.br/512/“, por exemplo, o visitante veria a página “http://www.dominio.com.br/index.php?id=512“, o que mascara a complexidade da URL. Se você preferir que os links abreviados tenham a aparência de páginas com extensão .htm, em vez de pastas, o arquivo .htaccess ficaria:

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteRule (.*)\.htm$ /index.php?id=$1
</IfModule>

A mesma regra pode ser aplicada também a pastas específicas. Se você quiser que ela se aplique apenas à pasta “produtos”, sem ser aplicada a outras pastas do servidor, por exemplo, você poderia usar uma regra como:

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteRule /produtos/(.*)\.htm$ /produtos/index.php?id=$1
</IfModule>

É possível também usar diversos parâmetros simultaneamente, facilitando o acesso a URLs que incluam um grande volume de argumentos, como em “http://www.dominio.com.br/index.php?cat=produtos&cat=info&id=23“, desde que você consiga bolar um formato de URL que permita incluir todos os parâmetros necessários, como em:

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteRule (.*)/(.*)/(.*)/$ /index.php?cat=$1&cat=$2&id=$3
</IfModule>

Com isso, os três parâmetros que precisam ser incluídos na URL são digitados pelo usuário na forma de uma sequência de subpastas, como em “http://www.dominio.com.br/produtos/info/23/” e o mod_rewrite converte automaticamente as URLs ao formato usado pelo servidor.

À primeira vista, pode parecer uma mera mudança cosmética, mas o uso das URLs amigáveis facilita bastante a navegação do visitante e pode ajudar até mesmo na indexação por parte dos mecanismos de busca.

mod_deflate

O mod_deflate permite comprimir de forma automática as páginas html (e também outros tipos de arquivos) enviados aos clientes, de forma a economizar banda e a reduzir o tempo de carregamento das páginas. Se os sites hospedados no servidor utilizam páginas com grandes volumes de texto, a redução pode ser bastante significativa.

O uso de compressão é negociado entre o servidor e o cliente no momento em que ele requisita a página, de forma que você não precisa se preocupar em excluir navegadores móveis ou clientes com browsers antigos. Ao perceber que o cliente não suporta o recurso, o servidor simplesmente envia a página sem compressão.

O uso do deflate aumenta sutilmente o uso de processamento no servidor, já que ele terá o trabalho de comprimir cada página solicitada antes de enviá-la ao cliente, mas isso é compensado pelo fato de o cliente demorar menos tempo para carregar cada página, o que permite que o servidor mantenha um número menor de instâncias do Apache carregadas na memória.

Do ponto de vista do cliente, o deflate é bastante benéfico, pois o texto das páginas carrega mais rápido. Uma página html comprimida pelo deflate fica com, tipicamente, um quarto do tamanho original. Com isso, uma página de 100 KB, que demoraria até 15 segundos para ser carregada por um cliente acessando via modem, passaria a ser carregada em apenas 3 ou 4 segundos. Depois disso, ainda teríamos o tempo de carregamento das imagens e de outros elementos da página, como de praxe, mas com o html carregado o cliente pode já ir adiantando a leitura.

Note que, as “páginas em html” que citei no parágrafo anterior, incluem também páginas dinâmicas em php e em outras linguagens, pois, de qualquer forma, depois de serem processadas pelo servidor, elas são enviadas ao cliente como uma página html.

Nas distribuições derivadas do Debian, o módulo é ativado usando o a2enmod:

# a2enmod deflate

Nas distribuições derivadas do Red Hat, verifique se a linha a seguir está presente dentro da seção “Dynamic Shared Object (DSO) Support” do arquivo “/etc/httpd/conf/httpd.conf“. Adicione-a manualmente caso necessário (não se esqueça de reiniciar o Apache para que a configuração entre em vigor):

LoadModule deflate_module modules/mod_deflate.so

Esta linha tem exatamente a mesma função desta outra, usada em algumas distribuições. A única diferença é que neste segundo exemplo é especificado o caminho completo até o arquivo: LoadModule deflate_module /usr/lib/apache2/modules/mod_deflate.so Em seguida, vem a configuração do módulo. No Debian, a configuração vai no arquivo “/etc/apache2/mods-available/deflate.conf“, enquanto do CentOS e no Fedora é usado o arquivo “/etc/httpd/conf.d/httpd-deflate.conf“.

Uma configuração simples, e bastante usada, é fazer com que o deflate comprima apenas arquivos em html, texto puro ou xml, sem tentar comprimir outros tipos de arquivos (como imagens ou arquivos diversos disponibilizados para download, que via de regra já estarão compactados). Esta configuração exige uma única linha e é a configuração padrão no Debian:

<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/xml
</IfModule>

Outra abordagem é orientar o deflate a comprimir todos os tipos de arquivos, com exceção das imagens em .gif, .png e .jpg. Isso pode ser interessante se, além das páginas html, você disponibiliza arquivos em formatos com baixos índices de compressão, como arquivos do MS Office, por exemplo. Nesse caso, a configuração ficaria:

<IfModule mod_deflate.c>
# Comprime tudo, com exceção de arquivos .gif, .jpg e .png:
SetOutputFilter DEFLATE
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary
</IfModule>

Note que esta configuração deve ser usada apenas em casos específicos, pois ela faz com que o servidor tente comprimir todo tipo de arquivos, incluindo arquivos em formatos já compactados, o que resultará em um grande aumento no uso de processamento, sem que haja uma redução tangível no tamanho dos arquivos.

Concluindo, uma recomendação geral é incluir exceções para versões antigas do Netscape 4 e do IE 3 que não são capazes de negociar a compressão de páginas com o servidor corretamente. Estes navegadores são extremamente raros hoje em dia, por isso mesmo os sites movimentados não recebem mais do que um punhado de visitas diárias de clientes utilizando um deles, mas não custa deixar o servidor preparado para atender a esses casos específicos. Para isso, são incluídas três linhas adicionais na configuração:

<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/xml
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
</IfModule>

mod_cband

O mod_cband permite limitar o uso de banda ou o número de requisições simultâneas atendidas pelos sites hospedados no Apache. Como você pode imaginar, ele é extremamente popular em serviços de shared hosting, já que permite limitar o volume de banda utilizado por cada site (ou por cada usuário que acessa o servidor) e estabelecer quotas de tráfego.

Nas distribuições derivadas do Debian, ele pode ser instalado através do pacote “libapache2-mod-cband”, como em:

# apt-get install libapache2-mod-cband

Com o módulo instalado, use o comando a2enmod para ativá-lo:

# a2enmod cband

No CentOS, é necessário instalar o pacote a partir do código fonte. Comece instalando o pacote “httpd-devel” usando o yum:

# yum install httpd-devel

Em seguida, baixe a versão mais recente do pacote no: http://sourceforge.net/projects/cband/

Para instalar, descompacte o arquivo, acesse o diretório que será criado e rode os comandos “./configure”, “make” e “make install”, como em:

# tar -zxvf mod-cband-0.9.6.1.tgz
# cd mod-cband-0.9.6.1
# ./configure
# make
# make install

O script de instalação se encarrega de instalar o módulo na pasta “/usr/lib/httpd/modules/” e adicionar uma linha similar à linha a seguir no arquivo “/etc/httpd/conf/httpd.conf”, de forma que ele seja carregado:

LoadModule cband_module /usr/lib/httpd/modules/mod_cband.so

Falta agora apenas editar a configuração de cada virtual host, definindo os limites desejados, como em:

<VirtualHost *:80>
ServerAdmin joao@joao.com.br
ServerName www.joao.com.br
ServerAlias joao.com.br
DocumentRoot /var/www/joao
CBandSpeed 1024kbps 10 20
CBandRemoteSpeed 512kbps 5 3
</VirtualHost>

A opção “CBandSpeed” determina os limites para o tráfego total do site, especificando o volume máximo de banda que pode ser usado, o número máximo de requisições de páginas e/ou arquivos por segundo e o número máximo de instâncias do Apache que podem ser utilizadas. No exemplo, limitei o tráfego do site a 1024 kbps, com um máximo de 10 requisições por segundo e um máximo de 20 conexões simultâneas.

Em seguida, temos a opção “CBandremoteSpeed”, que permite definir limites individuais para os visitantes, impedindo que um único usuário monopolize toda a banda disponível (pense no caso de um site que disponibiliza arquivos para download, por exemplo). No exemplo, cada usuário ficará limitado a um máximo de 256 kbps, com até 3 requisições por segundo e um máximo de três conexões simultâneas.

Como acabamos de ativar o módulo, é necessário reiniciar o Apache para que as alterações entrem em vigor, mas, quando você for apenas alterar os limites posteriormente, pode usar o “reload” para atualizar a configuração sem derrubar o servidor.

# /etc/init.d/apache2 force-reload

A partir daí, você pode verificar a aplicação dos limites simplesmente baixando um arquivo disponível no site. A taxa de transferência vai variar ao longo do download, ficando um pouco acima ou um pouco abaixo do estabelecido, mas na média a transferência não ultrapassa a quota estabelecida:

Nesse primeiro exemplo, estabelecemos apenas um limite de uso de banda e um número máximo de requisições simultâneas, mas não estabelecemos nenhum limite de tráfego, de forma que o webmaster do site poderia utilizar quanta banda quisesse, ficando restrito apenas ao limite total de 1024 kbps, de forma similar a uma conexão doméstica.

Os 1024 kbps estabelecidos podem parecer pouco, mas se eles forem utilizados 24 horas por dia, 7 dias por semana (pense no caso de um site de downloads), o site consumirá no final do mês um tráfego total de pouco mais de 300 GB. Se o mesmo limite for aplicado a todos os sites hospedados, teremos uma situação onde o acesso por parte dos visitantes será relativamente lento (apenas 512 kbps por visitante) e que não impedirá que os sites que hospedem predominantemente arquivos consumam um volume considerável de banda.

Outra questão importante é que limitando as taxas de download de cada usuário, os downloads demorarão mais tempo, o que fará com que cada instância do Apache fique mais tempo atendendo ao mesmo cliente, aumentando o consumo de memória do servidor.

Devido a essas desvantagens, a restrição com base no uso de banda tem se tornado menos comum, dando lugar a quotas de tráfego. No novo modelo, o site pode consumir quanta banda precisar, desde que não ultrapasse uma determinada quota de tráfego mensal.

Para definir a quota de tráfego, o primeiro passo é criar uma pasta onde o cband armazenará informações sobre o tráfego usado por cada host. Você pode tanto criar uma pasta dentro do diretório do site e restringir o acesso a ela quanto criar uma pasta em outro diretório do sistema. O mais importante é que você ajuste as permissões de acesso, de forma que o dono seja o usuário usado pelo Apache (“www-data” no Debian, ou “apache” no CentOS), como em:

# mkdir /var/www/scoreboard
# chown www-data:www-data /var/www/scoreboard/

ou:
# mkdir -p /var/spool/cband/scoreboard
# chown apache:apache /var/spool/cband/scoreboard

Dentro desse diretório, criamos um arquivo vazio para cada site onde formos ativar o cband, novamente dando a posse para o usuário usado pelo Apache, como em:

# touch /var/www/scoreboard/joao
# chown www-data:www-data /var/www/scoreboard/joao

Em seguida, precisamos alterar a configuração dos sites (dentro da pasta “/etc/apache2/sites-available” ou dentro do arquivo “/etc/httpd/conf/httpd.conf”), especificando a nova configuração, como em:

<VirtualHost *:80>
ServerAdmin joao@joao.com.br
ServerName www.joao.com.br
ServerAlias joao.com.br
DocumentRoot /var/www/joao
CBandLimit 100G
CBandPeriod 4W
CBandScoreboard /var/www/scoreboard/joao
CBandExceededURL http://provedor.com/quota_excedida.htm
</VirtualHost>

Como você pode imaginar, a opção “CBandLimit” especifica a quota de tráfego do site, que no exemplo foi definida como 100 GB (além do “G” você pode especificar o volume em “M”, de megabytes ou “K”, de kbytes).

A linha seguinte, “CBandPeriod”, determina o período de aplicação da quota, depois do qual a contagem é zerada. No exemplo usei “4W”, que especifica um período de 4 semanas, ou seja, 28 dias. Você poderia usar outros valores, como por exemplo “30D” (30 dias) ou “24H” (24 horas).

Em seguida, temos a opção “CBandScoreboard”, que indica o arquivo onde serão armazenadas as informações sobre o uso de banda do site (que criamos no passo anterior) e a CBandExceededURL, que permite especificar uma página de erro, que será exibida aos visitantes dos sites que ultrapassarem a quota de tráfego. Esta página continua sendo exibida (deixando o site essencialmente fora do ar) até o início do próximo período, quando a contagem é zerada.

O uso da página de erro não é muito bem visto entre os webmasters, pois faz com que o site fique fora do ar, fazendo com que visitas sejam perdidas e que as páginas percam posições nos mecanismos de busca. Em vez de tirar as páginas do ar, você pode simplesmente reduzir a velocidade de acesso, substituindo a opção “CBandExceededURL” pela “CBandExceededSpeed”, como em:

<VirtualHost *:80>
ServerAdmin joao@joao.com.br
ServerName www.joao.com.br
ServerAlias joao.com.br
DocumentRoot /var/www/joao
CBandLimit 100G
CBandPeriod 4W
CBandScoreboard /var/www/scoreboard/joao
CBandExceededSpeed 256kbps 3 5
</VirtualHost>

Nesse caso, ao ultrapassar a quota o site ficará limitado a 256 kbits, com direito a três requisições por segundo e um máximo de cinco requisições simultâneas. Ou seja, continuará no ar, mas o acesso ficará bastante lento (você pode ajustar os limites de acordo com a situação). Em um serviço comercial, o ideal seria combinar a aplicação da quota com o envio de um e-mail de aviso, explicando que a quota foi excedida e oferecendo a possibilidade de migrar para um plano com uma quota maior.

É possível também combinar o uso da limitação de banda e de conexões simultâneas com o uso da quota mensal, evitando assim que os sites consumam a quota muito rapidamente, prejudicando o desempenho dos outros sites hospedados no servidor. Nesse caso, combinamos as opções que acabamos de ver com as opções CBandSpeed e CBandRemoteSpeed, como em:

CBandLimit 100G
CBandPeriod 4W
CBandScoreboard /var/www/scoreboard/joao
CBandExceededSpeed 256kbps 3 5

CBandSpeed 1024kbps 10 20
CBandRemoteSpeed 512kbps 5 3

Depois de definidas as quotas, você pode concluir a configuração ativando o relatório de tráfego oferecido pelo cband. O relatório é atualizado em tempo real, mostrando detalhes sobre o uso de banda e o percentual da quota já consumido, permitindo que o próprio webmaster do site acompanhe e administre o tráfego do site e não seja pego de surpresa quando a quota for ultrapassada.

O cband oferece dois painéis de administração separados, um feito para ser acessado pelos usuários (o cband-status-me) e outro para uso do administrador (cband-status), que permite ver o tráfego de todos os sites e resetar os contadores de tráfego manualmente.

Para disponibilizar o painel de usuário, você adicionaria a entrada a seguir dentro da configuração do virtual host, logo depois das demais linhas de configuração do cband, que inserimos anteriormente:

<Location /cband-status-me>
SetHandler cband-status-me
</Location>

Isso fará com que o painel fique disponível dentro da pasta “cband-status-me”, dentro da URL do site. Se quiser usar outra pasta, basta especificá-la na primeira linha, alterando o “Location /cband-status-me”:

 

 

Para ativar o painel de acesso administrativo, adicione as linhas a seguir no arquivo principal de configuração do Apache (o apache2.conf ou httpd.conf). Isso faz com que ele fique disponível dentro da pasta “cband-status” de cada site, sem que você precise repetir a configuração dentro da seção referente a cada um. Note que, diferente da configuração anterior, criamos uma restrição de acesso, que permite o acesso apenas a partir do seu próprio endereço IP (de forma que apenas você tenha acesso). Se você usa uma conexão com IP dinâmico, vai precisar lembrar de alterar a configuração antes de cada acesso:

<Location /cband-status>
SetHandler cband-status
Order deny,allow
Deny from all
allow from 201.86.208.237
</Location>

Assim como no exemplo anterior, o relatório pode ser acessado via navegador, acessando a pasta “cband-status” de qualquer um dos sites hospedados no servidor.

Uma observação importante é que, no Debian Etch, os painéis de acesso são ativados, por padrão, através da configuração incluída no arquivo “/etc/apache2/mods-available/cband.conf“:

<IfModule mod_cband.c>
<Location /cband-status>
SetHandler cband-status
</Location>
<Location /cband-stats>
SetHandler cband-status-me
</Location>
</IfModule>

Essa configuração essencialmente desativa a aplicação das quotas, pois permite que qualquer um acesse o relatório administrativo através do “http://site.com/cband-status” e resete o contador na hora em que quiser.

A menos que você queira virar motivo de piada entre os usuários, é necessário editar o arquivo, limitando o acesso à pasta cband-status apenas para seu próprio endereço IP, como em:

<IfModule mod_cband.c>
<Location /cband-status>
SetHandler cband-status
Order deny,allow
Deny from all
allow from 201.86.208.237
</Location>
<Location /cband-stats>
SetHandler cband-status-me
</Location>
</IfModule>

Depois de cada alteração, não se esqueça de atualizar a configuração do Apache para que ela entre em vigor:

# /etc/init.d/apache2 reload

Concluindo, se o objetivo for apenas proteger o servidor contra usuários armados com programas aceleradores de download (que abrem um número muito grande de conexões simultâneas, com o objetivo de tornar a transferência de arquivos mais rápida) ou com programas que tentam baixar todo o site para leitura offline, sem estabelecer quotas ou limites de tráfego, você pode usar uma configuração mais simples, usando apenas a opção “CBandremoteSpeed”. Ela pode ser incluída diretamente no arquivo principal de configuração do Apache, o que faz com que ela seja aplicada automaticamente para todos os sites hospedados.

No caso do Debian, você poderia incluí-la no final do arquivo “/etc/apache2/apache2.conf”, antes da linha “Include /etc/apache2/sites-enabled/”, que carrega a configuração dos virtual-hosts, como em:

CBandRemoteSpeed 1024kbps 3 2

# Include the virtual host configurations:
Include /etc/apache2/sites-enabled/

No exemplo, limitei os clientes a um máximo de três requisições por segundo e duas conexões simultâneas, uma configuração que é similar à usada em muitos sites de download.