Você está na página 1de 15

Configurando um servidor LAMP

Nos primórdios da internet, eram utilizadas apenas páginas html estáticas e scripts CGI. O Apache em si
continua oferecendo suporte apenas a esses recursos básicos, mas ele pode ser expandido através de módulos.
Entram em ação, então, os gestores de conteúdo e fóruns, que combinam os recursos do PHP com um banco de
dados como o MySQL, acessado através dele. A combinação de tudo isso forma a solução que é popularmente
chamada de "LAMP" (Linux + Apache + MySQL + PHP), que forma a espinha dorsal da Internet. Este tutorial
mostra a configuração em detalhes.
Os servidores web são a espinha dorsal da Internet, são eles que hospedam todas as páginas, incluindo os
mecanismos de busca e servem como base para todo tipo de aplicativo via web, incluindo os webmails. No
futuro, esta tendência deve se acentuar, com páginas web dinâmicas e aplicativos via web substituindo cada vez
mais os aplicativos desktop.
Nos primórdios da internet, eram utilizadas apenas páginas html estáticas e scripts CGI. O Apache em si
continua oferecendo suporte apenas a esses recursos básicos, mas ele pode ser expandido através de módulos,
passando a suportar scripts em PHP, acessar bancos de dados MySQL, entre inúmeros outros recursos. Sempre
que é solicitada uma página em PHP ou outra linguagem, entra em ação o módulo apropriado, que faz o
processamento necessário e devolve ao Apache a página html que será exibida. Entram em ação, então, os
gestores de conteúdo e fóruns, que combinam os recursos do PHP com um banco de dados como o MySQL,
acessado através dele. A combinação de tudo isso forma a solução que é popularmente chamada de "LAMP"
(Linux + Apache + MySQL + PHP).
O Apache e o MySQL, juntamente com o suporte a PHP podem ser também instalados sobre o Windows
(formando o "WAMP"), uma solução relativamente popular entre administradores Microsoft que não se sentem
à vontade em usar o IIS.
Segundo a Netcraft, pouco mais de 50% dos servidores web do mundo rodam o Apache
(http://news.netcraft.com/archives/web_server_survey.html), a maior parte deles sobre o Linux. O percentual
real é na verdade um pouco maior, pois um grande número de administradores configuram seus servidores para
divulgarem informações falsas sobre o servidor web usado, de forma a não fornecer qualquer informação que
possa facilitar ataques. Estes servidores não-identificados aparecem na pesquisa como "other".
Além de ser um dos servidores web mais antigos e um dos mais seguros, o Apache possui inúmeros módulos,
que adicionam suporte aos mais exóticos recursos. A maioria das páginas atuais utiliza uma estrutura em PHP,
freqüentemente com um banco de dados MySQL ou PostgreSQL. Existem, inclusive, muitos sistemas prontos,
como o phpBB (fórum) e o WordPress (para gerenciamento de conteúdo), que podem ser instalados sem muita
dificuldade depois que o servidor web já estiver rodando.
Além do servidor web em si, você quase sempre vai precisar configurar também um servidor DNS, que
responderá pelo domínio do seu site ou empresa. Aprender a configurar o DNS corretamente é importante, caso
contrário você pode ter problemas ao enviar e-mails (pela falta do DNS reverso), ou mesmo ter problemas mais
graves com o registro do domínio.
A Apache permite hospedar vários sites no mesmo servidor, recurso chamado de virtual hosts. Apenas os sites
mais acessados são capazes de saturar os recursos de um servidor dedicado de configuração razoável, por isso
hospedar vários sites no mesmo servidor é uma forma de economizar recursos e trabalho.

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.
Ao instalar o Apache 2, o suporte a SSL é instalado automaticamente junto com o pacote principal. 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.

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
No caso do CentOS/Fedora o mod_php é instalado junto com o pacote "php" e ativado automaticamente,
através da criação do arquivo "/etc/httpd/conf.d/php.conf". Dentro dele, você encontra as linhas que carregam o
módulo e criam a associação com os arquivos .php, como em:
LoadModule php5_module modules/libphp5.so AddHandler php5-script .php AddType text/html .php
DirectoryIndex index.php
Se você tiver a curiosidade de olhar o conteúdo dos arquivos "/etc/apache2/mods-enabled/php5.conf" e
"/etc/apache2/mods-enabled/php5.load" em uma distribuição derivada do Debian, vai perceber que as linhas
contidas neles são muito similares. Na verdade, o Apache usado no Debian e o usado no CentOS é o mesmo
software, apenas configurado de forma ligeiramente diferente.
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.

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.

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.
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.

Criando 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.
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. Outra opção é utilizar o
SFTP, que permite acesso seguro.
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.

Otimizando a configuração do servidor


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, 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