Módulos do Apache PHP, suPHP, suexec e rewrite no Linux – Debian

Publicado: 25/12/2012 em Linux, Serviços IP
Tags:,

1. Comandos úteis
1.1 Para verificar disponibilidade de módulos Apache e seu estado
$ apache2 -l
// lista os módulos compilados com o servidor Apache. Estes módulos já estão no estado habilitado (ou seja, ativos e em funcionamento).
$ ls /usr/lib/apache2/modules/
// lista os módulos do Apache2 instalados (mas não necessariamente habilitados). Para um módulo ir ao estado habilitado, este necessita do comando a2enmod
$ ls -la /etc/apache2/mods-enabled/
// lista os módulos do Apache2 no estado habilitado. São links simbólicos para /etc/apache2/mods-available/
# a2enmod
// lista os módulos do Apache2 presentes na pasta default de arquivos de módulos: /usr/lib/apache2/modules/ (independentemente de estarem habilitados ou não).
// oferece a possibilidade de habilitar algum módulo.
# a2dismod
// Desabilita um módulo Apache2 (remove as entradas do diretório “/etc/apache2/mod-enabled/” relativo ao módulo).  Caso seja iniciado sem parâmetros, será mostrado a lista dos módulos habilitados e solicitado do usuário escolher um deles.

Exemplos:
i) Exemplo-1: verificar se os módulos suphp e suexec estão disponíveis no S.O.
$ ls /usr/lib/apache2/modules/ | grep -E  '(suphp|suexec)'
mod_suexec.so
mod_suphp.so

// Vê-se pela resposta do sistema que os módulos suphp e suexec estão disponíveis no ambiente do S.O.

ii) Exemplo-2: verificar se módulo suphp está no estado 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

// Vê-se pela resposta do sistema que o módulo suphp já está no estado habilitado.

iii) Exemplo-3 verificar quais módulos foram compilados junto com o Apache
$ apache2 -l
Compiled in modules:
core.c
mod_log_config.c
mod_logio.c
prefork.c
http_core.c
mod_so.c

1.2 Para o PHP
$ php -v
// informa a versão do PHP, inclusive se o PHP é CLI ou CGI
$php -i
// Esta opção de linha de comando chama a função phpinfo() e imprime os resultados. Se o PHP não está funcionando bem, o “php -i” imprime mensagem de erro impressa antes ou dentro das tabelas de informação. Utilizando o modo CGI o resultado impresso está em HTML, e ela por isso é um pouco grande.
$ php -r 'print_r(get_defined_constants());' | less
// para verificar os valores das contanstes predefinidas do PHP
$ php -m
// lista os módulos PHP e os módulos Zend compilados e carregados
$ php -l
//Esta opção fornece uma maneira conveniente apenas realizar uma checagem de sintaxe no código PHP fornecido.

2. Configurações do Apache para usar o PHPÍcone do Apache
Existem três maneiras diferentes de se configurar o Apache para usar o PHP:

a) O interpretador PHP como um módulo embutido ("built-in") do Apache - mod_php;
b) O interpretador PHP como um binário CGI - mod_cgi.
c) O interpretador PHP como um binário CGI, porém usando uma aplicação "wrapper" - Suexec
     ou Suphp

No entanto, tem sido relativamente comum encontrarmos o interpretador PHP rodando em um único servidor sob mais de um modo simultâneo: uma versão rodando como módulo embutido do Apache e outra versão rodando como CGI.

2.1 PHP como módulo embutido Apache
Como módulo embutido do Apache (mod_php), o interpretador PHP é compilado para ser parte integrante do binário do Apache, fazendo com que o interpretador do PHP quando executado esteja no âmbito do processo Apache (com seu id/permissões). Cada processo filho do Apache já conterá uma imagem binária do interpretador PHP (já que este será parte do próprio Apache). Assim, o interpretador PHP é executado com as permissões do usuário do Apache (usualmente “nobody” no CenTOS ou “www-data” no Debian).

