Posts com Tag ‘php’

1. Variáveis de ambiente do servidor web
$_SERVER é um array contendo informação como cabeçalhos, paths, e localizações do script. Trata-se de uma variável ‘superglobal’, ou global automática. Isto simplismente significa que ela está disponível aos scripts em todos os escopos.

<?php
$indicesServer = array('PHP_SELF',
     'argv',
     'argc',
     'GATEWAY_INTERFACE',
     'SERVER_ADDR',
     'SERVER_NAME',
     'SERVER_SOFTWARE',
     'SERVER_PROTOCOL',
     'REQUEST_METHOD',
     'REQUEST_TIME',
     'REQUEST_TIME_FLOAT',
     'QUERY_STRING',
     'DOCUMENT_ROOT',
     'HTTP_ACCEPT',
     'HTTP_ACCEPT_CHARSET',
     'HTTP_ACCEPT_ENCODING',
     'HTTP_ACCEPT_LANGUAGE',
     'HTTP_CONNECTION',
     'HTTP_HOST',
     'HTTP_REFERER',
     'HTTP_USER_AGENT',
     'HTTPS',
     'REMOTE_ADDR',
     'REMOTE_HOST',
     'REMOTE_PORT',
     'REMOTE_USER',
     'REDIRECT_REMOTE_USER',
     'SCRIPT_FILENAME',
     'SERVER_ADMIN',
     'SERVER_PORT',
     'SERVER_SIGNATURE',
     'PATH_TRANSLATED',
     'SCRIPT_NAME',
     'REQUEST_URI',
     'PHP_AUTH_DIGEST',
     'PHP_AUTH_USER',
     'PHP_AUTH_PW',
     'AUTH_TYPE',
     'PATH_INFO',
     'ORIG_PATH_INFO') ;

echo '<table cellpadding="2">' ;
foreach ($indicesServer as $arg) {
     if (isset($_SERVER[$arg])) {
          echo '<tr><td>'.$arg.'</td><td>' . $_SERVER[$arg] . '</td></tr>' ;
     }
     else {
          echo '<tr><td>'.$arg.'</td><td>-</td></tr>' ;
     }
}
echo '</table>' ;
?>

Referências:
1- Variáveis Superglobais: $_server

Anúncios

Os testes foram realizados em uma máquina alvo com:
Linux kernel 2.6.32
SO GNU Linux/Debian 6 (Squeeze)
Servidor de página Apache/2.2.16 (Debian)

Esta máquina servidora fora acessada de uma outra, a máquina do usuário, através de um navegador.

1. Preparar o ambiente para os testes
a) Instalações necessárias na máquina servidora
# apt-get install apache2 apache2-utils apache2-doc php5 libapache2-mod-suphp

b) Criar um usuário web1 e a pasta para realização dos testes na máquina servidora, definindo uma senha e as propriedades da pasta:
# useradd web1
# passwd web1    (será solicitado um password para o usuário web1)
# mkdir /var/www/client1
# chown web1:web1 /var/www/client1/

c) Na máquina do usuário, colocar na tabela de hosts (/etc/hosts) o resolvedor de nome da máquina servidora para facilitar os testes:
192.168.1.5    www.meusitio.com    meusitio.com

d) Preparar a máquina servidora para escutar a porta 8080 nestes testes  (apenas uma conveniência, não é uma exigência).
No arquivo /etc/apache2/ports.conf, trocar as diretivas de portas ficando do seguinte modo:

NameVirtualHost *:8080
Listen 8080
# /etc/init.d/apache2 restart

e) Resultados principais desta etapa de preparação:
– módulos PHP e suPHP do Apache instalados;
– usuário e pasta para execução dos testes criados.

2. Construir um site virtual para auxiliar nos testes
Criar o arquivo de configuração de host virtual /etc/apache2/sites-available/meusitio com o seguinte conteúdo:

<VirtualHost *:8080>
      ServerAdmin webmaster@localhost
      ServerName www.meusitio.com
      ServerAlias meusitio.com
      DocumentRoot /var/www/client1
      <Directory />
           Options FollowSymLinks
           AllowOverride None
      </Directory>
      <Directory /var/www/client1/>
           Options Indexes FollowSymLinks MultiViews
           AllowOverride None
           Order allow,deny
           allow from all
      </Directory>
      ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
      <Directory "/usr/lib/cgi-bin">
           AllowOverride None
           Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
           Order allow,deny
           Allow from all
      </Directory>
      ErrorLog ${APACHE_LOG_DIR}/error.log
      # Possible values include: debug, info, notice, warn, error, crit,
      # alert, emerg.
      LogLevel warn
      CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

O que é importante observar agora neste arquivo:
– existindo arquivos PHP na pasta /var/www/client1/ estes serão executados pelo módulo PHP do Apache, e não pelo módulo suPHP.

3. Teste-1: módulo Apache PHP utilizado
Condição: módulos PHP e suPHP habilitados, mas módulos rewrite e suexec desabilitados. Arquivo de host virtual do Apache conforme item 2 acima.
Crie o arquivo /var/www/client1/index.php  com o seguinte conteúdo:
<?php phpinfo();?>

Fixe as permissões da seguinte forma:
# chmod 777 /var/www/client1/index.php
# chmod 777 /var/www/client1/

Acesse a partir de um navegador da máquina do usuário a URL http://meusitio.com  para obter a página normalmente contendo informações de configuração do ambiente PHP instalado.
Conclusão: módulo Apache PHP sendo utilizado normalmente, e executando o script PHP solicitado.

4. Teste-2: módulo Apache PHP buscado pelo Apache e não encontrado
Condição: módulo suPHP habilitado, mas módulos PHP, rewrite e suexec desabilitados. Arquivo de host virtual do Apache conforme item 2 acima.
Desinstalar o módulo PHP.
# a2dismod php5
# /etc/init.d/apache2 restart

Novamente com o navegador da máquina do usuário acessar o sítio preparado. A resposta será a tradicional mensagem de erro interno:

Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.

Conclusão: módulo PHP5 não encontrado, encaminhando uma mensagem de erro interno.

5. Teste-3: módulo suPHP buscado pelo Apache, mas requisitos de segurança provocam erro de execução e script não é executado.
Condição: módulo suPHP habilitado, e módulos PHP, rewrite e suexec desabilitados. Nova configuração do host virtual do Apache.
Modifique  o arquivo de host virtual /etc/apache2/sites-available/meusitio de forma a possibitar a chamada do módulo suPHP pelo Apache:

<VirtualHost *:8080>
       ServerAdmin webmaster@localhost
       ServerName www.meusitio.com  
       ServerAlias meusitio.com
       DocumentRoot /var/www/client1
       <Directory />
            Options FollowSymLinks
            AllowOverride None
       </Directory>
       <Directory /var/www/client1/>
             Options Indexes FollowSymLinks MultiViews
             AllowOverride None
             Order allow,deny
             allow from all
             <IfModule mod_suphp.c>
                  <FilesMatch "\.ph(p3?|tml)$">
                  SetHandler application/x-httpd-suphp
                  suPHP_AddHandler application/x-httpd-suphp
                  </FilesMatch>
             </IfModule>
       </Directory>
       ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
       <Directory "/usr/lib/cgi-bin">
             AllowOverride None
             Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
             Order allow,deny
             Allow from all
       </Directory>
       ErrorLog ${APACHE_LOG_DIR}/error.log
       # Possible values include: debug, info, notice, warn, error, crit,
       # alert, emerg.
       LogLevel warn
       CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

É importante observar agora neste arquivo:
caso esteja o módulo suphp habilitado, o script PHP será executado no modo CGI, sob o “wrapper” suphp.

