Versión 2.1 del Servidor HTTP Apache
+
Versión 2.1 del Servidor HTTP Apache
+
Este documento describe cómo usar filtros en Apache.
+
| Módulos Relacionados | Directivas Relacionadas |
|---|---|
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.
+ +mod_includemod_deflate
+ Además, el módulo mod_ext_filter
+ permite definir programas externos como filtros.
Este documento describe cómo usar filtros en Apache.
+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
Actualmente, vienen con la distribución de Apache los + siguientes filtros seleccionables por el usuario.
+ +Además, el módulo
Versión 2.1 del Servidor HTTP Apache
+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.
+INCLUDES
+procesa documentos para Server Side Includes.www es un nombre de host,
+example.com es un nombre de dominio, y
+www.example.com es un nombre de dominio completamente
+qualificado.cgi-script designa los ficheros a ser
+procesados como CGIs./usr/local/apache2/conf/httpd.conf, pero puede moverse
+usando opciones de configuración al compilar o al iniciar
+Apache.GET,
+POST, y PUT.text/html,
+image/gif, y application/octet-stream. En
+HTTP, el tipo MIME se transmite en la cabecera
+del Tipo Contenido./images/.*(jpg|gif)$".
+Apache usa Expresiones Regulares compatibles con Perl gracias a la
+librería PCRE.tar. Las
+distribuciones Apache se almacenan en ficheros comprimidos con tar o
+con pkzip.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.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.
+INCLUDES
+procesa documentos para Server Side Includes.www es un nombre de host,
+example.com es un nombre de dominio, y
+www.example.com es un nombre de dominio completamente
+qualificado.cgi-script designa los ficheros a ser
+procesados como CGIs./usr/local/apache2/conf/httpd.conf, pero puede moverse
+usando opciones de configuración al compilar o al iniciar
+Apache.GET,
+POST, y PUT.text/html,
+image/gif, y application/octet-stream. En
+HTTP, el tipo MIME se transmite en la cabecera
+del Tipo Contenido./images/.*(jpg|gif)$".
+Apache usa Expresiones Regulares compatibles con Perl gracias a la
+librería PCRE.tar. Las
+distribuciones Apache se almacenan en ficheros comprimidos con tar o
+con pkzip.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.Versión 2.1 del Servidor HTTP Apache
+Este documento describe el uso de los Handlers en Apache.
+| Módulos Relacionados | Directivas Relacionadas |
|---|---|
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(), que es el handler
+ usado por defecto para tratar contenido
+ estático. (core)mod_asis)mod_cgi)mod_imap)mod_info)mod_status)mod_negotiation)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.
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>
+
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.
Este documento describe el uso de los Handlers en Apache.
+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
default_handler(), que es el handler
+ usado por defecto para tratar contenido
+ estático. (core)Las siguientes directivas hacen que cuando haya una
+ petición de ficheros con la extensión
+ html se lance el script CGI
+ footer.pl.
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.
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.
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:
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.
Versión 2.1 del Servidor HTTP Apache
+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.
+ +
Visión general del proceso para
+ impacientes Requisitos Descargar Descomprimir Configuración de la estructura de
+directorios Compilar Instalar Personalizar Comprobar que la instalación
+funciona Actualizar una instalación
+prrevia| Descargar | + +$ lynx http://httpd.apache.org/download.cgi
+ |
+
| Descomprimir | + +$ gzip -d httpd-2_1_NN.tar.gz |
+
| 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.
+Estos son los requisitos necesarios para compilar Apache:
+ +PATH debe contener la
+ ubicación donde de encuentran las herramientas básicas
+ para compilar tales como make.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.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.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.
+ +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.
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.
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.
+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.
+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.
+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
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
+
--prefix diferente y un puerto diferente (modificando
+ la directiva Listen)
+ para comprobar que no existe ninguna incompatibilidad antes de
+ hacer la actualización definitiva.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.
+ +| Descargar | + +$ lynx http://httpd.apache.org/download.cgi
+ |
+
| Descomprimir | + +$ gzip -d httpd-2_1_NN.tar.gz |
+
| 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.
+Estos son los requisitos necesarios para compilar Apache:
+ +PATH debe contener la
+ ubicación donde de encuentran las herramientas básicas
+ para compilar tales como make.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.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.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.
+ +Extraer el código fuente del archivo .tgz que acabada de + descargar es muy fácil. Ejecute los siguientes comandos:
+ +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.
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
+
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.
Ahora puede compilar las diferentes partes que forman Apache + simplemente ejecutando el siguiente comando:
+ +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.
+Ahora es el momento de instalar el paquete en el diretorio
+ elegido en PREFIX (consulte la opción
+ --prefix más arriba) ejecutando:
Si usted está solo actualizando una instalación + anterior, la nueva instalación no sobreescribirá sus + ficheros de configuración ni otros documentos.
+El paso siguiente, es personalizar su servidor Apache editando
+ los ficheros de configuración
+ que están en PREFIX/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.
+Ahora puede iniciar su servidor + Apache cuando quiera ejecutando:
+ +y entonces debe poder acceder al documento que tenga
+ especificado por defecto usando el siguiente URL:
+ http://localhost/. El documento que verá
+ estará en PREFIX/htdocs/.
+ Si quiere parar el servidor, puede
+ hacerlo ejecutando:
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 :
--prefix diferente y un puerto diferente (modificando
+ la directiva Versión 2.1 del Servidor HTTP 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.
Cómo iniciar Apache Errores Durante el Arranque Iniciar Apache al Iniciar el Sistema Información AdicionalSi 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.
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:
Puede encontrar más información sobre cómo + solucionar problemas, en la sección de Preguntas Frecuentes de Apache.
+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.
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.
+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.
Si el puerto especificado en la directiva 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
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
+
Si Apache encuentra una error irrecuperable durante el
+ arranque, escribirá un mensaje describiendo el problema en la
+ consola o en el archivo Unable to bind to Port ...". Cuando se recibe este
+ mensaje es normalmente por alguna de las siguientes razones:
Puede encontrar más información sobre cómo + solucionar problemas, en la sección de Preguntas Frecuentes de Apache.
+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.
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.
+Versión 2.1 del Servidor HTTP Apache
+Este documento describe que es un Módulo de Multiprocesamiento y +como los usa Apache.
+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:
+ +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.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.
+ +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.
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 |
Este documento describe que es un Módulo de Multiprocesamiento y +como los usa Apache.
+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:
+ +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.
+ +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.
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 | |
| Netware | |
| OS/2 | |
| Unix | |
| Windows |
Versión 2.1 del Servidor HTTP Apache
+Esta página contiene la lista con los documentos actualmente +disponibles de la Versión 2.1 de la Documentación del +Servidor HTTP Apache.
+ Notas de la Versión Funcionamiento del Servidor HTTP Apache Documuentación sobre Hosting Virtual en Apache Preguntas Más Frecuentes sobre Apache Encriptado SSL/TLS con Apache Guías, Tutoriales, y HowTos Notas específicas sobre plataformas Programas de soporte y el Servidor HTTP Apache Documentación adicional sobre Apache Módulos de Apache Documentación para desarrolladores Glosario e ÍndiceEsta página contiene la lista con los documentos actualmente +disponibles de la Versión 2.1 de la Documentación del +Servidor HTTP Apache.
+Versión 2.1 del Servidor HTTP 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.
+ Introducción Parar Apache Reinicio Graceful Reiniciar Apache Apéndice: señales y race conditionsPara 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.
apachectl -k stopEnviar 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.
apachectl -k gracefulLas 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.
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.
-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.apachectl -k restartEl 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.
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.
+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.
+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 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:
+ +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:
Modifique estos ejemplos para que coincidan con la
+ configuración que tenga especificada en las directivas
+
apachectl -k stopEnviar 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.
apachectl -k gracefulLas 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.
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
Los usuarios del módulo 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.
-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.apachectl -k restartEl 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 HUP.
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 HUP) 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
+
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.
+