mod_php (ou o Apache2 Handler) é um módulo do Apache para executar scripts PHP, que possui a característica de manter os processos de trabalho em execução em vez de começar e parar PHP para cada requisição Apache (ou seja, característica de persistência). Ou de outra maneira, o mod_php conserva os processos PHP “vivos” e rodando em vez de repetidamente ter de criá-los e destruí-los (como é feito no modo CGI). Este comportamento traz  ganhos de performance, embora que também  traga algumas dificuldades quanto à permissões de arquivos considerando que os mesmos pertencem ao usuário “nobody” (no CenTOS) ou “www-data” (no Debian) – vide mais abaixo esse aspecto. Retomando, estando o interpretador PHP como um módulo embutido do Apache fará o servidor ter um melhor desempenho no tratamento de páginas dinâmicas contendo scripts PHP (assim como mais estável sob carga) quando comparado com o modo CGI.  Vale salientar que é no modo mod_php que a maioria dos sistemas pré-configurados dos hostings comerciais geralmente são entregues.

Estando o servidor configurado para rodar o interpretador PHP como um módulo embutido do Apache (mod_php), tem-se as opções de utilizar tanto o php.ini como .htaccess para alterar as configurações do Apache (em contraste com o modo CGI onde só terá a opção da utilização dos arquivos locais php.ini).

Como neste modo o interpretador PHP é executado com as permissões do usuário do Apache, existem restrições quanto ao acesso a arquivos e demais recursos, como as bases de dados. Por exemplo, se você estiver usando o PHP para acessar um banco de dados, a menos que o banco de dados tenha um controle de acesso interno, você terá que fazer o banco de dados acessível ao usuário “www-data”. Isso significa que um script malicioso pode acessar e modificar o banco de dados, mesmo sem um usuário e senha. É possível que um web “spider” passe em uma página web de administração do banco de dados e remova todos os bancos de dados. Você pode se proteger contra isso usando autorização do Apache, ou pode desenvolver seu modelo de acesso prório usando LDAP, arquivos .htaccess, etc. e incluir esse código como parte dos seus scripts PHP.

Um erro freqüente de segurança é dar ao Apache permissões de administrador (root), ou aumentar as habilidades do Apache de uma outra forma. Aumentar as permissões do usuário do Apache para administrador é extremamente perigoso e pode comprometer o sistema inteiro. Logo, sudo’ing, chroot’ing, ou então executar como root, não devem ser considerados por aqueles que não são profissionais em segurança.

Resumindo:
- interpretador PHP é parte integrante do Apache e roda obrigatoriamente com o id deste último
  ("nobody" no CenTOS ou "www-data" no Debian);
- não existe processo PHP externo;
- opções de usar tanto o php.ini como .htaccess para alterar as configurações do Apache;
- limitações para acesso a arquivos e base de dados;
- PHP persistente;
- PHP como um módulo do Apache apresenta melhor desempenho (assim como mais estável sob carga)
  comparado com o modo CGI (ou fastCGI e mod_suphp).

2.2 PHP como modo binário CGI
Modo CGI roda scripts PHP como módulo CGI, ao invés de módulo embutido Apache. O modo CGI também é reconhecido por sua flexibilidade em muitos aspectos. O CGI é executado como um processo independente para cada requisição, fazendo uma chamada exec() ou fork() para o executável do interpretador PHP (ou seja, o Apache faz a criação de um processo externo PHP para cada necessidade de execução de script PHP), o que significa que cada requisição ao Apache que necessite execução de script PHP haverá a criação de um novo processo para o interpretador PHP. Ou seja, o modo CGI não é persistente o que provoca uma certa perda de performance.

Em outras palavras, o modo CGI executa os scripts PHP em processos isolados do servidor Webserver. Ou seja, PHP funcionando no modo CGI é mais seguro do que funcionando como módulo Apache (mod_php) pois o servidor agora tem condições de gerenciar e controlar o acesso aos binários. Executar PHP como um CGI significa que você basicamente informa a seu sevidor web a localização do interpetador PHP (arquivo executável), e o servidor web dá inicio a execução daquele executável, dando a ele o script que voce chamou, isto toda vez que você visita a página. Isto significa que você carrega a página, o PHP necessita ler o arquivo php.ini e fazer sua configuração, necessita carregar todas suas extensões, e então necessita iniciar o trabalho de análise do script – existe muito trabalho repetido que no modo mod_php não existe.