Conclusão: A resposta será a tradicional mensagem de erro interno, conforme teste anterior, mas por outro motivo:  por requisitos de segurança, o suPHP só executa o arquivo de script PHP se as permissões de sua pasta e do próprio arquivo não contrariarem certas regras de segurança definidas em seu arquivo de configuração localizado em /etc/suphp/suphp.conf:
; Security options
allow_file_group_writeable=
allow_file_others_writeable=
allow_directory_group_writeable=
allow_directory_others_writeable=

Se todas estas quatro diretivas de segurança contiverem a indicação “false”, então as permissões da pasta e do arquivo de script PHP  (index.php) não poderão ser superiores a 755 e 644 respectivamente.  Como estavam com 777, motivou o erro.

Pode-se fazer algumas combinações de valores (como as abaixo) e verificar que sempre a resposta na tela do navegador será de indicação de erro:
pasta    –    arquivo
777    –    644
757    –    644
755    –    664
752    –    700
e assim por diante.

Além do resultado mostrado na tela do navegador, estes poderão ser também observados através dos arquivos de log:
/var/log/apache2/access.log
/var/log/apache2/error.log
/var/log/suphp/suphp.log

No entanto, se as diretivas de segurança do arquivo de configuração do suPHP forem alteradas, estes valores limitantes de 755 e 644 se deslocarão (sofrerão alterações, portanto).

Vejamos com mais atenção o que significa aquelas diretivas de segurança do suPHP, considerado o octeto “rwx” das permissões de pastas e arquivos:

  • allow_directory_group_writeable: negar a gravação de arquivos ou outros diretórios ao grupo, significa r_x para o octeto da pasta referente ao grupo.
  • allow_directory_others_writeable: idem anterior, referente aos “outros” usuários.

Assim, a permissão máxima para a pasta é 755.
Para os arquivos, o suPHP não permite execução de scripts PHP apenas sua leitura e interpretação.  Assim já se tem rw_.

  • allow_file_group_writeable: negar escrita ao grupo, acumula a permissão r__ ao grupo.
  • allow_file_others_writeable: negar escrita aos outros, acumula a permissão r__ aos outros.

Assim, tem-se o máximo 644 par arquivos. Para os arquivos, 644 significa “owner” com permissão de leitura e gravação, grupo com permissão somente de leitura, outros com permissão somente de leitura.

6. Teste-4:  módulo suPHP ativado pelo Apache, mas requisitos de segurança geram novos erros de execução
Condição: módulo suPHP habilitado, mas módulos PHP, rewrite e suexec desabilitados. Arquivo de host virtual do Apache conforme item 5 acima.

Com o suPHP o proprietário da pasta tem que ser o proprietário do arquivo.  Se isto não acontecer, mesmo que tenhamos 755/644 de permissões, teremos um erro interno de servidor.  Para realização deste teste, modifique o proprietário da pasta e verifique o erro mostrado na tela do navegador:
# chown root:web1 /var/www/client1/

Depois disso, pode-se fazer outras combinações (trocando o proprietário do arquivo) e observar novos casos de erros.  Ou seja, com o suPHP o proprietário da pasta tem de ser obrigatoriamente o proprietário do arquivo.

7. Teste-5: módulo PHP ativado e executa normalmente o arquivo independentemente de permissões e de quem seja o proprietário.

Condição: módulo PHP habilitado, e módulos suPHP, rewrite e suexec desabilitados. Arquivo de host virtual do Apache conforme item 5 acima.
Desabilitar o módulo suPHP e habilitar de volta o módulo PHP conforme comandos abaixo:
# a2dismod suphp
# a2enmod php5
# /etc/init.d/apache2 restart

Observar que agora quem será chamado pelo Apache para interpretar o script PHP é o módulo PHP.  Faça algumas combinações entre o proprietário da pasta e do arquivo PHP, deixando-os diferentes entre si. Com o navegador acesse a URL que será executado o script index.php e veja que o mesmo é executado sem problemas independentemente dos proprietários desencontrados entre pasta/arquivo.

Agora altere as permissões da pasta e do arquivo para valores altos (portanto, de maior risco de segurança para o sistema), e veja que o script PHP é novamente sempre executado sem problemas.

Conclusão geral:  a execução de escripts através do módulo suPHP é muito mais segura, oferecendo menores risco para o sistema.

8. Aproveitando para comparar os ambientes PHP
Os contextos PHP são diferentes quando o script PHP é executado através de mod_php e mod_suphp. Isso se torna evidente desde o primeiro momento quando se percebe que os dois módulo utilizam php.ini diferentes:
módulo PHP: utiliza /etc/php5/apache2/php.ini
módulo suPHP: utiliza /etc/php5/cgi/php.ini

Veja o quadro comparativo (a partir do resultado da chamada da função PHP phpinfo()):

Geral
Server API Apache 2.0 Handler CGI/FastCGI
Configuration File (php.ini) Path /etc/php5/apache2 /etc/php5/cgi
Loaded Configuration File /etc/php5/apache2 /etc/php5/cgi
Scan this dir for additional .ini files /etc/php5/apache2/conf.d /etc/php5/cgi/conf.d
Apache Environment
DOCUMENT_ROOT /var/www/client1 /var/www/client1
SCRIPT_FILENAME /var/www/client1/index.php /var/www/client1/index.php
GATEWAY_INTERFACE CGI/1.1 CGI/1.1
SCRIPT_NAME /index.php /index.php
Environment
APACHE_RUN_DIR /var/run/apache2
APACHE_RUN_GROUP www-data
APACHE_RUN_USER www-data
APACHE_LOG_DIR /var/log/apache2
apache2handler
User/Group www-data(33)/33
Loaded Modules core mod_log_config mod_logio prefork http_core mod_so mod_alias mod_auth_basic mod_authn_file mod_authz_default mod_authz_groupfile mod_authz_host mod_authz_user mod_autoindex mod_cgi mod_deflate mod_dir mod_env mod_mime mod_negotiation mod_php5 mod_reqtimeout mod_setenvif mod_status
PHP Variables
_SERVER[“HTTP_ACCEPT”] text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
_SERVER[“HTTP_CONNECTION”] keep-alive keep-alive
_SERVER[“PATH”] /usr/local/bin:/usr/bin:/bin /bin
_SERVER[“SCRIPT_FILENAME”] /var/www/client1/index.php /var/www/client1/index.php
_SERVER[“GATEWAY_INTERFACE”] CGI/1.1 CGI/1.1
_SERVER[“SERVER_PROTOCOL”] HTTP/1.1 HTTP/1.1
cgi-fcgi
cgi.discard_path 0
fastcgi.logging 1
Core
PHP Version 5.3.3-7+squeeze14 5.3.3-7+squeeze14
include_path .:/usr/share/php:/usr/share/pear .:/usr/share/php:/usr/share/pear

9. Um FAQ rápido para ajudar a entender um pouquinho a mais

1- Quais os modos de funcionamento do Apache com o PHP aqui tratados neste post?
Fizemos testes com dois modos de funcionamento:
– utilizando o interpretador PHP como um módulo embutido (“built-in”) do Apache (mod_php);
– utilizando o interpretador PHP como um binário CGI, através da aplicação “wrapper” suphp (módulo suphp).

2- Que módulos próximos ao tema NÃO foram utilizados?
Não foram utilizados os seguintes módulos:
cgi
rewrite
suexec

Estes módulos ficaram desabilitados (a2dismod) ou até mesmo nem sequer carregados do repositório para a máquina.

3- Então posso carregar apenas o módulo PHP ou apenas o módulo suPHP e já poder executar scripts PHP?
Exatamente. Entretanto, executar scripts PHP através do módulo suPHP é mais seguro para o ambiente. No entanto, é mais lento e exigem alguns cuidados quanto a configurações por parte do usuário.

4- Então o que devo usar: PHP ou suPHP?
O suPHP diminui os riscos para o ambiente computacional. Vale a pena sempre buscar utilizar o suPHP para executar scripts PHP, apesar de um performance menor que o funcionamento com mod_php.

