Instalar e configurar Módulos do Apache2 no Debian

Publicado: 09/05/2011 em Linux, Programação, Serviços IP
Tags:

1) Manual de comandos do Apache2

Uma lista dos comandos disponíveis do Apache podem ser vistos a partir do seu manual, com o uso de um terminal:

# man apache2

Outra fonte de informação de excelente qualidade é o README do Apache para o Debian que é encontrado de forma compactada em /usr/share/doc/apache2.2-common/README.Debian.gz . Baixe o arquivo, descompacte-o ($ gunzip README.Debian.gz) e boa leitura.

Também é muito prático instalar a documentação completa do Apache na máquina local. Para isto, utilize o Synaptic ou o comando através do terminal:

# apt-get install apache2-doc

O acesso através do navegador se dará por http://localhost/manual/

2) Estados de um módulo

Um módulo pode estar em uma das 3 situações abaixo descrita, em relação ao Apache em execução em uma máquina:

a) módulo compilado juntamente com o Apache2
Estes módulos já estão habilitados (ou seja, em funcionamento). A listagem destes módulos é obtida através do comando #apache2 -l

b) módulos padrões do Apache2 instalados (mas não necessariamente habilitados)
Estes módulos já estão na máquina, baixados no momento da instalação do Apache. Mas precisam de um comando do usuário (administrador) para se tornarem habilitados. Normalmente habilitados pelo comando “a2enmod”. Estes módulos estão, de fato, na pasta “/usr/lib/apache2/modules/”. São arquivos terminados por “.so”, como pode ser observado naquela pasta:

-rw-r--r-- 1 root root libphp5.so
-rw-r--r-- 1 root root mod_actions.so
-rw-r--r-- 1 root root mod_alias.so
-rw-r--r-- 1 root root mod_asis.so
-rw-r--r-- 1 root root mod_auth_basic.so

Os arquivos da pasta “/etc/apache2/mods-available/” contém apenas a diretiva “LoadModule” do módulo depositado na pasta “/usr/lib/apache2/modules/”.

c) outros módulos do Apache2 não instalados
São módulos adicionais não padrão do Apache e que ainda não estão na máquina local. Eles podem ser instalados pelo usuário (administrador), se necessário. Normalmente através de um comando “apt-get install” ou usando o “Synaptic”. Uma quantidade grande de módulos do Apache estão disponíveis no repositório oficial do Debian, facilmente identificados por “libapache-….”.

3) Listar os módulos compilados com o servidor Apache

# apache2 -l
Compiled in modules:
core.c
mod_log_config.c
mod_logio.c
prefork.c
http_core.c
mod_so.c

No caso, foram 6 os módulos compilados juntamente com o servidor Apache.
Este comando lista apenas os módulos compilados com o servidor. Não é elencado os módulos dinamicamente carregados através da diretiva “LoadModule” (ou habilitados pelo comando a2enmod).

4) Listar os módulos habilitados
Dentro da pasta /etc/apache2/mods-enabled/ encontramos todos os módulos habilitados. Aqui vamos encontrar links simbólicos para os arquivos do mods_available para todos os módulos habilitados.

# ls -la /etc/apache2/mods-enabled
lrwxrwxrwx root root 28 alias.conf -> ../mods-available/alias.conf
lrwxrwxrwx root root 28 alias.load -> ../mods-available/alias.load
lrwxrwxrwx root root 26 cgi.load -> ../mods-available/cgi.load
lrwxrwxrwx root root 30 deflate.conf -> ../mods-available/deflate.conf
lrwxrwxrwx root root 30 deflate.load -> ../mods-available/deflate.load
lrwxrwxrwx root root 27 mime.conf -> ../mods-available/mime.conf
lrwxrwxrwx root root 27 mime.load -> ../mods-available/mime.load
lrwxrwxrwx root root 27 20:40 php5.conf -> ../mods-available/php5.conf
lrwxrwxrwx root root 27 php5.load -> ../mods-available/php5.load

5) Comandos relacionados:

a) # lsof -i tcp:80

