15. Apache - Introducción e Instalación

1. Origen de Apache

  • El NCSA (National Centre for Supercomputing Applications) de EE.UU. desarrolló un servidor web que se convirtió en el más extendido y empleado a comienzos de 1995.
  • Fue entonces cuando el principal desarrollador del NCSA Web Server abandonó el NCSA y el proyecto comenzó a estancarse.
  • Los usuarios del programa servidor comenzaron a desarrollar sus propios parches y ampliaciones hasta que finalmente surgió el Grupo Apache como punto de encuentro, de gestión de modificaciones en el código fuente y de publicación de actualizaciones y nuevas versiones.
  • La versión 1.0 del servidor Apache se hizo pública en diciembre de 1995, y en sólo 3 años lideraba el sector de servidores web. La última versión disponible actualmente es la 2.2.

 

2. El servidor web más popular

Apache se ejecuta en 50.588.433 sitios web de los 80.655.992 existentes en abril de 2006, lo que supone un 62,72 % del total.

 

3. Características de Apache

  • Servidor web compatible con el protocolo HTTP/1.1
  • De estructura completamente modular, tanto por su filosofía como por su desarrollo y propósito multiplataforma.
  • Altamente configurable y adaptable.
  • Extensible de forma particular mediante el desarrollo de módulos propios usando la API para módulos de Apache.
  • Gratuito y de código abierto.

 

4. Arquitectura de Apache

  • A partir de la versión 2.0 de Apache se produjo un gran cambio en su arquitectura, surgiendo el concepto de los Módulos de Multiprocesamiento (MPMs – MultiProcessing Modules).
  • En la versión 1.3 y anteriores, un proceso central generaba otros procesos hijo que atendían las peticiones. El proceso padre simplemente monitorizaba, generaba y finalizaba los procesos hijo según las peticiones.
  • Existen los siguientes esquemas de MPM, sólo uno de los cuales puede instalarse y emplearse en un servidor Apache:
      • beos: módulo optimizado para BeOS.
      • event: versión experimental de worker.
      • mpm_netware: módulo optimizado para Novell Netware.
      • mpmt_os2: módulo multi-proceso y multi-hebra optimizado para OS/2.
      • prefork: módulo multi-proceso NO multi-hebra.
      • mpm_winnt: módulo optimizado para Windows, empleando funciones nativas. Sólo crea un proceso hijo con múltiples hebras de ejecución.
      • worker: módulo multi-proceso y multi-hebra.
  • Según el sistema operativo, el MPM instalado por defecto es:
      • BeOS:beos
      • Netware: mpm_netware
      • OS/2:mpmt_os2
      • Unix / Linux:prefork
      • Windows: mpm_winnt
  • Además de las directivas indicadas en cada caso, existen 2 propias del servidor a las que puede asignarse un valor distinto del predeterminado, pero que en tal caso deben figurar antes que las directivas propias del MPM:
      • ServerLimit: determina el número máximo de procesos hijo. Su valor predeterminado es:
        • 256 en mpm_prefork.
        • 16 en los casos restantes.
      • ThreadLimit: determina el número máximo de hebras de ejecución por proceso hijo. Su valor predeterminado es:
        • 1920 en mpm_winnt.
        • 64 en los casos restantes.
  • prefork:
      • Sólo una hebra de ejecución
      • Cada proceso gestiona sólo una petición simultáneamente, de manera que el impacto por fallo en una petición es mínimo.
      • Similar a la estructura empleada por versiones anteriores de Apache.

Se crea un proceso padre que gestiona los procesos hijo que atenderán las peticiones, procurando que siempre haya alguno libre para poder atender las nuevas peticiones rápidamente.

Este MPM se adapta por lo general a los recursos del sistema, de manera que requiere escaso trabajo de configuración, pero sí es importante ajustar sus directivas (en <directorio de apache>/conf/extra/httpd-mpm.conf).

      • StartServers: número inicial de procesos hijo (5).
      • MinSpareServers: número mínimo deseado de procesos hijo desocupados (5).
      • MaxSpareServers: número máximo de procesos hijo desocupados (10).
      • MaxClients: número máximo de procesos hijo. Debe tener un valor adecuado, de manera que sea suficientemente elevado para responder a las peticiones existentes, pero suficientemente bajo para asegurar la memoria física necesaria para todos los procesos (256). Si elevamos este número por encima de 256, también hay que asignar el mismo valor a ServerLimit.
      • MaxRequestsPerChild: número de peticiones que atenderá un proceso hijo (0 = ilimitado).

El proceso padre se crea asociado al puerto 80 por defecto, de modo que debe ser lanzado como root. Los procesos hijo se generan con el usuario y el grupo indicados por las directivas de servidor user y group en httpd.conf.

  • worker:
      • Sistema híbrido multi-proceso y multi-hebra.
      • Es capaz de atender un mayor número de peticiones con el mismo número de procesos y los mismos recursos.
      • Del mismo modo, un proceso que se vea bloqueado por una petición afectará a todas las demás peticiones que estaban siendo atendidas por ese mismo proceso.

Un único proceso padre de control crea los procesos hijo, cada uno con un número determinado de hebras de ejecución. El proceso de control procura que siempre haya un determinado número de hebras disponibles. Sus directivas son:

      • StartServers: número inicial de procesos (2)
      • MaxClients: número máximo de conexiones simultáneas de clientes (150)
      • MinSpareThreads: número mínimo de hebras de ejecución desocupadas (25)
      • MaxSpareThreads: número máximo de hebras de ejecución desocupadas (75)
      • ThreadsPerChild: número de hebras de ejecución constantes en cada proceso hijo (25)
      • MaxRequestsPerChild: número máximo de peticiones que atiende un proceso (0)