5- Como os módulos PHP e suPHP são referenciados no repositório Debian e facilmente localizados pelo Synaptic ?
Para o módulo PHP: procure o pacote php5. Marcando este pacote e fazendo sua instalação, o servidor de páginas Apache já pode responder a solicitações de páginas dinâmicas com scripts PHP simples. Não necessita de mais nada. Para instalar, carregue pacote “PHP”:
# apt-get install php5


Para o módulo suPHP: procure o pacote libapache2-mod-suphp. Marcando este pacote e fazendo sua instalação, o servidor de páginas Apache já pode responder a solicitações de páginas dinâmicas com scripts PHP simples. Não necessita de mais nada. Para instalar, carregue o pacote “libapache2-mod-suphp”:
# apt-get install libapache2-mod-suphp

6- Como habilitar e desabilitar os módulos necessários?
Simples, usando comandos como os exemplificados aqui:
# a2dismod cgi rewrite suexec
# a2enmod php5 suphp
# /etc/init.d/apache2 restart

7- Os módulos exigem configurações específicos depois de carregados?
Alguns sim, outros não. O módulo PHP não exige. Já o módulo suPHP tem seu módulo de configuração em /etc/suphp/suphp.conf.
No entanto é importante perceber que o ambiente PHP pode ser alterado através das variáveis do arquivo php.ini que é lido pelo interpretador PHP tanto no módulo PHP como no módulo suPHP.

8- Onde encontro os arquivos php.ini?
Se estiver utilizando o módulo PHP, o arquivo php.ini se encontra em /etc/php5/apache2/ . Se estiver utilizando o módulo suPHP, ele se encontra em /etc/php5/cgi/

9- Instalando o módulo PHP5 (“PHP5”), o que será carregado do repositório Debian?
Os seguintes pacotes (e alguns outros para resolver as dependências):

  • libapache2-mod-php5 (this package provides the PHP5 module for the Apache 2 webserver, as found in the apache2-mpm-prefork package).
  • php5-common (arquivos comuns para pacotes construídos a partir do código fonte do php5)

10- E instalando o pacote suPHP (“libapache2-mod-suphp”), o que será carregado do repositório Debian?
Três pacotes principais (e outras bibliotecas para resolver as dependências):

  • suphp-common (que gera em /etc/apache2/mods-available/ os arquivos suphp.conf e suphp.load)
  • apache2.2-common
  • php5-cgi (interpretador PHP CGI, construído para uso com Apache2. Será depositado em /usr/lib/cgi-bin/)

pois:
a) O pacote libapache2-mod-suphp depende dos pacotes suphp-common e apache2.2-common
b) O pacote suphp-common depende do pacote php5-cgi
Referências:
1- Módulos do Apache PHP, suPHP, suexec e rewrite no Linux – Debian
2- Documentação do Apache
3- suPHP Homepage

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

Este post fora feito quando da versão 17.0 do Firefox.

1. Debug de scripts Javascript
O Firefox traz várias falicidades para debug, seja para códigos JavaScript, PHP ou conexões HTTP.

1.1 Console JavaScript
É possível ter um console para debug de scripts JavaScript através do Firefox. Além disso, é possível escrever código JavaScript diretamente para o browser com o Firefox, podendo ser uma maneira fácil de testar o código. No Fierfox, sua console é obtida através do menu Ferramentas -> Desenvolvedor Web -> Console da Web

A janela de console do Firefox será mostrada, conforme a imagem abaixo.

Imagem: console Firefox

Como pode ser visto pela figura anterior, o console exibe quatro tipos diferentes de mensagens, que podem ser ligadas através dos botões – solicitações de rede, mensagens de CSS, mensagens de JavaScript e mensagens ao desenvolvedor web. Mas o que é uma mensagem ao desenvolvedor web? É uma mensagem impressa no objeto “window.console”. Por exemplo, poderíamos executar o código JavaScript window.console.log("Olá Mundo"); no “rascunho” do Firefox (veja mais adiante) para imprimir uma mensagem de desenvolvedor para o console. Os desenvolvedores da Web podem integrar essas mensagens em seu código JavaScript para ajudar na depuração.

O interpretador da linha de comando
Na parte de baixo da janalea do console do Firefox existe uma caixa para o usuário entrar comandos. O desenvolvedor pode utilizar expressões JavaScript que em tempo real serão interpretadas. Qualquer expressão JavaScript que seja digitada será avaliada, e o resultado será enviado para o log do console. Pode-se fazer muitas coisas, como cálculos simples para avaliar expressões complexas, e até mesmo incluir variáveis definidas na página atual. Exemplos de comandos:

> 600+10
  610
>

1.2 JavaScript Scratchpad (Rascunho)
O Scratchpad é obtido através do Firefox seguindo o menu Ferramentas -> Desenvolvedor Web -> Scratchpad
Abaixo, a imagem da tela desta ferramenta de auxílio ao desenvolvimento de código:

Firefox Scratchpad

Exemplo de comandos JavaScript:

alert("Olá mundo");
window.console.log("Esta é uma mensagem enviado do scratchpad");

Para o primeiro comando acima, será aberta uma mensagem popup na tela do navegador. Para o segundo comando será escrito uma mensagem de desenvolvimento no console web (conforme já explicado anteriormente).

2. Debug de scripts JavaScript com Firebug
Logo do FirebugFirebug se integra com Firefox para colocar um conjunto de ferramentas de desenvolvimento nas mãos do usuário enquanto se navega na web. Com ele é possível editar, depurar e monitorar o comportamento de CSS, HTML e JavaScript em qualquer página web. Sem interferir na lógica do programa, com o auxilio do Firebug o programador poderá inserir em seu código JavaScript linhas que o irão ajudar a depurar seu script. São algumas funções que quando chamadas imprimem mensagens com um visual colorido e distinção semântica.

Veja alguns exemplos de mensagens enviadas ao console do Firebug na figura logo a seguir, considerando o recorte de código abaixo:


var mens = "teste de depuração";
var user = "João";
var score = 1000;
console.log("meu primeiro echo do JavaScript");
console.log("meu segundo echo do JavaScript: ",mens);
console.info("meu terceiro echo do JavaScript: ",mens);
console.warn("meu quarto echo do JavaScript: ",mens);
console.error("meu quinto echo do JavaScript: ",mens);
console.warn("%cUsuário %s tem %d pontos", "color:orange; background:blue; font-size: 16pt", user, score);

Onde pode-se utilizar:
%c – Formatar a saída de acordo com o estilo CSS fornecido.
%s – Formatar o valor como uma “string”.
%d – Formatar o valor como um “integer” (poderia também utilizar-se %i).
%f – Formatar o valor como “floating point”.
%O – Formatar o valor como um “expandable JavaScript object”.
%o – Formatar o valor como um “expandable DOM element” (como do painel DOM).

Tela do console do Firebug com mensagens

Firebug adiciona uma variável JavaScript global chamada “console” para todas as páginas carregadas no Firefox. Este objeto contém muitos métodos que permitem ao programa enviar ao console do Firebug informações que estejam fluindo através dos scripts JavaScripts que estejam em execução. Veja informações completas em Console API.

2.1 Configurar pontos de interrupção com o Firebug
É muito fácil configurar pontos de interrupção (“break points”) com o Firebug em códigos JavaScript. Basta ir ao painel “Script”, selecionar o arquivo de script desejado (fazendo o seu código aparecer), e então clicar em cima do número da linha onde se deseja o ponto de interrupção. Uma marca vermelha aparecerá antes do número da linha que contiver um ponto de interrupção. Vários pontos de interrupção podem ser inseridos cumulativamente.

Quando o script for executado e atingir uma linha com ponto de interrupção, o Firebug suspenderá sua execução (antes que o código desta linha seja executada), como ilustra se seguinte figura:

Tela do Firebug mostrando um ponto de interrupção

Note a marca vermelha antes do número da linha 1158 (indicando o ponto de interrupção), e sobreposto a esta marca um pequeno triangulo amarelo. Esta marca amarela indica a próxima linha do script a ser executada, ou seja, o código do script fora executado até a linha imediatamente anterior a que contém o ponto de interrupção.

Na última figura acima duas áreas especiais A e B com elipses vermelhas foram destacadas:
a) área A: 5 botões, com os seguintes significados (nesta ordem):

  • “return” (shift+F8): retorna ao início;
  • “continue” (F8): permite retomar normalmente a execução do script do ponto que fora interrompido (não usa a forma passo-a-passo);
  • “step into” (F11): passo-a-passo, onde se executa também na forma de passo-a-passo o corpo das outra funções que forem encontradas ao longo da execução;
  • “step over” (F10): passo-a-passo, onde NÃO se executa na forma passo-a-passo o código interno das outra funções que forem encontradas ao longo da execução;
  • “step out” (shift+F11): permite retomar a execução do script e vai parar no próximo ponto de interrupção.

b) área B: três janelas estão disponíveis:

  • Observar: pode ser auditado o valor das variáveis do script naquele momento de parada;
  • Pilha: um trace com a pilha de chamadas (semelhante a função console.trace() );
  • Pontos de interrupção: mostra os pontos de interrupção existentes.

2.2 Configurar pontos de interrupção condicionais com o Firebug
Às vezes se deseja fazer uma pausa somente numa condição muito específica. O Firebug permite que se defina pontos de interrupção condicionais, que verificam uma expressão que deve ser verdadeira para que seja interrompida a execução do script.

Para definir um ponto de interrupção condicional, basta clicar com o botão direito em qualquer número da linha. Um formulário será exibido, solicitando que se digite uma expressão JavaScript. Pode-se clicar com o botão direito novamente a qualquer momento para alterar a expressão, ou clique com o esquerdo do mouse para remover definitivamente o ponto de interrupção. A figura abaixo mostra uma tela para inserção de um ponto de interrupção condicional:

Tela do Firebug para inserção de ponto de interrupção condicional

Por exemplo, poderia ser digitado neste formulário: a == 1. Assim, só haveria a interrupção do script se a variável “a” tivesse valor 1. A avaliação é feita antes da execução do código JavaScript da linha em que fora inserido o ponto de interrupção condicional.

2.3 Pontos de interrupção com a instrução “debugger”
A instrução “debugger” do JavaScript atua como um ponto de interrupção: a execução do script é interrompida e se pode utilizar o Firebug para auditar os valores das variáveis, examinar a pilha de chamada, etc. Note que só haverá a interrupção do script se houver um depurador em execução. Abaixo exemplificamos um fragmento de código JavaScript com a instrução debugger:
var mens = "teste de depuração";
var user = "João";
debugger;
var score = 1000;

A instrução debugger fora adicionada formalmente na linguagem por ECMAScript 5.

2.4 Comando “trace” do Firebug
Basta chamar console.trace() e o Firebug irá escrever as informações de um rastreamento (trace) da pilha para o console. Não só ele irá informar quais as funções estão na pilha, mas ele irá incluir também o valor de cada argumento que foi passado para cada função. Você pode clicar nas funções ou nos objetos para inspecioná-los.

Observe o exemplo de recorte de código abaixo e sua respectiva saída no console do Firebug, conforme mostrado a seguir.


function fsis_principal(p_acao, p_indicador) {
'use strict';
function e(){console.trace();}
function d(){ e();}
function c(){ d();}
function b(){ c();}
function a(){ b();}
a();

Tela com saída no console do Firebug para sua função trace.

2.5 Outras facilidades do Firebug
a) Ir diretamente para determinada linha do script
Muitas vezes se deseja visualizar diretamente o código do script a partir de uma determinada linha. Fazer isso não poderia ser mais fácil, basta digitar o número da linha na caixa de pesquisa rápida, precedido pelo sinal “#”, como se vê na captura de tela abaixo.

Tela do Firebug dando opção para mostrar determinada linha do código

3. Debug de scripts PHP com FirePHP
3.1 Introdução

FirePHP iconQuando necessitamos fazer debug de aplicações PHP, a maneira mais imediata é verificar o conteúdo das variáveis do PHP, obtendo seus valores diretamente nas páginas web de saída da plicação através de instruções “echo”, “print_r” ou similares. Outras possibilidades mais potentes, ainda que requeira mais preparação, seria:
(a) utilizar um sistema de Debug, como o que existe no Eclipse ou em outras Integrated Development Environment (IDE) de desenvolvimento de PHP com algum build-in debugger;
(b) registrar os processos de depuração exibindo no próprio navegador (browser).

O que estamos tratando neste post é a opção de se registrar as mensagens de debug dentro do console do próprio navegador. Vamos utilizar o navegador Firefox e as extensões FireBug e FirePHP. Isso será muito vantajoso, observe:
– simples de instalar e de se usar as facilidades de debug;
– não realização de bagunça no código do programa pois não se exige modificações de nada para capturar os erros;
– as mensagens que são criadas são enviadas diretamente para o navegador através de “HTTP response headers”, ou seja, as mensagens de debug não vão “quebrar” as respostas das requisições do programa com mensagens e erros de debug e fazendo parar de funcionar toda a aplicação. Ou seja, as mensagens não aparecem na tela de saída da plicação não molestando a visualizaçao dos resultados dos scripts PHP.
– resposta vem limpa e todo o processo de depuração vem catalogado no console do Firebug.

Como funciona FirePHP
O complemento FirePHP tem a particularidade de enviar mensagens ao console do Firebug, sem que estas apareçam na tela de saída do programa. As mensagens que podem ser enviadas são:
(a) simples log, com o conteúdo de qualquer elemento que necessite ser visualizado (como variáveis criadas no PHP);
(b) mensagens informativas;
(c) mensagens de erro;
(d) mensagens de warning.

3.2 Instalando
3.2.1 Quanto ao ambiente do cliente
Para fazer o FirePHP funcionar é necessário ter instalado:

Tanto Firebug como o FirePHP são instalados como extensões do Firefox através do menu Ferramentas -> Complementos do Firefox.

3.2.2 Quanto ao ambiente do Servidor
(a) Instalar a biblioteca FirePHPCore
Download standalone ou instale pelo PEAR conforme instruções.
Obs:

    • se optou por fazer o download standalone, extraia os arquivos numa pasta auxiliar qualquer:

$ unzip firephp-core-0.4.0.zip (0.4.0 foi a versão existente no momento deste post). Será criada uma pasta firephp-core-0.4.0 onde os arquivos serão extraídos. Os arquivos que serão relacionados neste posto logo adiante estarão contidos no caminho “firephp-core-0.4.0/lib/FirePHPCore/”

  • se utilizar o PEAR, no momento deste post a biblioteca é instalada em /usr/share/php/FirePHPCore/

(b) Fazer uma cópia da biblioteca FirePHPCore
Disponibilize uma cópia da biblioteca FirePHPCore no documentRoot do script a ser depurado. Se for /var/www, a biblioteca deve ficar assim:
/var/www/FirePHPCore/FirePHP.class.php
/var/www/FirePHPCore/FirePHP.class.php4
/var/www/FirePHPCore/fb.php
/var/www/FirePHPCore/fb.php4

Obs:
i. se a instalação fora realizada através do PEAR e se o repositório PEAR estiver no include path este passo pode ser opcional.
ii. a diferença entre fb.php e FirePHP.class.php é que o arquivo fb.php tem o código para poder acionar o FirePHP por meio de funções ou procedimentos e FirePHP.class.php contém uma classe para poder fazer basicamente as mesmas coisas, mas por meio de programação orientada a objetos.

