2 Apresentao sobre o Apache (histrico, levantamento sobre forma de distribuio, sua funcionalidade, caractersticas)

2.1 Histrico

Segundo ao site do prprio Apache Software Foundation relatar o seguinte sobre seu surgimento: Em fevereiro de 1995, o software de servidor mais popular na Web foi o domnio pblico Daemon HTTP desenvolvido por Rob McCool no Centro Nacional de Aplicaes de Supercomputao da Universidade de Illinois, em Urbana-Champaign. No entanto, o desenvolvimento de httpd que tinha parado depois de Rob esquerda NCSA (National Center of Supercomputing Applications) em meados de 1994, e muitos webmasters desenvolveram suas prprias extenses e correes de bugs que estavam em necessidade de uma distribuio comum. Um pequeno grupo destes webmasters, contactado atravs do e-mail particular, se reuniram com o propsito de coordenar suas mudanas (na forma de "patches"). Brian Behlendorf e Cliff Skolnick montar uma lista de discusso, espao de informao compartilhada, e logins para os desenvolvedores do ncleo em uma mquina na rea da baa da Califrnia, com largura de banda doados por HotWired. At o final de fevereiro, oito contribuintes centrais formaram a fundao do Grupo Apache original: Brian Behlendorf Roy T. Fielding Rob Hartill David Robinson Cliff Skolnick Randy Terbush Robert S. Thau Andrew Wilson

Com contribuies adicionais de: Eric Hagberg Frank Peters Nicolas Pioch Usando NCSA httpd 1.3 como uma base, eles adicionamos todas as correes de bugs e melhorias valiosas publicados ns poderamos encontrar, testou o resultado nos prprios servidores, e fez o primeiro lanamento oficial pblico (0.6.2) do servidor Apache em Abril de 1995. Por coincidncia, NCSA reiniciado o seu prprio desenvolvimento, no mesmo perodo, e Brandon Long e Beth Frank, da equipe de desenvolvimento do servidor NCSA entrou para a lista em maro como membros honorrios, de modo que os dois projetos podem compartilhar ideias e correes. O servidor Apache no incio foi um grande sucesso, mas todos sabamos que a base de cdigo necessria uma reviso geral e redesenho. Durante Maio e Junho de 1995, enquanto Rob Hartill e o resto do grupo focada na implementao de novos recursos para 0.7.x, e apoiar a comunidade de usurios crescente Apache, Robert Thau projetou uma nova arquitetura de servidor (cdigo chamado Shambhala), que incluiu uma estrutura modular e API para uma melhor capacidade de extenso de alocao de memria e um modelo de processo adaptativo pr-bifurcao. O grupo ligado a esta base de novo servidor em julho e adicionou as caractersticas de 0.7.x, resultando em Apache 0.8.8 em agosto. Aps o teste beta extensa, muitas portas para plataformas obscuros, um novo conjunto de documentao (por David Robinson), e da adio de muitos recursos na forma de nossos mdulos padro, o Apache 1.0 foi lanado em 1 de dezembro de 1995. Menos de um ano depois que o grupo foi formado, o servidor Apache passou httpd da NCSA como o servidor nmero 1 na Internet de acordo com a pesquisa da Netcraft, mantm essa posio hoje. Em 1999, os membros do Grupo Apache formaram a Apache Software Foundation para fornecer suporte organizacional, legal e financeira para o Servidor HTTP Apache. A fundao colocou o software em uma base slida para o desenvolvimento futuro, e expandiu o nmero de projetos de software de cdigo aberto.
2.2 Formas de distribuio