O modo CGI é mais lento quando comparado com mod_php, devido justamente ao fato de que a cada nova solicitação ao Apache um novo processo do interpretador PHP é criado e posteriormente necessita ser destruído.

No modo CGI puro, os scripts não analisados e executados como usuário Apache (“nobody” no CenTOS ou “www-data” no Debian). Entretanto, se o CGI estiver usando uma aplicação “wrapper” (suexec ou suPHP – ver logo adiante neste post) os scripts serão executados com a identificação/permissões da conta do dono do script PHP (haverá um chaveamento na identificação do processo).

Quanto a possibilidade de alterar parâmetros de configuração do Apache, no modo CGI só haverá a opção de utilizar os arquivos locais php.ini (perdendo a possibilidade de se utilizar os arquivos .htaccess). Neste sentido, é importante perceber a diferença principal entre .htaccess ou php.ini:

  • o   .htaccess   pode ser colocado no diretório raiz e fazer efeito para todos os subdiretórios com apenas um arquivo;
  • o   php.ini  tem efeito apenas no diretório em que está colocado.
Resumindo:
- cada requisição do Apache criará um novo processo do interpretador PHP;
- PHP não persistente;
- os processos CGI do interpretador PHP herda o id/permissões do Apache;
- apenas o php.ini é utilizado para alterar as configurações do Apache (.htaccess NÃO utilizado)*;
- PHP como CGI é mais seguro que o PHP como módulo do Apache;
- o modo CGI é mais lento quando comparado com mod_php.

(*) mas pode ser colocado um arquivo .htaccess na pasta que este será lido. Para alterar as configurações do php.ini default, deve-se neste arquivo .htaccess ter o apontamento para o arquivo php.ini particular para o script em questão.

2.3 PHP como um binário CGI usando uma aplicação “wrapper” suexec ou suphp
O servidor Apache pode ser configurado como CGI usando uma aplicação “wrapper” para servir páginas dinâmicas de scripts PHP. Para isto deve ser instalando um dos dois módulos suexec ou suPHP (ou ambos):

  • Módulo suexec (mod_suexec);
  • Módulo suPHP (mod_suphp).

Estes wrappers são utilizados pelo Apache HTTP Server para chavear a identificação do processo CGI para outro usuário diferente do seu, antes de passar o controle para execução do programa CGI (para o interpretador PHP). De outra forma, suexec e suphp são módulos Apache (mod_suexec e mod_suphp) que permitem aos usuários do Apache executarem scripts CGI e SSI sob IDs dos proprietários destes scripts, chaveando do ID do servidor web (no Debian “www-data”, que recebe UID=33). Usado corretamente, esse recurso pode reduzir consideravelmente os riscos de segurança existentes permitindo aos usuários desenvolverem e executarem programas CGI ou SSI particulares sem riscos para o ambiente computacional.

Tanto o suexec como o suphp fazem várias verificações de segurança antes de decidir executar os scripts. Um pouco destas verificações:

  • verificar se o usuário que tem que executar o script é um usuário válido no sistema;
  • verificar se o arquivo não permite escrita pelo “world” (ou seja, no mínimo 755. Melhor seria 644);
  • requer que o diretório que contém o script CGI não permita escrita por outros (ou seja, 755);
  • verificar se o diretório é de propriedade do mesmo usuário;
  • verificar se o arquivo é de propriedade do mesmo usuário;
  • e mais algumas verificações adicionais…

Depois que todas estas verificações tenham sido concluídas com êxito, o wrapper chaveia o ID do processo: do UID do servidor web para o UID do usuário proprietário do script que será executado. Só então é que se inicia a execução do script PHP.

Caso as verificações tenham insucesso, ou caso ocorra falha quando da execução do script, o arquivo de log de erros do Apache indicará “Premature end of script headers”, e o arquivo de log de erros do wrapper indicará o problema com mais detalhes, por exemplo, “error: directory is writable by others”. Na tela do navegador do usuário, a indicação de erro será uma mensagem de “Internal Server Error” (error 500). Deve ser observado que o Debian Linux não faz automaticamente o “rotate” do arquivo de log do wrapper, o qual poderá crescer excessivamente. Para evitar isto, deve-se programar este ‘rotate’ através dos arquivos em /etc/logrotate.