3.3 Utilizando
Veja um pequeno exemplo de arquivo PHP, disponibilizado em /var/www/teste.php


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<?php
#Include a classe FirePHP
# require_once('FirePHPCore/FirePHP.class.php');
require_once('FirePHPCore/fb.php');
#Start buffering the output. Not required if output_buffering is set on in php.ini file
ob_start();
# buscar variavel de referência do firePHP
$firephp = FirePHP::getInstance(true);
# FB::setEnabled(false);
function testar1() {
echo "que legal-1"."<br>";
}
function testar2() {
echo "que legal-2"."<br>";
}
$todays_date = date('l jS of F Y h:i:s A'); /* data de hoje */
$firephp->log($todays_date, 'Date');
$firephp->log("minha mensagem de log");
$firephp->info("minha mensagem de informação");
$firephp->warn("minha mensagem de warning");
fb("minha nova mensagem de aviso",FirePHP::WARN);
$firephp->error("minha mensagem de alerta de erro");
$var = array('a'=>'pizza', 'b'=>'biscoitos', 'c'=>'doces', 'd'=>'sucos');
$firephp->log($var);
$firephp->info($var);
fb('Hello World!', FirePHP::TRACE);
testar1();
testar2();
?>

A saída do FirePHP para o exemplo acima seria:
Saída do FirePHP

3.4 Observações
a) Sobre FB::setEnabled(true|false)
Se refere a habilitar/desabilitar o registro de logs no Console. Quando o site vai para produção é importante que o FirePHP esteja desabilitado para que cesse o envio das mensagens de depuração. Assim, o código de chamadas do FirePHP escrito para debugar o programa não será necessário retirá-lo (pelo menos no primeiro momento).

b) Janelas com informações adicionais
Quando se passa o mouse em cima de algumas mensagens que foram logadas no console do FirePHP, uma janela aparece com todas as informações logadas, tudo tabulado de forma legível para desenvolvedor. No exemplo acima, é o caso, por exemplo, do log de “info($var)”.

c) Visualização do TRACE
Um click simples no label “Hello World!” do exemplo acima servirá para mostrar o trace inteiro.

3.5 Problemas de cache
O cache do navegador pode ser um problema na visualização dos resultados durante o desenvolvimento. O desenvolvedor poderá estar vendo um resultado no navegador que não corresponde ao código recém modificado. Assim, é recomendado:
a) desativar o cache nas configurações do navegador;
b) desativar o cache através das opções do FirePHP, conforme figura abaixo:
Desabilitar o cache no FirePHP

4. LiveHTTPHeaders
Live HTTP Headers Firefox é um ferramenta que exibe numa janela os cabeçalhos HTTP de cada requisição, auxiliando na verificação de erros de rede. As informações dos cabeçalhos também podem ser exibidas numa barra lateral, e as URLs das requisições que serão analisadas podem ser definidas como expressões regulares.

Tela do LiveHTTPHeaders

Referências:
1- Firebug – Web Development Evolved
2- Install FirePHP
3- Como debugar aplicações AJAX/PHP com FirePHP
4- Variáveis globais do Firebug
5- Live HTTP Headers
6- Debugging PHP Code with FirePHP

1. Introdução
ISPConfig 3 é um painel de controle para “hosting” de código aberto para Linux, que é capaz de gerenciar múltiplos servidores a partir de um painel de controle. ISPConfig está licenciado sob a licença BSD e tem suporte para a língua portuguesa. Já o Egroupware é uma ferramenta de colaboração on-line que pode ser utilizado tanto através de sua interface web nativa (que podemos afirmar que é sua forma mais utilizada), quanto pela utilização de clientes de groupware, tais como Kontact e Novell Evolution. Egroupware está licenciada através da GNU General Public License v.2.0 (GPL2).

Ambiente utilizado neste post:
Egroupware: 1.8.004
ISPConfig: 3.0.4.6
Apache: 2.2
S.O.: Linux/Debian Squeeze (Debian 6)
Módulos Apache habilitados (entre outros): rewrite ssl suexec php5 suphp vhost_alias

2. Considerações preliminares
O Egroupware está empacotado para Debian (bem como para outras distribuições), pronto para ser instalado e utilizado como serviço, rodando como usuário “root”. Em um ambiente multisites, é interessante que os scripts do e-groupware sejam instalados e executados a partir das próprias pastas de cada site (que estariam vinculados ao proprietário do site instalado, e não ao usuário “root”). Claro, o servidor Apache estaria com o módulo rewrite habilitado, e, para aumentar a segurança e facilidades de funcionamento do ambiente, com os módulos do Apache su_php e su_exec habilitados.

Deve-se criar um novo dominio através do ISPConfigure. Para efeito deste post, serão criados:
Para o cliente: client1
Para o site: web1 (primeiro criar a pasta subdominios/egroupware, e com o ISPConfig configurar esta como um subdominio)

Assim, o ISPConfig e Apache utilizarão como endereço físico para chegar ao site o endreço /var/www/clients/client1/web1/web/subdominios/egroupware/
Para facilitar a descrição deste post, vamos chamar pasta_inicial = /var/www/clients/client1/web1/web/subdominios/egroupware/

Também para facilitar este post, introduzimos o conceito de pasta_raiz_web (obs: que seria equivalente ao public_html do CPanel) como sendo a pasta a partir da qual deve-se disponibilizar os scripts das aplicações, incluindo a criação dos subdiretórios o site. No caso deste post, o domínio criado através do ISPConfig http://www.meusite.com.br tem seu DocumentRoot em /var/www/clients/client1/web1/web . Por segurança e bom funcionamento junto ao módulo su_php, todas as pastas a partir de pasta_raiz_web devem ter modo 755, e todos os arquivos modo 644.

3. Baixe o e-groupware e descompacte o arquivo em pasta_inicial
O Egrooupware pode ser baixado de http://sourceforge.net/projects/egroupware/files/
OBS: a versão do EGroupware 1.8 pode ser encontrada em: http://sourceforge.net/projects/egroupware/files/eGroupware-1.8/eGroupware-1.8.004.20121024/

Dois arquivos são essenciais:
eGroupware-egw-pear-1.8
eGroupware-1.8

4. Configurar arquivo php.ini
No arquivo .htaccess que está em pasta_inicial/ e que fora fornecido pelo Egroupware (OBS: verifique o seu conteúdo pois muitos “shared hosts” não concordam com certos parâmetros ali definidos), acrescentar uma linha para orientar o módulo su_php de não adotar o php.ini “default” definido no ambiente geral do servidor. Isso é razoável de ser feito pois, por exemplo, esta aplicação Egroupware requer mais memória que outras aplicações. Assim, estaremos dando a cada aplicação o que realmente necessita sem sobrecarregar o ambiente do servidor. No início do arquivo pasta_inicial/.htacces acrescente uma linha para ler um arquivo php.ini personalizado que será colocado neste pasta:

suPHP_ConfigPath pasta_inicial/php.ini

Desta forma, neste momento, o arquivo .htacces ficou da seguinte forma:


<IfModule mod_suphp.c>
suPHP_ConfigPath /var/www/clients/client1/web1/web/subdominios/egroupware
</IfModule>
Options All -Indexes
#
# Set
#
# AllowOverride FileInfo
#
# to enable parsing off this file
#
php_flag file_uploads on
php_flag log_errors on
php_flag magic_quotes_gpc off
php_flag magic_quotes_runtime off
php_flag register_globals off
php_flag short_open_tag on
php_flag track_vars on
php_flag display_errors off
# E_ALL & ~E_NOTICE & ~E_STRICT = 8191 - 8 - 2048 = 6135
php_value error_reporting 6135
php_value max_execution_time 90
php_value memory_limit 256M
php_value session.gc_maxlifetime 14400
php_value upload_max_filesize 64M
php_value post_max_size 65M
# session handling: now the check for expired sessions is done on every 10th session creation
php_flag session.use_trans_sid Off
php_value session.gc_probability 1
php_value session.gc_divisor 10
# multibyte extension: needed for utf-8
php_value mbstring.func_overload 7

Inicialmente, copie o seu php.ini “default” de seu ambiente (/etc/php5/apache2/php.ini) para pasta_inicial/php.ini
Este arquivo deve ser alterado a partir dos apontamentos que serão revelados quando da etapa “Roteiro de instalação do Egroupware” adiante descrita. Por exemplo, será mostrado neste roteiro que a variável upload_max_filesize deve ter 8M.

Também fizemos algumas parametrizações em pasta_inicial/php.ini para adequá-lo ao Egroupware:


mbstring.func_overload = 7
file_uploads = On
memory_limit = 128M

5. Criar a base de dados
Antes de seguir com o roteiro de instalação do Egroupware, criar a base de dados do site. Utilize comandos bash, seu phpMyadmin ou outra forma de sua preferência. No caso do exemplo deste post, criamos:

‘db_name’ => ‘c1egroup’,
‘db_user’ => ‘c1useregroup’,
‘db_pass’ => ‘minha_senha’

6. Roteiro de instalação do Egroupware
Será necessário (como será visto logo adiante) instalar uma série de bibliotecas comlementares no ambiente do servidor para fazer o Egroupware funcionar. Antecipando-se, entre outras instalações, serão necessárias:

# apt-get install php5-sqlite tnef
# pear install HTTP_WebDAV_Server-1.0.0RC6
# pear install Auth_SASL --alldeps
# pear install Net_IMAP
# pear install Net_Sieve
# pear install XML_Feed_Parse
r

6.1 Abrir a tela inicial da aplicação
(OBS: caso não exista um resolvedor de DNS, cadastrar o endereço do sitio em sua máquina local em /etc/hosts)
Ao abrir http://egroupware.meusite.com.br/  será mostrada a página inicial de instalação, conforme mostrada abaixo. Isso deve-se ao fato de ainda não existir o arquivo pasta_inicial/header.inc.php.
Tela inicial de instalação do Egroupware

Execute os testes de instalação, que verificará a instalação do Egroupware.   Deve-se sanar as pendências apresentadas.  Após isto, clicar no link “Continuar para a administração de cabeçalhos”, conforme imagem abaixo.

Tela de testes de instalação do Egroupware

6.2 Configurar base de dados e valores iniciais
O final da próxima página será conforme abaixo:
Tela de configuração base de dados do Egroupware

Fornecemos as seguintes informações no formulário desta tela:

a) Raiz do Servidor Caminho (não URL!) para sua instalação do eGroupWare: /var/www/clients/client1/web1/web/subdominios/egroupware
b) Usuário para configuração do servidor: admin_cabecalho
c) Senha para configuração do servidor: senha_cabecalho
d) Conexões Persistentes: Sim
e) Sessions Handler: PHP session handler enabled in php.ini
f) Habilitar MCrypt: Não
g) Vetor de iniciação do MCrypt: (deixar o apresentado)
h) Caixa de seleção de domínios no login: Não
i) Instância da base de dados (domínio do eGroupWare): (deixar o apresentado, ou seja, default)
j) Tipo de base de dados: MySQL
l) Servidor da base de dados: localhost
m) Nome da base de dados: c1egroupware
n) Usuário da base de dados: c1egroupware
o) Senha da base de dados: minha_senha
p) Usuário de Configuração: administrador
q) Senha de Configuração: administrador

OBS: o nome do Usuário para configuração do servidor e sua senha servirá para que no futuro seja possível reeditar este formulário, mesmo que já tenha sido criado o arquivo header.inc.php

Após isto, clicar no botão WRITE
A próxima tela informará que fora criado o arquivo pasta_inicial/header.inc.php. Clicar em CONTINUAR.

6.3 Configurar os acessos
Será fornecido a seguinte tela:
Tela de instalação dos acessos do Egroupware
O primeiro formulário servirá para prosseguir na configuração do Egroupware, passando a configuração de domínio. Preencha este primeiro formulário para prosseguir, com as informações fornecidas anteriormente no campo “Configuração do utilizador”. Caso deseje voltar a preencher o formulário anterior, preencha o segundo formulário com as informações fornecidas anteriormente no campo “Nome de utilizador do cabeçalho”.

6.4 Configurar domínio
A próxima tela de formulário será como mostrada abaixo:
Tela de configuração de dominio do Egroupware

Inicialmente cique no botão “INSTALAR Todas as aplicações” e ……… Espere…..

Uma tela como a mostrada a seguir será exibida:
Tela instalação das tabelas do Egroupware

Clique em VERIFICAR NOVAMENTE A INSTALAÇÃO que, caso seja mostrada a tela abaixo, vá para o PASSO 2 (CONFIGURAÇÃO DO SISTEMA).
Tela de configuração de dominio do Egroupware, passo 2

6.5 Configurar domínio – parte 2
Após clicar em EDITAR CONFIGURAÇÃO ATUAL relativo ao passo 2 (Configuração do sistema) uma tela com um novo formulário será apresentado, conforme mostrado abaixo.
Tela de configuração de domínio do Egroupware - parte 2

As principais configurações que utilizei foram as seguintes:
a) Insira o caminho completo para ficheiros de utilizadores e grupos:
/var/www/clients/client1/web1/egroupware3_arquivos/usuarios

b) Insira o caminho completo para a directoria de cópias de segurança:
/var/www/clients/client1/web1/egroupware3_arquivos/backups

c) Insira o caminho completo para ficheiros temporários:
/var/www/clients/client1/web1/egroupware3_arquivos/temp
( OBS:

1- observe que os três caminhos acima tomamos o cuidado para que fossem externos à root de documentos dos servidores Web!!!
2- devem ser criadas, via comandos bash, estas pastas citadas nos últimos 3 caminhos acima )

d) Insira a URL do eGroupWare: http://egroupware.meusite.com.br
e) Insira o nome da máquina em que este sistema está a ser executado: server0.meusite.com.br
f) Nome do servidor POP/IMAP de correio electrónico ou endereço IP: localhost
g) Protocolo de servidor de correio electrónico: IMAP
h) Tipo de acesso ao servidor de correio electrónico: <Por omissão(nome de acesso igual ao nome de utilizador do eGroupWare)>
i) Domínio de correio electrónico (para gestor virtual de correio electrónico): meusite.com.br
j) Nome do servidor SMTP ou endereço IP: localhost
k) Porto do servidor SMTP: 25
l) Utilizador para a autenticação SMTP (deixe-o vazio se a autenticação não for necessária): joao
m) Activate safe password check: Não
n) Permitir a autentiação por cookies: Sim
o) Acesso automático do utilizador anónimo: Não
p) Id mínimo para contas (Exemplo: 500 ou 100, etc.): 1000
q) Criar contas de utilizadores automaticamente para utilizadores autenticados: Não
r) Se não existirem registos ACL do utilizador ou grupo, o utilizador é um membro de: Negar acesso

Ao final, clicar no botão GUARDAR. Se tudo correr bem, uma tela como abaixo será mostrada:
Tela configurar dominios Egroupware - passo 2 final

6.6 Configurar conta do administrador
Clicar no botão “CRIAR CONTA DE ADMINISTRADOR”, cuja nova tela será mostrada conforme mostrada abaixo.

Tela instalação Egroupware - fase configuração administrador

Preencha os detalhes da conta do administrador:
a) Nome do utilizador do administrador: jose
b) Nome próprio do administrador: Jose
c) Apelido do administrador: Zezinho
d) Admin email address: jose@meusite.com.br
e) Senha do administrador: xxxxxxxxxx
f) Re-insira a senha: xxxxxxxxxx
g) Give admin access to all installed apps: (marcar a caixa)
h) Criar contas de demonstração: (deixar sem marcar)

