Glosario

Reviewed by: Daniel Lopez Revision Changes Path 1.1 httpd-2.0/docs/manual/glossary.xml.es Index: glossary.xml.es =================================================================== Glosario

Este glosario define la terminología más común relacionada con Apache en particular y con los servidores web en general. En los enlaces que hay asociados a cada término se puede encontrar información más detallada.

Definiciones

Autentificación: La identificación positiva de una entidad de red tal como un servidor, un cliente, o un usuario.
Consulte: Autentificación, Autorización, y Control de Acceso
Control de Acceso: La restricción en el acceso al entorno de una red. En el contexto de Apache significa normalmente la restricción en el acceso a ciertas URLs.
Consulte: Autentificación, Autorización, y Control de Acceso
Algoritmo: Un proceso definido sin ambiguedades o un conjunto de reglas para solucionar un problema en un número finito de pasos. Los algoritmos para encriptar se llaman normalmente algoritmos de cifrado.
Herramienta de extensión de Apache (apxs): Es un script escrito en Perl que ayuda a compilar el código fuente de algunos módulos para convertirlos en Objetos Dinamicos Compartidos (DSOs) y ayuda a instalarlos en el servidor web Apache.
Consulte: Paginas de Ayuda: apxs
Certificado: Una información que se almacena para autentificar entidades de red tales como un servidor o un cliente. Un certificado contiene piezas de información X.509 sobre su poseedor (llamado sujeto) y sobre la Autoridad Certificadora (llamada el expendedor) que lo firma, más la clave publica del propietario y la firma de la AC. Las entidades de red verifican las firmas usando certificados de las AC.
Consulte: Encriptado SSL/TLS
Autoridad Certificadora (CA): Una entidad externa de confianza cuyo fin es firmar certificados para las entidades de red que ha autentificado usando medios seguros. Otras entidades de red pueden verificar la firma para comprobar que una Autoridad Certificadora ha autentificado al poseedor del certificado.
Consulte: Encriptado SSL/TLS
Petición de firma de Certificado (CSR): Es la petición a una Autoridad Certificadora para que firme un certificado aún sin firmar. La Autoridad Certificadora firma el Certificado con la Clave Privada de su certificado de Autoridad Certificadora. Una vez que el CSR está firmado, se convierte en un auténtico certificado.
Consulte: Encriptado SSL/TLS
Algoritmo de cifrado: Es un algoritmo o sistema de encriptado de información. Ejemplos de estos algoritmos son DES, IDEA, RC4, etc.
Consulte: Encriptado SSL/TLS
Texto cifrado: El resultado de haber aplicado a un texto sin cifrar un algoritmo de cifrado.
Consultar: Encriptado SSL/TLS
Common Gateway Interface (CGI): Una definición estándar para un interfaz entre un servidor web y un programa externo que permite hacer peticiones de servicio a los programas externos. Este interfaz fue definido originalmente por la NCSA pero tambien hay un proyecto RFC.
Consulte: Contenido Dinámico con CGI
Directivas de configuración: Consulte: Directivas
Fichero de Configuración: Un fichero de texto que contiene Directivas que controlan la configuración de Apache.
Consulte: Ficheros de Configuración
CONNECT: Un método de HTTP para hacer proxy a canales de datos sin usar HTTP. Puede usarse para encapsular otros protocolos, tales como el protocolo SSL.
Contexto: Un área en los ficheros de configuración donde están permitidos ciertos tipos de directivas.
Consulte: Terminos usados para describir las directivas de Apache
Firma Digital: Un bloque de texto encriptado que verifica la validez de un certificado o de otro fichero. Una Autoridad Certificadora crea una firma generando un hash a partir de la Clave Pública que lleva incorporada en un Certificado, después encriptando el hash con su propia Clave Privada. Solo las claves públicas de las CAs pueden desencriptar la firma, verificando que la CA ha autentificado a la entidad de red propietaria del Certificado.
Consulte: Encriptado SSL/TLS
Directiva: Un comando de configuración que controla uno o más aspectos del comportamiento de Apache. Las directivas se ponen en el Fichero de Configuración
Consulte: Índice de Directivas
Objetos Dinámicos Compartidos (DSO): Los Módulos compilados de forma separada al binario httpd de Apache se pueden cargar según se necesiten.
Consulte: Soporte de Objetos Dinámicos Compartidos
Variable de Entorno (env-variable): Variables que gestionan el shell del sistema operativo y que se usan para guardar información y para la comunicación entre programas. Apache también contiene variables internas que son referidas como variables de entorno, pero que son almacenadas en las estructuras internas de Apache, en lugar de en el entorno del shell.
Consulte: Variables de entorno de Apache
Export-Crippled: Disminución de la fortaleza criptográfica (y seguridad) para cumplir con las Regulaciones sobre Exportación de la Administracción de los Estados Unidos (EAR). El software criptográfico Export-crippled está limitado a una clave de pequeño tamaño, de tal manera que el texto cifrado que se consigue con él, puede desencriptarse por fuerza bruta.
Consulte: Encriptado SSL/TLS
Filtro: Un proceso que se aplica a la información que es enviada o recibida por el servidor. Los ficheros de entrada procesan la información enviada por un cliente al servidor, mientras que los filtros de salida procesan la información en el servidor antes de enviársela al cliente. Por ejemplo, el filtro de salida INCLUDES procesa documentos para Server Side Includes.
Consulte: Filtros
Nombre de dominio completamente qualificado (FQDN): El nombre único de una entidad de red, que consiste en un nombre de host y un nombre de dominio que puede traducirse a una dirección IP. Por ejemplo, www es un nombre de host, example.com es un nombre de dominio, y www.example.com es un nombre de dominio completamente qualificado.
Handler: Es una representación interna de Apache de una acción a ser ejecutada cuando se llama a un fichero. Generalmente, los ficheros tienen un handler implícito, basado en el tipo de fichero. Normalmente, todos los ficheros son simplemente servidos por el servidor, pero sobre algunos tipos de ficheros se ejecutan acciones complementarias. Por ejemplo, el handler cgi-script designa los ficheros a ser procesados como CGIs.
Consulte: Uso de Handlers en Apache
Cabecera: La parte de la petición y la respuesta HTTP que se envía antes del contenido propiamente dicho, y que contiene meta-información describiendo el contenido.
.htaccess: Un fichero de configuración que se pone dentro de la estructura de directorios del sitio web y aplica directivas de configuración al directorio en el que está y a sus subdirectorios. A pesar de su nombre, este fichero puede contener cualquier tipo de directivas, no solo directivas de control de acceso.
Consulte: Ficheros de Configuración
httpd.conf: Es el fichero de configuración principal de Apache. Su ubicación por defecto es /usr/local/apache2/conf/httpd.conf, pero puede moverse usando opciones de configuración al compilar o al iniciar Apache.
Consulte: Ficheros de Configuración
Protocolo de Tranferencia de Hipertexto (HTTP): Es el protocolo de transmisión estádar usado en la World Wide Web. Apache implementa la versión 1.1 de este protocolo, al que se hace referencia como HTTP/1.1 y definido por el RFC 2616.
HTTPS: Protocolo de transferencia de Hipertext (Seguro), es el mecanismo de comunicación encriptado estándar en World Wide Web. En realidad es HTTP sobre SSL.
Consulte: Encriptado SSL/TLS
Método: En el contexto de HTTP, es una acción a ejecutar sobre un recurso, especificado en la líneas de petición por el cliente. Algunos de los metodos diponibles en HTTP son GET, POST, y PUT.
Message Digest: Un hash de un mensaje, el cual pude ser usado para verificar que el contenido del mensaje no ha sido alterado durante la transmisión.
Consulte: Encriptado SSL/TLS
MIME-type: Una manera de describir el tipo de documento a ser transmitido. Su nombre viene del hecho de que su formato se toma de las Extensiones del Multipurpose Internet Mail. Consiste en dos componentes, uno principal y otro secundario, separados por una barra. Algunos ejemplos son text/html, image/gif, y application/octet-stream. En HTTP, el tipo MIME se transmite en la cabecera del Tipo Contenido.
Consulte: mod_mime
Módulo: Una parte independiente de un programa. La mayor parte de la funcionalidad de Apache está contenida en módulos que pueden incluirse o excluirse. Los módulos que se compilan con el binario httpd de Apache se llaman módulos estáticos, mientras que los que se almacenan de forma separada y pueden ser cargados de forma opcional, se llaman módulos dinamicos o DSOs. Los módulos que están incluidos por sefecto de llaman módulos base. Hay muchos módulos disponibles para Apache que no se distribuyen con la tarball del Servidor HTTP Apache . Estos módulos son llamados módulos de terceros.
Consulte: Índice de Módulos
Número Mágico de Módulo (MMN): El número mágico de módulo es una constante definida en el código fuente de Apache que está asociado con la compatibilidad binaria de los módulos. Ese número cambia cuando cambian las estructuras internas de Apache, las llamadas a funciones y otras partes significativas de la interfaz de programación de manera que la compatibilidad binaria no puede garantizarse sin cambiarlo. Si cambia el número mágico de módulo, todos los módulos de terceros tienen que ser al menos recompilados, y algunas veces, incluso hay que introducir ligeras modificaciones para que funcionen con la nueva versión de Apache
OpenSSL: El toolkit Open Source para SSL/TLS
see http://www.openssl.org/
Pass Phrase: La palabra o frase que protege los archivos de clave privada. Evita que usuarios no autorizados los encripten. Normalmente es solo la clave de encriptado/desencriptado usada por los Algoritmos de Cifrado.
Consulte: Encriptado SSL/TLS
Plaintext: Un texto no encriptado.
Clave Privada: La clave secreta de un sistema criptográfico de Clave Pública, usada para desencriptar los mensajes entrantes y firmar los salientes.
Consulte: Encriptado SSL/TLS
Proxy: Un servidor intermedio que se pone entre el cliente y el servidor de origen. Acepta las peticiones de los clientes, las transmite al servidor de origen, y después devuelve la respuesta del servidor de origen al cliente. Si varios clientes piden el mismo contenido, el proxy sirve el contenido desde su caché, en lugar de pedirlo cada vez que lo necesita al servidor de origen, reduciendo con esto el tiempo de respuesta.
Consulte: mod_proxy
Clave Publica: La clave disponible públicamente en un sistema criptográfico de Clave Pública, usado para encriptar mensajes destinados a su propietario y para desencriptar firmas hechas por su propietario.
Consulte: Encriptado SSL/TLS
Criptográfia de Clave Pública: El estudio y aplicación de sistemas de encriptado asimétricos, que usa una clave para encriptar y otra para desencriptar. Una clave de cada uno de estos tipos constituye un par de claves. Tambien se llama Criptografia Asimétrica.
Consulte: Encriptado SSL/TLS
Expresiones Regulares (Regex): Una forma de describir un modelo de texto - por ejemplo, "todas las palabras que empiezan con la letra "A" o "todos los números de teléfono que contienen 10 dígitos" o incluso "Todas las frases entre comas, y que no contengan ninguna letra Q". Las Expresiones Regulares son utiles en Apache porque permiten aplicar ciertos atributos a colecciones de ficheros o recursos de una forma flexible - por ejemplo, todos los archivos .gif y .jpg que estén en un directorio "imágenes" podrían ser escritos como "/images/.*(jpg|gif)$". Apache usa Expresiones Regulares compatibles con Perl gracias a la librería PCRE.
Reverse Proxy: Es un servidor proxy que se presenta al cliente como si fuera un servidor de origen. Es útil para esconder el auténtico servidor de origen a los clientes por cuestiones de seguridad, o para equilibrar la carga.
Secure Sockets Layer (SSL): Un protocolo creado por Netscape Communications Corporation para la autentificación en comunicaciones en general y encriptado sobre redes TCP/IP. Su aplicación más popular es HTTPS, el Protocolo de Transferencia de Hipertexto (HTTP) sobre SSL.
Consulte: Encriptado SSL/TLS
Server Side Includes (SSI): Una tecnica para incluir directivas de proceso en archivos HTML.
Consulte: Introducción al Server Side Includes
Sesion: Información del contexto de una comunicación en general.
SSLeay: La implementación original de la librería SSL/TLS desarrollada por Eric A. Young
Criptografía Simétrica: El estudio y aplicación de Algoritmos de Cifrado que usan una solo clave secreta tanto para encriptar como para desencriptar.
Consulte: Encriptado SSL/TLS
Tarball: Un grupo de ficheros puestos en un solo paquete usando la utilidad tar. Las distribuciones Apache se almacenan en ficheros comprimidos con tar o con pkzip.
Transport Layer Security (TLS): Es el sucesor del protocolo SSL, creado por el Internet Engineering Task Force (IETF) para la autentificación en comunicaciones en general y encriptado sobre redes TCP/IP. La versión 1 de TLS es casi idéntica a la versión 3 de SSL.
Consulte: Encriptado SSL/TLS
Localizador de Recursos Uniforme (URL): El nombre de un recurso en Internet. Es la manera informal de decir lo que formalmente se llama un Identificador de Recursos Uniforme. Las URLs están compuestas normalmente por un esquema, tal como http o https, un nombre de host, y una ruta. Una URL para esta página es http://httpd.apache.org/docs-2.1/glossary.html.
Identificador de Recursos Uniforme (URI): Una cadena de caracteres compacta para identificar un recurso físico o abstracto. Se define formalmente en la RFC 2396. Los URIs que se usan en world-wide web se refieren normalmente como URLs.
Hosting Virtual: Se trata de servir diferentes sitios web con una sola entidad de Apache. El hosting virtual de IPs diferencia los sitios web basandose en sus direcciones IP, mientras que el hosting virtual basado en nombres usa solo el nombre del host y de esta manera puede alojar muchos sitios web con la misma dirección IP.
Consulte: Documentación sobre Hosting Virtual en Apache
X.509: Un esquema de certificado de autentificación recomendado por la International Telecommunication Union (ITU-T) que se usa en la autentificación SSL/TLS.
Consulte: Encriptado SSL/TLS

1.1 httpd-2.0/docs/manual/handler.xml.es Index: handler.xml.es =================================================================== Uso de los Handlers en Apache

Este documento describe el uso de los Handlers en Apache.

¿Qué es un Handler? mod_actions mod_asis mod_cgi mod_imap mod_info mod_mime mod_negotiation mod_status Action AddHandler RemoveHandler SetHandler

Un "handler" es una representación interna de Apache de una acción que se va a ejecutar cuando hay una llamada a un fichero. Generalmente, los ficheros tienen handlers implícitos, basados en el tipo de fichero de que se trata. Normalmente, todos los ficheros son simplemente servidos por el servidor, pero algunos tipos de ficheros se tratan de forma diferente.

Apache 1.1 añade la posibilidad de usar handlers explicitamente. Basándose en la extension del fichero o en la ubicación en la que este, se pueden especificar handlers sin tener en cuenta el tipo de fichero de que se trate. Esto es una ventaja por dos razones. Primero, es una solución más elegante. Segundo, porque a un fichero se le pueden asignar tanto un tipo como un handler. (Consulte también la sección Ficheros y extensiones múltiples.)

Los Handlers pueden ser tanto ser compilados con el servidor como incluidos en un módulo, como añadidos con la directiva Action. Los handlers compilados con el servidor de la distribución estándar de Apache son:

default-handler: Envía el fichero usando el default_handler(), que es el handler usado por defecto para tratar contenido estático. (core)
send-as-is: Envía el fichero con cabeceras HTTP tal y como es. (mod_asis)
cgi-script: Trata el fichero como un sript CGI. (mod_cgi)
imap-file: Trata el fichero como un mapa de imágenes. (mod_imap)
server-info: Extrae la información de configuración del servidor. (mod_info)
server-status: Extrae el informe de estado del servidor. (mod_status)
type-map: Trata el fichero como una correspondencia de tipos para la negociación de contenidos. (mod_negotiation)

Ejemplos

Modificar contenido estático usando un script CGI

Las siguientes directivas hacen que cuando haya una petición de ficheros con la extensión html se lance el script CGI footer.pl.

Action add-footer /cgi-bin/footer.pl
AddHandler add-footer .html

En este caso, el script CGI es el responsable de enviar el documento originalmente solicitado (contenido en la variable de entorno PATH_TRANSLATED) y de hacer cualquier modificación o añadido deseado.

Archivos con cabaceras HTTP

Las siguientes directivas activan el handler send-as-is, que se usa para ficheros que contienen sus propias cabeceras HTTP. Todos los archivos en el directorio /web/htdocs/asis/ serán procesados por el handler send-as-is, sin tener en cuenta su extension.

<Directory /web/htdocs/asis>
SetHandler send-as-is
</Directory>

Nota para programadores

Para implementar las funcionalidades de los handlers, se ha hecho un añadido a la API de Apache que puede que quiera usar. Para ser más específicos, se ha añadido un nuevo registro a la estructura request_rec:

char *handler

Si quiere que su módulo llame a un handler , solo tiene que añadir r->handler al nombre del handler en cualquier momento antes de la fase invoke_handler de la petición. Los handlers se implementan siempre como se hacía antes, aunque usando el nombre del handler en vez de un tipo de contenido. Aunque no es de obligado cumplimiento, la convención de nombres para los handlers es que se usen palabras separadas por guiones, sin barras, de manera que no se invada el media type name-space.

1.1 httpd-2.0/docs/manual/install.xml.es Index: install.xml.es =================================================================== Compilación e Instalación

