--- /dev/null
+<?xml version="1.0" encoding="UTF-8" ?>
+<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
+<?xml-stylesheet type="text/xsl" href="./style/manual.es.xsl"?>
+<!-- English Revision: 106849 -->
+
+<!--
+ Copyright 2005 The Apache Software Foundation or it licensors,
+ as applicable.
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<manualpage metafile="logs.xml.meta">
+
+ <title>Archivos de Registro (Log Files)</title>
+
+ <summary>
+ <p>Para administrar de manera efectiva un servidor web, es
+ necesario tener registros de la actividad y el rendimiento del
+ servidor así como de cualquier problema que haya podido
+ ocurrir durante su operación. El servidor HTTP Apache ofrece
+ capacidades muy amplias de registro de este tipo de
+ información. Este documento explica cómo configurar esas
+ capacidades de registro, y cómo comprender qué
+ información contienen los ficheros de registro.</p>
+ </summary>
+
+ <section id="security">
+ <title>Advertencia de seguridad</title>
+
+ <p>Cualquiera que tenga permisos de escritura sobre el directorio
+ en el que Apache esté escribiendo un archivo de registro
+ puede con casi toda seguridad tener acceso al identificador de
+ usuario con el que se inició el servidor, normalmente
+ root. <em>NO</em> le de a nadie permisos de escritura sobre el
+ directorio en que se almacenan los ficheros de registro sin tener
+ en cuenta las consecuencias; consulte los <a
+ href="misc/security_tips.html">consejos de seguridad</a> para
+ obtener más información.</p>
+
+ <p>Además, los ficheros de registro pueden contener
+ información suministrada directamente por el cliente, sin
+ sustituir. Es posible por tanto que clientes con malas intenciones
+ inserten caracteres de control en los ficheros de registro. Por
+ ello es necesario tener cuidado cuando se procesan los ficheros de
+ registro originales.</p>
+ </section>
+
+ <section id="errorlog">
+ <title>Registro de Errores (Error Log)</title>
+
+ <related>
+ <directivelist>
+ <directive module="core">ErrorLog</directive>
+ <directive module="core">LogLevel</directive>
+ </directivelist>
+ </related>
+
+ <p>El registro de errores del servidor, cuyo nombre y
+ ubicación se especifica en la directiva <directive
+ module="core">ErrorLog</directive>, es el más importante de
+ todos los registros. Apache enviará cualquier
+ información de diagnóstico y registrará cualquier
+ error que encuentre al procesar peticiones al archivo de registro
+ seleccionado. Es el primer lugar donde tiene que mirar cuando
+ surja un problema al iniciar el servidor o durante su
+ operación normal, porque con frecuencia encontrará en
+ él información detallada de qué ha ido mal y
+ cómo solucionar el problema.</p>
+
+ <p>El registro de errores se escribe normalmente en un fichero
+ (cuyo nombre suele ser <code>error_log</code> en sistemas Unix y
+ <code>error.log</code> en Windows y OS/2). En sistemas Unix
+ también es posible hacer que el servidor envíe los
+ mensajes de error al <code>syslog</code> o <a
+ href="#piped">pasarlos a un programa</a>.</p>
+
+ <p>El formato del registro de errores es relativamente libre y
+ descriptivo. No obstante, hay cierta información que se
+ incluye en casi todas las entradas de un registro de errores. Por
+ ejemplo, este es un mensaje típico.</p>
+
+ <example>
+ [Wed Oct 11 14:32:52 2000] [error] [client 127.0.0.1]
+ client denied by server configuration:
+ /export/home/live/ap/htdocs/test
+ </example>
+
+ <p>El primer elemento de la entrada es la fecha y la hora del
+ mensaje. El segundo elemento indica la gravedad del error que se
+ ha producido. La directiva <directive
+ module="core">LogLevel</directive> se usa para controlar los tipos
+ de errores que se envían al registro de errores según su
+ gravedad. La tercera parte contiene la dirección IP del
+ cliente que generó el error. Después de la dirección
+ IP está el mensaje de error propiamente dicho, que en este
+ caso indica que el servidor ha sido configurado para denegar el
+ acceso a ese cliente. El servidor reporta también la ruta en
+ el sistema de ficheros (en vez de la ruta en el servidor
+ web) del documento solicitado.</p>
+
+ <p>En el registro de errores puede aparecer una amplia variedad de
+ mensajes diferentes. La mayoría tienen un aspecto similar al
+ del ejemplo de arriba. El registro de errores también
+ contiene mensaje de depuración de scripts CGI. Cualquier
+ información escrita en el <code>stderr</code> por un script
+ CGI se copiará directamente en el registro de errores.</p>
+
+ <p>El registro de errores no se puede personalizar añadiendo
+ o quitando información. Sin embargo, las entradas del
+ registro de errores que se refieren a determinadas peticiones
+ tienen sus correspondientes entradas en el <a
+ href="#accesslog">registro de acceso</a>. El ejemplo de arriba se
+ corresponde con una entrada en el registro de acceso que
+ tendrá un código de estado 403. Como es posible
+ personalizar el registro de acceso, puede obtener más
+ información sobre los errores que se producen usando ese
+ registro también.</p>
+
+ <p>Si hace pruebas, suele ser de utilidad monitorizar de forma
+ continua el registro de errores para comprobar si ocurre
+ algún problema. En sistemas Unix, puede hacer esto
+ usando:</p>
+
+ <example>
+ tail -f error_log
+ </example>
+ </section>
+
+ <section id="accesslog">
+ <title>Registro de Acceso (Access Log)</title>
+
+ <related>
+ <modulelist>
+ <module>mod_log_config</module>
+ <module>mod_setenvif</module>
+ </modulelist>
+ <directivelist>
+ <directive module="mod_log_config">CustomLog</directive>
+ <directive module="mod_log_config">LogFormat</directive>
+ <directive module="mod_setenvif">SetEnvIf</directive>
+ </directivelist>
+ </related>
+
+ <p>El servidor almacena en el registro de acceso información
+ sobre todas las peticiones que procesa. La ubicación del
+ fichero de registro y el contenido que se registra se pueden
+ modificar con la directiva <directive
+ module="mod_log_config">CustomLog</directive>. Puede usar la
+ directiva <directive module="mod_log_config">LogFormat</directive>
+ para simplificar la selección de los contenidos que quiere
+ que se incluyan en los registros. Esta sección explica como
+ configurar el servidor para que registre la información que
+ usted considere oportuno en el registro de acceso.</p>
+
+ <p>Por supuesto, almacenar información en el registro de
+ acceso es solamente el principio en la gestión de los
+ registros. El siguiente paso es analizar la información que
+ contienen para producir estadísticas que le resulten de
+ utilidad. Explicar el análisis de los registros en general
+ está fuera de los propósitos de este documento, y no es
+ propiamente una parte del trabajo del servidor web. Para más
+ información sobre este tema, y para aplicaciones que analizan
+ los registros, puede visitar
+ <a
+ href="http://dmoz.org/Computers/Software/Internet/Site_Management/Log_analysis/">
+ Open Directory</a> o <a
+ href="http://dir.yahoo.com/Computers_and_Internet/Software/Internet/World_Wide_Web/Servers/Log_Analysis_Tools/">
+ Yahoo</a>.</p>
+
+ <p>Diferentes versiones de Apache httpd han usado otros
+ módulos y directivas para controlar la información que
+ se almacena en el registro de acceso, incluyendo mod_log_referer,
+ mod_log_agent, y la directiva <code>TransferLog</code>. Ahora la
+ directiva <directive module="mod_log_config">CustomLog</directive>
+ asume toda la funcionalidad que antes estaba repartida.</p>
+
+ <p>El formato del registro de acceso es altamente configurable. El
+ formato se especifica usando una cadena de caracteres de formato
+ similar a las de printf(1) en lenguaje C. Hay algunos ejemplos en
+ las siguientes secciones. Si quiere una lista completa de los
+ posibles contenidos que se pueden incluir, consulte la
+ documentació sobre <a
+ href="mod/mod_log_config.html#formats">las cadenas de caracteres
+ de formato</a> del <module>mod_log_config</module>.</p>
+
+ <section id="common">
+ <title>Formato Común de Registro (Common Log
+ Format)</title>
+
+ <p>Una configuración típica del registro de acceso
+ podría tener un aspecto similar a este.</p>
+
+ <example>
+ LogFormat "%h %l %u %t \"%r\" %>s %b" common<br />
+ CustomLog logs/access_log common
+ </example>
+
+ <p>Con esto se define el <em>apodo (nickname)</em> <code>common</code> y se
+ le lo asocia con un determinado formato. El formato consiste en
+ una serie de directivas con tantos por ciento, cada una de las
+ cuales le dice al servidor que registre una determinada
+ información en particular. El formato también puede
+ incluir caracteres literales, que se copiarán directamente
+ en el registro. Si usa el caracter comillas (<code>"</code>)
+ debe anteponerle una barra invertida para evitar que sea
+ interpretado como el final la cadena de caracteres a
+ registrar. El formato que especifique también puede
+ contener los caracteres de control especiales "<code>\n</code>"
+ para salto de línea y "<code>\t</code>" para tabulador.</p>
+
+ <p>La directiva <directive
+ module="mod_log_config">CustomLog</directive> crea un nuevo
+ fichero de registro usando el <em>apodo</em> definido. El
+ nombre del fichero de registro de acceso se asume que es
+ relativo al valor especificado en <directive
+ module="core">ServerRoot</directive> a no ser que empiece
+ por una barra (/).</p>
+
+ <p>La configuración de arriba escribirá las entradas
+ en el registro con el formato conocido como Formato Común
+ de Registro (CLF). Este formato estándar lo pueden generar
+ muchos servidores web diferentes y lo pueden leer muchos de los
+ progrmas que analizan registros. Las entradas de un fichero de
+ registro que respetan ese formato común tienen una
+ aparariencia parecida es esta:</p>
+
+ <example>
+ 127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET
+ /apache_pb.gif HTTP/1.0" 200 2326
+ </example>
+
+ <p>Cada una de las partes de la entrada se explican a
+ continuaci#243;n.</p>
+
+ <dl>
+ <dt><code>127.0.0.1</code> (<code>%h</code>)</dt>
+
+ <dd>Es la dirección IP del cliente (host remoto) que hizo
+ la petición al servidor. Si la directiva <directive
+ module="core">HostnameLookups</directive> tiene valor
+ <code>On</code>, el servidor intentará determinar el
+ nombre del host y registrar ese nombre en lugar de la
+ dirección IP. Sin embargo, no se recomienda que use esta
+ configuración porque puede ralentizar significativamente
+ las operaciones del servidor. En su lugar, es mejor usar un
+ programa que realice esta tarea posteriormente sobre el
+ registro, por ejemplo <program>logresolve</program>. Las
+ direcciones IP que se registren no son necesariamente las
+ direcciones de las máquinas de los usuarios finales. Si
+ existe un servidor proxy entre el usuario final y el servidor,
+ la dirección que se registra es la del proxy.</dd>
+
+ <dt><code>-</code> (<code>%l</code>)</dt>
+
+ <dd>Un "guión" siginifica que la información que
+ debería ir en ese lugar no está disponible. En este
+ caso, esa información es la identidad RFC 1413 del
+ cliente determinada por <code>identd</code> en la máquina
+ del cliente. Esta información es muy poco fiable y no
+ debería ser usada nunca excepto con clientes que
+ estén sometidos a controles muy estrictos en redes
+ internas. Apache httpd ni siquiera intenta recoger esa
+ información a menos que la directiva <directive
+ module="core">IdentityCheck</directive> tenga valor
+ <code>On</code>.</dd>
+
+ <dt><code>frank</code> (<code>%u</code>)</dt>
+
+ <dd>Este es el identificador de usuario de la persona que
+ solicita el documento determinado por la autentificación
+ HTTP. Normalmente ese mismo valor se pasa a los scripts CGI
+ con la variable de entorno <code>REMOTE_USER</code>. Si el
+ código de estado de la petición (ver abajo) es 401,
+ entonces no debe confiar en la veracidad de ese dato porque el
+ usuario no ha sido aún autentificado. Si el documento no
+ está protegido por contraseña, se mostrará un
+ guión "<code>-</code>" en esta entrada.</dd>
+
+ <dt><code>[10/Oct/2000:13:55:36 -0700]</code>
+ (<code>%t</code>)</dt>
+
+ <dd>
+ La hora a la que el servidor terminó de procesar la
+ petición. El formato es:
+
+ <p class="indent">
+ <code>[día/mes/año:hora:minuto:segundo zona_horaria]<br />
+ day = 2*digit<br />
+ month = 3*letter<br />
+ year = 4*digit<br />
+ hour = 2*digit<br />
+ minute = 2*digit<br />
+ second = 2*digit<br />
+ zone = (`+' | `-') 4*digit</code>
+ </p>
+ Es posible mostrar la hora de otra manera especificando
+ <code>%{format}</code> en el formato a usar en el registro,
+ donde <code>format</code> se sustituye como se haría al
+ usar <code>strftime(3)</code> de la librería
+ estándar de C.
+ </dd>
+
+ <dt><code>"GET /apache_pb.gif HTTP/1.0"</code>
+ (<code>\"%r\"</code>)</dt>
+
+ <dd>La línea de la petición del cliente se muestra
+ entre dobles comillas. La línea de petición contiene
+ mucha información de utilidad. Primero, el método
+ usado por el cliente es <code>GET</code>. Segundo, el cliente
+ ha hecho una petición al recurso
+ <code>/apache_pb.gif</code>, y tercero, el cliente uso el
+ protocolo <code>HTTP/1.0</code>. También es posible
+ registrar una o más partes de la línea de
+ petición independientemente. Por ejemplo, el formato
+ "<code>%m %U%q %H</code>" registrará el método, ruta,
+ cadena de consulta y protocolo, teniendo exactamente el mismo
+ resultado que "<code>%r</code>".</dd>
+
+ <dt><code>200</code> (<code>%>s</code>)</dt>
+
+ <dd>Es el código de estado que el servidor envía de
+ vuelta al cliente. Esta información es muy valiosa,
+ porque revela si la petición fue respondida con
+ éxito por el servidor (los códigos que empiezan por
+ 2), una redirección (los códigos que empiezan por
+ 3), un error provocado por el cliente (los códigos que
+ empiezan por 4), o un error en el servidor (los códigos
+ que empiezan por 5). La lista completa de códigos de
+ estado posibles puede consultarle en <a
+ href="http://www.w3.org/Protocols/rfc2616/rfc2616.txt">la
+ especificación de HTTP</a> (RFC2616 sección
+ 10).</dd>
+
+ <dt><code>2326</code> (<code>%b</code>)</dt>
+
+ <dd>La última entrada indica el tamaño del objeto
+ retornado por el cliente, no incluídas las cabeceras de
+ respuesta. Si no se respondió con ningún contenido
+ al cliente, este valor mostrará valor
+ "<code>-</code>". Para registrar "<code>0</code>" en ese caso,
+ use <code>%B</code> en su lugar.</dd>
+ </dl>
+ </section>
+
+ <section id="combined">
+ <title>Formato de Registro Combinado (Combined Log Format)</title>
+
+ <p>Otro formato usado a menudo es el llamado Formato de Registro
+ Combinado. Este formato puede ser usado como sigue.</p>
+
+ <example>
+ LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\"
+ \"%{User-agent}i\"" combined<br />
+ CustomLog log/access_log combined
+ </example>
+
+ <p>Es exactamente igual que Formato Común de Registro, pero
+ añade dos campos. Cada campo adicional usa la directiva
+ <code>%{<em>header</em>}i</code>, donde <em>header</em> puede
+ ser cualquier cabecera de petición HTTP. El registro de
+ acceso cuando se usa este formato tendrá este aspecto:</p>
+
+ <example>
+ 127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET
+ /apache_pb.gif HTTP/1.0" 200 2326
+ "http://www.example.com/start.html" "Mozilla/4.08 [en]
+ (Win98; I ;Nav)"
+ </example>
+
+ <p>Los campos adicionales son:</p>
+
+ <dl>
+ <dt><code>"http://www.example.com/start.html"</code>
+ (<code>\"%{Referer}i\"</code>)</dt>
+
+ <dd>La cabecera de petición de HTTP "Referer"
+ (sic). Muestra el servidor del que proviene el cliente. (Esta
+ debería ser la página que contiene un enlace o
+ que contiene a <code>/apache_pb.gif</code>).</dd>
+
+ <dt><code>"Mozilla/4.08 [en] (Win98; I ;Nav)"</code>
+ (<code>\"%{User-agent}i\"</code>)</dt>
+
+ <dd>La cabecera de petición HTTP "User-Agent". Es la
+ información de identificación que el navegador del
+ cliente incluye sobre sí mismo.</dd>
+ </dl>
+ </section>
+
+ <section id="multiple">
+ <title>Cómo usar varios registros de acceso</title>
+
+ <p>Para crear varios registros de acceso solamente tiene que
+ especificar varias directivas <directive
+ module="mod_log_config">CustomLog</directive> en el fichero de
+ configuración. Por ejemplo, las siguientes directivas
+ crearán tres registros de acceso. El primero contendrá
+ la información básica en Formato Común de
+ Registro, mientras que el segundo y el tercero contendrán
+ contendrán la información de los "referer" y de los
+ navegadores usados. Las dos últimas líneas <directive
+ module="mod_log_config">CustomLog</directive> muestran cómo
+ reproducir el comportamiento de las directivas
+ <code>ReferLog</code> y <code >AgentLog</code>.</p>
+
+ <example>
+ LogFormat "%h %l %u %t \"%r\" %>s %b" common<br />
+ CustomLog logs/access_log common<br />
+ CustomLog logs/referer_log "%{Referer}i -> %U"<br />
+ CustomLog logs/agent_log "%{User-agent}i"
+ </example>
+
+ <p>Este ejemplo también muestra que no es necesario definir un
+ "apodo" con la directiva <directive
+ module="mod_log_config">LogFormat</directive>. En lugar de esto,
+ el formato de registro puede especificarse directamente en la
+ directiva <directive
+ module="mod_log_config">CustomLog</directive>.</p>
+ </section>
+
+ <section id="conditional">
+ <title>Registro Condicional</title>
+
+ <p>Algunas veces es más conveniente excluir determinadas
+ entradas del registro de acceso en función de las
+ características de la petición del cliente. Puede
+ hacer esto fácilmente con la ayuda de <a
+ href="env.html">variables de entorno</a>. Primero, debe
+ especificar una variable de entorno que indique que la
+ petición cumple determinadas condiciones. Esto se hace
+ normalmente con <directive
+ module="mod_setenvif">SetEnvIf</directive>. Entonces puede usar
+ la claúsula <code>env=</code> de la directiva <directive
+ module="mod_log_config">CustomLog</directive> para incluir o
+ excluir peticiones en las que esté presente la variable de
+ entorno. Algunos ejemplos:</p>
+
+ <example>
+ # Marcar las peticiones de la interfaz loop-back<br />
+ SetEnvIf Remote_Addr "127\.0\.0\.1" dontlog<br />
+ # Marcar las peticiones del fichero robots.txt<br />
+ SetEnvIf Request_URI "^/robots\.txt$" dontlog<br />
+ # Registrar lo que quede<br />
+ CustomLog logs/access_log common env=!dontlog
+ </example>
+
+ <p>Como otro ejemplo, considere registrar las peticiones de los
+ angloparlantes en un fichero de registro, y el resto de
+ peticiones en un fichero de registro diferente.</p>
+
+ <example>
+ SetEnvIf Accept-Language "en" english<br />
+ CustomLog logs/english_log common env=english<br />
+ CustomLog logs/non_english_log common env=!english
+ </example>
+
+ <p>Aunque acabamos de mostar que el registro condicional es muy
+ potente y flexible, no es la única manera de controlar los
+ contenidos de los ficheros de registro. Los ficheros de registro
+ son más útiles cuanta más información sobre
+ la actividad del servidor contengan. A menudo es más
+ fácil eliminar las peticiones que no le interesen
+ procesando posteriormente los ficheros de registro
+ originales.</p>
+ </section>
+ </section>
+
+ <section id="rotation">
+ <title>Rotación de los ficheros de registro</title>
+
+ <p>Incluso en un servidor con una actividad moderada, la cantidad
+ de información almacenada en los ficheros de registro es muy
+ grande. El registro de acceso crece normalmente en 1MB por cada
+ 10.000 peticiones. Por lo tanto, es necesario rotar
+ periódicamente los registros moviendo o borrando su
+ contenido. Esto no se puede hacer con el servidor funcionando,
+ porque Apache continuará escribiendo en el antiguo registro
+ mientras que el archivo esté abierto. En lugar de esto, el
+ servidor debe ser <a href="stopping.html">reiniciado</a>
+ después de mover o borrar los ficheros de registro para que
+ se abran nuevos ficheros de registro.</p>
+
+ <p>Usando un reinicio <em>graceful</em>, se le puede indicar al
+ servidor que abra nuevos ficheros de registro sin perder ninguna
+ petición siendo servida o en espera de algún cliente. Sin
+ embargo, para hacer esto, el servidor debe continuar escribiendo
+ en los ficheros de registro antiguos mientras termina de servir
+ esas peticiones. Por lo tanto, es preciso esperar algún
+ tiempo después del reinicio antes de realizar ninguna
+ operación sobre los antiguos ficheros de registro. Una
+ situación típica que simplemente rota los registros y
+ comprime los registros antiguos para ahorrar espacio es:</p>
+
+ <example>
+ mv access_log access_log.old<br />
+ mv error_log error_log.old<br />
+ apachectl graceful<br />
+ sleep 600<br />
+ gzip access_log.old error_log.old
+ </example>
+
+ <p>Otra manera de realizar la rotación de los registros es
+ usando <a href="#piped">ficheros de registro redireccionados
+ (piped logs)</a> de la forma en que se explica en la siguiente
+ sección.</p>
+ </section>
+
+ <section id="piped">
+ <title>Ficheros de registro redireccionados (Piped Logs)</title>
+
+ <p>Apache httpd es capaz de escribir la información del
+ registro de acceso y errores mediante una redirección a otro
+ proceso, en lugar de directamente a un fichero. Esta capacidad
+ incrementa de forma muy importante la flexibilidad de registro,
+ sin añadir código al servidor principal. Para escribir
+ registros a una redirección, simplemente reemplace el nombre
+ de fichero por el carácter "<code>|</code>", seguido por el
+ nombre del ejecutable que debería aceptar las entradas de
+ registro por su canal de entrada estándar. Apache
+ iniciará el proceso de registro redireccionado cuando se
+ inicie el servidor, y lo reiniciará si se produce algún
+ error irrecuperable durante su ejecución. (Esta última
+ funcionalidad es la que hace que se llame a esta técnica
+ "registro redireccionado fiable".)</p>
+
+ <p>Los procesos de registros son engendrados por el proceso padre
+ de Apache httpd, y heredan el identificador de usuario de ese
+ proceso. Esto significa que los programas a los que se
+ redireccionan los registros se ejecutan normalmente como root. Es
+ por ello que es muy importante que los programas sean simples y
+ seguros.</p>
+
+ <p>Un uso importante de los registros redireccionados es permitir
+ la rotación de los registros sin tener que reiniciar el
+ servidor. El servidor Apache HTTP incluye un programa simple
+ llamado <program>rotatelogs</program> con este propósito. Por
+ ejemplo para rotar los registros cada 24 horas, puede usar:</p>
+
+ <example>
+ CustomLog "|/usr/local/apache/bin/rotatelogs
+ /var/log/access_log 86400" common
+ </example>
+
+ <p>Tenga en cuenta que las comillas se usan para abarcar el
+ comando entero que será invocado por la
+ redirección. Aunque estos ejemplos son para el registro de
+ acceso, la misma técnica se puede usar para el registro de
+ errores.</p>
+
+ <p>Otro programa para la rotación de los registros mucho
+ más flexible llamado <a
+ href="http://www.cronolog.org/">cronolog</a> está disponible
+ en un sitio web externo.</p>
+
+ <p>Como ocurre con el registro condicional, la redirección de
+ registros es una herramienta muy potente, pero no deben ser usados
+ si hay disponible una solución más simple de procesado
+ posterior de los registros fuera de línea.</p>
+ </section>
+
+ <section id="virtualhost">
+ <title>Hosts Virtuales</title>
+
+ <p>Cuando se está ejecutando un servidor con muchos <a
+ href="vhosts/">hosts virtuales</a>, hay varias formas de abordar
+ el asunto de los registros. Primero, es posible usar los registros
+ de la misma manera que se usarían si hubiera solamente un
+ host en el servidor. Simplemente poniendo las directivas que
+ tienen que ver con los registros fuera de las secciones <directive
+ module="core" type="section">VirtualHost</directive> en el
+ contexto del servidor principal, puede almacenar toda la
+ información de todas las peticiones en los mismos registros
+ de acceso y errores. Esta técnica no permite una
+ recolección fácil de las estadísticas individuales
+ de cada uno de los hosts virtuales.</p>
+
+ <p>Si una directiva <directive
+ module="mod_log_config">CustomLog</directive> o <directive
+ module="core">ErrorLog</directive> se pone dentro una sección
+ <directive module="core" type="section">VirtualHost</directive>,
+ todas las peticiones de ese host virtual se registrarán
+ solamente en el fichero especificado. Las peticiones de cualquier
+ host virtual que no tenga directivas de registro específicas
+ para él se registrarán en los registros del servidor
+ principal. Esta técnica es muy útil si usa un
+ pequeño número de hosts virtuales, pero si usa un gran
+ número de ellos, puede ser complicado de
+ gestionar. Además, puede a menudo provocar problemas con <a
+ href="vhosts/fd-limits.html"> descriptores de fichero
+ insuficientes</a>.</p>
+
+ <p>Para el registro de acceso, se puede llegar a un buen
+ equilibrio. Añadiendo información del host virtual al
+ formato de registro, es posible registrar las operaciones de todos
+ los hosts en un único registro, y posteriormente dividir el
+ fichero con todos los registros en ficheros individualizados. Por
+ ejemplo, considere las siguientes directivas.</p>
+
+ <example>
+ LogFormat "%v %l %u %t \"%r\" %>s %b"
+ comonvhost<br />
+ CustomLog logs/access_log comonvhost
+ </example>
+
+ <p>El <code>%v</code> se usa para registrar el nombre del host
+ virtual que está sirviendo la petición. Puede usar un
+ programa como <a href="programs/other.html">split-logfile</a> para
+ procesar posteriormente el registro de acceso y dividirlo en
+ ficheros independientes para cada host virtual.</p>
+ </section>
+
+ <section id="other">
+ <title>Otros ficheros de registro</title>
+
+ <related>
+ <modulelist>
+ <module>mod_cgi</module>
+ <module>mod_rewrite</module>
+ </modulelist>
+ <directivelist>
+ <directive module="mpm_common">PidFile</directive>
+ <directive module="mod_rewrite">RewriteLog</directive>
+ <directive module="mod_rewrite">RewriteLogLevel</directive>
+ <directive module="mod_cgi">ScriptLog</directive>
+ <directive module="mod_cgi">ScriptLogBuffer</directive>
+ <directive module="mod_cgi">ScriptLogLength</directive>
+ </directivelist>
+ </related>
+
+ <section id="pidfile">
+ <title>Fichero PID (PID File)</title>
+
+ <p>Al iniciar, Apache httpd guarda el identificador del proceso
+ padre del servidor en el fichero
+ <code>logs/httpd.pid</code>. Puede modificar el nombre de este
+ fichero con la directiva <directive
+ module="mpm_common">PidFile</directive>. El identificador del
+ proceso puede usarlo el administrador para reiniciar y finalizar
+ el demonio (daemon) mediante el envío de señales al
+ proceso padre; en Windows, use la opción de línea de
+ comandos -k en su lugar. Para más información al
+ respecto, consulte la documentación sobre <a
+ href="stopping.html">parar y reiniciar Apache</a>.</p>
+ </section>
+
+ <section id="scriptlog">
+ <title>Registro de actividad de scripts (Script Log)</title>
+
+ <p>Para ayudar a la detección de errores, la directiva
+ <directive module="mod_cgi">ScriptLog</directive> permite
+ guardar la entrada y la salida de los scripts CGI. Esta
+ directiva solamente debería usarla para hacer pruebas - no
+ en servidores en producción. Puede encontrar más
+ información al respecto en la documentación de <a
+ href="mod/mod_cgi.html">mod_cgi</a>.</p>
+ </section>
+
+ <section id="rewritelog">
+ <title>Registro de actividad de Rewrite (Rewrite Log)</title>
+
+ <p>Cuando use las potentes y complejas funcionalidades de <a
+ href="mod/mod_rewrite.html">mod_rewrite</a>, será casi
+ siempre necesario usar la direcitiva <directive
+ module="mod_rewrite">RewriteLog</directive> para ayudar a la
+ detección de errores. Este fichero de registro produce un
+ análisis detallado de cómo actúa este
+ módulo sobre las peticiones. El nivel de detalle del
+ registro se controla con la directiva <directive
+ module="mod_rewrite">RewriteLogLevel</directive>.</p>
+ </section>
+ </section>
+</manualpage>
+
+
+
+
<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.en.xsl"?>
-<!-- English Revision: 103430:106090 (outdated) -->
+<!-- English Revision: 106090 -->
<!--
- Copyright 2004 The Apache Software Foundation
+ Copyright 2004-2005 The Apache Software Foundation or it licensors,
+ as applicable.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
<manualpage metafile="upgrading.xml.meta">
-<title>Migrar su instalación de la versión 1.3 a la
-2.0</title>
+<title>Pasar a usar Apache 2.0 si ahora usa Apache 1.3</title>
<summary>
<p>Este documento recoge infomación crítica sobre el
<li>Además de la selección de módulos habitual
que puede hacer al compilar, en Apache 2.0 la mayor parte del
- procesamiento de las petición es llevada a cabo por
los <a
- href="mpm.html">Módulos de MultiProcesamiento</a>
+ procesamiento de las petición es llevada a cabo por <a
+ href="mpm.html">módulos de multiprocesamiento</a>
(MPMs).</li>
</ul>
</section>
<section id="run-time">
- <title>Cambios en el proceso de la configuración inicial del
+ <title>Cambios en el proceso de configuración inicial del
servidor</title>
<ul>
- <li>Muchas directivas que no pertenicían al conjunto
- básico en Apache 1.3 están ahora en los MPMs. Si desea
- que el nuevo servidor de comporte de la forma más parecida
- posible a Apache 1.3, debe seleccionar el Módulo de
- MultiProcesamiento <module>prefork</module>. Otros MPMs tienen
- diferentes directivas para controlar el proceso de creación
- y procesamiento de peticiones.</li>
+ <li>Muchas directivas que pertenecían al core (núcleo)
+ del servidor en Apache 1.3 se encuentran ahora en distintos
+ módulos de multiprocesamiento. Si desea que el nuevo
+ servidor de comporte de la forma más parecida posible a
+ como lo hacía Apache 1.3, debe usar el módulo de
+ multiprocesamiento <module>prefork</module>. Otros módulos
+ de multiprocesamiento tienen diferentes directivas para
+ controlar la creación de procesos y el procesamiento de
+ peticiones.</li>
<li>El <a href="mod/mod_proxy.html">módulo proxy</a> ha
sido remodelado para ponerlo al día con la
module="mod_proxy">Proxy</directive> en lugar de en un bloque
<code><Directory proxy:></code>.</li>
- <li>El procesamiento de<code>PATH_INFO</code> (la informacion de
- path que aparece tras un nombre de fichero válido) ha
- cambiado para algunos módulos. Módulos que fueron
- previamente implementados como un handle pero ahora son
- implementados como filtros puede que no acepten ahora peticiones
- que incluyan <code>PATH_INFO</code>. Filtros como <a
- href="mod/mod_include.html">INCLUDES</a> o <a
+ <li>El procesamiento de <code>PATH_INFO</code> (la
+ información que aparece detrás de un nombre de fichero
+ válido) ha cambiado en algunos módulos. Los
+ módulos que fueron previamente implementados como un handler
+ pero que ahora son implementados como un filtro puede que no
+ acepten peticiones que incluyan <code>PATH_INFO</code>. Filtros
+
como <a href="mod/mod_include.html">INCLUDES</a> o <a
href="http://www.php.net/">PHP</a> están implementados
- encima del handler principal (core handler) core handler, y por
- tanto rechazan peticiones con <code>PATH_INFO</code>. Puede usar
- la directiva <directive module="core">AcceptPathInfo</directive>
- para forzar al handler principal a aceptar peticiones con
- <code>PATH_INFO</code> y por tanto restaurar la habilidad de
- usar <code>PATH_INFO</code> en server-side includes.</li>
+ sobre el handler principal (core handler), y por tanto
+ rechazarán peticiones con <code>PATH_INFO</code>. Puede
+ usar la directiva <directive
+ module="core">AcceptPathInfo</directive> para forzar al handler
+ principal a aceptar peticiones con <code>PATH_INFO</code> y por
+ tanto restaurar la posibilidad de usar <code>PATH_INFO</code> en
+ server-side includes.</li>
<li>La directiva <directive
module="mod_negotiation">CacheNegotiatedDocs</directive> toma
ahora como argumento <code>on</code> u <code>off</code>. Las
- instacias existentes de <directive
+ instancias existentes de <directive
>CacheNegotiatedDocs</directive> deben reemplazarse por
<code>CacheNegotiatedDocs on</code>.</li>
La directiva <directive
module="core">ErrorDocument</directive> no usa ya dobles
comillas al principio del argumento para indicar el mensaje de
- texto que tiene que mostrarse. En lugar de esto, se debe poner
- entre comillas todo el mensaje. Por ejemplo,
+ texto a mostrar. En lugar de esto, ponga entre comillas todo
+ el mensaje. Por ejemplo,
<example>
ErrorDocument 403 "Mensaje
<li>Las directivas <code>AccessConfig</code> y
<code>ResourceConfig</code> han desaparecido. Las instancias
- existentes de estas directivas pueden sustituirse por la
- directiva <directive module="core">Include</directive> que tiene
- una funcionalidad equivalente. Si hacía uso de los valores
- por defecto de esas directivas sin incluirlas en los ficheros de
- configuración, puede que necesite añadir <code>Include
- conf/access.conf</code> e <code>Include conf/srm.conf</code> a
- su fichero <code>httpd.conf</code>. Para asegurarse de que
- Apache lee el fichero de configuración en el mismo orden
- que asumían las antiguas directivas, las directivas
- <directive module="core">Include</directive> deben ser
- reemplazadas al final del fichero <code>httpd.conf</code>, con
- la de <code>srm.conf</code> precediendo a la de
+ existentes de estas directivas pueden ser sustituidas por
+ directivas <directive module="core">Include</directive> que
+ tienen una funcionalidad equivalente. Si hacía uso de los
+ valores por defecto de esas directivas sin incluirlas en los
+ ficheros de configuración, puede que necesite añadir
+ <code>Include conf/access.conf</code> e <code>Include
+ conf/srm.conf</code> a su fichero <code>httpd.conf</code>. Para
+ asegurar que Apache lee el fichero de configuración en el
+ mismo orden que asumían las antiguas directivas, las
+ directivas <directive module="core">Include</directive> deben
+ ser reemplazadas al final del fichero <code>httpd.conf</code>,
+ con la de <code>srm.conf</code> precediendo a la de
<code>access.conf</code>.</li>
<li>Las directivas <code>BindAddress</code> y <code>Port</code>
<li>La directiva <code>ServerType</code> ha dejado de existir.
El método usado para servir peticiones está ahora
- determinado por la selección del Módulo de
- MultiProcesamiento. Actualmente no hay diseñado un MPM que
- pueda ser ejecutado por inetd.</li>
+ determinado por la selección del módulo de
+ multiprocesamiento. Actualmente no hay diseñado un
+ módulo de multiprocesamiento que pueda ser ejecutado por
+ inetd.</li>
<li>Los módulos <code>mod_log_agent</code> y
<code>mod_log_referer</code> que contenían las directivas
<code>AgentLog</code>, <code>RefererLog</code> y
- <code>RefererIgnore</code> han desaparecido. Los logs de agente
- y de referer están disponibles todavía usando la
- directiva <directive
+ <code>RefererIgnore</code> han desaparecido. Los registros de
+ "agente" y de "referer" están disponibles todavía
+ usando la directiva <directive
module="mod_log_config">CustomLog</directive> del módulo
<module>mod_log_config</module>.</li>
- <li>las directivas <code>AddModule</code> y
+ <li>Las directivas <code>AddModule</code> y
<code>ClearModuleList</code> no están presentes en la nueva
- versión. Estan directivas se usaban para asegurarse de que
- los módulos pudieran activarse en el orden correcto. La
- nueva API de Apache 2.0 permite a los módulos especificar
- explícitamente su orden de activación, eliminando la
- necesidad de estas directivas.</li>
+ versión de Apache. Estas directivas se usaban para
+ asegurar que los módulos pudieran activarse en el orden
+ correcto. La nueva API de Apache 2.0 permite a los módulos
+ especificar explícitamente su orden de activación,
+ eliminando la necesidad de las antiguas directivas.</li>
<li>La directiva <code>FancyIndexing</code> se ha eliminado. La
funcionalidad que cubría está ahora disponible a
comportamiento puede restaurarse usando la directiva <directive
module="mod_mime">MultiviewsMatch</directive>.</li>
+ <li>(<em>a partir de la versión 2.0.51</em>) <p>La
+ funcionalidad de la directiva <code>ErrorHeader</code> se ha
+ unido con la de la directiva <directive
+ module="mod_headers">Header</directive>, porque se estaba usando
+ un término equivocado. Use</p>
+
+ <example>
+ Header always set foo bar
+ </example>
+
+ <p>en lugar de conseguir el comportamiento deseado.</p></li>
+
</ul>
</section>
independiente <code>src</code>. En su lugar, el código
fuente se ha organizado a partir del directorio principal de la
distribución, y las intalaciones del servidor compilado
- deben hecerse en un directorio diferente.</li>
+ deben hacerse en un directorio diferente.</li>
</ul>
</section>
projects / thirdparty / apache / httpd.git / commitdiff