b) ferramenta Debian para habilitar módulo: a2enmod
Habilita um módulo Apache2 (este não faz mais nada além de criar os links adequados para os arquivos modulo.load e modulo.conf).

OBS: executando a2enmod sem qualquer parâmetro, será mostrado uma lista de módulos passíveis de habilitação e será solictado do usuário escolher um deles. Na verdade, o comando apresenta a listagem com os nomes dos  arquivos que estão em  “/usr/lib/apache2/modules/”.  Exemplo:

# a2enmod
Your choices are: actions alias asis auth_basic auth_digest authn_alias authn_anon authn_dbd authn_dbm authn_default authn_file authnz_ldap authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cern_meta cgi cgid charset_lite dav dav_fs dav_lock dbd deflate dir disk_cache dump_io env expires ext_filter file_cache filter headers ident imagemap include info ldap log_forensic mem_cache mime mime_magic mod-dnssd negotiation php5 proxy proxy_ajp proxy_balancer proxy_connect proxy_ftp proxy_http proxy_scgi reqtimeout rewrite setenvif speling ssl status substitute suexec unique_id userdir usertrack version vhost_alias
Which module(s) do you want to enable (wildcards ok)?

c) ferramenta Debian para desabilitar módulo: a2dismod
Desabilita um módulo Apache2 (remove os links do diretório “/etc/apache2/mod-enabled/” relativo ao módulo).
OBS: executando a2dismod sem qualquer parâmetro, será mostrado uma lista de módulos habilitados e será solicitado ao usuário escolher um deles. Na verdade, o comando apresenta a listagem com os nomes dos  arquivos que estão em  “/etc/apache2/mods-enabled/”.  Exemplo:

# a2dismod
Your choices are: alias auth_basic authn_file authz_default authz_groupfile authz_host authz_user autoindex cgi deflate dir env mime negotiation php5 reqtimeout rewrite setenvif status
Which module(s) do you want to disable (wildcards ok)?

6) Módulo suPHP no Apache2
Logo do módulo do suphp
a) O que é o Suphp
suPHP é uma ferramenta para executar scripts PHP com as permissões de seus proprietários, bem como de controle de quem pode acessar determinados arquivos. Todos os scripts executados no servidor precisam ser autorizados para poderem ser executados no servidor. Isto é feito através das permissões de arquivo. Assim cada usuário só pode mexer nos seus ficheiros.