Este documento explica cómo compilar e instalar Apache en sistemas Unix y tipo Unix. Para obtener información sobre cómo compilar e instalar en Windows, consulte la sección Usar Apache en Microsoft Windows. Para otras plataformas, consulte la documentación sobre plataformas.

El entorno de configuración e instalación de Apache 2.0 ha cambiado completamente respecto al de Apache 1.3. Apache 1.3 usaba un conjunto de scripts a medida para conseguir una instalación fácil. Apache 2.0 usa libtool y autoconf para crear un entorno más parecido al de muchos otros proyectos Open Source.

Si lo que quiere hacer es actualizar su servidor Apache desde una versión menor (por ejemplo, desde la 2.0.50 a la 2.0.51), pase directamente a la sección de actualización.

Configuración de la estructura de directorios Iniciar Apache Parar y reiniciar Apache

Visión general del proceso para impacientes

Descargar	`$ lynx http://httpd.apache.org/download.cgi`
Descomprimir	`$ gzip -d httpd-2_1_NN.tar.gz $ tar xvf httpd-2_1_NN.tar`
Ejecutar el script configure	`$ ./configure --prefix=PREFIX`
Compilar	`$ make`
Instalar	`$ make install`
Personalizar	`$ vi PREFIX/conf/httpd.conf`
Comprobar que la instalación funciona	`$ PREFIX/bin/apachectl start`

NN hay que reemplazarlo por el número de la versión menor, y PREFIX hay que reemplazarlo por la ruta en la que se va a instalar Apache. Si no especifica ningún valor en PREFIX, el valor por defecto que se toma es /usr/local/apache2.

Cada parte del proceso de configuración e instalación se describe detalladamente más abajo, empezando por los requisitos para compilar e instalar Apache.

Requisitos

Estos son los requisitos necesarios para compilar Apache:

