10.2. Migración de los archivos de configuración de la versión del Servidor Apache HTTP 1.3
Si ha actualizado desde Red Hat Linux 7.3 o una versión anterior en el cual el Servidor Apache HTTP ya se había instalado, entonces el nuevo archivo de configuración para el paquete Servidor Apache HTTP 2.0 esta instalado como /etc/httpd/conf/httpd.conf.rpmnew y la versión original 1.3 httpd.conf no se toca. Por supuesto, depende absolutamente de usted, si elije migrar a la nueva versión y migrar los viejos cambios o si usar el archivo ya existente y modificarlo para que se adapte; sin embargo, algunas partes del archivo se han cambiado más que otras y lo mejor es llegar a un punto intermedio. Los archivos de configuración para ambas versiones están dividos en tres secciones. El objetivo de este manual es sugerirle la manera más sencilla.
Si el archivo /etc/httpd/conf/httpd.conf es una versión modificada de la versión por defecto de Red Hat Linux y ha guardado una copia del original, entonces le será más fácil invocar el comando diff, como se muestra a continuación:
diff -u httpd.conf.orig httpd.conf | less |
Este comando subraya los cambios realizados. Si no tiene una copia del archivo original, cójalo del paquete RPM usando los comandos rpm2cpio y cpio, como en el ejemplo siguiente:
rpm2cpio apache-<version-number>.i386.rpm | cpio -i --make |
En el comando de arriba, sustituya <version-number> con el número de versión para el paquete apache.
Finalmente, es útil saber que el Servidor Apache HTTP tiene un modo de prueba para verificar si hay errores en la configuración. Para ello, escriba el siguiente comando:
apachectl configtest |
10.2.1. Configuración del entorno a nivel global
La sección del entorno global del archivo de configuración contiene directivas que afectan a todas las áreas que cubre el Servidor Apache HTTP como por ejemplo el número de peticiones que puede recibir al mismo tiempo y las localizaciones de varios archivos que usa. Esta sección requiere un gran número de cambios comparado con las otras y por ello se recomienda que base esta sección en el archivo de configuración de la versión 2.0 del Servidor Apache HTTP y que migre sus configuraciones anteriores en el.
10.2.1.1. Selección de las interfaces y de los puertos a los que vincularse
Ya no existen las directivas BindAddress y Port; porque quedan recogidas en la directiva Listen.
Si tenía configurado el Puerto 80 en el archivo de configuración de la versión 1.3, debe cambiarlo a Listen 80 en el archivo de configuración 2.0. Si el valor del Puerto estaba configurado a un valor diferente que 80, tiene que poner el número del puerto a los contenidos de la directiva ServerName.
Por ejemplo, el siguiente ejemplo es una directiva de la versión 1.3 del Servidor Apache HTTP:
Port 123 ServerName www.example.com |
Para migrar esta configuración a la versión 2.0 del Servidor Apache HTTP use la siguiente estructura:
Listen 123 ServerName www.example.com:123 |
Para mayor información sobre este tema, consulte la siguiente documentación en el sitio web de la Apache Software Foundation:
10.2.1.2. Regulación del tráfico de peticiones-respuestas del servidor
En la versión 2.0 del Servidor Apache HTTP se han creado un grupo de módulos llamados Módulos de procesos múltiples (MPMs), que se encargan de aceptar las peticiones y de dar procesos hijo para gestionarlos. A diferencia de otros módulos, el Servidor Apache HTTP solamente puede cargar un módulo del grupo MPM. Hay tres módulos MPM que incluye la versión 2.0: prefork, worker y perchild.
El comportamiento original del Servidor Apache HTTP 1.3 se ha convertido en prefork MPM. Actualmente solamente está disponible el MPM prefork en el Red Hat Linux aunque los otros estaran disponibles más adelante.
El MPM prefork acepta las mismas directivas que el Servidor Apache HTTP 1.3, por tanto las siguientes directivas se pueden migrar directamente:
StartServers
MinSpareServers
MaxSpareServers
MaxClients
MaxRequestsPerChild
Para mayor información consulte la documentación en el sitio web de la Apache Software Foundation:
10.2.1.3. Soporte del Dynamic Shared Object (DSO) (Objeto dinámico compartido)
Se tienen que realizar muchos cambios aquí, por eso se recomienda que para modificar la configuración del Servidor Apache HTTP 1.3 para pasar a la 2.0 se copie esta sección del archivo de configuración del Red Hat Linux Servidor Apache HTTP 2.0.
Aquellos que no deseen copiar la sección desde el tronco del Servidor Apache HTTP 2.0 deberían tomar en cuenta lo siguiente:
Las directivas AddModule y ClearModuleList ya no existen. Estas directivas eran usadas para asegurar que se pudiesen activar los módulos en el orden correcto. La API del Servidor Apache HTTP 2.0 permite a los módulos especificar su orden, eliminando la necesidad de estas dos directivas.
El orden de las líneas LoadModule ya no es relevante.
Se han añadido muchos módulos, otros han sido eliminados, renombrado, dividido o incorporados con otros.
Ya no son necesarias las líneas LoadModule para los módulos empaquetados en los propios RPMs (mod_ssl, php, mod_perl y similares) ya que se pueden encontrar en el directorio /etc/httpd/conf.d/.
Las definiciones HAVE_XXX ya no existen.
 | Importante | |
