Instalacao e Configuracao Apache 1.3.24 + lingerd 0.93 + PHP 4.1.2 mod_gzip 1.3.19.1a + ZendOptimizer 1.2.0 -------------------------------------------------------------------------------- Versao 1.3 - 2002 / 04 / 20 Nuno Monteiro -------------------------------------------------------------------------------- 1. Necessario -------------------------------------------------------------------------------- o Apache 1.3.24 --> ftp://ftp.netc.pt/pub/apache o lingerd 0.93 --> ftp://iagora.com/pub/software/lingerd/lingerd-0.93.tar.gz o mod_gzip 1.3.19.1a --> http://www.remotecommunications.com/apache/mod_gzip o PHP 4.1.2 --> http://pt.php.net o Zend Optimizer 1.2.0 --> 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.24.tar.gz [/usr/local/src]# tar zxf php-4.1.2.tar.gz [/usr/local/src]# tar zxf ZendOptimizer-1.2.0-PHP_4.1.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.24/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.24/src/main/ [/usr/local/src/lingerd-0.93]# patch -p0 -d /usr/local/src/apache_1.3.24/src/ < apache-1.3/aplinger.diff Vamos agora criar um utilizador e um grupo para o apache correr. No meu sistema esse utilizador / grupo e' www/www, o que nao significa que tenha forcosamente de ser esse, mas, 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 -s -pipe -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 e clones Pentium s/TSC) -march=i686 (Pentium Pro, Pentium 2, Pentium 3, Pentium 4) Se tiverem um K6 ou K7 da AMD (Athlon / Duron) e usam gcc versao 3.0 (penso que tambem deve funcionar no 2.96, que afinal e' um snapshot do 3.0), podem especificar -march=K7 ou -march=K6 . Se no entanto tiverem problemas, -march=i686 devera' ser a aposta mais segura para estes processadores. /* FIXME: actualizar isto, nao esta grande coisa. novos targets no */ /* gcc v3{1,2} ... e nem todo o mundo e' x86 ;) */ 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 -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.24 [/usr/local/src/apache_1.3.24]# ./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.1.2]# CFLAGS='-O3 -fomit-frame-pointer -pipe -s \ -ffast-math -fexpensive-optimizations -march=i686' ./configure \ --with-config-file-path=/etc --enable-inline-optimization \ --enable-track-vars --with-mysql=/usr/mysql --with-apache=../apache_1.3.24 \ --enable-sysvsem --enable-sysvshm --enable-shmop --with-gd --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/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 ou 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 do apache. Nao e' nada obscuro, todas estas opcoes encontram-se bem documentadas no manual. 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.24]# CFLAGS='-O3 -fomit-frame-pointer \ -pipe -s -ffast-math -fexpensive-optimizations -march=i686 \ -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 --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 --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'. Mas, 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: May 21 21:12:53 hobbes 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 May 21 21:12 lingerd.pid srwxr-xr-x 1 www www 0 May 21 21:12 lingerd.sock= Bom, e agora ja' so' nos resta instalar o Zend Optimizer... Nas versoes antigas tinha de se instalar 'a mao, por assim dizer, ou seja, tinha de se copiar os ficheiros necessarios para o seu destino e editar o php.ini manualmente. Actualmente ja' nao e' preciso fazer isso pois no .tar.gz da distribuicao do Optimizer encontra-se um shell script que se encarrega de fazer isso por nos. Por isso, nada mais simples do que [(...)/ZendOptimizer]# ./install.sh ou, se preferiem uma instalacao em modo texto puro [(...)/ZendOptimizer]# ./install-tty.sh e seguir as instrucoes no ecra. Geralmente os valores default propostos pelo programa sao correctos, excepto a localizacao do ficheiro php.ini, que, na nossa instalacao se encontra em /etc/php.ini . E pronto, e' tudo o que e' necessario modificar, a instalacao ira fazer tudo o resto e nao precisamos de nos preocupar mais :) E assim 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. Deves, tambem, alterar a variavel ServerTokens para 'prod', de modo a divulgarmos o menos possivel sobre o server e o software que ele corre. 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, podes por exemplo, acrescentar o seguinte ao httpd.conf: Options ExecCGI AllowOverride none AddHandler cgi-script .cgi .pl Procura agora a opcao DirectoryIndex, que por defeito contem `index.html' e modifica-a, de modo a reconhecer tambem o index.php: DirectoryIndex index.html index.php 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, ate' porque dependem das condicoes da rede nesse determinado momento, podem ser algo lentas (todos nos sabemos quao lento e' por vezes o dns) 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 HostnameLookups on o que fara' com que so' sejam processados os lookups para ficheiros acabados em .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 Deves verificar algumas coisas na configuracao do teu PHP antes de poderes realmente entrar com o servidor em producao. Ha' varios aspectos de seguranca que nao se devem descurar. E lembra-te, no php.ini master deves ser o mais estricto possivel com permissoes e seguranca, pois podes modificar os valores para cada vhost, caso seja necessario, usando as directivas php_admin_value e php_admin_flag. Eu recomendo que desligues (definas como Off) as funcoes file_uploads ; register_globals ; allow_url_fopen . Deves tambem afinar a funcao disable_functions de modo a nao permitires o acesso a funcoes que podem ser potencialmente perigosas. Dois candidatos obvios a inclusao nessa lista sao o 'phpinfo' e o 'posix_kill' Do mesmo modo, e' geralmente uma boa medida impor o safe_mode como On e, com configuracoes para cada vhost os varios valores como open_basedir doc_root, user_dir, safe_mode_exec_dir, etc. Um exemplo: DocumentRoot /var/www/hosting/exemplo.com ServerAdmin webmaster@exemplo.com ServerName www.exemplo.com ServerAlias outro.exemplo.com [...] php_admin_flag safe_mode On php_admin_value open_basedir /var/www/hosting/exemplo.com php_admin_value doc_root /var/www/hoting/exemplo.com php_admin_value user_dir /var/www/hosting/exemplo.com php_admin_value safe_mode_exec_dir /var/www/hosting/exemplo.com php_admin_value session.save_path /var/www/hosting/exemplo.com/tmp php_admin_value mysql.default_host localhost:/var/lib/mysql/mysql.sock php_admin_value mysql.default_socket /var/lib/mysql/mysql.sock php_admin_flag mysql.allow_persistent On php_admin_value mysql.max_links 5 php_admin_flag magic_quotes_gpc On [...] Ha' outras opcoes a ter em conta, de modo a limitar convenientemente os recursos a que cada vhost podera' ter acesso, como por exemplo 'max_execution_time' e 'memory_limit', que tambem devem ser definidos para cada vhost, de acordo com as necessidades de cada um. Tambem se deve ter em atencao 'safe_mode_{allowed,protected}_env_vars'. Outro ponto fulcral e' o display de erros - deve-se definir display_errors como Off e possivelmente definir error_log para um ficheiro onde se queira que os erros sejam logged. Enfim, recomenda-se uma leitura atenta do php.ini, pelo menos. Esta' quase... so' falta adicionar a configuracao do mod_gzip ao httpd.conf. Eu tenho a configuracao num ficheiro chamado mod_gzip.conf, que incluo a partir do httpd.conf, usando `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, gerando 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_with_mod_gzip_info2 CustomLog /usr/local/httpd/logs/access_log common_with_mod_gzip_info2 O resultado final, nos logs, e' qualquer coisa deste genero: 192.168.0.6 - - [21/May/2001:21:27:12 +0100] "hobbes.itsari.int 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 durante a fase 2.4.4pre, 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, pois, 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 Apr 20 17:11:21 2002] [warn] Connection to lingerd socket (/var/run/lingerd/lingerd.sock) failed Server version: Apache/1.3.24 (Unix) Server built: Apr 20 2002 15:19:17 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 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 -3 error_log [Tue Apr 20 17:12:13 2002] [notice] Apache configured -- resuming normal operations [Tue Apr 20 17:12:13 2002] [notice] suEXEC mechanism enabled (wrapper: /usr/local/httpd/bin/suexec) [Tue Apr 20 17:12:13 2002] [notice] Accept mutex: sysvsem (Default: sysvsem) 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 `configure.status' que vais encontrar tanto na directoria apache_1.3.24 como na php-4.1.2 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 6 meses vais fazer upgrades e ja' nao fazes a minima ideia de como configuraste a aplicacao X ou Y - nesse caso estes ficheiros vao dar-te uma grande ajuda, pois vais conseguir duplicar a configuracao e 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 para o mail 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.monteiro@ptnix.com Por agora, e' tudo! Divirtam-se :) -- Nuno OBS: Como obviamente nao me outorgo o titulo de "expert" em apache & friends, tudo o acima exposto pode ser, obviamente, errado ou incorrecto. De qualquer forma, _eu_ uso estas configuracoes e/ou procedimentos em varias instalacoes de apache (eat your own cookings ;) com trafego moderado, e ate' 'a data nao tem havido grandes quirks :) YMMV.