A Licena Apache (Apache License em ingls) uma licena para software livre (Open Source) de autoria da Apache Software Foundation (ASF). Todo software produzido pela ASF ou qualquer um dos seus projetos e subprojetos licenciado de acordo com os termos da licena Apache. Alguns projetos no pertencentes ASF tambm utilizam esta licena. A licena Apache (verses 1.0, 1.1 e 2.0) exige a incluso do aviso de Copyright, Disclaimer, mas no se torna uma Copyleft, ASF permite o uso e distribuio do cdigo fonte tanto no software Open Source como no software proprietrio. Segundo o autor Robson quila: Copyright seu uso, redistribuio ou modificaes proibido, ou requer que voc pea permisso, ou restrito de tal forma que voc no possa efetivamente faz-lo livremente. Disclaimer uma ressalva ou aviso legal ou termo de responsabilidade ou ainda, uma referncia ou aviso. Copyleft um conceito atrelado a um programa protegido por uma licena de software livre que contenha clusula garantindo a liberdade permanente, inclusive de modificaes, onde o programa redistribudo tenha que disponibilizar, de fcil acesso, o cdigo fonte contendo as modificaes. Todo o software livre se destina a ser, assim, livre para todos. No entanto, existem algumas legais restries que as licenas de software individuais imposta. Por exemplo, o Linux, que feita gratuitamente pela GNU Public License (GPL), exige que todas as alteraes para o Linux ser tornada pblica. Apache, por outro lado, no exige que as alteraes feitas no Apache se torne pblica ( Mohammed J. Kabir, pag. 10). Segundo Mohammed J. Kabir: Em suma, acho que o Apache como livre, software protegido por direitos autorais publicados pelo Apache Grupo. No nem do domnio pblico nem Shareware. Alm disso, note que o Apache no so cobertos pela GPL. Em Wikipdia: Shareware um programa de computador disponibilizado gratuitamente, porm com algum tipo de limitao. Um Shareware est protegido por direitos autorais.

2.3 Funcionalidade do Servidor Apache

Por ser um software livre, o que significa que qualquer um pode estudar ou alterar seu cdigo-fonte, alm de poder utiliz-lo gratuitamente (Mohammed J. Kabir, 2002). graas a essa caracterstica que o software continua sendo melhorado ao passar dos anos. Alm de estar disponvel para o Linux e para outros sistemas operacionais baseados no Unix, como tambm conta com verses para o Windows, para o Novell Netware e para o OS/2. O servidor Apache capaz de executa cdigo em PHP, Perl, Shell Script e at em ASP e pode atuar como servidor FTP, PROXY, entre outros. Sua utilizao mais conhecida a que combina o Apache com a linguagem PHP e o banco de dados MySQL.
2.4 Caracterstica do Servidor Apache

Abaixo, segue um resumo com as principais caractersticas (extrado do Guia Foca Linux): Possui suporte a scripts CGI usando linguagens como Perl, PHP, Shell Script, ASP, etc; Suporte a autorizao de acesso podendo ser especificadas restries de acesso separadamente para cada endereo/arquivo/diretrio acessado no servidor; Autenticao requerendo um nome de usurio e senha vlidos para acesso alguma pgina/subdiretrio/arquivo (suportando criptografia via Crypto e MD5); Negociao de contedo, permitindo a exibio da pgina web no idioma requisitado pelo cliente navegador; Suporte a tipos Mime; Personalizao de Logs; Mensagens de erro; Suporte a Virtual Hosting ( possvel servir duas ou mais pginas com endereos e portas diferentes atravs do mesmo processo ou usar mais de um processo para controlar mais de um endereo); Suporte a IP virtual Hosting; Suporte a Name Virtual Hosting; Suporte a servidor Proxy FTP e HTTP, com limite de acesso, caching (todas flexivelmente configurveis); Suporte a Proxy e redirecionamentos baseados em URLs para endereos Internos; Suporte a criptografia via SSL, Certificados digitais;

 Mdulos DSO (Dynamic Shared Objects) permitem adicionar/remover funcionalidades e recursos sem necessidade de recompilao do programa.

2.5 Arquitetura Apache 2.0