|---|---|---|
Si se está modificando el archivo original, por favor tenga en cuenta que es de suma importancia que httpd.conf contenga la directiva siguiente:
La omisión de esta directiva podría resultar en la falla de todos los módulos enpaquetados en sus propios RPMs (tales como mod_perl, php y mod_ssl). |
10.2.1.4. Otros cambios en el entorno global
Se han eliminado las siguientes directivas de la configuración del Servidor Apache HTTP 2.0:
ServerType — El Servidor Apache HTTP se puede ejecutar solamente como ServerType standalone por lo que esta directiva es irrelevante.
AccessConfig y ResourceConfig — Se han eliminado estas directivas porque su funcionalidad aparece ya en la directiva Include. Si las directivas AccessConfig y ResourceConfig son configuradas entonces reemplácelas por las directivas Include.
Para asegurarse que estos archivos se lean en el orden de las antiguas directivas, las directivas Include se deberían colocar al final de httpd.conf, con la correspondiente a ResourceConfig precediendo la que corresponde a AccessConfig. Si se estan usando los valores por defecto, inclúyalos explícitamente como archivos conf/srm.conf y conf/access.conf.
10.2.2. Configuración del servidor principal
La sección de la configuración del servidor principal del archivo de configuración configura el servidor principal que responde a todas aquellas peticiones que no maneja un host virtual definido dentro de un contenedor <VirtualHost>. Los valores aquí también proporcionan valores por defecto para cualquier contenedor <VirtualHost> definido.
Las directivas de esta sección han cambiado ligeramente respecto a las de la versión 1.3. Si la configuración del servidor principal está fuertemente personalizada le será fácil modificar la configuración existente para que se adapte a la versión 2.0 del Servidor Apache HTTP. Los usuarios con secciones del servidor principal ligeramente personalizadas deberían migrar sus cambios al archivo de configuración de Apache 2.0 por defecto.
10.2.2.1. Asignaciones UserDir
La directiva UserDir se usa para permitir asignaciones de URLs tales como http://example.com/~bob/ a subdirectorios dentro del directorio principal del usuario bob, tal como /home/bob/public_html. Un efecto secundario de esta característica es que un atacante potente puede determinar si un nombre de usuario está en el sistema, por esta razón la configuración por defecto para Servidor Apache HTTP 2.0 desactiva esta directiva.
Para habilitar la asignación de UserDir, cambie la directiva en httpd.conf desde:
UserDir disable |
a lo siguiente:
UserDir public_html |
Para mayor información sobre este tema, consulte la documentación en el sitio de la Apache Software Foundation, http://httpd.apache.org/docs-2.0/mod/mod_userdir.html#userdir.
10.2.2.2. Conexión
Se han eliminado las siguientes directivas de conexión:
AgentLog
RefererLog
RefererIgnore
Sin embargo, las conexiones agent y referrer estan disponibles usando las directivas CustomLog y LogFormat.
Para mayor información, consulte los siguientes sitios web de la Apache Software Foundation:
10.2.2.3. Índice de directorios
Se ha eliminado la directiva FancyIndexing. La misma funcionalidad se encuentra ahora en FancyIndexing option dentro de la directiva IndexOptions.
La nueva opción VersionSort para la directiva IndexOptions causa que los archivos conteniendo números de versiones sean ordenados de una forma más natural. Por ejemplo, httpd-2.0.6.tar aparece antes de httpd-2.0.36.tar en una página de índices de directorio.
Las directivas predeterminadas ReadmeName y HeaderName han sido cambiadas desde README y HEADER a README.html y HEADER.html.
Para mayor información sobre este tema, consulte los siguientes sitios web de la Apache Software Foundation:
10.2.2.4. Negociación de contenido
La directiva CacheNegotiatedDocs toma ahora el argumento on o off. Las instancias existentes de CacheNegotiatedDocs deberían ser cambiadas con CacheNegotiatedDocs on.
Para mayor información sobre este tema, refiérase a la documentación siguiente en los sitios web de la Apache Software Foundation:
10.2.2.5. Documentos de error
Para usar un mensaje codificado con la directiva
ErrorDocument, el mensaje tiene que aparecer en un par de
dobles comillas
Para migrar la configuración de ErrorDocument a Servidor Apache HTTP 2.0, use la siguiente estructura:
ErrorDocument 404 "The document was not found" |
Observe que se han puesto las dobles comillas en el ejemplo anterior.
Para mayor información sobre este tema, consulte la documentación siguiente en los sitios web de la Apache Software Foundation:
10.2.3. Configuración de las máquinas virtuales
Los contenidos de los contenedores <VirtualHost> se tienen que migrar de la misma manera que en la sección del servidor principal como se describió en Sección 10.2.2.
| Importante |
|---|---|
Observe que la configuración de las máquinas virtuales SSL/TLS se han quitado del archivo de configuración del servidor principal al archivo /etc/httpd/conf.d/ssl.conf. |
Para mayor información, consulte el capítulo llamado Configuración del Servidor HTTP de Apache en el Manual de personalización de Red Hat Linux y la documentación en línea en el siguiente URL:
10.2.4. Módulos y el Servidor Apache HTTP 2.0
En la versión 2.0 del Servidor Apache HTTP, el sistema de módulos se ha cambiado para permitir que los módulos se encadenen o se combinen en maneras nuevas e interesantes. Los scripts CGI (Common Gateway Interface), por ejemplo, pueden generar documentos HTML interpretados por el servidor que luego pueden ser procesados por mod_include. Esto abre una gran cantidad de posibilidades en lo que respecta a cómo los módulos pueden combinarse para llevar a cabo una meta determinada.
La forma en que esto funciona es que cada petición es servida por exáctamente un módulo handler seguido por cero o más módulos filtro.
Bajo el Servidor Apache HTTP 1.3, por ejemplo, un script PHP es manejado completamente por el módulo PHP. En la versión 2.0 del Servidor Apache HTTP, la petición la gestiona inicialmente el módulo principal — que sirve archivos estáticos — y que es luego filtrado por el módulo PHP.
Exactamente cómo se lleva esto a cabo y otras de las nuevas características del Servidor Apache HTTP 2.0, estan más allá del ámbito de este documento; sin embargo, el cambio tiene ramificaciones si ha usado la directiva PATH_INFO, que contiene información del recorrido después del nombre del archivo verdadero, en un documento que se gestiona con un módulo que se usa como filtro. EL módulo principal no entiende por defecto PATH_INFO y devuelve la petición como error 404 Not Found. Puede usar la directiva AcceptPathInfo como alternativa para obligar al módulo principal a que acepte peticiones con PATH_INFO.
A continuación se presenta un ejemplo de esta directiva:
AcceptPathInfo on |
Para mayor información sobre este tema, revise los documentos siguientes en los sitios web de la Apache Software Foundation:
10.2.4.1. El módulo mod_ssl
La configuración del módulo mod_ssl ahora está en el archivo /etc/httpd/conf.d/ssl.conf. Para cargar este archivo y hacer que mod_ssl funcione, tiene que tener la declaración Include conf.d/*.conf en httpd.conf como se describe en Sección 10.2.1.3.
Las directivas ServerName en las máquinas virtuales SSL tienen que especificar el número del puerto.
Por ejemplo, este es un ejemplo de la directiva de la versión 1.3 del Servidor Apache HTTP:
<VirtualHost _default_:443>
# General setup for the virtual host
ServerName ssl.example.name
...
</VirtualHost> |
Para migrar esta configuración a la versión 2.0, use la siguiente estructura:
<VirtualHost _default_:443>
# General setup for the virtual host
ServerName ssl.host.name:443
...
</VirtualHost> |
Para mayor información, refiérase a la documentación siguiente en los sitios web de la Apache Software Foundation:
10.2.4.2. El módulo mod_proxy
Las declaraciones de control del acceso proxy se encuentran ahora en el bloque <Proxy> en vez de en <Directory proxy:>.
La funcionalidad de caché del antiguo mod_proxy se ha dividido en tres módulos siguientes:
mod_cache
mod_disk_cache
mod_file_cache
Estos generalmente usan las mismas directivas o similares que las versiones anteriores del módulo mod_proxy.
Para mayor información, consulte los siguientes sitios web de la Apache Software Foundation:
10.2.4.3. El módulo mod_include
El módulo mod_include es ahora implementado como un filtro y por tanto se activa de una forma diferente. Consulte Sección 10.2.4 para más información sobre filtros.
Por ejemplo, a continuación se muestra una directiva del Servidor Apache HTTP 1.3:
AddType text/html .shtml AddHandler server-parsed .shtml |
Para cambiar esta configuración al Servidor Apache HTTP 2.0, use la estructura siguiente:
AddType text/html .shtml AddOutputFilter INCLUDES .shtml |
Observe que como antes, la directiva Options +Includes es aún requerida para el contenedor <Directory> o en el archivo .htaccess.
Para mayor información, consulte la documentación en los siguientes sitios web de la Apache Software Foundation:
10.2.4.4. Los módulos mod_auth_dbm y mod_auth_db
El Servidor Apache HTTP 1.3 soportaba dos módulos de autenticación, mod_auth_db y mod_auth_dbm, que usaba las bases de datos Berkeley y las DBM respectivamente. Estos módulos se han combinado en un único módulo que se llama mod_auth_dbm en el Servidor Apache HTTP 2.0, que puede acceder a las diferentes bases de datos. Para migrar desde mod_auth_db, los archivos de configuración se tienen que ajustar reemplazando AuthDBUserFile y AuthDBGroupFile con los equivalentes: mod_auth_dbm: AuthDBMUserFile y AuthDBMGroupFile. También, se debe añadir la directiva AuthDBMType DB para indicar el tipo de archivo de base de datos en uso.
El ejemplo siguiente muestra una configuración mod_auth_db de ejemplo para el Servidor Apache HTTP 1.3:
<Location /private/> AuthType Basic AuthName "My Private Files" AuthDBUserFile /var/www/authdb require valid-user </Location> |
Para migrar esta configuración a la versión 2.0 del Servidor Apache HTTP, use la estructura siguiente:
<Location /private/> AuthType Basic AuthName "My Private Files" AuthDBMUserFile /var/www/authdb AuthDBMType DB require valid-user </Location> |
Observe que la directiva AuthDBMUserFile también puede ser usada en archivos .htaccess.
El script Perl dbmmanage, usado para manipular bases de datos de nombres de usuarios y contraseñas, ha sido reemplazado por htdbm en Servidor Apache HTTP 2.0. El programa htdbm ofrece una funcionalidad equivalente y como mod_auth_dbm puede operar en una variedad de formatos de bases de datos; la opción -T se puede usar en la línea de comandos para especificar el formato a utilizar.
Tabla 10-1 muestra cómo migrar desde un formato de base de datos DBM al formato htdbm usando dbmmanage.
| Acción | comando dbmmanage (1.3) | comando equivalente htdbm (2.0) |
|---|---|---|
| Añade un usuario a la base de datos (usando la contraseña dada) | dbmmanage authdb add username password | htdbm -b -TDB authdb username password |
| Añade un usuario a la base de datos ( le pide la contraseña) | dbmmanage authdb adduser username | htdbm -TDB authdb username |
| Eliminar el usuario de la base de datos | dbmmanage authdb delete username | htdbm -x -TDB authdb username |
| Listar usuarios en la base de datos | dbmmanage authdb view | htdbm -l -TDB authdb |
| Verificar una contraseña | dbmmanage authdb check username | htdbm -v -TDB authdb username |
Tabla 10-1. Migración del dbmmanage a htdbm
Las opciones -m y -s trabajan con dbmmanage y con htdbm, permitiendo el uso de los algortimos MD5 o SHA1 para las contraseñas hashing, respectivamente.
Cuando cree una nueva base de datos con htdbm, use la opción -c.
Para mayor información, consulte los siguientes sitios web de la Apache Software Foundation:
10.2.4.5. El módulo mod_perl
La configuración del módulo mod_perl se ha pasado al archivo /etc/httpd/conf.d/perl.conf. Para cargar este archivo, y hacer funcionar mod_perl, se debe incluir la declaración Include conf.d/*.conf en el httpd.conf como se describe en Sección 10.2.1.3.
Las ocurrencias del Apache:: en el httpd.conf tienen que ser sustituídas por ModPerl::. Además se ha cambiado el modo en que los gestores se graban.
Ejemplo de configuración del módulo mod_perl en el Servidor Apache HTTP 1.3:
<Directory /var/www/perl>
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
</Directory> |
Este es el equivalente del mod_perl para el Servidor Apache HTTP 2.0:
<Directory /var/www/perl>
SetHandler perl-script
PerlModule ModPerl::Registry
PerlHandler ModPerl::Registry::handler
Options +ExecCGI
</Directory> |
La mayoría de los módulos para mod_perl 1.x deberían funcionar sin modificación con los módulos mod_perl 2.x. Los módulos XS requieren recompilación y quizás algunas modificaciones menores de Makefile.
10.2.4.6. El módulo mod_python
La configuración para mod_python ha sido movida desde httpd.conf al archivo /etc/httpd/conf.d/python.conf. Para que se cargue este archivo y por tanto funcione mod_python, se debe incluir la declaración Include conf.d/*.conf en el httpd.conf como se describe en Sección 10.2.1.3.
10.2.4.7. PHP
La configuración del PHP ha sido movida de httpd.conf al archivo /etc/httpd/conf.d/php.conf. Para cargar este archivo, tiene que tener la declaración Include conf.d/*.conf en httpd.conf tal y como se describe en Sección 10.2.1.3.
El PHP es ahora implementado como un filtro y tiene que ser habilitado en una manera diferente. Consulte la Sección 10.2.4 para mayor información.
Bajo el Servidor Apache HTTP 1.3, PHP era implementado usando las directivas siguientes:
AddType application/x-httpd-php .php AddType application/x-httpd-php-source .phps |
Bajo el Servidor Apache HTTP 2.0, utilice las directivas siguientes:
<Files *.php>
SetOutputFilter PHP
SetInputFilter PHP
</Files> |
En PHP 4.2.0 y en las versiones sucesivas, el conjunto predeterminado de las variables predefinidas que están disponibles en el ámbito global han cambiado. Las entradas individuales y las variables del servidor ya no se colocan directamente en el ámbito global. Este cambio puede hacer que se rompan los scripts. Tiene que invertir al antiguo comportamiento poniendo register_globals a On en el archivo /etc/php.ini.
Para mayor información sobre estos temas, consulte los siguientes sitios web: