WARNING: Esta versao esta' desactualizada, vejam o link para a versao texto que se encontra mais abaixo, e' consideravelmente mais recente.

Instalacao e Configuracao

Apache 1.3.20 + lingerd 0.93 + PHP 4.0.5 + mod_gzip 1.3.19.1a + Zend Optimizer 1.1.0

Versao 1.2 - 2001 / 06 / 05
Nuno Monteiro <nuno@null.net>
Podem encontrar uma versao texto aqui

 

----------------
1. Necessario
----------------

  • Apache 1.3.20
  • lingerd 0.93
  • mod_gzip 1.3.19.1a
  • PHP 4.0.5
  • Zend Optimizer 1.1.0
--> ftp://ftp.netc.pt/pub/apache
--> ftp://iagora.com/pub/software/lingerd/lingerd-0.93.tar.gz
--> http://www.remotecommunications.com/apache/mod_gzip
--> http://pt.php.net
--> http://www.zend.com/shop/products/zend-optimizer.html

 

----------------
2. Preparacao
----------------

Primeiro e' preciso escolher uma localizacao no teu sistema onde possas descomprimir os varios pacotes, eu pessoalmente uso /usr/local/src, podes no entanto escolher qualquer outra, a tua homedir, /tmp, etc.

[/usr/local/src]# tar zxf apache_1.3.20.tar.gz
[/usr/local/src]# tar zxf php-4.0.5.tar.gz
[/usr/local/src]# tar zxf ZendOptimizer-1.1.0-PHP_4.0.5-Linux_glibc21-i386.tar.gz
[/usr/local/src]# tar zxf lingerd-0.93.tar.gz
[/usr/local/src]# gzip -d mod_gzip.c.gz
Agora que ja' temos as sources de tudo o que vai ser preciso, vamos la' comecar:

Primeiro, comecamos por copiar o mod_gzip.c para dentro da tree do apache:

[/usr/local/src]# cp mod_gzip.c apache_1.3.20/src/modules/extra

Depois, vamos aplicar os patches para o apache usar o lingerd:
[/usr/local/src]# cd lingerd-0.93
[/usr/local/src/lingerd-0.93]# vi apache-1.3/ap_lingerd.h
Nao e' realmente necessario editar este ficheiro, os defaults funcionam correctamente mas, de qualquer modo, define `LINGER_ON_FAILURE' (junto ao fim do ficheiro) para '0' e nao `1', como vem por defeito
[/usr/local/src/lingerd-0.93]# cp apache-1.3/ap_lingerd.* /usr/local/src/apache_1.3.20/src/main/
[/usr/local/src/lingerd-0.93]# patch -p0 -d /usr/local/src/apache_1.3.20/src/ < apache-1.3/aplinger.diff
Vamos agora criar um utilizador e um grupo para o apache correr. No meu sistema, geralmente, esse utilizador / grupo e' www/www, o que nao significa que tenha de ser esse, apenas por motivos de conveniencia neste exemplo, vamos usa-lo tambem:
[/root]# groupadd www
[/root]# adduser -g www www

 

----------------------------
3. Compilacao / Instalacao
----------------------------
Agora vamos configurar e compilar o apache & friends. Vamos comecar pelo daemon 'lingerd':

Antes de mais vamos dar uma olhada no config.h e configurar a gosto. Em principio nao sera' preciso mudar nada. Em seguida, vamos dar uma olhada ao Makefile, onde ai' sim, iremos fazer algumas alteracoes:
[/usr/local/src/lingerd-0.93]# vi Makefile
vamos mudar a linha

  CFLAGS = -Wall -g -O

que passara' a ser

  CFLAGS = -Wall -O3 -fomit-frame-pointer -pipe -s -ffast-math -fexpensive-optimizations -march=i686
- NOTA: -
Neste caso eu uso o -march=i686 porque o meu CPU e' um Pentium III coppermine, mas de acordo com o _VOSSO_ processador, terao de alterar este parametro. Se tiverem um processador Intel x86 ou compativel, devem usar:

-march=i386 (se nao sabem qual o CPU, ou e' REALMENTE um 386 antigo)
-march=i486 (Intel 80486)
-march=i586 (Pentium classico e MMX, Cyrix, Winchip, AMD K6, K6-II e K6-III)
-march=i686 (Pentium II, Celeron, Xeon, Pentium III, Pentium 4)

Se tiverem um K7 da AMD (Athlon / Duron / Thunderbird) e usam o gcc versao 3.0 (penso que tambem deve funcionar no 2.96, que afinal e' um snapshot do 3.0), podem especificar -march=K7 . Se no entanto tiverem problemas, -march=i586 devera' ser a aposta mais segura para estes processadores.

A seguir encontramos uma linha

  LDFLAGS = -g

que vamos mudar para

  LDFLAGS =

Depois de feitas estas alteracoes ao Makefile, vamos compilar:
[/usr/local/src/lingerd-0.93]# make
gcc -Wall -O3 -fomit-frame-pointer -pipe -s -ffast-math -fexpensive-optimizations -march=i686 -c -o lingerd.o lingerd.c
gcc lingerd.o -o lingerd
E pronto, ja temos o binario. Por agora vamos deixa-lo ficar onde esta', e vamos passar ao PHP:

Para se poder configurar e compilar o PHP correctamente deve-se fazer uma primeira configuracao `falsa' do apache, para o PHP nao se queixar:
[/usr/local/src]# cd apache_1.3.20
[/usr/local/src/apache_1.3.20]# ./configure
Nota que _NAO_ deves compilar ja' o apache. Este passo destina-se, unica e exclusivamente a `enganar' o configure do PHP :)

