Configurando um servidor LAMPNos 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 ApacheO 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 PHPNo 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 psUT7wq01Enter 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 HostsO 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 processosO 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 apacheii 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:

# freetotal 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çõesA 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