No Apache Verso 1.3 ou anterior usou uma arquitetura preforking, nesta arquitetura, um processo pai Apache bifurcada um conjunto de processos filhos, que atendido os pedidos atuais. O processo pai simplesmente acompanhou os processos filhos ou mortos com base na quantidade de pedidos recebido (Mohammed J. Kabir, 2002). Infelizmente, esse modelo no funciona bem em plataformas que no so centrado no processo, como o Windows. O grupo Apache veio com a MPM, que so Mdulos de multiprocessamento, a primeira grande mudana no Apache 2.0 a introduo de multiprocessamento mod-regras ou mod-rules (MPMs). Essa foi base da soluo. Cada MPM responsvel por iniciar os processos do servidor e para o servio pedidos via processos filhos ou tpicos, dependendo da implementao MPM (Apache Software Foundation). Vrios MPMs esto disponveis, Retirado da Bblia do Apache: O MPM prefork imita o Apache 1.3 ou anterior arquitetura, criando um tipo de armazenamento de processos filhos para solicitaes de servios. Cada processo filho tem um nico segmento. Por exemplo, se o Apache comea 30 processos filhos, ele pode atender 30 pedidos simultaneamente. Se algo der errado e o processo filho morre, apenas um pedido nico est perdido. O nmero de processos filhos controlado por uma configurao mnima e mxima. Quando aumenta o nmero de pedidos, os processos filhos so adicionados novos at o mximo atingido. Da mesma forma, quando os pedidos caem, quaisquer processos adicionais filho so mortos. Este MPM permite o suporte segmento no Apache 2.0. Isto como o MPM prefork, mas em vez de cada processo filho ter um nico fio, cada processo filho permitido ter um determinado nmero de segmentos. Cada segmento dentro de um processo filho pode ser vice e versa um pedido diferente. Se o Apache comea 30 processos filhos onde cada filho permitido ter, no mximo, 10 linhas, que o Apache pode atender 30 10 = 300 pedidos simultaneamente. Se algo der errado com uma linha, um mdulo experimental provoca a morte da thread, em seguida, todo o processo morrer. Isto significa que todos os pedidos sendo atendido pelos segmentos dentro do processo filho ser perdido. Segundo Mohammed J. Kabir:

"Um processo adicionado ou removido, monitorando sua contagem da linha de reposio, se um processo tem menos do que o nmero mnimo de segmentos de reposio, um novo processo adicionado. Da mesma forma, quando um processo tem um nmero mximo de segmentos ociosos, ele matar o processo." Todos os processos so executados sob o mesmo usurio e ID do grupo designado para o servidor Apache. Como segmentos so mais eficientes do que os processos de recurso, este MPM muito escalvel. O MPM perchild tambm novo no Apache 2.0 um modelo MPM um nmero definido de processos filhos so iniciados com um nmero especificado de linhas, medida que a carga aumenta a pedido processos adicionar novos tpicos, conforme necessrio. Quando a contagem de pedido reduz, os processos de encolher seu segmento conta com uma configurao de contagem mnima e mxima discusso. A principal diferena entre este mdulo e o MPM que o processo de contagem esttica e tambm cada processo pode ser executado usando um usurio diferente e ID do grupo, com isso torna mais fcil para executar diferentes sites virtuais sob usurio e grupo IDs. O MPM winnt este o MPM para a plataforma Windows, incluindo o Windows 2000, Windows NT, e Janela 9x, um mdulo de vrios segmentos, usando este mdulo o Apache criar um processo pai e um processo filho. O processo filho cria todos os tpicos que servios a solicitao, alm disso, este mdulo agora tira proveito de algumas chamadas de funo nativas para Windows, o que permite um melhor desempenho do que as verses anteriores do Apache servidor na plataforma Windows. Filtragem de I / O significa dizer que um mdulo de sada pode tornar-se um outro mdulo de entrada, este novo efeito de filtragem se torna um recurso muito interessante. Segundo Mohammed J. Kabir: "A sada produzida por scripts CGI, o qual processado pelo mdulo mod_cgi, pode agora ser entregue ao mdulo mod_include responsvel por SSIs. Em outras palavras, os scripts CGI pode produzir uma sada como tags SSI, o que pode ser processada antes da sada final enviado para o navegador."