Espacio en disco: Compruebe que tiene disponibles al menos 50 MB de espacio libre en disco. Después de la instalación, Apache ocupa aproximadamente 10 MB. No obstante, la necesidad real de espacio en disco varía considerablemente en función de las opciones de configuración que elija y de los módulos externos que use.
Compilador ANSI-C y Build System: Compruebe que tiene instalado un compilador de ANSI-C. Se recomienda el Compilador GNU C (GCC) de la Free Software Foundation (FSF) (con la versión 2.7.2 es suficiente). Si no tiene instaldo el GCC, entonces compruebe que el compilador que va a utilizar cumple con los estándares ANSI. Además, su PATH debe contener la ubicación donde de encuentran las herramientas básicas para compilar tales como make.
Ajuste exacto del reloj del sistema: Los elementos del protocolo HTTP están expresados según la hora del dia. Por eso, si quiere puede investigar como instalar alguna utilidad para sincronizar la hora de su sistema. Para esto, normalmente, se usan los programas ntpdate o xntpd, que están basados en el protocolo Network Time Protocol (NTP). Consulte el grupo de noticias comp.protocols.time.ntp y el sitio web de NTP para obtener más información sobre NTP y los servidores públicos de tiempo.
Perl 5 [OPCIONAL]: Para algunos de los scripts de soporte como apxs o dbmmanage (que están escritos en Perl) es necesario el intérprete de Perl 5 (las versiones 5.003 o posteriores son suficientes). Si el script `configure' no encuentra ese intérprete tampoco pasa nada. Aún puede compilar e instalar Apache 2.0. Lo único que ocurrirá es que esos scripts de soporte no podrán ser usados. Si usted tiene varios interpretes de Perl instalados (quizás Perl 4 porque estaba ya incluido en su distribución de Linux y Perl 5 porque lo ha instalado usted), entonces se recomienda usar la opción --with-perl para asegurarse de que ./configure usa el intérprete correcto.

Descargar

Puede descargar Apache desde la sección de descargas del sitio web de Apache el cual tiene varios mirrors. Para la mayoría de los usuarios de Apache que tienen sistemas tipo Unix, se recomienda que se descarguen y compilen el código fuente. El proceso de compilación (descrito más abajo) es fácil, y permite adaptar el servidor Apache a sus necesidades. Además, las versiones de disponibles en archivos binarios no están siempre actulizadas con las últimas modificaciones en el codigo fuente. Si se descarga un binario, siga las instrucciones contenidas en el archivo INSTALL.bindist incluido en la distribución

Después de la descarga, es importante que verifique que el archivo descargado del servidor HTTP Apache está completo y sin modificaciones. Esto puede hacerlo comparando el archivo descargado (.tgz) con su firma PGP. Instrucciones detalladas de cómo hacer esto están disponibles en la sección de descargas junto con un ejemplo de cómo usar PGP.

Descomprimir

Extraer el código fuente del archivo .tgz que acabada de descargar es muy fácil. Ejecute los siguientes comandos:

$ gzip -d httpd-2_1_NN.tar.gz
$ tar xvf httpd-2_1_NN.tar

Estos comandos crearán un nuevo directorio dentro del directorio en el que se encuentra y que contendrá el código fuente de la distribución. Debe cambiarse a ese directorio con cd para proceder a compilar el servidor Apache.

Configuración de la estructura de directorios

El siguiente paso es configurar la estructura de directorios para su plataforma y sus necesidades personales. Esto se hace usando el script configure incluido en el directorio raiz de la distribución que acaba de descargar. (Los desarrolladores que se descarguen la versión del CVS de la estructura de directorios necesitarán tener instalados autoconf y libtool, y necesitarán ejecutar buildconf antes de continuar con los siguientes pasos. Esto no es preciso para las versiones oficiales.)

Para configurar la estructura de directorios a partir del código fuente usando las opciones por defecto, solo tiene que ejecutar ./configure. Para cambiar las opciones por defecto, configure acepta una serie de variables y opciones por la línea de comandos.

La opción más importante es --prefix que es el directorio en el que Apache va a ser instalado después, porque Apache tiene que ser configurado para el directorio que se especifique para que funcione correctamente. Es posible lograr un mayor control del lugar donde se van a instalar los ficheros de Apache con otras opciones de configuración.

En este momento, puede especificar que características o funcionalidades quiere incluir en Apache activando o desactivando módulos. Apache viene con una selección básica de módulos incluidos por defecto. Se pueden activar otros módulos usando la opción --enable-module, donde module es el nombre del módulo sin el mod_ y convirtiendo los guiones bajos que tenga en guiones normales. También puede optar por compilar módulos como objetos dinámicos compartidos (DSOs) -- que pueden ser activados o desactivados al ejecutar -- usando la opción --enable-module=shared. De igual manera, puede desactivar alguno de los módulos que vienen por defecto en la selección basica con la opción --disable-module. Tenga cuidado cuando use estas opciones, porque configure no le avisará si el módulo que especifica no existe; simplemente ignorará esa opción.

Además, a veces es necesario pasarle al script configure información adicional sobre donde esta su compilador, librerias o ficheros de cabecera. Esto se puede hacer, tanto pasando variables de entorno, como pasandole opciones a configure a través de la línea de comandos. Para más información, consulte el Manual del script configure.

Para que se haga una idea sobre las posibilidades que tiene, aquí tiene un ejemplo típico que configura Apache para la ruta /sw/pkg/apache con un compilador y unos flags determinados, y además, con dos módulos adicionales mod_rewrite y mod_speling para cargarlos después a través del mecanismo DSO:

$ CC="pgcc" CFLAGS="-O2" \
./configure --prefix=/sw/pkg/apache \
--enable-rewrite=shared \
--enable-speling=shared

Cuando se ejecuta configure se comprueban que características o funcionalidades están disponibles en su sistema y se crean los Makefiles que serán usados luego para compilar el servidor. Esto tardará algunos minutos.

La información sobre todas las opciones de configure está disponible en el Manual del script configure.

Compilar

Ahora puede compilar las diferentes partes que forman Apache simplemente ejecutando el siguiente comando:

$ make

Por favor, tanga un poco de paciencia ahora, porque una configuración básica tarda aproximadamente 3 minutos en compilar en un Pentium III con un sistema Linux 2.2, pero este tiempo puede variar considerablemente en función de su hardware y del número de módulos que haya seleccionado.

Instalar

Ahora es el momento de instalar el paquete en el diretorio elegido en PREFIX (consulte la opción --prefix más arriba) ejecutando:

$ make install

Si usted está solo actualizando una instalación anterior, la nueva instalación no sobreescribirá sus ficheros de configuración ni otros documentos.

Personalizar

El paso siguiente, es personalizar su servidor Apache editando los ficheros de configuración que están en PREFIX/conf/.

$ vi PREFIX/conf/httpd.conf

échele un vistazo al Manual de Apache que está en docs/manual/ o consulte en http://httpd.apache.org/docs-2.1/ la versión más reciente de este manual y la Guia de Referencia de todas las directivas de configuración disponibles.

Comprobar que la instalación funciona

Ahora puede iniciar su servidor Apache cuando quiera ejecutando:

$ PREFIX/bin/apachectl start

y entonces debe poder acceder al documento que tenga especificado por defecto usando el siguiente URL: http://localhost/. El documento que verá estará en DocumentRoot y casi siempre estará en PREFIX/htdocs/. Si quiere parar el servidor, puede hacerlo ejecutando:

$ PREFIX/bin/apachectl stop

Actualizar una instalación prrevia

El primer paso para actualizar una instalación anterior es leer las especificaciones de la versión y el fichero CHANGES en la distribución de código fuente que ha descargado para encontrar los cambios que puedan afectar a su instalación actual. Cuando el cambio sea entre versiones mayores (por ejemplo, de la 1.3 a la 2.0 o de la 2.0 a la 2.2), entonces es más probable que haya diferencias importantes en la compilación y en la ejecución que necesitarán ajustes manuales. Todos los módulos necesitarán también ser actualizados para adaptarse a los cambios en el interfaz de programación (API) de módulos.

La actualización cuando el cambio es entre versiones menores (por ejemplo, de la 2.0.55 a la 2.0.57) es más fácil. El proceso make install no sobreescribirá ninguno de los documentos existentes, archivos log, o archivos de configuración. Además, los desarrolladores hacen todos los esfuerzos posibles para evitar cambios que generen incompatibilidades en las opciones de configure, en la configuración de la ejecución o en la interfaz de programación de módulos. En la mayor parte de los casos debe poder usar un comando configure idéntico, un fichero de configuracién idéntico, y todos sus módulos deben seguir funcionando. (Esto es válido solo para versiones posteriores a la 2.0.41; las versiones anteriores contienen cambios incompatibles.)

Si va a conservar la estructura de directorios de su anterior instalación, la actualización es más fácil incluso. El fichero config.nice que está en el directorio raiz de la estructura de directorios antigua contiene exactamente el comando configure que usted usó para configurar la estructura de directorios de Apache. Entonces, para actualizar su instalación de una versóon a la siguinete, solo tiene que copiar el archivo config.nice a la estructura de directorios del código fuente de la nueva versión, editarlo, hacer cualquier cambio que desee, y ejecutarlo :

$ ./config.nice
$ make
$ make install
$ PREFIX/bin/apachectl stop
$ PREFIX/bin/apachectl start
Tenga en cuenta que antes de poner una nueva versión de Apache en producción, debe siempre probarla antes en su entorno. Por ejemplo, puede instalar y ejecutar la nueva versión junto con la antigua usando un --prefix diferente y un puerto diferente (modificando la directiva Listen) para comprobar que no existe ninguna incompatibilidad antes de hacer la actualización definitiva.

1.1 httpd-2.0/docs/manual/invoking.xml.es Index: invoking.xml.es =================================================================== iniciar Apache

En Windows, Apache se ejecuta normalmente como un servicio en Windows NT, 2000 and XP, y como una aplicacion de consola en Windows 9x y ME. Para obtener más información, consulte Ejecutar Apache como un servicio y Ejecutar Apache como una aplicación de consola.

En Unix, el programa httpd se ejecuta como un demonio (daemon) de forma silenciosa y atiende las peticiones que le lleguen. Este documento describe cómo invocar el programa httpd.

Parar y reiniciar Apache httpd apachectl

Cómo iniciar Apache

Si el puerto especificado en la directiva Listen del fichero de configuración es el que viene por defecto, es decir, el puerto 80 (o cualquier otro puerto por debajo del 1024), entonces es necesario tener privilegios de usuario root (superusuario) para iniciar Apache, de modo que pueda establecerse una conexión a través de esos puertos privilegiados. Una vez que el servidor Apache se ha iniciado y ha completado algunas tareas preliminares, tales como abrir sus ficheros log, lanzará varios procesos, procesos hijo, que hacen el trabajo de escuchar y atender las peticiones de los clientes. El proceso principal, httpd continúa ejecutandose como root, pero los procesos hijo se ejecutan con menores privilegios de usuario. Esto lo controla el Módulo de MultiProcesamiento (MPM) seleccionado.

La forma recomendada para invocar el ejecutable httpd es usando el script de control apachectl. Este script fija determinadas variables de entorno que son necesarias para que httpd funcione correctamente en el sistema operativo, y después invoca el binario httpd. apachectl pasa a httpd cualquier argumento que se le pase a través de la línea de comandos, de forma que cualquier opción de httpd puede ser usada también con apachectl. Puede editar directamente el script apachectl y cambiar la variable HTTPD variable que está al principio y que especifica la ubicación exacta en la que está el binario httpd y cualquier argumento de línea de comandos que quiera que esté siempre presente.

La primera cosa que hace httpd cuando es invocado es localizar y leer el fichero de configuración httpd.conf. El lugar en el que está ese fichero se determina al compilar, pero también es posible especificar la ubicación en la que se encuentra al iniciar el servidor Apache usando la opción de línea de comandos -f

/usr/local/apache2/bin/apachectl -f /usr/local/apache2/conf/httpd.conf

Si todo va bien durante el arranque, la sesión de terminal se suspenderá un momento y volverá a estar activa casi inmediatamente. Esto quiere decir que el servidor está activo y funcionando. Puede usar su navegador para conectarse al servidor y ver la pagina de prueba que hay en el directorio DocumentRoot y la copia local de esta documentación a la que se puede acceder desde esa página.

Errores Durante el Arranque

Si Apache encuentra una error irrecuperable durante el arranque, escribirá un mensaje describiendo el problema en la consola o en el archivo ErrorLog antes de abortar la ejecución. Uno de los mensajes de error más comunes es "Unable to bind to Port ...". Cuando se recibe este mensaje es normalmente por alguna de las siguientes razones:

Está intentando iniciar el servidor Apache en un puerto privilegiado (del 0 al 1024) sin haber hecho login como usuario root; ó
Está intentando iniciar el servidor Apache mientras está ya ejecutando Apache o algún otro servidor web en el mismo puerto.

Puede encontrar más información sobre cómo solucionar problemas, en la sección de Preguntas Frecuentes de Apache.

Iniciar Apache al Iniciar el Sistema

Si quiere que el servidor Apache continú su ejecución después de reiniciar el sistema, debe añadir una llamada a apachectl en sus archivos de arranque (normalmente rc.local o un fichero en ese directorio del tipo rc.N). Esto iniciará Apache como usuario root. Antes de hacer esto, asegúrese de que la configuración de seguridad y las restricciones de acceso de su servidor Apache están correctamente configuradas.

El script apachectl está diseñado para actuar como un script estandar de tipo SysV init; puede tomar los argumentos start, restart, y stop y traducirlos en las señales apropiadas para httpd. De esta manera, casi siempre puede simplemente enlazar apachectl con el directorio init adecuado. Pero asegúrese de comprobar los requisitos exactos de su sistema.

Información Adicional

En la sección El Servidor y Programas de Soporte puede encontrar más información sobre las opciones de línea de comandos que puede pasar a httpd y apachectl asi como sobre otros programas de soporte incluidos con el servidor Apache. También hay documentación sobre todos los módulos incluidos con la distribucion de Apache y sus correspondientes directivas asociadas.

1.1 httpd-2.0/docs/manual/mpm.xml.es Index: mpm.xml.es =================================================================== Módulos de MultiProcesamiento (MPMs)

Este documento describe que es un Módulo de Multiprocesamiento y como los usa Apache.

Introducción

Apache está diseñado para ser un servidor web potente y flexible que pueda funcionar en la más amplia variedad de plataformas y entornos. Las diferentes plataformas y los diferentes entornos, hacen que a menudo sean necesarias diferentes características o funcionalidades, o que una misma característica o funcionalidad sea implementada de diferente manera para obtener una mayor eficiencia. Apache se ha adaptado siempre a una gran variedad de entornos a través de su diseño modular. Este diseño permite a los administradores de sitios web elegir que características van a ser incluidas en el servidor seleccionando que módulos se van a cargar, ya sea al compilar o al ejecutar el servidor.

Apache 2.0 extiende este diseño modular hasta las funciones más básicas de un servidor web. El servidor viene con una serie de Módulos de MultiProcesamiento que son responsables de conectar con los puertos de red de la máquina, acceptar las peticiones, y generar los procesos hijo que se encargan de servirlas.

La extensión del diseño modular a este nivel del servidor ofrece dos beneficios importantes:

Apache puede soportar de una forma más fácil y eficiente una amplia variedad de sistemas operativos. En concreto, la versión de Windows de Apache es mucho más eficiente, porque el módulo mpm_winnt puede usar funcionalidades nativas de red en lugar de usar la capa POSIX como hace Apache 1.3. Este beneficio se extiende también a otros sistemas operativos que implementan sus respectivos MPMs.
El servidor puede personalizarse mejor para las necesidades de cada sitio web. Por ejemplo, los sitios web que necesitan más que nada escalibildad pueden usar un MPM hebrado como worker, mientras que los sitios web que requieran por encima de otras cosas estabilidad o compatibilidad con software antiguo pueden usar prefork. Además, se pueden configurar funcionalidades especiales como servir diferentes hosts con diferentes identificadores de usuario (perchild).

A nivel de usuario, los MPMs son como cualquier otro módulo de Apache. La diferencia más importante es que solo un MPM puede estar cargado en el servidor en un determinado momento. La lista de MPMs disponibles está en la sección índice de Módulos.

Cómo Elegir un MPM

Los MPMs deben elegirse durante el proceso de configuración, y deben ser compilados en el servidor. Los compiladores son capaces de optimizar muchas funciones si se usan hebras, pero solo si se sabe que se están usando hebras. Como algunos MPM usan hebras en Unix y otros no, Apache tendrá un mejor rendimiento si el MPM es elegido en el momento de compilar y está incorporado en el servidor.

Para elegir el MPM deseado, use el argumento --with-mpm= NAME con el script ./configure. NAME es el nombre del MPM deseado.

Una vez que el servidor ha sido compilado, es posible determinar que MPM ha sido elegido usando ./httpd -l. Este comando lista todos los módulos compilados en el servidor, incluido en MPM.

MPM por defecto

En la siguiente tabla se muestran los MPMs por defecto para varios sistemas operativos. Estos serán los MPM seleccionados si no se especifica lo contrario al compilar.

BeOS	beos
Netware	mpm_netware
OS/2	mpmt_os2
Unix	prefork
Windows	mpm_winnt

1.1 httpd-2.0/docs/manual/stopping.xml.es Index: stopping.xml.es =================================================================== Iniciar y Parar el servidor Apache

Este documento explica como iniciar y parar el servidor Apache en sistemas tipo Unix. Los usuarios de Windows NT, 2000 y XP deben consultar la sección Ejecutar Apache como un servicio y los usuario de Windows 9x y ME deben consultar Ejecutar Apache como una Aplicación de Consola para obtener información sobre como controlar Apache en esas plataformas.

httpd apachectl

Introducción

Para parar y reiniciar Apache, hay que enviar la señal apropiada al proceso padre httpd que se esté ejecutando. Hay dos maneras de enviar estas señales. En primer lugar, puede usar el comando de Unix kill que envía señales directamente a los procesos. Puede que tenga varios procesos httpd ejecutandose en su sistema, pero las señales deben enviarse solamente al proceso padre, cuyo pid está especificado en la directiva PidFile. Esto quiere decir que no debe necesitar enviar señales a ningún proceso excepto al proceso padre. Hay tres señales que puede enviar al proceso padre: TERM, HUP, y USR1, que van a ser descritas a continuación.

Para enviar una señal al proceso padre debe escribir un comando como el que se muestra en el ejemplo:

kill -TERM `cat /usr/local/apache2/logs/httpd.pid`

La segunda manera de enviar señales a los procesos httpd es usando las opciones de línea de comandos -k: stop, restart, y graceful, como se muestra más abajo. Estas opciones se le pueden pasar al binario httpd, pero se recomienda que se pasen al script de control apachectl, que a su vez los pasará a httpd.

Después de haber enviado las señales que desee a httpd, puede ver como progresa el proceso escribiendo:

tail -f /usr/local/apache2/logs/error_log

Modifique estos ejemplos para que coincidan con la configuración que tenga especificada en las directivas ServerRoot y PidFile en su fichero principal de configuración.

Parar Apache

Señal: TERM: apachectl -k stop

Enviar las señales TERM o stop al proceso padre hace que se intenten eliminar todos los procesos hijo inmediatamente. Esto puede tardar algunos minutos. Una vez que hayan terminado todos los procesos hijo, terminará el proceso padre. Cualquier petición en proceso terminará inmediatanmente, y ninguna petición posterior será atendida.

Reinicio Graceful

Señal: USR1: apachectl -k graceful

Las señales USR1 o graceful hacen que el proceso padre indique a sus hijos que terminen después de servir la petición que estén atendiendo en ese momento (o de inmediato si no están sirviendo ninguna petición). El proceso padre lee de nuevo sus ficheros de configuración y vuelve a abrir sus ficheros log. Conforme cada hijo va terminando, el proceso padre lo va sustituyendo con un hijo de una nueva generación con la nueva configuración, que empeciezan a servir peticiones inmediatamente.

En algunas plataformas que no permiten usar USR1 para reinicios graceful, puede usarse una señal alternativa (como WINCH). Tambien puede usar apachectl graceful y el script de control enviará la señal adecuada para su plataforma.

Apache está diseñado para respetar en todo momento la directiva de control de procesos de los MPM, así como para que el número de procesos y hebras disponibles para servir a los clientes se mantenga en los valores adecuados durante el proceso de reinicio. Aún más, está diseñado para respetar la directiva StartServers de la siguiente manera: si después de al menos un segundo el nuevo hijo de la directiva StartServers no ha sido creado, entonces crea los suficientes para se atienda el trabajo que queda por hacer. Así, se intenta mantener tanto el número de hijos adecuado para el trabajo que el servidor tenga en ese momento, como respetar la configuración determinada por los parámetros de la directiva StartServers.

Los usuarios del módulo mod_status notarán que las estadísticas del servidor no se ponen a cero cuando se usa la señal USR1. Apache fue escrito tanto para minimizar el tiempo en el que el servidor no puede servir nuevas peticiones (que se pondrán en cola por el sistema operativo, de modo que se no se pierda ningún evento), como para respetar sus parámetros de ajuste. Para hacer esto, tiene que guardar el scoreboard usado para llevar el registro de los procesos hijo a través de las distintas generaciones.

El mod_status también usa una G para indicar que esos hijos están todavía sirviendo peticiones previas al reinicio graceful.

Actualmente no existe ninguna manera de que un script con un log de rotación usando USR1 sepa con seguridad que todos los hijos que se registraron en el log con anterioridad al reinicio han terminado. Se aconseja que se use un retardo adecuado después de enviar la señal USR1 antes de hacer nada con el log antiguo. Por ejemplo, si la mayor parte las visitas que recibe de usuarios que tienen conexiones de baja velocidad tardan menos de 10 minutos en completarse, entoces espere 15 minutos antes de hacer nada con el log antiguo.

Si su fichero de configuración tiene errores cuando haga el reinicio, entonces el proceso padre no se reinciciará y terminará con un error. En caso de un reinicio graceful, también dejará a los procesos hijo ejecutandose mientras existan. (Estos son los hijos de los que se está saliendo de forma graceful y que están sirviendo sus últimas peticiones.) Esto provocará problemas si intenta reiniciar el servidor -- no será posible conectarse a la lista de puertos de escucha. Antes de reiniciar, puede comprobar que la sintaxis de sus ficheros de configuracion es correcta con la opción de línea de comandos -t (consulte httpd). No obstante, esto no garantiza que el servidor se reinicie correctamente. Para comprobar que no hay errores en los ficheros de configuración, puede intentar iniciar httpd con un usuario diferente a root. Si no hay errores, intentará abrir sus sockets y logs y fallará porque el usuario no es root (o porque el httpd que se está ejecutando en ese momento ya está conectado a esos puertos). Si falla por cualquier otra razón, entonces casi seguro que hay algún error en alguno de los ficheros de configuración y debe corregir ese o esos errores antes de hacer un reinicio graceful.

Reiniciar Apache

Señal: HUP: apachectl -k restart

El envío de las señales HUP o restart al proceso padre hace que los procesos hijo terminen como si le enviá ramos la señal TERM, para eliminar el proceso padre. La diferencia está en que estas señales vuelven a leer los archivos de configuración y vuelven a abrir los ficheros log. Se genera un nuevo conjunto de hijos y se continúa sirviendo peticiones.

Los usuarios del módulo mod_status notarán que las estadísticas del servidor se ponen a cero cuando se envía la señal HUP.

Si su fichero de configuración contiene errores, cuando intente reiniciar, el proceso padre del servidor no se reiniciará, sino que terminará con un error. Consulte más arriba cómo puede solucionar este problema.

Apéndice: señales y race conditions

Con anterioridad a la versión de Apache 1.2b9 había varias race conditions implicadas en las señales para parar y reiniciar procesos (una descripción sencilla de una race condition es: un problema relacionado con el momento en que suceden las cosas, como si algo sucediera en momento en que no debe, y entonces el resultado esperado no se corresponde con el obtenido). Para aquellas arquitecturas que tienen el conjunto de características "adecuadas", se han eliminado tantas race conditions como ha sido posible. Pero hay que tener en cuenta que todavía existen race conditions en algunas arquitecturas.

En las arquitecturas que usan un ScoreBoardFile en disco, existe la posibilidad de que se corrompan los scoreboards. Esto puede hacer que se produzca el error "bind: Address already in use" (después de usarHUP) o el error "long lost child came home!" (después de usar USR1). En el primer caso se trata de un error irrecuperable, mientras que en el segundo, solo ocurre que el servidor pierde un slot del scoreboard. Por lo tanto, sería aconsejable usar reinicios graceful, y solo hacer reinicios normales de forma ocasional. Estos problemas son bastante complicados de solucionar, pero afortunadamente casi ninguna arquitectura necesita un fichero scoreboard. Consulte la documentación de la directiva ScoreBoardFile para ver las arquitecturas que la usan.

Todas las arquitecturas tienen una pequeña race condition en cada proceso hijo implicada en la segunda y subsiguientes peticiones en una conexión HTTP persistente (KeepAlive). Puede ser que el servidor termine después de leer la línea de petición pero antes de leer cualquiera de las cebeceras de petición. Hay una solución que fue descubierta demasiado tarde para la incluirla en versión 1.2. En teoria esto no debe suponer ningún problema porque el cliente KeepAlive ha de esperar que estas cosas pasen debido a los retardos de red y a los timeouts que a veces dan los servidores. En la practica, parece que no afecta a nada más -- en una sesión de pruebas, un servidor se reinició veinte veces por segundo y los clientes pudieron navegar sin problemas por el sitio web sin encontrar problemas ni para descargar una sola imagen ni encontrar un solo enlace roto.

1.1 httpd-2.0/docs/manual/filter.xml.es Index: filter.xml.es =================================================================== Filtros

Este documento describe cómo usar filtros en Apache.

Filtros mod_deflate mod_ext_filter mod_include AddInputFilter AddOutputFilter RemoveInputFilter RemoveOutputFilter ExtFilterDefine ExtFilterOptions SetInputFilter SetOutputFilter

Un filtro es un proceso que se aplica a los datos que se reciben o se envían por el servidor. Los datos enviados por los clientes al servidor son procesados por filtros de entrada mientras que los datos enviados por el servidor se procesan por los filtros de salida. A los datos se les pueden aplicar varios filtros, y el orden en que se aplica cada filtro puede especificarse explícitamente.

Los filtros se usan internamente por Apache para llevar a cabo funciones tales como chunking y servir peticiones de byte-range. Además, los módulos contienen filtros que se pueden seleccionar usando directivas de configuración al iniciar el servidor. El conjunto de filtros que se aplica a los datos puede manipularse con las directivas SetInputFilter, SetOutputFilter, AddInputFilter, AddOutputFilter, RemoveInputFilter, y RemoveOutputFilter.

Actualmente, vienen con la distribución de Apache los siguientes filtros seleccionables por el usuario.

INCLUDES: Server-Side Includes procesado por mod_include
DEFLATE: Comprime los datos de salida antes de enviarlos al cliente usando el módulo mod_deflate

Además, el módulo mod_ext_filter permite definir programas externos como filtros.