Clicar no botão GUARDAR. Se tudo tiver ocorrido bem, uma tela como a abaixo será mostrada.

Tela instalação Egroupware - passo 4 final

6.7 Configuração avançada das aplicações
Após o procedimento anterior, clicar no botão CONFIGURAR APLICAÇÕES uma nova página será mostrada conforme cópia da tela mostrada abaixo.
Tela configuração Egroupware - passo 5

Clique no botão GUARDAR. Esta foi a última etapa do roteiro.

7. Acessar a aplicação
Use SAIR, pois o processo de instalação está completo. Por segurança, limpe o cache do navegador, cookies, etc. Feche o navegador.

Após isso, acesse o Egroupware através de http://egroupware.meusite.com.br/ , que será mostrada a tela abaixo.

Use usuário/senha fornecida quando do preenchimento do formulário da conta do administrador (jose/xxxxxxxxxx)

Tela inicial de acesso ao Egroupware

8. No futuro, sendo necessário refazer alguma configuração

Basta acessar http://egroupware.meusite.com.br/setup/  fornecendo as informações cadastradas do “Usuário para configuração do servidor”.
O arquivo principal de configuração é o “header.inc.php”.

9. Alguns problemas de tradução para o português
a) em egroupware/admin/lang/egw_pt-br.lang existe um erro de digitação. Alterar:
DE: regsitro
PARA: registro

b) em egroupware/calendar/lang/egw_pt-br.lang incluir a seguinte tradução:

freebusy calendar pt-br disponibilidade
Deny Ressources reservation for private events calendar pt-br Proibir a reserva de recursos para eventos privados
History logging calendar pt-br Log Histórico
Prevent deleting of entries calendar pt-br Prevenir a exclusão de entradas
Require an ACL grant to invite other users and groups calendar pt-br Exigir uma concessão ACL para convidar outros usuários e grupos
Every user can invite other users and groups calendar pt-br Cada usuário pode convidar outros usuários e grupos
Yes, only admins can purge deleted items calendar pt-br Sim, apenas os admins podem eliminar os itens deletados
Yes, users can purge their deleted items calendar pt-br Sim, usuários podem eliminar seus itens deletados
Groups: other users can allways be invited, only groups require an invite grant calendar pt-br Grupos: outros usuários podem sempre ser convidados, apenas os grupos exigem uma concessão de convite
users + groups: inviting both allways requires an invite grant calendar pt-br usuários + grupos: convidar ambos sempre exige uma concessão de convite

c) em egroupware/admin/lang/egw_pt-br.lang incluir as seguintes traduções:
Limit to members of admin pt-br Limitado aos membros do
Actions admin pt-br Ações

d) em egroupware/tracker/lang/egw_pt-br.lang incluir as seguintes traduções:
Bugs tracker pt-br Falhas
Status tracker pt-br Estado
Do not notify of these changes tracker pt-br Não modifique estas mudanças

10. Configurações legais de serem feitas no EGroupware
a) Colocar o seu logo
Coloque a imagem de seu logo na página pasta_inicial/phpgwapi/templates/default/images/ e informe ao EGroupware o nome do arquivo depositado nesta pasta através do menu administrador -> configuração do servidor -> aparência -> digite a URL ou o nome do arquivo (em phpgwapi/templates/default/images) do seu logotipo.

Links:
1- Download Egroupware
2- Egroupware

O phpScheduleIt é um sistema de reservas e de agendamento, Open Source Web-based, que permite a usuários registrar e fazer reservas de qualquer tipo de recursos, tais como salas de conferência, máquinas, computadores, etc. A parte administrativa da solução oferece o controle completo sobre as permissões de usuários, sobre os dados dos recursos e da reserva, e tem muitas opções configuráveis​​.

No momento deste post, tínhamos:
Debian: Debian-6, Squeeze
Versão do phpScheduleIt: 2.3

1.Fazer download do phpScheduleIt e desempacotar o aplicativo
Acessar a página para download do aplicativo em http://sourceforge.net/projects/phpscheduleit/files/1.%20phpScheduleIt/2.3/

/usr/share# unzip  phpScheduleIt-2.3.3.zip
/usr/share# rm phpScheduleIt-2.3.3.zip
/usr/share# cd phpScheduleIt

2. Criar as configuração para o Apache
# mkdir /etc/phpScheduleIt

Criar o arquivo /etc/phpScheduleIt/apache.conf com o seguinte conteúdo:

Alias /phpScheduleIt /usr/share/phpScheduleIt/
<Directory /usr/share/phpScheduleIt/>
DirectoryIndex index.php
Options +FollowSymLinks
AllowOverride None

order deny,allow
deny from all
# allow from 127.0.0.0/255.0.0.0 ::1/128
allow from all

<IfModule mod_php5.c>
php_flag magic_quotes_gpc Off
php_flag track_vars On
php_value include_path .
</IfModule>
</Directory>

Criar um link simbólico e reiniciar o Apache:
/etc/apache2/conf.d# ln -s ../../phpScheduleIt/apache.conf phpScheduleIt
# /etc/init.d/apache2 restart

3. Setar autoridades
/usr/share/phpScheduleIt# chmod 757 tpl_c/
/usr/share/phpScheduleIt# chmod 757 tpl

4. Preparar arquivo de configuração do phpScheduleIt
/usr/share/phpScheduleIt# cp config/config.dist.php config/config.php

Editar o arquivo config.php, atentando para as seguintes parametrizações:

$conf['settings']['server.timezone'] = 'America/Belem';
$conf['settings']['default.language'] = 'pt_br';
$conf['settings']['script.url'] = 'http://agenda.meusite.com.br'; // no caso usei um subdominio agenda
$conf['settings']['install.password'] = 'minha_senha_instalacao';

$conf['settings']['database']['type'] = 'mysql';
$conf['settings']['database']['user'] = 'user_admin_base';        // database user with permission to the phpScheduleIt database
$conf['settings']['database']['password'] = 'user_admin_base_password';
$conf['settings']['database']['hostspec'] = '127.0.0.1';        // ip, dns or named pipe
$conf['settings']['database']['name'] = 'phpscheduleit2';

5. Configurar a base de dados manualmente
Isto é especialmente recomendável em caso de instalação do phpScheduleIt remotamente.

5.1 Abra o arquivo “…/phpScheduleIt/database_schema/full-install.sql” e edite o nome do “banco” e o nome de “usuário/senha” para coincidir com os valores fornecidos em “config.php”. No caso mostrado, as primeiras linhas deste arquivo ficarão assim:

DROP DATABASE IF EXISTS phpscheduleit2;
CREATE DATABASE phpscheduleit2;
USE phpscheduleit2;
GRANT ALL on phpscheduleit2.* to 'user_admin_base'@'127.0.0.1' identified by 'user_admin_base_password';SET foreign_key_checks = 0;

5.2 Importar o script de criação do banco e tabelas do phpScheduleIt
/usr/share/phpScheduleIt/database_schema# mysql -u root -p < full-install.sql

5.3 Importar “sample-data-utf8.sql” to phpscheduleit2 (Serão criados 2 usuários: admin/password e user/password). Estes usuários estarão disponíveis para testar a instalação).
/usr/share/phpScheduleIt/database_schema# mysql -u root -p -D phpscheduleit2 < sample-data-utf8.sql

6. Arquivos de Log
phpScheduleIt faz o “log” de vários níveis de informações categorizadas em “logs” da aplicação e do banco de dados. Por padrão, o “log” está desativado (“OFF”).

Para ativar, proceder:
6.1 Renomear o arquivo de configuração de logs:
/usr/share/phpScheduleIt/config# mv log4php.config.dist.xml log4php.config.xml

6.2 Configurar a pasta de logs no arquivo log4php.config.xml
<param name="file" value="/var/log/phpscheduleit/log_%s.log" />

6.3 Configurar os níveis de logs
“Logging” é controlado alterando o valor referente a tag <level>. Os “levels” usados pelo phpScheduleIt são: OFF, DEBUG, ERROR. Em operação em produção, a opção ERROR é a mais apropriada. Se trace logs São necessárias, DEBUG é apropriada.  Para alterar o nível de “logging” da aplicação, deve-se alterar o <level value=”OFF” /> para o nível apropriado tanto da aplicação quanto dos “sql loggers”. Por exemplo, <level value=”ERROR” />.

7. Quanto a tradução
Na versão que estava utilizando, observei alguns problemas de tradução especialmente quanto a não tradução de alguns termos. Abaixo transcrevo os termos que tive de agregar ao arquivo phpscheduleIT/lang/pt_br.php:

$strings['Select'] = 'Selecionar';
$strings['List'] = 'Lista';
$strings['TotalTime'] = 'Tempo Total';
$strings['Count'] = 'Contagem';
$strings['Resources'] = 'Recursos';
$strings['Accessories'] = 'Acessórios';
$strings['AllTime'] = 'Tempo Total';
$strings['CurrentMonth'] = 'Mês Corrente';
$strings['CurrentWeek'] = 'Semana Corrente';
$strings['Today'] = 'Hoje';
$strings['Between'] = 'Entre';
$strings['None'] = 'Nenhum';
$strings['Resource'] = 'Recurso';
$strings['Usage'] = 'Uso';
$strings['Range'] = 'Intervalo';
$strings['FilterBy'] = 'Filtrado por';
$strings['AllAccessories'] = 'Todos os acessórios';
$strings['GetReport'] = 'Gerar Relatório';
$strings['GenerateReport'] = 'Gerar Novo Relatório';
$strings['AggregateBy'] = 'Agregado por';
$strings['Group'] = 'Grupo';
$strings['ReservedResources'] = 'Recursos Reservados';
$strings['ReservedAccessories'] = 'Acessórios Reservados';
$strings['ResourceUsageTimeBooked'] = 'Uso dos Recursos - Tempo Reservado';
$strings['ResourceUsageReservationCount'] = 'Uso dos Recursos - Contagem de Reservas';
$strings['Top20UsersTimeBooked'] = '20 maiores Usuários - Tempo Reservado';
$strings['Top20UsersReservationCount'] = '20 maiores Usuários - Contagem de Reservas';
$strings['Total'] = 'Total';
$strings['Administration'] = 'Administration';
$strings['NoResultsFound'] = 'Sem Resultados';
$strings['QuantityReserved'] = 'Quantidade Reservada';
$strings['All'] = 'Todos';

Além disso, para que na Gerência de Usuários (http://agenda.meusite.com.br/admin/manage_users.php) possa ser visualizado o estado de cada usuário, é necessário corrigir o valor das variáveis:

$strings['Active'] = 'Active';
$strings['Inactive'] = 'Inactive';

8. Dicas úteis
8.1 Encontrei alguns questionamentos no fórum do phpscheduleIT sobre como configurar a página inicial do aplicativo. Estava utilizando um subdominio chamado “agenda” para armazenar os scripts do aplicativo. Assim, configurei:
a) em phpscheduleIt/config/config.php:
$conf['settings']['script.url'] = 'http://agenda.meusite.com.br';

b) para o link do Apache, usar a página inicial do phpscheduleIt como sendo:
http://agenda.meusite.com.br/Web/

8.2 Cache do phpscheduleIT
Os arquivos de cache da aplicação são armazenados em phpscheduleIt/tpl_c

8.3 Outras páginas com traduções insuficientes
a) Página de créditos: phpscheduleIt/tpl/support-and-credits.tpl
b) Página da ajuda da administração: /lang/pt_br/help-admin.tpl (obs: na verdade este arquivo nem existia. Tive de copiá-lo da pasta lang/en_us/ para esta pasta e traduzi-lo.)

9. Páginas úteis
Página inicial da aplicação: http://<IP-server>/phpScheduleIt/Web/
Página de help:  http://<IP-server>/phpScheduleIt/Web/help.php
Procedimentos de instalação: /usr/share/phpScheduleIt/readme_installation.html, acessado por http://<IP-server>/phpScheduleIt/readme_installation.html (obs: se a instalação for numa máquina remota, é recomendável realizar os procedimentos manuais conforme descritos anteriormente).

Links
1- phpScheduleIt Forum
2- phpScheduleIt home-page

Collabtive - banner

O “collabtive” é um gerenciador de projetos “web-based” totalmente em PHP, com licenciamento GPL (software livre). Collabtive é escrito em PHP5 e usa uma interface de usuário baseado em AJAX. Tem característica multi-linguagem, suportando mais de 30 idiomas. Collabtive integra-se com outros webservices através de uma API XML. Além disso, prevê a importação de funcionalidade e os dados de outros aplicativos. Ele permite ao usuário trabalhar com listas de tarefas, metas, arquivos e controlar o tempo trabalhado tarefa à tarefa.

o banco de dados usado é o MySQL 4.1 or 5.x

No momento deste post, tínhamos:
Debian: Debian-6, Squeeze
Versão do collabtive:  0.7.6 (liberada em 30.mai.2012)

O collabtive pode ser obtido de http://sourceforge.net/projects/collabtive/files/collabtive/0.7.6/collabtive076.zip/download

1. Desempacotar o collabtive
# mkdir /usr/share/collabtive
# cd /usr/share/collabtive
/usr/share/collabtive# unzip collabtive076.zip
/usr/share/collabtive# chmod -R 757 templates_c/
/usr/share/collabtive# chmod 757 config/standard/config.php

2. Criar os arquivos de configuração para o Apache
# mkdir /etc/collabtive

Criar o arquivo /etc/collabtive/apache.conf com o seguinte conteúdo:

Alias /collabtive /usr/share/collabtive/
<Directory /usr/share/collabtive/>
DirectoryIndex index.php
Options +FollowSymLinks
AllowOverride None

order deny,allow
deny from all
# allow from 127.0.0.0/255.0.0.0 ::1/128
allow from all

<IfModule mod_php5.c>
php_flag magic_quotes_gpc Off
php_flag track_vars On
php_value include_path .
</IfModule>
</Directory>

Criar um link simbólico e reiniciar o Apache:
/etc/apache2/conf.d# ln -s ../../collabtive/apache.conf collabtive
# /etc/init.d/apache2 restart

3. Criar a base de dados para o collabtive:

$ mysql -u root -p

mysql> create database collabtive;
mysql> grant all on collabtive.* to collabuser;
mysql> grant all on collabtive.* to collabuser@localhost;
mysql> set password for collabuser=password('meu_collab_passw');
mysql> set password for collabuser@localhost=password('meu_collab_passw');
mysql> exit

4. Instalar o collabtive
com o navegador acessar http://<ip_servidor>/collabtive/install.php
Uma tela como a baixo será mostrada.

Tela de instalação do gerenciador de projetos collabtive

Conforme a base de dados criada, as informações a serem fornecidas neste tela serão:
Database host: localhost
Database name: collabtive
Database user: collabuser
Database passw: meu_collab_passw

Agora é só seguir dos demais passos e o gerenciador de projetos estará instalado e funcionando.
A tela inicial de login será lcançada através do navegador em http://<ip_servidor>/collabtive
Veja a tela inicial do aplicativo:

Tela inicial do gerenciador de projetos Collabtive

5. Cuidados com a segurança
Por questões de segurança, remova o arquivo php de instalação pois o mesmo não será mais necessário:
# rm /usr/share/collabtive/install.php

Bom uso!

Links:
1- Obter o collabtive: em http://collabtive.o-dyn.de/
2- Collabtive Forums