O suporte a virtual hosts é um daqueles recursos fundamentais, que possibilitaram o surgimento da Internet da forma como a conhecemos hoje. Ele permite hospedar diversos sites, com domínios ou subdomínios diferentes usando um único servidor e um único endereço IP. Os únicos limitantes com relação ao volume de sites que é possível hospedar são os recursos de hardware do servidor e a banda disponível.
Serviços de hospedagem compartilhada (os planos de shared hosting) utilizam este recurso de forma intensiva, de forma a espremer o maior número possível de clientes em cada servidor, sem falar nos serviços de hospedagem gratuita onde, em muitos casos, um único servidor pode hospedar dezenas de milhares de sites diferentes.
Ao usar virtual hosts, os arquivos de cada site ficam guardados em uma pasta diferente e o servidor se encarrega de direcionar cada visitante à pasta correta. Os recursos do servidor (HD, memória, processamento e link) são divididos entre os sites hospedados, assim como vários programas abertos simultaneamente disputam os recursos da máquina. Isso faz muito sentido no caso de sites pequenos ou médios, que não possuem um número suficiente de visitas para saturarem, sozinhos, o servidor.
Em geral, o servidor é configurado de forma que os usuários tenham direito a uma determinada quota de espaço em disco, possam acessar os arquivos do site via FTP ou SFTP e tenham acesso a uma ou mais bases de dados do servidor MySQL, o que permite a instalação de gestores de conteúdo como o WordPress. Entretanto, eles não podem instalar novos pacotes nem alterar a configuração do servidor. Feitas as apresentações, vamos à configuração. 🙂
Invariavelmente, ao hospedar vários domínios, você precisa configurar um servidor DNS para responder por todos os domínios hospedados no servidor, entregando o endereço IP do seu servidor Apache. O cliente acessa então o servidor, solicitando o site desejado, como em “joao.com.br”; o servidor web verifica a configuração e entrega os arquivos apropriados ao cliente.
A configuração do servidor DNS é pouco intuitiva, mas não chega a ser tão complicada quanto muitos dizem. Em resumo, você precisaria instalar o bind no servidor e editar a configuração, adicionando uma nova configuração de zona para cada domínio hospedado. Isso é feito em duas etapas. Na primeira, você edita o arquivo named.conf, adicionando uma entrada com esta, especificando o domínio e o arquivo com a configuração:
zone “joao.com.br” IN {
type master;
file “/etc/bind/db.joao”;
allow-transfer { 64.234.23.13; };
};
Dentro do arquivo “/etc/bind/db.joao”, especificado no arquivo, iria uma configuração similar a esta, especificando o domínio, o nome do servidor e o endereço IP usado por ele, assim como o nome e o endereço IP do servidor DNS secundário:
@ IN SOA servidor.joao.com.br. hostmaster.joao.com.br. (
2008061645 3H 15M 1W 1D )
NS servidor.joao.com.br.
NS ns2.joao.com.br.
IN MX 10 servidor.joao.com.br.
joao.com.br. A 64.234.23.12
www A 64.234.23.12
ns1 A 64.234.23.13
Não é necessário que o DNS esteja instalado no mesmo servidor que o Apache, a função dele será unicamente responder às requisições dos clientes, fornecendo o IP correto. Vamos estudar a configuração do DNS em detalhes no próximo capítulo, dedicado unicamente ao assunto. Este foi apenas um exemplo rápido para que você tenha uma idéia geral sobre a configuração. Por enquanto, vamos nos concentrar na configuração do Apache propriamente dito.
Para ativar o uso dos virtual hosts, o primeiro passo é criar uma pasta separada para cada site que será hospedado. Você pode usar a própria pasta “/var/www”, como em:
Índice
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:
ServerAdmin [email protected] ServerName www.joao.com.br ServerAlias joao.com.br www.joao.com.br DocumentRoot /var/www/joao
- /etc/apache2/sites-available/maria:
ServerAdmin maria@gmail.com ServerName www.maria.com.br ServerAlias maria.com.br www.maria.com.br DocumentRoot /var/www/maria
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”:
ServerAdmin [email protected] ServerName maria.gdhn.com.br DocumentRoot /var/www/maria
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 *
Por:
NameVirtualHost *: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 “” ao invés de “”.
Você pode adicionar quantos sites quiser usando esses mesmos passos. Sempre que alterar a configuração, é necessário atualizar a configuração do Apache. Nesse caso, o parâmetro “reload” é suficiente (o “force-reload” é necessário apenas ao ativar ou desativar módulos):
/etc/init.d/apache2 reload
Além de configurar o servidor web, é preciso configurar também um servidor FTP ou SFTP, para que os usuários possam acessar os arquivos de suas respectivas pastas, a fim de atualizarem seus sites. A forma mais simples de fazer isso é criar um usuário para cada um e dar acesso a eles via FTP (mais adiante veremos como configurar o servidor FTP com o Proftpd). Outra opção é utilizar o SFTP, que permite acesso seguro. Veremos mais detalhes sobre ele no capítulo sobre o SSH.
Veja que as três coisas acabam se integrando: o Bind resolve os nomes de domínio, o Apache fornece as páginas e o FTP ou SFTP permite que os webmasters atualizem os sites.
Continuando, ao utilizar o Fedora, CentOS ou outra distribuição derivada do Red Hat, a configuração de todos os virtual hosts é adicionada na seção final do arquivo “/etc/httpd/conf/httpd.conf”, depois do “# Section 3: Virtual Hosts”. Procure pela seção “Virtual Hosts”, perto do final do arquivo, e descomente a linha:
NameVirtualHost *:80
A partir daí, você pode adicionar cada um dos sites hospedados no servidor usando a mesma configuração que vimos anteriormente, como em:
ServerName www.joao.com.br ServerAlias joao.com.br www.joao.com.br DocumentRoot /var/www/joao
ServerName www.maria.com.br ServerAlias maria.com.br www.maria.com.br DocumentRoot /var/www/maria
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:
ServerAdmin [email protected] 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
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:
ServerAdmin [email protected] 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
Note que, como todos os sites ficam hospedados no mesmo servidor, a única forma de chegar ao site desejado é fazendo o acesso através do domínio. Se você tentar acessar diretamente o IP do servidor, vai cair no site padrão (configurado através do arquivo “/etc/apache2/sites-available/default”), que, por padrão, usa o raiz da pasta “/var/www”. Esta página default pode ser usada para mostrar alguma publicidade da empresa responsável pelo servidor, ou uma lista dos sites hospedados, por exemplo.
Concluindo, caso queira ativar o suporte a SSL para algum dos virtual hosts, adicione a sessão referente ao SSL dentro da configuração de cada site, indicando corretamente a pasta do site e os arquivos de log. O SSL pode ser tanto ativado para o raiz do site, permitindo que os visitantes visualizem qualquer parte do site usando o “https://”, ou utilizar uma pasta separada, onde está a parte de comércio eletrônico do site, por exemplo, como em:
ServerName www.joao.com.br DocumentRoot /var/www/joao/ssl SSLEngine on SSLCertificateFile /etc/apache2/ssl/apache.pem
Neste caso, ao acessar o “http://www.joao.com.br”, o visitante visualizará o conteúdo da pasta “/var/www/joao/html”, enquanto ao acessar o “https://www.joao.com.br”, visualizará a “/var/www/joao/ssl”.
Como vimos no tópico anterior, certificados SSL são válidos apenas para um domínio específico. Se você deseja oferecer suporte a SSL para vários subdomínios hospedados no servidor, a melhor opção é adquirir um certificado wildcard, que é valido para qualquer subdomínio dentro do domínio principal da sua empresa. Isso permite que você crie diversos virtual hosts, como “loja1.minhaempresa.com” e “loja2.minhaempresa.com”, utilizando o mesmo certificado.
Essa configuração manual funciona para pequenos servidores, que hospedam algumas dezenas ou centenas de páginas. Grandes serviços de hospedagem geralmente acabam desenvolvendo algum tipo de sistema para automatizar a tarefa. Nos serviços de hospedagem gratuita, por exemplo, onde o número de clientes é assustadoramente grande, as alterações são feitas de forma automática quando o visitante faz seu cadastro, geralmente através de um sistema escrito em PHP ou Java.
Conforme o número de usuários cresce e o espaço em disco no servidor começa a ficar escasso, você começará a sentir falta de um sistema de quotas, que limite o espaço que cada usuário pode usar. Para isso, consulte o tópico sobre quotas de disco, mais adiante.