O suPHP consiste em dois componentes:

  • mod_suphp, que é o “Apache2 module to run php scripts with the owner permissions” (obs: os módulos suphp e suexec podem conviver concomitantemente na mesma máquina, conforme descrito adiante).
    No repositório Debian é o pacote “libapache2-mod-suphp” instalado pelo comando:
    # apt-get install libapache2-mod-suphp
  • suPHP, um binário setuid root que substitui Apache suEXEC. É chamado pelo módulo do Apache para mudar a identificação do usuário (“uid” – user id) do processo de execução do interpretador PHP. Normalmente, o Apache roda com uid=”nobody” (no CenTOS) ou uid=”www-data” (no Debian).
  • Assim, para se ter o módulo suphp instalado na máquina, é preciso executar “apt-get install libapache2-mod-suphp” o qual fará a instalação (no mínimo) dos pacotes:
    suphp-common
    apache2.2-common
    php5-cgi

    Vejamos os detalhes:
    i) O pacote libapache2-mod-suphp:
    depende de: pacote suphp-common e apache2.2-common
    ii) O pacote suphp-common:
    depende de: php5-cgi

    b) Quais as vantagens de se utilizar suPhp?
    Duas vantagens maiores:
    – melhorar a segurança do site;
    – fazer todas as aplicações PHP (como sistemas de CMS) mais amigáveis.

    Todos os CMS trabalham com páginas dinâmicas, criando novos arquivos e reescrevendo outros para controle das atividades dos usuários. Com a instalação do módulo apenas do PHP, os arquivos PHP são executados a partir do Apache como usuário “nobody” (isso no CentOS, e no Debian como usuário “www-data”), fazendo com que o controle do arquivo esteja diretamente relacionado com as permissões atribuídas ao arquivo. Uma vez que “nobody” não é um “usuário” real ou membro de qualquer “grupo”, para ser possível fazer o CMS funcionar seria necessário que os arquivos PHP e pastas tivessem permissões 0777 (leitura, escrita e execução para todos). Isso é problemático pois se estaria permitindo que usuários externos ao servidor adicionassem arquivos ao site e fizessem a sua execução. Isto daria a estes usuários externos a capacidade de adicionar códigos maliciosos para a URL e manipular os arquivos livremente.

    suPHP manipula os arquivos PHP e as suas pastas não mais como uid=”nobody”, mas identificado como o usuário proprietário do site (e tendo suas permissões e propriedades). suPHP torna possível o funcionamento do CMS sem a necessidade de fixar as permissões como 777 para as pastas e aos arquivos PHP que serão executados, o que torna o seu site flexível no uso e seguro. E ajudando a melhorar ainda mais a segurança do site, suPHP também vai lançar uma mensagem de erro se o usuário tentar acessar qualquer pasta a qual tenha sido fixada a permissão 777. No caso do suPHP, o desenvolvedor necessita apenas duas permissões para o funcionamento ideal do sistema: 755 para diretórios e arquivos (obs: para arquivos o ideal é 644). Qualquer permissão acima disso resultará em um “Internal Server Error” (o erro 500).

    O suPHP é muito importante para os administradores de sites, pois caso um processo esteja consumindo 100% de CPU este processo tem seu proprietário identificado. Caso o suPHP não estivesse habilitado, não haveria condições de saber a quem pertencia (pelo menos de forma rápida e direta).

    c) Quais as desvantagens do suPHP?
    O suPHP tem um defeito que é causar uma perda de performance no servidor.

    d) Verificar se o suphp está disponível e habilitado
    # ls /usr/lib/apache2/modules/ | grep suphp
    mod_suphp.so

    Vê-se pela resposta do sistema que o módulo suphp está disponível. Caso não esteja, fazer sua instalação:
    # apt-get install libapache2-mod-suphp

    Para verificar se um módulo está habilitado:
    $ ls -la /etc/apache2/mods-enabled | grep suphp
    lrwxrwxrwx 1 root root 28 Set 8 18:14 suphp.conf -> ../mods-available/suphp.conf
    lrwxrwxrwx 1 root root 28 Set 8 18:14 suphp.load -> ../mods-available/suphp.load

    No caso acima, pela resposta do sistema, o móduo suphp está instalado e habilitado.

    Se o módulo suPHP não estiver ainda habilitado, precisa ser utilizado um comando especial do administrador da máquina para se tornar habilitado: comando “a2enmod”.
    #a2enmod suphp

    e) Convivência simultânea dos módulos PHP e suPHP
    Os módulos PHP5 (libapache2-mod-php5) e suPHP (libapache2-mod-suPHP) não entram em conflito e podem conviver simultaneamente em uma instalação. Apenas será necessário preparar uma configuração para deixar os dois módulos do Apache em sintonia.

    Se não houver mais necessidade do módulo PHP, utilize:
    # a2dismod php

    No entanto, o módulo PHP (libapache2-mod-php5) continuará a ser bastante necessário se existir qualquer aplicação PHP instalada a partir de pacotes debs (por exemplo, phpmyadmin e phppgadmin). Os arquivos destes pacotes são de propriedade da raiz (root), e eles não devem ser executados através do módulo suPHP mas sim através do módulo PHP.

    A seguir está uma configuração para o suPHP que deixa os dois módulos convivendo bem. Tudo é executado sob suPHP, exceto as aplicações PHP instaladas a partir de pacotes deb (que ficarão instaladas na pasta /usr/share):

    1) remover /etc/apache2/mods-enabled/php5.conf (deixar php5.load intocado)
    2) deixar /etc/apache2/mods-enabled/suphp.conf com o seguinte conteúdo:

    ##################### suphp.conf #####################
    <IfModule mod_suphp.c>
    <FilesMatch "\.ph(p3?|tml)$">
    SetHandler application/x-httpd-suphp
    suPHP_AddHandler application/x-httpd-suphp
    </FilesMatch>


    <Directory />
    suPHP_Engine on
    </Directory>


    # Por default, desabilitar suPHP para aplicações web
    # empacotadas Debian. Tais arquivos pertencem ao usuário
    # "root" e não podem ser executados através do suPHP devido
    # ao min_uid.
    <Directory /usr/share>
    suPHP_Engine off
    <IfModule mod_php5.c>
    <FilesMatch "\.ph(p3?|tml)$">
    SetHandler application/x-httpd-php
    </FilesMatch>
    </IfModule>
    </Directory>
    <Directory /var/lib>
    suPHP_Engine off
    <IfModule mod_php5.c>
    <FilesMatch "\.ph(p3?|tml)$">
    SetHandler application/x-httpd-php
    </FilesMatch>
    </IfModule>
    </Directory>

    # # Use um arquivo específico de php config (um diretorio que contém um arquivo php.ini)
    # suPHP_ConfigPath /etc/php4/cgi/suphp/
    # Fazer com que mod_suphp NÃO atenda solicitações com
    # o type <mime-type>.
    # suPHP_RemoveHandle <mime-type>
    </IfModule>

    ##################### suphp.conf #####################

    Atenção especial ao arquivo /etc/suphp/suphp.conf, que deve conter, além de outras, as seguintes diretivas:

    ;Umask to set, specify in octal notation
    umask=0022
    ;Loglevel
    loglevel=warn
    ; Security options
    allow_file_group_writeable=true
    allow_file_others_writeable=false
    allow_directory_group_writeable=true
    allow_directory_others_writeable=false

    ; Minimum UID
    min_uid=100
    ; Minimum GID
    min_gid=100

    Reiniciar o Apache:
    # /etc/init.d/apache2 restart

    7) Módulo “suEXEC” no Apache2
    Os módulos suEXEC e suPHP possuem similaridade em seus nomes por se tratarem de uma mesma implementação, porém de abrangência diferenciada. O suEXEC é utilizado para qualquer aplicação externa que utilize CGI ou SSI (como Perl, por exemplo) enquanto o suPHP é específico para scripts em PHP. Em ambos os casos a restrição é feita sobre as mesmas regras gerais:

  • O script a ser executado deve ter owner e grupo do usuário que possui o virtual host.
  • As permissões não devem ser superiores a 644 para arquivos e 755 para pastas que contenham os arquivos (exceto a pasta public_html, que deve ter no máximo permissão 750, owner igual ao usuário e grupo nobody).
  • Estas configurações são necessárias pois ao executar um script PHP ou CGI o usuário definido no virtual host será utilizado para executar o processo, ao invés do usuário do servidor Apache. Isso evita que usuários tenham acesso ou até mesmo executem scripts de outros usuários hospedados no mesmo servidor.
  • “suEXEC” cria um ambiente muito mais seguro, pois os aplicativos CGI trabalharão sob as permissões do usuário/grupo do proprietário do site, e não de root ou do servidor Apache. Ou seja, permite a chamada de scripts a partir dos IDs dos diversos usuários, não utilizando o ID do servidor de páginas web Apache chamador.
    obs: as permissões dos arquivos PHP não podem ser maiores que 755 (ler/escrever/executar pelo seu usuário, ler/executar pelo grupo.todos). O padrão é 644.

    Para habilitar o suEXEC:
    # a2enmod suexec

    8) Módulo “rewrite” no Apache2

    Na instalação default do Apache2.2 no Debian, o módulo mod_rewrite não é habilitado por default. Então, caso este módulo seja necessário, o usuário deve habilitá-lo manualmente.

    Este módulo é importante especialmente para criar URLs amigáveis quando se utiliza CMSs como WordPress e outros. Observe que os search engines — como o Google — não têm acesso aos arquivos dinâmicos dos sites. Os spiders acessam apenas o código (X)HTML gerado por eles. Um spider é como um usuário qualquer. A diferença é que ele é uma ferramenta automatizada que percorre os links que encontra e cria um índice que será usado pelo sistema de busca. Um “spider” é como um usuário qualquer. A diferença é que ele é uma ferramenta automatizada que percorre os links que encontra e cria um índice que será usado pelo sistema de busca.

    Sendo assim, uma página que antes seria acessada pela URL:
    http://www.seusite.com/index.php?data=01-02-2005&nome=meu-artigo

    agora será acessada por:
    http://www.seusite.com/01/02/2005/meu-artigo.

    A URL antiga continuará funcionando e o buscador só passará a listar a nova URL se todos os links para a referida página forem atualizados para a nova URL. A troca — ou reescrita — das URLs é feita pelo apache de maneira transparente ao usuário, portanto, apenas o servidor tem conhecimento desta reescrita. O usuário, assim como o spider, não consegue perceber este processo. A reescrita (feita pelo mod_rewrite) é um processo interno ao servidor web. Este analisa uma regra de reescrita (RewriteRule) existente em um arquivo .htaccess, executa um redirecionamento e entrega o recurso ao user agent sem informar uma nova URL.

    Os procedimentos para ativação do módulo são:

    a) Atualize a tabela para uso do mlocate e verifique onde se encontra o módulo mod_rewrite.so, conforme comandos abaixo:

    # updatedb
    # locate mod_rewrite.so

    A resposta deve ser: “/usr/lib/apache2/modules/mod_rewrite.so”

    b) Apache2 usa a pasta “/etc/apache2/mods-enabled” de módulos habilitados. Verifique o módulo rewrite (arquivo rewrite.load) não se encontra presente. Se não, há duas formas de ativar o módulo:

    Método-1:
    Um procedimento muito simples e direto:

    # a2enmod rewrite

    É só isso. Observe a criação do arquivo rewrite.load em /etc/apache2/mods-enabled/:
    lrwxrwxrwx 1 root root rewrite.load -> ../mods-available/rewrite.load

    Método-2:
    Um procedimento manual e mais tradicional. Faça a criação do arquivo rewrite.load manualmente, editando-o em seguida para acrescentar a linha "LoadModule rewrite_module /usr/lib/apache2/modules/mod_rewrite.so", conforme abaixo:

    # cd /etc/apache2/mods-enabled
    # touch rewrite.load
    # mcedit rewrite.load (você pode usar qualquer editor)

    c) Edite o arquivo /etc/apache2/sites-available/default, fazendo a troca das linhas:

    DE:

    Options Indexes FollowSymLinks MultiViews
    AllowOverride None
    Order allow,deny
    allow from all

    POR:

    Options Indexes FollowSymLinks MultiViews
    AllowOverride all
    Order allow,deny
    allow from all

    d) Reinicie o Apache:

    # /etc/init.d/apache2 restart

    Links:
    1- Instalar servidor LAMP (Linux + Apache + PHP + MySQL) no Debian
    2- Configurar domínios virtuais do Apache em máquina Linux/Debian
    3- How enable mod_rewrite in apache2
    4- URLs amigáveis – esclarecendo dúvidas
    5- Ativando o mod_rewrite
    6- Módulos do Apache: rewrite e deflate
    7- MDLog:/sysadmin

    comentários
    1. Depois do procedimento meu server apresenta erro 500

    2. rbl1984 disse:

      Cara parabéns pelo post foi de muita utilidade…

    Deixe um comentário, pois isto é muito motivante para continuarmos este trabalho

    Preencha os seus dados abaixo ou clique em um ícone para log in:

    Logotipo do WordPress.com

    Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

    Imagem do Twitter

    Você está comentando utilizando sua conta Twitter. Sair / Alterar )

    Foto do Facebook

    Você está comentando utilizando sua conta Facebook. Sair / Alterar )

    Foto do Google+

    Você está comentando utilizando sua conta Google+. Sair / Alterar )

    Conectando a %s