Novo CGI Daemon um mdulo que roda de forma independente em background, em vez de ser controlado diretamente por um usurio. Um script cgi pode ser de qualquer tipo (perl, bash, binrio c, etc...) e pode estar em qualquer diretrio. Segundo o Apache Software Foundation: O CGI (Common Gateway Interface) define um caminho para um servidor web para interagir com o contedo externas geradoras de programas, que so muitas vezes referidos como programas CGI ou scripts CGI. o mais simples, e mais comum forma, colocar contedo dinmico em seu site. No apache 2.0 o mod_cgid cria um processo daemon, que gera processos CGI e interage de forma mais eficiente. Os scripts CGI so executados de trs formas, Quando o pedido CGI chega a um segmento dentro de um processo filho, que passa a solicitar ao daemon CGI, ou quando o daemon CGI gera o script CGI e emite o CGI-script gerado dados para o segmento no processo filho e quando o segmento retorna os dados para o browser. Quando o servidor Apache principal iniciado, ele tambm inicia o daemon CGI e estabelece uma conexo de soquete. Assim, quando um novo processo filho criado, ele herda o soquete de ligao e, portanto, no tm nenhuma necessidade de criar uma ligao para o CGI daemon para cada solicitao.
2.6 Estrutura de Diretrios do Apache

Segundo a Documentao da Apache Software Foundation: include: Contm tudo o cabealho C (incluir) os arquivos que so necessrios apenas se desenvolver aplicativos da Web que se integram com o Apache ou quiser usar utilizao software de terceiros com o Apache, o que pode exigir os arquivos de cabealho. Num servidor de produo voc pode remover este diretrio. lib: Abriga o Apache Portable Run-Time arquivos (APR) de bibliotecas, os arquivos que so necessrios para a execuo de Apache, e utilidades de apoio, tais como ab. bin: Contm os programas ab, apachectl, APXS, htdigest, htpasswd, httpd, logresolve e rotatelogs. Detalhe no Anexo B.

 conf: Arquivos de configurao para o Apache. Ele contm os arquivos httpd.conf, httpd std.conf, highperformance.conf e mime.types. Detalhe no Anexo C. htdocs: o padro diretrio raiz do documento para o Apache principal servidor. O arquivo httpd.conf define a diretiva DocumentRoot para este diretrio. Por padro, o diretrio htdocs tambm tem o manual do Apache inteiro instalado em um subdiretrio. icons: Usados para armazenar cones Apache vrios que so necessrios para a exibio dinamicamente a lista do diretrio de construo. logs: Usados para armazenar os logs do servidor Apache, o daemon de socket CGI (Cgisock), e o ficheiro de PID (httpd.pid). cgi-bin: O diretrio padro do script CGI, que definido usando o ScriptAlias directiva em httpd.conf.
2.7 Arquivos de log criados pelo Apache

O servidor httpd grava seus arquivos de log geralmente em /var/log/apache, no possvel descrever os arquivos de logs usados porque tanto seus nomes como contedo podem ser personalizados no arquivo httpd.conf (Mohammed J. Kabir, 2002), mesmo assim, os arquivos de logs encontrados na instalao padro do Apache so os seguintes: access.log: Registra detalhes sobre o acesso as pginas do servidor httpd. error.log: Registra detalhes saber erros de acesso as pginas ou erros internos do servidor. agent.log: Registra o nome do navegador do cliente (campo UserAgent do cabealho http)
2.8 Arquivos de configurao do Apache