Depois, configuras o PHP normalmente. Eu uso estas opcoes:
[/usr/local/src/php-4.0.5]# CFLAGS='-O3 -fomit-frame-pointer -s -pipe -ffast-math \
-fexpensive-optimizations -march=i686' ./configure --with-config-file-path=/etc \
--with-mysql=/usr/local/mysql --enable-inline-optimization --enable-track-vars \
--with-apache=../apache_1.3.20 --enable-sigchild --enable-sysvsem --enable-sysvshm \
--enable-shmop --with-gd --with-jpeg-dir --with-zlib
Mais uma vez, cuidado com a optimizacao -march do gcc, devem altera-la de acordo com o vosso processador.

Ha' que ter em atencao tambem que eu uso suporte MySQL, se nao quiserem, podem deixar a opcao --with-mysql de fora. Se optarem por utiliza-la, devem modificar o path da instalacao caso seja necessario - o meu MySQL esta' instalado em /usr/local/mysql, o vosso podera' nao estar... Your mileage may vary :) Do mesmo modo, se nao tiverem o gd instalado (e' uma livraria grafica, permite criar .jpeg e .png on-the-fly), devem deixar de fora o --with-gd

Ha' varias outras opcoes populares, ./configure --help mostrara' todas, escolhe as que melhor reflectem a tua configuracao / sistema / necessidades

Depois do `make', que devera' ocorrer sem sobressaltos, e do `make install', concentremo-nos no apache. Eu utilizo algumas cflags adicionais que, teoricamente, irao aumentar a performance e o desempenho geral. Nao e' nada obscuro, todas estas opcoes encontram-se bem documentadas no manual do apache. Entretanto, algumas dessas optimizacoes ate' ja' fazem parte dos defaults, por exemplo, desde o 1.3.15 que `SINGLE_LISTEN_UNSERIALIZED_ACCEPT' e' definido, nao sendo necessario activa-lo durante o configure, como faziamos anteriormente. Eu opto por desactivar alguns modulos que vem activados por defeito, modulos esses que sao de pouca ou nenhuma utilidade na grande maioria dos casos, sendo ate' boa ideia em termos de performance e/ou seguranca desactiva-los. Fica ao vosso criterio, depende tambem das vossas necessidades especificas. A minha configuracao e' a seguinte:
[/usr/local/src/apache_1.3.20]# CFLAGS='-O3 -fomit-frame-pointer -s -pipe -ffast-math \
-fexpensive-optimizations -march=i586 -DDYNAMIC_MODULE_LIMIT=0 -DBUFFERED_LOGS' \
./configure --prefix=/usr/local/httpd --add-module=src/modules/extra/mod_gzip.c \
--activate-module=src/modules/php4/libphp4.a --disable-module=status --disable-module=include \
--disable-module=autoindex --disable-module=asis --disable-module=imap --enable-module=speling \
--server-uid=www --server-gid=www --enable-suexec --suexec-caller=www \
--suexec-userdir=public_html/cgi-bin --suexec-uidmin=1000
Ou seja, desactivo os modulos `status', `include', `autoindex', `asis' e `imap', e activo o modulo `speling', bem como o mod_gzip e o php4. Nota tambem que estamos a compilar tudo estaticamente no core do apache, uma vez que esta configuracao e' orientada para um rendimento optimo, especialmente em servidores com um volume de trafego de medio a elevado. Em virtude disso definimos o DYNAMIC_MODULE_LIMIT como zero, ou seja, a memoria disponibilizada para modulos dinamicos (.so) e' zero, visto que temos tudo o que precisamos compilado no proprio binario do apache. Do mesmo modo, definimos BUFFERED_LOGS, o que faz com que os logs nao sejam escritos imediatamente apos cada request, como normal, mas sim armazenados num buffer intermedio. Quando esse buffer estiver cheio sera' escrito no disco, o que equivale a dizer que em servidores especialmente movimentados ha' bastante menos actividade do disco, maximizando a velocidade de resposta e minimizando a latencia. Em caso de ser preciso ver os ultimos logs, que ainda nao se encontram no disco, basta mandar o sinal -1 (-SIGHUP) ao processo `pai', ou seja, o processo httpd que corre como root, e o conteudo do buffer sera' imediatamente escrito. Isto e' especialmente util nos scripts que rodam os logs, por exemplo.