Estes wrappers são muito importantes para os administradores de sites, pois caso um processo esteja consumindo exageramente o tempo de CPU, este terá seu proprietário rapidamente identificado. Caso o wrapper não estivesse sendo utilizado, não haveria condições de saber a quem pertencia o script problemático (pelo menos de forma rápida e direta), pois todos os processos PHP tanto no mod_php como CGI padrão pertencem a um mesmo proprietário (ao servidor web, que no caso do Debian possui id=”www-data”).

Sob execução de um wrapper, a manipulação dos arquivos PHP e as suas pastas não mais ocorrem como uid=”nobody” ( ou uid=”www-data”, para o caso do Debian), mas identificado como o usuário proprietário do script (e tendo suas permissões e propriedades). Com o wrapper torna-se possível o funcionamento do CMS sem a necessidade de fixar as permissões como 777 para as pastas e para os scripts PHP que serão executados, o que torna o site do usuário flexível no uso e seguro.

Resumindo:
- cada requisição do Apache criará um novo processo do interpretador PHP;
- PHP não persistente;
- o interpretador PHP passará por um chaveamento para estar associado ao id e permissões do
  proprietário do script PHP a ser executado;
- apenas o php.ini utilizado para alterar as configurações do Apache (.htaccess NÃO utilizado);
- PHP usando aplicação "wrapper:  é mais seguro que o PHP como módulo do Apache, bem
  como do modo CGI tradicional;
- os mecanismos suexec e suPHP do Apache proporcionam maior segurança para casos de ataques;
- alto custo de performance, sendo mais lento que o mod_php e modo CGI puro.

a) Suexec
Suexec – “Switch” o usuário antes de executar programas externos. O Suexec consiste de um módulo para o web server e um binário executável os quais agem como um wrapper. Suexec exige uma configuração individual para cada host virtual.

Antes de executar o script, Suexec faz o log da execução em suexec.log (se não mudou durante a compilação). O ponto negativo do suexec é que ele é o mais lento de todos: mais lento que mod_php, CGI padrão e suphp.

b) SuphpLogo do módulo do suphp
Suphp é um módulo Apache (mod_suphp) e executa scripts php como CGI. Seu funcionamento é muito semelhante ao Suexec. Suphp não exige configuração para cada host virtual. Ele simplesmente executa os scripts php com as permissões do usuário proprietário do script. Suphp é mais lento que o módulo CGI padrão e muito mais lento que o módulo embutido PHP do Apache – modphp (cerca de 25 vezes). Entretanto ele é mais rápido que o suexec. Suphp inicia um processo PHP a cada solicitação do Apache. Isto implica que ele não utiliza nenhum recurso (memória RAM, processador, …) quando nenhuma página está sendo solicitada. Podemos considerar que o Suphp é ideal para websites de tráfego não elevado.

Existem desvantagens em usar o Suphp ?
O Suphp tem um defeito que é causar uma perda de performance no servidor comparado com o módulo embutido PHP (modphp). Suphp executa scripts PHP em modo CGI, o qual, como temos comentado neste post, causa uma certa lentidão.

c) Comando associado para instalação:
# apt-get install apache2-suexec libapache2-mod-suphp
Suexec e Suphp possuem similaridades por se tratar 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 e PHP, por exemplo) enquanto o Suphp é específico para o PHP e traz melhores resultados de desempenho. Ambos, Suexec e Suphp, podem ser utilizados simultaneamente em uma mesma máquina sem quaisquer problemas.


2.4 Como verificar sob qual modo o PHP está sendo executado? Como obter mais informações do ambiente Apache sendo executado?

Existem várias maneiras.
a) executar um pequeno programa PHP do tipo <?php phpinfo() ?>
Observar a resposta quanto a diretiva “Server API”, que basicamente poderá vir como “CGI/FastCGI” ou “Apache 2.0 Handler”, dependendo do modo como o Apache está utilizando o interpretador PHP.