Por padro esses arquivos se encontrar no diretrio /etc/apache, so seguinte segundo a Documentao da Apache Software Foundation: httpd.conf: - Arquivo de configurao principal do Apache, possui diretivas que controlam a operao do daemon servidor. Um arquivo de configurao alternativo pode ser especificado atravs da opo "-f" da linha de comando.

 srm.conf: - Contm diretivas que controlam a especificao de documentos que o servidor oferece aos clientes. O nome desse arquivo pode ser substitudo atravs da diretiva ResourceConfig no arquivo principal de configurao. access.conf: - Contm diretivas que controlam o acesso aos documentos. O nome desse arquivo pode ser substitudo atravs da diretivaAccessConfig no arquivo principal de configurao. O servidor Web l os arquivos acima na ordem que esto especificados (httpd.conf, srm.conf e access.conf). As configuraes tambm podem ser especificadas diretamente no arquivo httpd.conf. Uma observao a ser feita que no obrigatrio usar os arquivos srm.conf e access.conf, segundo Mohammed J. Kabir, 2002, mas isto proporciona uma melhor organizao das diretivas do servidor, principalmente quando se tem um grande conjunto de diretivas.
2.9 Virtual Host

Na apostila Apache completo Cap. 10, pag. 81 fornecida pelo site http://apostilando.com, relatar o seguinte: Virtual Hosts (sites virtuais) um recurso que permite servir mais de um site no mesmo servidor. Podem ser usadas diretivas especficas para o controle do site virtual, como nome do administrador, erros de acesso pgina, controle de acesso e outros dados teis para personalizar e gerenciar o site. Existem dois mtodos de Virtual Hosts: No virtual hosts baseados em IP requer um endereo IP diferente para cada site. Este poder ser um IP real, que o da interface de rede, deve haver um endereo IP diferente para cada site. O nmero de sites servidos estar limitado a quantidade de endereos IP disponveis em sua classe de rede. O apache foi um dos primeiros servidores a incluir suporte a virtual hosts baseados em IP. Em virtual hosts baseados em nome, utiliza nomes para identificar os sites servidos e requerem somente um endereo IP. Desta maneira possvel servir um nmero ilimitado de sites virtuais. O navegador do cliente deve suportar os cabealhos necessrios para garantir o funcionamento deste recurso, hoje praticamente todos os navegadores atuais possuem este suporte. As explicaes seguintes so baseadas na documentao do Apache:

 Virtual hosts baseados em IP Existem duas maneiras de rodar este tipo de host virtual: Atravs de daemons httpd separados ou em um nico daemon httpd usando a diretiva <VirtualHost>. As vantagens do uso de daemons separados para servir requisies a proteo sob UID e GID diferente dos outros servidores, assim o administrador do site1 no ter acesso ao httpd.conf, pgina do site2 (porque ele rodar sob uma UID e GID diferentes e o acesso restrito). Para usar este mtodo, especifique a opo f [arquivo_cfg] para utilizar um arquivo de configurao personalizado e a diretiva Listen endereo: porta para dizer onde o servidor aguardar as requisies. As vantagens do uso de um mesmo daemon para servir as requisies so: quando no h problema se os administradores de outros sites tenham acesso ao mesmo arquivo de configurao ou quando h a necessidade de servir muitas requisies de uma s vez (quanto menos servidores web estiverem em execuo, melhor o desempenho do sistema). Abaixo um exemplo de configurao de virtual hosts servindo os sites:

www.site1.com.br e www.site2.com.br:
ServerAdmin webmaster@site.com.br <VirtualHost www.site1.com.br> ServerName www.site1.com.br ServerAdmin site1@site1.com.br DocumentRoot /var/www/www_site1_com_br TransferLog /var/log/apache/site1/access.log ErrorLog /var/log/apache/site1/error.log User wwwdata Group wwwdata </VirtualHost> <VirtualHost www.site2.com.br>

ServerName www.site2.com.br DocumentRoot /var/www/www_site2_com_br TransferLog /var/log/apache/site2/access.log ErrorLog /var/log/apache/site2/error.log </VirtualHost>