Tem atencao com as opcoes --server-uid, --server-gid e --suexec-caller, certifica-te que correspondem 'a mesma UID e GID criada anteriormente. Quanto 'a opcao --suexec-uidmin, no meu sistema todos os utilizadores tem uid acima de 1000 (e' o default do slackware, ja' no redhat e mandrake, por ex, e' a partir de 500), deves verificar qual e' o valor no teu sistema, geralmente esse parametro encontra-se definido no ficheiro /etc/login.defs - um simples `grep UID_MIN /etc/login.defs' deve dizer-te qual o valor correcto. Podes tambem omitir todas as opcoes do `suexec' se nao pretendes usar essa funcionalidade. Ela e', no entanto, muito 'util, pois permite aos utilizadores correrem scripts/cgis com a sua uid, em vez da do apache.

Ora bem, resta-nos agora fazer `make' e `make install', et voila', o apache esta' compilado e instalado no seu devido sitio. Mas, atenção, nao esta' ainda pronto a funcionar - falta o lingerd! O lingerd e' um pequeno daemon cuja principal (e unica) funcionalidade e' tomar conta da tarefa de fechar os sockets abertos pelo apache. O apache por si mesmo toma conta desta tarefa, mas 'a medida que o trafego sobe, e porque esta operacao, apesar de tao trivial, pode demorar alguns segundos por cada socket, fara' concerteza que se perca rendimento, velocidade e responsividade. E' ai' que intervem o lingerd, deixando o apache livre para servir outros eventuais clientes, sem se preocupar com outras tarefas. O lingerd tem de correr com a mesma UID do apache, que foi definida durante a configuracao. No nosso caso, e' `www', por isso vamos la' ao que interessa:
[/usr/local/src]# mkdir -m 755 /var/run/lingerd
[/usr/local/src]# chown www.www /var/run/lingerd
[/usr/local/src]# cd lingerd-0.93
[/usr/local/src/lingerd-0.93]# strip lingerd
[/usr/local/src/lingerd-0.93]# mv lingerd /usr/local/httpd/bin
E pronto, o lingerd esta' pronto a correr. Uma nota _MUITO_ importante, e aqui faco questao de ressalvar o _MUITO_, e' que o lingerd TEM de ser iniciado _ANTES_ do apache. Por isso, convem que nos vossos init scripts iniciem o lingerd imediatamente antes do apache, senao nada disto ira' funcionar correctamente. E claro, o lingerd tem de ser iniciado e correr com a mesma UID do apache. Se nao sabem como fazer isto, no vosso script de init do apache, antes da linha que inicia realmente o httpd, acrescentem

     /bin/su -c /usr/local/httpd/bin/lingerd www

Podem verificar se esta' a funcionar devidamente vendo as ultimas linhas do /var/log/messages ou equivalente, que devera' conter uma linha parecida com esta:

Jun 5 21:12:53 newton lingerd[29511]: Linger daemon started; socket table has 1016 entries.

e a directoria /var/run/lingerd deve conter

-rw-r--r-- 1 www www 6 Jun 5 21:12 lingerd.pid srwxr-xr-x 1 www www 0 Jun 5 21:12 lingerd.sock=
Bom, agora ja' so' nos resta instalar o Zend Optimizer...
[/usr/local/src]# cp php-4.0.5/php.ini-optimized /etc/php.ini
[/usr/local/src]# mkdir -m 755 /usr/local/httpd/lib
[/usr/local/src]# cp ZendOptimizer-1.1.0-PHP_4.0.5-Linux_glibc21-i386/ZendOptimizer.so /usr/local/httpd/lib
E pronto, ja' esta' tudo no seu devido sitio!

 

---------------------------------------------
4. Configuracoes / Afinacoes / Optimizacoes
---------------------------------------------
Agora chegamos 'a parte de configurar / afinar. Primeiro vamos editar o httpd.conf. Deves pelo menos editar a variavel ServerAdmin e/ou ServerName. Para o PHP funcionar, deves tambem descomentar estas duas linhas

AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps

Esta ultima nao e' estritamente necessaria. Outras coisas, provavelmente podes comentar todas as referencias de AddLanguage e de LanguagePriority. Se compilaste suporte de suEXEC, tambem convem configurar a directoria escolhida para os utilizadores correrem os seus scripts, se escolheste --suexec-userdir=public_html/cgi-bin, podes por exemplo, acrescentar o seguinte ao httpd.conf:

<Directory /home/*/public_html/cgi-bin>
    Options ExecCGI
    SetHandler cgi-script
</Directory>

Procura agora a opcao DirectoryIndex, que devera' ja' conter `index.html' e modifica-a, de modo a reconhecer tambem o index.php:

<IfModule mod_dir.c>
     DirectoryIndex index.html index.php
</IfModule>

Ainda acerca do httpd.conf , dependendo do volume de requests que o apache ira' servir, se este for razoavel ou elevado, talvez seja boa ideia aumentar um bocadinho o valor de MinSpareServer, MaxSpareServers e StartServers, para o dobro por exemplo, 10,20,10, respectivamente, e talvez diminuir o TimeOut e KeepAliveTimeOut. Mas isto so' interessara' se notarem alguma degradacao na performance em utilizacao normal, devendo ser ajustado especificamente de acordo com as necessidades de cada um.

DICAS: apaga as opcoes Indexes, Includes e MultiViews de todas as directivas , e se possivel utiliza sempre a opcao FollowSymLinks em deterimento de SymLinksIfOwnerMatch, para maiores ganhos de performance. Do mesmo modo, considera usar AllowOverride None. Outro parametro que pode ser afinado, para extrair mais um bocadinho de velocidade e' o HostNameLookups. De cada vez que algum documento e' requesitado o apache faz um reverse lookup ao IP do cliente, seguido de um forward lookup, para se certificar que o endereco nao e' spoofado. Estas operacoes apesar de rapidas demoram sempre algum tempo, e num ambiente com muito trafego pode tornar-se problematico. A solucao aqui e' investigar se realmente precisamos que o apache saiba o nome em vez do IP. Na maioria dos casos nao fara' grande diferenca. Ha' duas excepcoes, uma e' se utilizas Deny's ou Allow's por nomes de dominios, podes passar a usar esses mesmos Deny e Allow com o IP. A outra excepcao sao scripts de php ou cgi's que necessitem do nome. Aqui, tens duas opcoes: podes por no httpd.conf isto, por exemplo:

HostnameLookups off
<Files ~ "\.(php|cgi|pl)$">
HostnameLookups on
</Files>

o que fara' com que so' sejam processados os lookups para ficheiros com extensao .php, .cgi ou .pl, ou entao a solucao optima, que e' _nao_ incluir isto, e modificar o script para usar o gethostbyname ou equivalente (que existe tanto no PHP como no C como no Perl) para traduzir de IP para nome. Fica ao criterio de cada um.

Vamos agora passar ao PHP. Em primeiro lugar, vamos acrescentar o Zend Optimizer. Comecamos por editar o php, que anteriormente copiamos para /etc:
[/etc]# vi php.ini
Mesmo junto ao fim do ficheiro, vamos acrescentar tres linhas, de modo a que fique a parecer-se com isto:

   ; Local Variables:
   ; tab-width: 4
   ; End:


   ; Zend Optimizer 1.1.0
   zend_optimizer.optimization_level=15
   zend_extension="/usr/local/httpd/lib/ZendOptimizer.so"

Esta parte ja' esta'! Ha' no entanto, outras opcoes no php.ini que podes/deves afinar. Por exemplo, podes mudar o valor de zlib.output_compression para On, assim o proprio PHP encarrega-se de comprimir o seu output - mas, uma vez que estamos a usar o mod_gzip, esta opcao talvez nao seja necessaria (talvez faca aqui falta um benchmark para ver qual dos metodos tem melhores resultados em termos de compressao versus performance, se o mod_gzip se a zlib. Se alguem estiver interessado em fazer esse tipo de comparacao, agradecia que me informasse dos resultados :) Obrigado!), eu tenho-a como Off. Um bocadinho mais abaixo temos safe_mode_protected_env_vars, que e' uma lista de variaveis do ambiente que os scripts de php _NAO_ poderao nunca mudar. Uma boa opcao e' especificar, pelo menos LD_LIBRARY_PATH, LTDL_LIBRARY_PATH, LD_PRELOAD, HISTFILE, HISTFILESIZE, HISTSIZE, PATH, USER, etc

Logo abaixo, temos disable_functions. Eu so' tenho 1 funcao proibida, nesta lista, que e' `phpinfo', como revela dados mais ou menos sensiveis sobre o sistema, opto por desactiva-la. Mas atencao, antes de a incluires aqui nesta lista deves primeiro por o httpd a andar, e dar uma olhada ao output precisamente do phpinfo(); . Por enquanto, nao a incluas.

Mais abaixo encontras a definicao display_errors, que deves desligar, ou seja, definir como Off, e definir mais abaixo um error_log, de modo a que os erros sejam encaminhados para um ficheiro, para posterior revisao e/ou debug. Cerca de 2 paginas abaixo, temos a directiva user_dir, que deves modificar para a directoria de html publico, que devera' ser `public_html' . Algumas linhas depois, temos file_uploads, que deves definitivamente desligar (Off). Estes sao os items mais importantes, deves no entanto dar uma olhada a todos os outros e configurar de acordo com as tuas necessidades.

Esta' quase... so' falta adicionar a configuracao do mod_gzip ao httpd.conf. Eu tenho a configuracao num ficheiro chamado mod_gzip.conf, que chamo atraves do httpd.conf, com a linha `Include conf/mod_gzip.conf'. A minha configuracao do apache esta' separada por varios ficheiros, desta forma e' mais facil fazer alteracoes quando preciso, pois as varias 'areas estao separadas, tornando-se o acesso a elas muito mais rapido e simples.
[/usr/local/httpd/conf]# cat mod_gzip.conf

    ### configuracao do mod_gzip
    ### modificado: 23 abr 2001 19:44pm, nuno

    mod_gzip_on Yes

    mod_gzip_minimum_file_size 512
    mod_gzip_maximum_file_size 0
    mod_gzip_maximum_inmem_size 131072
    mod_gzip_item_include mime "application/x-httpd-php"
    mod_gzip_item_include mime "httpd/unix-directory"
    mod_gzip_item_include mime "text/*"

    mod_gzip_dechunk Yes
    mod_gzip_keep_workfiles No
    mod_gzip_temp_dir "/usr/local/httpd/tmp"

    mod_gzip_item_include file "\.php$"
    mod_gzip_item_include file "\.txt$"
    mod_gzip_item_include file "\.html$"
    mod_gzip_item_include file "\.htm$"
    mod_gzip_item_include file "\.pl$"
    mod_gzip_item_include file "\.cgi$"
    mod_gzip_item_exclude file "\.css$"
    mod_gzip_item_exclude file "\.js$"

    ### EOF
Ainda em relacao ao mod_gzip, podes alterar a directiva LogFormat e CustomLog, de modo a que os logs contenham informacao do mod_gzip, nomeadamente, se o documento enviado foi ou nao comprimido, a taxa de compressao, tamanho inicial, tamanho final, etc. E' de alguma forma util, pois existem ja' varias aplicacoes que processam os logs do apache/mod_gzip e fazem estatisticas sobre a taxa de compressao, trafego, etc. Deves, portanto comentar todas as instancias anteriores destas duas directivas, LogFormat e CustomLog, acrescentando estas duas:

LogFormat "%h %l %u %t \"%V %r\" %>s %b mod_gzip: %{mod_gzip_result}n In:%{mod_gzip_input_size}n Out:%{mod_gzip_output_size}n:%{mod_gzip_compression_ratio}npct." common_mod_gzip
(Atencao que esta directiva e' uma unica linha, aqui aparece partida porque e' muito grande)
CustomLog /usr/local/httpd/logs/access_log common_mod_gzip

O resultado final, nos logs, e' qualquer coisa deste genero:

192.168.0.17 - - [05/Jun/2001:21:27:12 +0100] "newton.itsari.net GET / HTTP/1.0" 200 1197 mod_gzip: OK In:1310 Out:751:43pct.

Ainda em relacao ao mod_gzip, como podem ver pela variavel `mod_gzip_temp_dir', vamos precisar de uma directoria temporaria, onde o mod_gzip comprime os documentos antes de os enviar ao cliente. Aqui, o ideal, em termos de performance e' utilizar um ramdisk, de modo a que nunca seja necessario escrever nada no disco, perdendo assim menos tempo. A mim nao me agrada particularmente usar ramdisks, pois estes tem um tamanho fixo e imutavel, nao sendo portanto muito flexiveis. O que eu uso e' o tmpfs, que e' um filesystem que guarda todos os seus ficheiros no espaco de memoria virtual, podendo crescer ou diminuir, de acordo com as necessidades especificas do momento. Anteriormente, este era conhecido como shmfs e existe com o nome tmpfs em todos os kernels 2.4-ac, tendo sido introduzido na tree oficial algures durantea fase 2.4.3pre, se nao me engano. Por isso, talvez esteja na hora de fazer um upgrade! Depois de compilar um kernel com suporte para tmpfs, tens de criar uma directoria onde queiras montar o fs. Eu uso /usr/local/httpd/tmp, e tenho, por isso, uma linha no /etc/fstab que se encarrega de montar este fs durante o boot:
[/root]# grep tmpfs /etc/fstab
tmpfs /usr/local/httpd/tmp tmpfs defaults 0 0
[/root]# df | grep tmpfs
tmpfs 252052 0 252052 0% /usr/local/httpd/tmp
No entanto, se nao usam ainda o kernel 2.4, ou se nao pretendem recompilar, ou qualquer outro motivo, podem usar um ramdisk, ou, simplesmente, nao usar nada e deixar o mod_gzip utilizar uma directoria normal no disco. Apenas como metodo didatico, se pretendem usar um ramdisk, o procedimento sera' mais ou menos este:
[/root]# dd if=/dev/zero of=/dev/ram bs=1k count=4096
4096+0 records in
4096+0 records out
[/root]# mke2fs -vm0 /dev/ram 4096
[/root]# mount -t ext2 /dev/ram /usr/local/httpd/tmp
[/root]# chown -R www.www /usr/local/httpd/tmp
Este procedimento criara' um ramdisk com 4mb, que deverao ser suficientes - em caso de necessidade podes sempre aumentar o valor. Obviamente deves acrescentar estes passos ao teu script de init do apache, de modo a que o ramdisk esteja disponivel logo que o apache precise dele. Ah, uma outra coisa, o ramdisk _NAO_ ira' funcionar a menos que tenhas dito YES 'a opcao CONFIG_BLK_DEV_RAM, ao compilar o kernel. Se nao tens suporte para isto e queres usar ramdisks, nao e' necessario recompilar todo o kernel, torna a correr o configure do kernel, selecciona esta opcao como modulo (M) e faz so' make modules e make modules_install

 

----------------------
5. Fire in the hole!
----------------------
Agora que ja' temos tudo configurado e no seu devido sitio, lets put the show on the road :)
[/usr/local/httpd/bin]# ./httpd -v
[Tue Jun 5 21:16:40 2001] [warn] Connection to lingerd socket (/var/run/lingerd/lingerd.sock) failed
Server version: Apache/1.3.20 (Unix)
Server built: Jun 5 2001 19:00:34
Ora bem, como podemos ver, o lingerd ainda nao esta' a correr, o que faz com que o apache nos avise desse facto. Atencao que este erro nao e' fatal, ou seja, mesmo sem o lingerd a correr, o apache funciona normalmente, apenas nao nas condicoes optimas de performance. Desta vez teremos de iniciar o lingerd manualmente, mas como modificamos os scripts de init (rc.local, rc.M, seja la' qual for no teu sistema), ele iniciara' automaticamente sempre que o computador for reiniciado, nao precisando portanto de qualquer outra intervencao externa.
[/usr/local/httpd/bin]# su -c ./lingerd www
[/usr/local/httpd/bin]# ./httpd -l
Compiled-in modules:
   http_core.c
   mod_env.c
   mod_log_config.c
   mod_mime.c
   mod_negotiation.c
   mod_dir.c
   mod_cgi.c
   mod_actions.c
   mod_speling.c
   mod_userdir.c
   mod_alias.c
   mod_access.c
   mod_auth.c
   mod_setenvif.c
   mod_gzip.c
   mod_php4.c
suexec: enabled; valid wrapper /usr/local/httpd/bin/suexec
Como podem ver, agora o apache ja' nao se queixou da falta do lingerd :) De resto, parece tambem estar tudo bem. Esta' na hora de o levarmos para um test drive...
[/usr/local/httpd/bin]# ./apachectl start
./apachectl start: httpd started
[/usr/local/httpd/bin]# cd ../logs
[/usr/local/httpd/logs]# tail -2 error_log
[Tue Jun 5 21:19:47 2001] [notice] Apache/1.3.20 (Unix) PHP/4.0.5 mod_gzip/1.3.19.1a configured -- resuming normal operations
[Tue Jun 5 21:19:47 2001] [notice] suEXEC mechanism enabled (wrapper: /usr/local/httpd/bin/suexec)
Ate' aqui, tudo bem! So' um 'ultimo teste para ver se o PHP funciona...
[/usr/local/httpd/htdocs]# echo "<?PHP phpinfo(); ?>" > info.php
[/usr/local/httpd/htdocs]# chmod 644 info.php
Agora, abre o teu browser preferido e ve http://ip.ip.ip.ip/info.php Obviamente que deves substituir ip.ip.ip.ip pelo ip ou nome da tua maquina! Entre variadissimas outras informacoes sobre o PHP e sobre o Apache, deve tambem dizer que o Zend Optimizer esta' a funcionar:
This program makes use of the Zend scripting language engine:
Zend Engine v1.0.5, Copyright (c) 1998-2001 Zend Technologies
   with Zend Optimizer v1.1.0, Copyright (c) 1998-2000, by Zend Technologies
   -------------------------------------------------------------------------
                  |
                   ---> ca' esta'!
E, um bocadinho mais abaixo, aparece isto:
Zend Optimizer

Optimization Pass 1                  enabled
Optimization Pass 2                  enabled
Optimization Pass 3                  enabled
Ou seja, esta' tudo a funcionar devidamente. Uma vez que ja' testamos tudo, vamos editar o /etc/php.ini e acrescentar phpinfo 'a lista de funcoes interditas, tal como ja' se tinha visto mais em cima. Edita-o, procura por `disable_functions' (que, ja' agora, nao deve conter nada ainda), acrescenta `phpinfo', e salva o ficheiro. Agora, e' necessario reiniciar o apache, para a nova configuracao do PHP tomar efeito. Aproveita e apaga o ficheiro info.php que criaste, pois ja' nao vai servir para nada.
[/usr/local/httpd/bin]# ./apachectl restart
./apachectl restart: httpd restarted
[/usr/local/httpd/bin]# rm -f ../htdocs/info.php
Neste ponto, podes aproveitar e apagar tudo o que ja' nao precisas, ou seja, as sources comprimidas e as directorias para onde elas foram descomprimidas. Uma coisa que deves fazer, no entanto, e' copiar os ficheiros `config.status' que vais encontrar tanto na directoria apache_1.3.20 como na php-4.0.5 para outro lado qualquer (eu tenho uma directoria `configs' na minha homedir). Estes ficheiros sao extremamente uteis, pois permitem-te saber como configuraste o pacote em causa, quais as opcoes que utilizaste, bem como as optimizacoes (cflags), etc. Talvez agora estejas a pensar "Sim, e isso serve para que?", mas imagina que daqui a 8 ou 9 meses vais fazer upgrades e ja' nao fazes a minima ideia de como configuraste a aplicacao X ou Y - nesse caso estes ficheiros vao-te dar uma grande ajuda, pois vais conseguir duplicar a configuracao/compilacao comodamente e sem problemas. Para evitar confusoes, convem tambem que acrescentes o nome da aplicacao ao nome do ficheiro, por ex, `php-4.0.5.configure.status'. Acredita que medio/longo prazo estes backups te vao poupar imenso tempo, trabalho e dores de cabeca :)

E pronto, parece que o nosso trabalho chegou ao fim :) Se nada correu mal, deves ter agora um apache plenamente funcional e pronto para uso. Se (god forbid) alguma coisa nao correu como esperado, volta atras, le com mais atencao, e certifica-te que nao cometeste nenhum erro - as vezes as coisas mais pequenas tem os resultados mais catastroficos. A titulo de exemplo, quando estava a compilar o PHP para este exemplo nao conseguia de maneira nenhuma que o configure encontrasse a zlib, apesar de a ter instalada numa localizacao standard. Apos ter modificado o script de configure para conseguir passar isso 'a frente, e quando ja' estava a escrever um mail 'a Zend para reportar o bug, ao fazer copy/paste da minha linha de ./configure e' que reparei que, em vez de --with-jpeg-dir, tinha escrito --with-jpge-dir ... duh! Um erro minimo, mas o suficiente para fazer com que todo o configure se engasgasse. Claro que apos ter corrigido esse erro tudo funcionou 'as mil maravilhas - o material tem _sempre_ razao! Se, mesmo assim, tiveres alguma duvida ou questao, ou simplesmente queiseres partilhar opinioes ou experiencias, manda-me um mail para nuno@null.net

Por agora, e' tudo! Divirtam-se :)

-- Nuno / paran0id