b) Executar o programa PHP abaixo:
<?php
echo "Hostname: ". @php_uname(n) ."<br \>";
if (function_exists( 'shell_exec' )) {
echo "Hostname: ". @gethostbyname(trim(`hostname`)) . "<br \>";
} else {
echo "Server IP: ". $_SERVER['SERVER_ADDR'] . "<br \>";
}
echo "Platform: ". @php_uname(s) ." ". @php_uname(r) ." ". @php_uname(v) ."<br \>";
echo "Architecture: ". @php_uname(m) ."<br \>";
echo "Current script owner:: ". get_current_user () ." ( UiD: ". getmyuid() .", GiD: ". getmygid() ." )<br \>";
echo "ID do processo PHP: ". getmypid()."<br \>";
echo "Curent Path: ". getcwd () ."<br \>";
echo "Server Type: ". $_SERVER['SERVER_SOFTWARE'] . "<br \>";
echo "Server Admin: ". $_SERVER['SERVER_ADMIN'] . "<br \>";
echo "Server Signature: ". $_SERVER['SERVER_SIGNATURE'] ."<br \>";
echo "Server Protocol: ". $_SERVER['SERVER_PROTOCOL'] ."<br \>";
echo "Server Mode: ". $_SERVER['GATEWAY_INTERFACE'] ."<br \>";
?>

Uma possível resposta seria:
Hostname: server1.meusite.com.br
Hostname: 66.92.73.198
Platform: Linux 2.6.32-042stab059.7 #1 SMP Tue Jul 24 19:12:01 MSK 2012
Architecture: i686
Current script owner:: web1 ( UiD: 5004, GiD: 5005 )
ID do processo PHP: 29504
Curent Path: /var/www/clients/client1/web1/web/subdominios/meuscript
Server Type: Apache/2.2.16 (Debian)
Server Admin: webmaster@meusite.com.br
Server Signature:
Apache/2.2.16 (Debian) Server at equipe.meusite.com.br Port 80
Server Protocol: HTTP/1.1
Server Mode: CGI/1.1

3. Alguns apontamentos importantes

3.1) Instalações padrões
a) Servidor LAMP padrão
#apt-get install apache2 apache2-utils libapache2-mod-php5 php5 mysql-server-5.0 php5-mysql
// Vê-se uma instalação simples, configurando o Apache para executar o interpretador PHP como seu módulo embutido (“built-in”) – modphp;
obs: vide post Instalar servidor LAMP (Linux + Apache + PHP + MySQL) no Debian

b) Servidor típico preparado para suportar o WordPress
Instalar servidor LAMP, na forma apontada acima
# apt-get install libapache2-mod-suphp
# a2enmod rewrite
# a2dismod php5
# a2enmod suphp
obs: vide post Instalar o WordPress no Linux distribuição Debian

3.2) Quanto ao CORE do Apache:
# apt-get install apache2 apache2.2-common apache2-doc apache2-mpm-prefork apache2-utils
i) apache2-mpm-prefork:
é o padrão Linux Apache MPM (Multi-Processing Modules). Neste modo, um único servidor de processos master gera vários servidores de processos filhos (ou sobressalentes) para tratar as solicitações de entrada. O servidor master bifurca (gera) processos servidores filhos antes deles serem utilizados. É uma implementação non-threaded. Cada processo manipula apenas uma conecção de cada vez. Não é tão rápida quanto ao modo threaded (apache2-mpm-worker), porém é avaliada como a mais estável. Para servidores web de alto tráfego é recomendado o modo apache2-mpm-worker.

OBS: para saber qual o modo do servidor Apache instalado, basta usar o comando:
# dpkg -l | grep apache

ii) apache2:
metapacote do servidor HTTP Apache.
iii) apache2-common:
instala importantes arquivos de suporte ao Apache2.0 requerido para todas as plataformas.
apache2-utils:
provê alguns programas adicionais úteis para qualquer webserver. Isto inclui:
– ab (Ferramenta de avaliação de desempenho – “benchmark” – do Apache);
– logresolve (resolve endereços IP para nomes de máquina nos arquivos de log);
– htpasswd (Manipulate basic authentication files)
– htdigest (manipula arquivos de autenticação “basic”);
– dbmmanage (Manipula arquivos de authenticação básicas no formato DBM, usando perl)
– htdbm (Manipula arquivos de authenticação básicas no formato DBM, usando APR)
– rotatelogs (periodicamente para de escrever em um arquivo de log e abre um novo)
– split-logfile (Divide um único log que inclui múltiplos vhosts)
– checkgid (Verifica se o chamador pode setgid para um grupo especificado )
– check_forensic (Extrai a saída mod_log_forensic dos arquivos de log do Apache)
– httxt2dbm (Gera arquivos dbm para uso com RewriteMap)

