Tabela de conteúdo
|
Para usar o Apache2.2 em um ambiente com Debian Squeeze 6.0 basta instalar os pacotes listados abaixo:
# apt-get install apache2
com isso todas as bibliotecas necessárias estarão rodando, mas nosso ambiente não está pronto para produção ainda.
Para adicionar o suporte a linguagem PHP5 no Debian Lenny, vamos instalar o seguinte meta pacote:
# apt-get install php5
feito isso, todas as dependências necessárias serão instaladas. Vamos agora ativar o PHP5:
# /etc/init.d/apache2 restart
com o Apache recarregado, o módulo do PHP já foi carregado.
Antes de configurar, não esqueça de ativar o módulo do Apache que gerencia autenticação simples:
# a2enmod auth_basic
Para configurar a autenticação simples basta criar um arquivo contendo as senhas:
# htpasswd -c /caminho/para/arquivo USUARIO New password: SENHA Re-type new password: SENHA Adding password for user USUARIO
feito isso, vamos editar as configurações no Apache e colocar a seguinte configuração (onde arquivo é o arquivo que contém os usuários e senhas):
AuthType Basic AuthName "Área Restrita" AuthUserFile /caminho/para/arquivo Require user USUARIO
para algumas configurações, todos os usuários podem ser válidos, então é melhor usar:
Require valid-user
para dizer que qualquer usuário válido pode acessar aquele local. Você pode opcionalmente criar grupos de acesso também, basta editar um arquivo (no nosso caso o arquivo grupo):
# vim /caminho/para/grupo autores: USUARIO1 USUARIO2
onde USUARIO1 e USUARIO2 fazem parte do grupo autores, e agora definir isso na configuração:
AuthGroupFile /caminho/para/grupo Require group autores
Um exemplo completo de autenticação somente por usuários válidos:
AuthType Basic AuthName "Área Restrita" AuthUserFile /caminho/para/arquivo Require valid-user
e um exemplo por grupo:
AuthType Basic AuthName "Área Restrita" AuthUserFile /caminho/para/arquivo AuthGroupFile /caminho/para/grupo Require group autores
pronto, nossa autenticação simples está pronta.
Devemos ativar no Apache primeiramente o módulo de autenticação digest:
# a2enmod auth_digest
Para trabalhar com autenticação digest, que é mais segura que a autenticação básica, devemos primeiro criar da mesma forma um arquivo contendo as senhas e o domínio (realm):
# htdigest -c /caminho/para/digest dominio USUARIO Adding password for USUARIO in realm dominio. New password: SENHA Re-type new password: SENHA
você será questionado sobre a inserção da senha duas vezes, faça isso. Agora vamos configurar o Apache para usar nossa autenticação digest:
AuthType Digest AuthName "dominio" AuthUserFile /caminho/para/digest Require valid-user
o AuthName deve ser o domínio que você definiu ao criar o arquivo de senhas, a lógica para usuários e grupos é a mesma que definimos na autenticação básica.
Primeiro precisamos adicionar suporte a autenticação usando LDAP no Apache, para isso vamos ativar o módulo correspondente:
# a2enmod authnz_ldap
este passo vai ativar tanto o módulo authnz_ldap como o modo ldap, após isso devemos alterar as configurações do diretório que desejamos que esta funcionalidade esteja ativa, geralmente no Debian cada pacote web contém seu próprio apache.conf dentro do /etc, podemos tanto editar diretamente este arquivo ou então alterar o parâmetro AllowOverride configurado para permitir AuthConfig no diretório, dai seria criado o arquivo .htaccess.
<Directory /caminho/do/diretorio/web/> Options +FollowSymLinks AllowOverride None Order deny,allow Deny from all AuthType Basic AuthName "Restricted Access" AuthLDAPURL ldap://ldap.dominio.com.br/ou=people,dc=dominio,dc=com,dc=br?uid?sub AuthBasicProvider ldap AuthUserFile /dev/null AuthLDAPBindDN "cn=leitor_da_base_ldap,dc=dominio,dc=com,dc=br" AuthLDAPBindPassword SENHA_DO_USUARIO Authzldapauthoritative On AuthLDAPGroupAttributeIsDN Off AuthLDAPGroupAttribute memberUid Require ldap-group cn=Administrators,ou=groups,dc=dominio,dc=com,dc=br Satisfy any </Directory>
no nosso exemplo, estamos liberando o grupo Administrators para acessar este caminho do Apache, para liberar usuários em especial o parâmetro seria
Require ldap-user USER1 USER2 USER3
Também é importante notar que o parâmetro AuthUserFile aponta para null e o AuthBasicProvider tem que ser definido para ldap senão teremos erros sendo gerados de que a senha não confere. Finalizando, veja que a variável AuthLDAPURL requer uma atenção especial, pois ela é usada para retornar o usuário que queremos autenticar, no nosso caso autenticamos pelo uid e queremos uma busca nas sub árvores, parâmetro: sub.
Os domínios virtuais dentro do Apache2.2 são utilizados quando desejamos mapear para um mesmo IP, vários domínios e que estarão localizados também em diretórios, bancos de dados e outras configurações diferentes. Vamos supor que eu possua dois sites para serem hospedados:
Lembrando que no DNS, ambos vão estar apontando para o IP 200.129.202.132 do servidor web. No servidor WEB eu devo então criar 2 arquivos de configuração da seguinte maneira:
# vim /etc/apache2/sites-available/exemplo.conf
<VirtualHost *:80>
DocumentRoot /var/www/exemplo
ServerName exemplo.com.br
ServerAlias www.exemplo.com.br
ServerAdmin admin@exemplo.com.br
<Directory /var/www/exemplo >
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
</Directory>
ServerSignature Off
</VirtualHost>
e para o outro domínio:
# vim /etc/apache2/sites-available/outracoisa.conf
<VirtualHost *:80>
DocumentRoot /var/www/outracoisa
ServerName outracoisa.com.br
ServerAlias www.outracoisa.com.br
ServerAdmin admin@outracoisa.com.br
<Directory /var/www/outracoisa >
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
</Directory>
ServerSignature Off
</VirtualHost>
depois de criar estes 2 arquivos, precisamos ativá-los no Apache2.2:
# a2ensite exemplo.conf # a2ensite outracoisa.conf
e recarregue as configurações no Apache2.2:
# /etc/init.d/apache2 reload
Pronto, agora as requisições de cada site serão enviadas para os respectivos diretórios.
É importante saber que o usuário www-data tem que ter permissão de leitura, pelo menos, dos diretórios e arquivos que você deseja que sejam publicados, senão você poderá ter erros relacionados a permissão de arquivos.
Existem situações que você deseja que o usuário hospede sites dentro do seu próprio ambiente de usuário sem acesso ao servidor ou a diretórios mais privativos para publicação web como o /var/www. Para estas situações o módulo UserDir é interessante, pois através dele é possível definir um diretório dentro do diretório pessoal do usuário que será utilizado para publicar informações na web.
Primeiro vamos ativar este módulo:
# a2enmod userdir
ao fazer isso será necessário reinicializar o Apache2.2:
# /etc/init.d/apache2 restart
feito isso o módulo estará ativo. Vamos abrir as configurações do mod_userdir para entendê-lo melhor:
# vim /etc/apache2/mods-enabled/userdir.conf
<IfModule mod_userdir.c>
UserDir public_html
UserDir disabled root
<Directory /home/*/public_html>
AllowOverride FileInfo AuthConfig Limit Indexes
Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
<Limit GET POST OPTIONS>
Order allow,deny
Allow from all
</Limit>
<LimitExcept GET POST OPTIONS>
Order deny,allow
Deny from all
</LimitExcept>
</Directory>
</IfModule>
note que as configurações definem que o diretório public_html dentro de cada usuário será utilizado como pasta pública na web de cada usuário. A forma de acessar este ambiente web do usuário é bem simples: http://ip_publico_do_servidor/~usuario, note que o ~ é necessário para que o Apache interprete corretamente o que você deseja fazer.
Com o Apache2 instalado, vamos ativar o módulo de balanceamento de carga:
# a2ensite proxy_balancer
reinicie o Apache2:
# /etc/init.d/apache2 restart
Para que um domínio virtual (VirtualDomain) do seu sistema ganhe suporte a utilização de vários servidores, vamos ter que configurá-lo para isso, vamos supor que nosso servidor Apache2 hospede o domínio: www.exemplo.com.br. Lembrando que esta configuração vai ser feita no nó gerenciador e que tem o DNS apontado para ele.
# vim /etc/apache2/sites-avaliable/exemplo.com.br.conf
<VirtualHost *:80>
ServerAdmin webmaster@exemplo.br
ServerName exemplo.com.br
ServerAlias *.exemplo.com.br
#O ideal é bloquear de todos e liberar somente para sua subrede ou IP
<Location /balancer-manager>
SetHandler balancer-manager
Order Deny,Allow
Deny from all
Allow from 127.0.0.1 REDE_PRIVADA/MASCARA
</Location>
ProxyPass /balancer-manager !
ProxyPass / balancer://exemplo lbmethod=byrequests stickysession=BALANCEID
ProxyPassReverse / balancer://exemplo
<Proxy balancer://exemplo>
BalancerMember http://no01.exemplo.com.br loadfactor=1 route=web01
BalancerMember http://no02.exemplo.com.br loadfactor=1 route=web02
</Proxy>
</VirtualHost>
Vamos entender o que está acontecendo aqui, primeiro estamos ativando a interface de gerenciamento do Apache2 para o balanceamento em: http://www.exemplo.com.br/balancer-manager. Veja a imagem do gerenciador:
Logo em seguida, dizemos que para este caminho (do balance-manager), não devemos repassar a requisição via proxy (a exclamação serve para isso). O próximo passo é definir quem faz parte do balanceamento, neste caso temos o no01 e no02, colocamos o nome por comodidade, mas poderíamos apontar para os IPs públicos/privados dos servidores Apache2 que fazem parte do balanceamento. Na linha:
ProxyPass / balancer://exemplo lbmethod=byrequests stickysession=BALANCEID
definimos como nosso balanceamento deve se comportar, o parâmetro lbmethod define como o balanceamento deve acontecer, que são:
Outro parâmetro que vocês notaram foi o loadfactor, que representa o peso que este servidor tem em relação aos outros, no caso, quanto maior o número definido, mais este servidor vai receber carga de trabalho. E o último parâmetro é o route que vai ser utilizado para a resolução de problemas com sessões em PHP (vocês vão notar que uma vez que está balanceado, o servidor fica direcionando a cada reload do site para um nó diferente), o mesmo vale para o stickysession que foi definido, ele serve para isso também.
Com isso, se o seu servidor tem apenas conteúdo estático, isso já resolve muito bem o problema de balanceamento, agora se tem sistemas que utilizam sessões, você vai precisar adicionar as configurações abaixo nos servidores Apache2 que atendem as requisições gerenciadas pelo servidor Apache2 gestor. No servidor principal (o que gerencia as conexões de chegada), adicione o seguinte ao VirtualDomain desejado (exemplo.com.br.conf):
# vim /etc/apache2/sites-avaliable/exemplo.com.br.conf
<VirtualHost *:80>
...
RewriteRule ^/(.*\.(png|jpg|jpeg|gif|jpg|css|php|ico|js)) balancer://exemplo%{REQUEST_URI} [NC,P,L]
...
</VirtualHost>
não esqueça de habilitar o módulo de reescrita:
# a2enmod rewrite # /etc/init.d/apache2 restart
e agora, em cada nó você deve também colocar uma regra de reescrita:
# vim /etc/apache2/sites-avaliable/exemplo.com.br-no01.conf
<VirtualHost *:80>
ServerAdmin webmaster@exemplo.com.br
ServerName exemplo.com.br
ServerAlias *.exemplo.com.br
DocumentRoot /var/www/
RewriteEngine On
RewriteRule .* - [CO=BALANCEID:exemplo.web01:.exemplo.com.br]
<Directory /var/www/>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
Esta configuração deve ser feita nos 2 nós. Primeiro, não esqueça de ativar o módulo de rewrite, depois atente bem a regra de reescrita feita, o stickysession deve ser igual, o parâmetro seguinte é o nome do balanceamento que você definiu no servidor principal e o parâmetro seguinte é o nome que foi definido na rota. Ou seja, para o segundo servidor a linha deverá ser:
... RewriteRule .* - [CO=BALANCEID:exemplo.web02:.exemplo.com.br] ...
reinicie os servidores Apaches2 dos nós e tudo deve estar funcionando.
Se a extensão de algum arquivo não estiver na RewriteRule, você pode receber um erro sobre não ter carregado algum módulo, apenas adicione a nova extensão. Outro detalhe importante é que se você simplesmente redirecionar qualquer requisição com uma linha como:
RewriteRule ^/(.*)$ balancer://exemplo%{REQUEST_URI} [P,QSA,L]
o acesso a interface administrativa vai ser redirecionada também e como isso seu acesso deixará de existir, pois os nós não sabem que fazem parte de um cluster de balanceamento.
Um Servidor rodando Apache publicamente, pode por boas práticas limitar as informações que publica na Internet, esta técnica é conhecida como segurança por obscuridade, mas não custa nada reduzir a gama de informações que um cracker tenha do seu ambiente.
Dentro do diretório /etc/apache2/conf.d podem existir vários arquivos, o arquivo de interesse é o security, edite o arquivo com as seguintes definições:
# Esta configuração quebra a configuração que vem com alguns aplicativos web
# dos pacotes do Debian. E se tornará padrão para o release depois do lenny.
<Directory />
AllowOverride None
Order Deny,Allow
Deny from all
</Directory>
# Estes parâmetros não vão aumentar a segurança em si, mas vão servir para
# dificultar a ação maliciosa
ServerTokens Prod
ServerSignature On
TraceEnable Off
feito isso, reinicie o serviço do Apache2 e sua configuração vai passar a ocultar algumas informações do servidor. Uma outra forma de aumentar mais ainda a segurança é dar uma olhada no módulo do Apache para o Fail2Ban.
Para instalar o Apache2.2 no CentOS, basta instalar o pacote chamado httpd:
# yum install httpd
ele vai baixar algumas dependências e já estará funcionando. Não esqueça de liberar no firewall do CentOS a possibilidade de acesso a porta 80. Para isso use o script da RHEL:
# system-config-securitylevel-tui
seleciona a opção: Personalizar e depois marque Permitir entrada: WWW (HTTP).
Para adicionar suporte ao PHP, é tão fácil quanto instalar o Apache2.2 em si:
# yum install php
ele não vai colocar todos os módulos do PHP, mas o mínimo necessário para funcionar. Reinicie o serviço do Apache:
# service httpd restart
pronto, o PHP já está funcionando.
--Brivaldo 19h11min de 27 de novembro de 2010 (UTC)