Por tanto, el número máximo de procesos será MaxClients / ThreadsPerChild, y hay que tener en cuenta el límite predeterminado de 16 que indica ServerLimit.

Al igual que con el modelo prefork, el proceso padre se crea asociado al puerto 80 por defecto, de modo que debe ser lanzado como root. Los procesos hijo se generan con el usuario y el grupo indicados por las directivas de servidor user y group en httpd.conf.

 

5. Instalación de Apache

  • Requisitos del sistema:
      • 50 MBs libres de espacio en disco.
      • Compilador ANSI-C y capacidad para generar ejecutables. Se aconseja el GNU C Compiler (GCC).
      • Recomendado: intérprete de PERL versión 5.003 ó superior. No es imprescindible para el funcionamiento del servidor, sólo para la ejecución de algunos scripts.
  • Proceso de instalación:
      • Descargar el código fuente de la última versión disponible de http://www.apache.org (o el mirror más próximo).
      • Descargar la firma digital del código fuente y el archivo de claves públicas de los desarrolladores de Apache.
      • Para comprobar la autenticidad del código:
      • Importamos las firmas: gpg --import KEYS
      • Verificamos el código: gpg --verify httpd-2.2.0.tar.gz.asc
      • Descomprimimos el código fuente.
      • gzip –d httpd-2.2.0.tar.gz
      • tar xvf httpd-2.2.0.tar
      • Ejecutamos el script configure
      • ./configure --prefix=directorio de instalación (valor predeterminado: /usr/local/apache2 )
      • podemos añadir posteriormente opciones de configuración ejecutando ./config.status
      • Compilamos el código fuente:
      • make
      • Y realizamos la instalación:
      • make install
      • Para arrancar el servicio HTTP de Apache:
      • <directorio de Apache>/bin/apachectl start

Módulos habilitados por defecto: algunos módulos se instalan de forma predeterminada, a menos que se indique lo contrario mediante el script configure. Podemos ver los módulos instalados en el servidor con bin/apachectl –l o bin/httpd -l

  • core: núcleo de Apache, siempre está instalado.
  • prefork: por defecto, en un sistema Unix o Linux se escoge este esquema de MPM.
  • mod_actions: habilita eventos lanzados por peticiones, que son tratados por scripts.
  • mod_alias: permite el preprocesamiento de la URL, estableciendo relaciones entre direcciones en la URL y rutas en el sistema de archivos.
  • mod_asis: permite el envío de archivos que incluyen sus propias cabeceras, de manera que Apache no las incluye.
  • mod_auth_basic: habilita la autenticación básica, como texto sencillo sin encriptar.
  • mod_authn_file: provee a los módulos de autenticación de un repositorio de contraseñas en archivos de texto.
  • mod_authn_default: sin otros métodos de autenticación, como mod_authn_basic, este módulo nos permite transferir la autenticación a otros módulos de bajo nivel.
  • mod_authz_host: gestiona autorizaciones de acceso en grupo según criterios según nombre del host o dirección IP.
  • mod_authz_groupfile: autorizaciones de acceso según grupos definidos en un archivo de texto.
  • mod_authz_user: autorizaciones de acceso según el usuario.
  • mod_authz_default: sin otros módulos de autenticación, como mod_authz_groupfile o mod_authz_user, permite indicar otros métodos de autenticación de bajo nivel.
  • mod_include: filtro que procesa las respuestas antes de ser enviadas al cliente y permite las tareas típicas de Server Side Includes, como incluir archivos, control condicional, imprimir o establecer variables de entorno, ejecutar scripts, etc.
  • mod_filter: permite un control inteligente de los filtros de salida, de manera que el contenido es procesado sólo por los filtros pertinentes.
  • mod_autoindex: permite la visualización del listado de un directorio si no existe un documento predeterminado.
  • mod_cgi: cuando se utiliza un MPM NO multi-hebra, como prefork, mod_cgi permite la ejecución de scripts CGI.
  • mod_cgid: cuando se utiliza un MPM multi-hebra, como worker, mod_cgid permite la ejecución de scripts CGI. Este módulo emplea un demonio externo dedicado a la ejecución de scripts CGI.
  • mod_log_config: registra las peticiones recibidas en el servidor.
  • mod_env: controla las variables de entorno manejadas por los scripts CGI y por los SSI.
  • mod_setenvif: permite establecer variables de entorno según características de la petición (por ejemplo, según la dirección IP del cliente o el navegador que esté empleando).
  • mod_mime: asocia las extensiones de los archivos con el procesamiento que recibirán y la especificación del contenido.
  • mod_status: suministra información del rendimiento del servidor.
  • mod_negotiation: permite la negociación del contenido, según las especificaciones del protocolo HTTP/1.1, para ofrecer al cliente la versión del archivo que más se adapte a sus preferencias, si es posible.
  • mod_dir: controla la asignación de un documento predeterminado y la adición automática del carácter “/” al final de una url que apunta a un directorio.
  • mod_userdir: permite la asignación de directorios a usuarios mediante urls del tipo http://servidor.dominio/~usuario
  • mod_so: permite cargar módulos en Apache en tiempo de ejecución mediante el mecanismo DSO (Dynamic Shared Object).

 

Fichero pdf para descargar aquí.

vidalmb_admin – Mar, 22/08/2006 – 13:30