3.3) Quanto aos MÓDULOS do Apache:
apt-get install libapache2-mod-php5 libapache2-mod-suphp libapache2-mod-fcgid apache2-suexec
i) libapache2-mod-php5:
módulo PHP para o webserver Apache2 (este módulo funciona apenas com o modo Apache prefork MPM, pois ele não é compilado com “thread-safe”). As seguintes extensões estão embutidas (“built in”):
bcmath bz2 calendar Core ctype date dba dom ereg exif fileinfo filter ftp gettext hash iconv json libxml mbstring mhash openssl pcre Phar posix Reflection session shmop SimpleXML soap sockets SPL standard sysvmsg sysvsem sysvshm tokenizer wddx xml xmlreader xmlwriter zip zlib.

ii) libapache2-mod-fcgid:
módulo de alta performance alternativo ao mod_cgi ou mod_cgid. Instancia um número suficiente do programa CGI para tratar solicitações concorrentes. Estes programas permanecem em execução para tratarem futuras solicitações entrantes. Tem sido a preferência dos desenvolvedores PHP como alternativa para executarem processos em mod_php, apresentando uma performance muito similar.

iii) apache2-suexec:
programa suexec padrão para o mod_suexec do Apache 2. Fornece o programa auxiliar suexec padrão para o mod_suexec. Esta versão é compilada com /var/www como a raiz dos documentos (“document root”) e public_html como sufixo para diretórios de usuário (“userdir”). Se houver necessidade de configurações diferentes, deve-se usar o pacote apache2-suexec-custom.

iv) libapache2-mod-suphp:
módulo suPHP do Apache2 para executar o interpretador PHP com as permissões do proprietário do script. Se há a necessidade de se executar um webserver para muitos usuários diferentes, é recomendável que cada script PHP seja executado com a identidade do usuário proprietário daquele script – em vez de ter todos os scripts sendo executados através do mesmo usuário (tipicamente www-data nos sistemas Debian). suphp permite isto facilmente, alterando o uid do processo de execução do interpretador PHP para o do proprietário do script php .
O suPHP consiste de dois componentes: mod_suphp e suPHP.

  • mod_suphp: módulo do Apache2, que substitui mod_php (podendo os dois módulos conviverem simultaneamente).
  • suPHP: 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).

Com o uso do binário “suphp setuid root” (do pacote suphp-common), este módulo do Apache2 altera o uid do processo que está com o interpretador PHP para o proprietário do script PHP. É uma alternativa compatível módulo mod_fastcgi do Apache2.
Notas:

  • Ao instalar libapache2-mod-suphp, automaticamente também está sendo instalado o pacote suphp-common.
  • O arquivo de configuração do suPHP está em /etc/suphp/suphp.conf
  • O arquivo de configuração para o módulo suPHP  está em /etc/apache2/mods-enabled/suphp.load
  • O arquivo de configuration do suPHP para o Apache está em  /etc/apache2/mods-enabled/suphp.conf
  • O arquivo de log do suPHP está em /var/log/suphp/suphp.log.
  • O suPHP necessita do php5-cgi para ser instalado. Ele usa PHP CGI para iniciar a execução dos scripts.Por esta razão, suphp é muito mais lento que mod_php. Porém Suphp adiciona segurança e identificação aos usuários que executam os scripts PHP.

v) mod_rewrite:
é um módulo do servidor Apache2, responsável pela reescrita de URLs em páginas Web. Ao instalar o Apache2, este módulo estará disponível em /usr/lib/apache2/modules/mod_rewrite.so , embora ainda não ativado. Seu principal objetivo é tornar as URL’s mais “amigas” dos usuários e dos motores de busca. Na verdade, o módulo mod_rewrite permite ao usuário fazer quase qualquer coisa nas solicitações entrantes ao servidor Apache2. Para funcionar, o mod_rewrite necessita ser ativado e da existência de um arquivo .htaccess devidamente configurado (veja detalhes em Configuração .htaccess do Apache2). Para ativar o mod_rewrite no Debian basta um comando simples: “a2enmod rewrite”.
Este módulo é especialmente importante quando se utiliza CMSs, como WordPress ou 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, embora seja 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.

3.4) Especialmente, quanto ao funcionamento do PHP
apt-get install php5 php5-common php5-cli php5-cgi
i) php5:
metapacote que dá garantias de se ter instalado pelo menos uma das quatro versões do interpretador PHP5. Removendo este pacote não removerá o PHP do sistema, no entanto pode remover outros pacotes que dependam deste.
ii) php5-common:
contém a documentação e arquivos exemplos relevantes para todos os outros pacotes construídos do fonte php5.
iii) php5-cli:
interpretador de linha de comando para linguagem de script php5 encontrado em /usr/bin/php5. Muito útil para testar scripts PHP a partir de um shell ou executar arquivos batch de shell scripting. Observe que o PHP está disponível no Debian como CLI ou CGI, pelos pacotes php5-cli e php5-cgi.
iv) php5-cgi:
interpretador de scripts PHP no modo CGI encontrado em /usr/lib/cgi-bin/php5. O Suphp necessita do php5-cgi para ser instalado.  Foi construído para uso no Apache2 com “mod_actions”, ou com qualquer outro CGI httpd que suporte mecanismos similares.
Nota: a maioria dos usuários do Apache provavelmente utilizam o pacote libapache2-mod-php5. Observe que o PHP está disponível no Debian como CLI ou CGI, pelos pacotes php5-cli e php5-cgi.

3. Executando através dos módulos SuEXEC e SuPHP

a) 500 Internal Server Error

Isto significa que suphp está provavelmente funcionando, porém por alguma razão ele não permitiu a execução do script.
Possiveis razões para isto:

    •   Verifique se você não tem qualquer opcode PHP  caching (APC, etc) sendo executado.  Se você está executando qualquer tipo de cache   PHP cache, suphp nunca funcionará. Você deve desabilitar seu cache de opcode.  Se você está usando APC, você pode desabilitar seu  system-wide by simplesmente editando /etc/php5/conf.d/apc.ini  e comentar a linha abaixo com ponto e vírgula como abaixo:

;extension=apc.so

    • Um outro elemento importante são as permissões dos arquivos. SuPHP falhará (com um 500 Internal Server Error) se qualquer arquivo que tenha permissões que não sejam permitidas, conforme definido em /etc/suphp/ suphp.conf. Por exemplo:

; Security options
allow_file_group_writeable=false
allow_file_others_writeable=false
allow_directory_group_writeable=false
allow_directory_others_writeable=false

  • As permissões do arquivo/pasta são excessivamente permissivas. Arquivos devem ter permissões  644 ou menores e pastas 755 ou menores, caso contrário suPHP  recusará analisar o script.
  • O arquivo é de propriedade do usuário apache. Se a questão principal para usar suPHP é separar usuário apache do usuário proprietário do script, a criação de arquivos com propriedade de www-data é um passo para trás.  Por padrão, o proprietário do script deve ter um uid superior a 100 pora o suPHP aceitar. Isto significa que os arquivos com propriedade pertencente a www-data não funcionará. Você poderá precisar de ajustar min_gid em /etc/suphp.conf  de 100 para 33. Obviamente, isso não deve ser um problema se você só tem hosts virtuais.
  • Tabém deve ser verificado se o arquivo /var/log/suphp/suphp.log   não ultrapassou 2GB.
  • Por último, verifique /var/log/suphp/suphp.log e  /var/log/apache2/error.log por sugestões.