Qualquer diretiva dentro de <VirtualHost> controlaro e tero efeito no site virtual especificado. Quando uma diretiva no for especificada dentro de <VirtualHost>, sero usados os valores padres especificados no arquivo de configurao do Apache (como a diretiva ServerAdmin webmaster@site.com.br que ser usado como padro na configurao de www.site2.com.br). Observao: Digite apache S para ver suas configuraes de virtual hosts atual. Observao1: Desative a diretiva UseCanonicalName off quando utilizar o recurso de mquinas virtuais, esta diretiva faz que o nome do servidor retornado usando o valor em ServerName quando o cliente digita um endereo qualquer. Observao2: Utilize sempre que possvel endereos IP em configuraes crticas, assim os servios no sero to vulnerveis a possveis falsificaes ou erros. OBS3: No permita que outros usurios a no ser o root e o dono do processo Apache (especificado pela diretiva User) tenham acesso de gravao aos logs gerados pelo servidor, pois os dados podem ser apagados ou criados links simblicos para binrios do sistema que sero destrudos quando o Apache gravar dados. Virtual hosts baseados em nome Este mtodo idntico ao baseado em IP, em especial adicionamos a diretiva NameVirtualHost para dizer qual o endereo IP do servidor que est servindo o virtual hosts baseados em nome. Veja o exemplo de configurao:
NameVirtualHost 200.200.200.10:80 <VirtualHost 200.200.200.10>

ServerName www.site1.com.br ServerAdmin admin1@site1.com.br DocumentRoot /var/www/www_site1_com_br TransferLog /var/log/apache/site1/access.log ErrorLog /var/log/apache/site1/error.log </VirtualHost> <VirtualHost 200.200.200.10> ServerName www.site2.com.br ServerAdmin admin2@site2.com.br DocumentRoot /var/www/www_site2_com_br TransferLog /var/log/apache/site2/access.log ErrorLog /var/log/apache/site2/error.log </VirtualHost>

A diretiva NameVirtualHost diz que ser usado virtual hosts baseados em nome servidos pela mquina com IP 200.200.200.10. Os parmetros dentro do bloco das diretivas <VirtualHost> so especficas somente no site virtual especificado, caso contrrio os valores padres definidos no arquivo de configurao sero usados. Digite apache S para ver suas configuraes de virtual hosts atual. Se sua inteno criar um grande nmero de virtual hosts que sero servidos pela mesma mquina, o uso da expanso %0 e diretivas VirtualDocumentRoot e VirtualScriptAlias so recomendados:
NameVirtualHost 200.200.200.10:80 <VirtualHost 200.200.200.10> VirtualDocumentRoot /var/www/%0 VirtualScriptAlias /var/www/%0/cgibin TransferLog log/apache/site1/access.log ErrorLog log/apache/site1/error.log

</VirtualHost>

Agora crie os diretrios em /var/www correspondentes aos nomes de domnios que sero servidos por sua mquina: mkdir /var/www/www.site1.com.br mkdir /var/www/www.site2.com.br Observao: Note que sua mquina dever estar com o DNS configurado para responder por estes domnios. ATENO: importante que os endereos especificados nas diretivas ServerName (www.site1.com.br) resolvam o endereo IP da diretiva VirtualHost (200.200.200.10). Isto deve ser feito via DNS ou nos arquivos /etc/hosts. Observao1: Utilize sempre que possvel endereos IP em configuraes crticas, assim os servios no sero to vulnerveis a possveis falsificaes ou erros. Observao2: No permita que outros usurios a no ser o root e o dono do processo Apache (especificado pela diretiva User) tenha acesso de gravao aos logs gerados pelo servidor. Pois os dados podem ser apagados ou criados links para binrios do sistema que sero destrudos quando o apache gravar dados para os logs. No anexo E, est alguns procedimentos para manter a segurana na criao de um virtual host.