Embed Size (px)
DESCRIPTION
Configurando um servidor LAMP(Linux + Apache + MySQL + PHP)
Citation preview
Configurando um servidor LAMP
(Linux + Apache + MySQL + PHP)
Introdução
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
servidorDNS, 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 [email protected]
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 [email protected]
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 [email protected]
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 [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
</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 [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
</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