b) Arquivo de configuração do suPHP
Como dito, o arquivo de configuração está em /etc/suphp/suphp.conf, cujas instruções deconfiguração podem ser encontradas no site oficial do suPHP.
Aqui vamos tecer alguns detalhes:
docroot=/var/www:${HOME}/public_html ; o formato padrão
docroot=/* ; o motor suPHP irá analisar em qualquer lugar do sistema de arquivos, e não apenas no diretório html padrão.
check_vhost_docroot ; Verifica se o script PHP está dentro do DOCUMENT_ROOT especificado pelo webserver. Esta opção destina-se a evitar links simbólicos para além do diretório página. Você pode querer desativá-lo, quando você estiver usando mod_vhost_alias ou a diretiva Alias. Esta opção é desabilitada por padrão, se em tempo de compilação a opção “- disable-check-docroot” for especificada, caso contrário, é ativada por padrão.

4. Outros aspectos relevantes sobre o PHPÍcone do PHP
A partir versão 4.3.0, o PHP suporta um novo tipo SAPI (“Server Application Programming Interface”) chamado CLI que significa Command Line Interface. Como o próprio nome indica, essa SAPI tem foco no desenvolvimento de aplicações shell (ou no terminal/linha de comando) com o PHP. Há algumas diferenças entre a a CLI SAPI e a CGI SAPI. Mas é errado dizer que a versão CLI e CGI são SAPIs diferentes pelo motivo que elas compartilham muitos comportamentos idênticos.

Por “default”, o PHP é construído como dois programas: CLI e CGI. A versão CGI possibilita aos usuários executarem diferentes scripts PHP sob diferentes user-ids. De muitas maneiras, o SAPI CLI funciona da mesma forma como o SAPI CGI e outras SAPIs. No entanto, é importante ter o conhecimento de onde eles diferem porque pode afetar diretamente como se escreve os scripts. Podemos resumir da seguinte forma:

  • PHP CLI é a interface de linha de comando para o PHP (isto é, para criação de aplicações standalone);
  • PHP CGI é a “common gateway interface” para o PHP (isto é, voltada para aplicações web). Entre outras coisas ela manipula cabeçalhos HTTP e certos parâmetros de segurança.

Ou com mais detalhes, estas são as diferenças mais importantes entre CLI e CGI:

  • Ao contrário da SAPI CGI, por padrão CLI não escreve cabeçalhos para a saída;
  • Há algumas diretivas do php.ini que são sobrescritas pela SAPI CLI porque não fazem sentido no ambiente shell:
    • html_errors: o padrão CLI é FALSO
    • implicit_flush: o padrão CLI é TRUE
    • max_execution_time: o padrão CLI é 0 (ilimitado)
    • register_argc_argv: o padrão CLI é TRUE
  • O usuário pode ter argumentos na linha de comando para o script! A variável “$ argc” informa o número de argumentos passados ​​para a aplicação. E o array “$ argv” informa os argumentos.
  • Existem três novas constantes definidas para o ambiente shell: STDIN, STDOUT, STDERR. Todos elas são manipuladores de arquivos para dispositivos shell correspondentes. Por exemplo STDIN é o manipulador para fopen(‘php://stdin’, ‘r’). Assim, você pode ler uma linha de stdin como esta: $strLine = trim(fgets(STDIN));. STDIN já está definido para você pelo PHP CLI!
  • PHP CLI não altera o diretório atual para o diretório de execução do script. O diretório atual para o script será o diretório onde se digitou o comando PHP CLI.
  • Há um número de opções úteis disponíveis para PHP CLI. Que lhe permitirá obter algumas informações valiosas sobre a configuração do php, sob o script php ou ainda executá-lo em diferentes modos.

Links:
1- Instalar servidor LAMP (Linux + Apache + PHP + MySQL) no Debian
2- Configurar domínios virtuais do Apache em máquina Linux/Debian
3- Configuração .htaccess do Apache2
4- Documentação do Apache: suEXEC Support
5- PHP CLI vs. PHP CGI
6- Utilizando o PHP na linha de comando
7- MDLog:/sysadmin
8- Exercícios para compreender o funcionamento dos módulos PHP e suPHP

Anúncios
comentários
  1. Marcos disse:

    bacana as dicas, porém no # apache2 -l , não aparece se o mod_rewrite tá ativado, mesmo estando e no $ ou # php -l ou php5 -l , nada acontece.

    • O comando “apache2 -l” lista os módulos que foram compilados conjuntamente com o servidor Apache. Se não aparece é porque ele não fora compilado com o apache (que é a situação default). Utilize os outros comandos para identificar que ele está disponível e será carregado quando solicitado pelo Apache.

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