10.2. Migración de los archivos de configuración de la versión del Servidor Apache HTTP 1.3

Esta sección detalla la migración de un archivo de configuración Servidor Apache HTTP 1.3 para ser utilizado por Servidor Apache HTTP 2.0.

Si está actualizando desde Red Hat Enterprise Linux 2.1 al Red Hat Enterprise Linux 4, tenga en cuenta que el nuevo archivo de configuración para el paquete Servidor Apache HTTP 2.0 es instalado como /etc/httpd/conf/httpd.conf.rpmnew y no se toca la versión original 1.3 httpd.conf. 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.

Si el archivo /etc/httpd/conf/httpd.conf es una versión modificada de la versión por defecto recién instalada y ha guardado una copia del original, entonces le será más fácil invocar el comando diff, como se muestra a continuación (conectándose como root):

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 directrices que afectan la operación general del Servidor Apache HTTP como por ejemplo el número de peticiones que puede manejar al mismo tiempo y las ubicaciones de varios archivos que usa. Esta sección requiere un gran número de cambios 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. Interfaces y vinculación de puertos

Ya no existen las directrices BindAddress y Port; porque quedan recogidas en la directriz 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 directriz ServerName.

Por ejemplo, el siguiente ejemplo es una directriz de la versión 1.3 del Servidor Apache HTTP:

Port 123
ServerName www.example.com

Para cambiar esta configuración al Servidor Apache HTTP 2.0, use la estructura siguiente:

Listen 123
ServerName www.example.com:123 

Para mayor información, consulte los siguientes sitios web de la Apache Software Foundation:

10.2.1.2. Regulación del tamaño del pool de servidores

Cuando el Servidor Apache HTTP acepta peticiones, este despacha procesos hijo o hilos para que las manejen. Este grupo de procesos o hilos es conocido como un pool de servidores. Bajo el Servidor Apache HTTP 2.0, se ha abstraído la responsabilidad de crear y mantener estos pool de servidores a un grupo de módulos llamados Módulos de procesos múltiples (MPMs). A diferencia de otros módulos, el Servidor Apache HTTP solamente puede cargar un módulo del grupo MPM. Hay tres módulos MPM incluidos con la versión 2.0: prefork, worker y perchild. Actualmente, únicamente están disponibles los MPMs prefork y worker, pero perchild estará disponible más adelante.

El MPM prefork tiene el mismo comportamiento de Servidor Apache HTTP 1.3. El MPM prefork acepta las mismas directrices que en Servidor Apache HTTP 1.3, por tanto, las siguientes directrices se pueden migrar directamente:

  • StartServers

  • MinSpareServers

  • MaxSpareServers

  • MaxClients

  • MaxRequestsPerChild

El MPM worker implementa un servidor multi-proceso y multi-hilos proporcionando una gran escalabilidad. Cuando este utilizando este MPM, las peticiones son manejadas por hilos, conservando recursos del sistema y permitiendo servir grandes números de peticiones de forma eficiente. Aún cuando algunas de las directrices aceptadas por el MPM worker son las mismas que aquellas aceptadas por el MPM prefork, los valores para esas directrices no deberían ser transferidos directamente desde una instalación del Servidor Apache HTTP 1.3. Es mejor utilizar los valores por defecto como una guía y luego experimentar para determinar los valores que funcionan mejor.

ImportanteImportante
 

Para utilizar el MPM worker, cree el archivo /etc/sysconfig/httpd y añada la directriz siguiente:

HTTPD=/usr/sbin/httpd.worker

Para mayor información sobre el tema de MPMs, consulte la documentación siguiente 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 adaptarse a la versión 2.0 (al contrario de migrar los cambios en la configuración de la versión 2.0) copie esta sección del archivo de configuración del 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 directrices AddModule y ClearModuleList ya no existen. Estas directrices 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 directrices.

  • El orden de las líneas LoadModule ya no es relevante en la mayoría de los casos.

  • 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 sus propios RPMs (mod_ssl, php, mod_perl y similares) ya que se pueden encontrar en sus archivos relevantes dentro del directorio /etc/httpd/conf.d/.

  • Las definiciones HAVE_XXX ya no existen.

ImportanteImportante
 

Si se está modificando el archivo original, por favor tenga en cuenta que es de suma importancia que httpd.conf contenga la directriz siguiente:

Include conf.d/*.conf

La omisión de esta directriz 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 directrices 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 directriz es irrelevante.

  • AccessConfig y ResourceConfig — Se han eliminado estas directrices porque su funcionalidad aparece ya en la directriz Include. Si las directrices AccessConfig y ResourceConfig son configuradas, entonces reemplácelas por las directrices Include.

    Para asegurarse que estos archivos se lean en el orden de las antiguas directrices, las directrices 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 directrices utilizadas en esta sección han cambiado ligeramente respecto a las de la Servidor Apache HTTP versión 1.3. Si la configuración del servidor principal está fuertemente personalizada, le será más fácil modificar el archivo de 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 2.0 por defecto.

10.2.2.1. Asignaciones UserDir

La directriz 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 dado está en el sistema; por esta razón la configuración por defecto para Servidor Apache HTTP 2.0 desactiva esta directriz.

Para habilitar la asignación de UserDir, cambie la directriz en httpd.conf desde:

UserDir disable

a lo siguiente:

UserDir public_html

Para mayor información, consulte los siguientes sitios web de la Apache Software Foundation:

10.2.2.2. Conexión

Se han eliminado las siguientes directrices de conexión:

  • AgentLog

  • RefererLog

  • RefererIgnore

Sin embargo, las conexiones agent y referrer estan disponibles usando las directrices 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 directriz FancyIndexing. La misma funcionalidad se encuentra ahora en FancyIndexing option dentro de la directriz IndexOptions.

La opción VersionSort para la directriz 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 directrices predeterminadas ReadmeName y HeaderName han sido cambiadas desde README y HEADER a README.html y HEADER.html.

Para mayor información, consulte los siguientes sitios web de la Apache Software Foundation:

10.2.2.4. Negociación de contenido

La directriz CacheNegotiatedDocs toma ahora el argumento on o off. Las instancias existentes de CacheNegotiatedDocs deberían ser cambiadas con CacheNegotiatedDocs on.

Para mayor información, consulte los siguientes sitios web de la Apache Software Foundation:

10.2.2.5. Documentos de error

Para usar un mensaje codificado con la directriz ErrorDocument, el mensaje tiene que aparecer en un par de dobles comillas ["], en vez de estar simplemente precedido por las comillas como en el Servidor Apache HTTP 1.3.

Por ejemplo, el siguiente ejemplo es una directriz de la versión 1.3 del Servidor Apache HTTP:

ErrorDocument 404 "The document was not found

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 las dobles comillas en la directriz ErrorDocument del ejemplo anterior.

Para mayor información, consulte los siguientes sitios web de la Apache Software Foundation:

10.2.3. Configuración de host 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.

ImportanteImportante
 

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 más información sobre este tópico, consulte el capítulo llamado Configuración del Servidor Seguro HTTP de Apache en el Manual de administración del sistema de Red Hat Enterprise 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 Perl es manejado completamente por el módulo Perl (mod_perl). 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 mod_perl.

Exactamente cómo utilizar esto 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 directriz PATH_INFO para un documento que es gestionado por un módulo que es ahora implementado como un filtro, pues cada uno contiene información del recorrido del nombre del archivo verdadero. El módulo principal, que inicialmente manejaba la petición, no entiende por defecto PATH_INFO y devuelve el error 404 Not Found para las peticiones que contienen dicha información. Como alternativa, puede utilizar la directriz AcceptPathInfo para obligar al módulo principal a que acepte peticiones con PATH_INFO.

A continuación se presenta un ejemplo de esta directriz:

AcceptPathInfo on

Para mayor información, consulte los siguientes sitios web de la Apache Software Foundation:

10.2.4.1. El módulo suexec

En el Servidor Apache HTTP 2.0, el módulo mod_suexec utiliza la directriz SuexecUserGroup, en vez de las directrices User y Group, la cual es utilizada para la configuración de hosts virtuales. Las directrices User y Group también se pueden utilizar, pero no para la configuración de hosts virtuales.

Por ejemplo, el siguiente ejemplo es una directriz de la versión 1.3 del Servidor Apache HTTP:

<VirtualHost vhost.example.com:80>
    User someone
    Group somegroup
</VirtualHost>

Para cambiar esta configuración al Servidor Apache HTTP 2.0, use la estructura siguiente:

<VirtualHost vhost.example.com:80>
    SuexecUserGroup someone somegroup
</VirtualHost>

10.2.4.2. El módulo mod_ssl

La configuración para mod_ssl se ha cambiado desde httpd.conf al 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 la Sección 10.2.1.3.

Las directrices ServerName en las máquinas virtuales SSL tienen que especificar el número del puerto.

Por ejemplo, el siguiente ejemplo es una directriz 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 cambiar esta configuración al Servidor Apache HTTP 2.0, use la estructura siguiente:

<VirtualHost _default_:443>
    # General setup for the virtual host
    ServerName ssl.host.name:443
    ...
</VirtualHost>

También es importante tener en cuenta que ambas directrices SSLLog y SSLLogLevel han sido eliminadas. El módulo mod_ssl obedece las directrices ErrorLog y LogLevel. Para más información sobre estas directrices, consulte la Sección 10.5.35 y la Sección 10.5.36.

Para mayor información, consulte los siguientes sitios web de la Apache Software Foundation:

10.2.4.3. 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_mem_cache

Estos generalmente usan directrices similares a las versiones anteriores del módulo mod_proxy, pero se recomienda que verifique cada directriz antes de migrar cualquier configuración caché.

Para mayor información, consulte los siguientes sitios web de la Apache Software Foundation:

10.2.4.4. 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 la Sección 10.2.4 para más información sobre filtros.

Por ejemplo, el siguiente ejemplo es una directriz de la versión 1.3 del Servidor Apache HTTP:

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 la directriz Options +Includes aún es requerida para el contenedor <Directory> o en el archivo .htaccess.

Para mayor información, consulte los siguientes sitios web de la Apache Software Foundation:

10.2.4.5. 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 diferentes formatos de 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 directriz 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 directriz 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óncomando 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 passwordhtdbm -b -TDB authdb username password
Añade un usuario a la base de datos ( le pide la contraseña)dbmmanage authdb adduser usernamehtdbm -TDB authdb username
Eliminar el usuario de la base de datosdbmmanage authdb delete usernamehtdbm -x -TDB authdb username
Listar usuarios en la base de datosdbmmanage authdb viewhtdbm -l -TDB authdb
Verificar una contraseñadbmmanage authdb check usernamehtdbm -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.6. El módulo mod_perl

La configuración del módulo mod_perl se ha pasado del httpd.conf 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 la 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 se registran los manejadores.

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
    PerlResponseHandler ModPerl::Registry
    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.7. 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, que funcione mod_python, se debe incluir la declaración Include conf.d/*.conf en el httpd.conf como se describe en la Sección 10.2.1.3.

10.2.4.8. 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 la Sección 10.2.1.3.

NotaNota
 

Cualquier directriz de configuración PHP en Servidor Apache HTTP 1.3 son ahora completamente compatibles, cuando se migra a Servidor Apache HTTP 2.0 en Red Hat Enterprise Linux 4.

En PHP 4.2.0 y posterior, el conjunto predeterminado de variables predefinidas que están disponibles en el ámbito global, han cambiado. Las entradas individuales y las variables del servidor, por defecto, ya no se colocan directamente en el ámbito global. Este cambio puede hacer que se rompan los scripts. Cámbiese al antiguo comportamiento colocando register_globals a On en el archivo /etc/php.ini.

Para mayor información sobre estos temas, consulte los siguientes sitios web:

10.2.4.9. El módulo mod_authz_ldap

Red Hat Enterprise Linux se entrega con el módulo mod_authz_ldap para el Servidor Apache HTTP. Este módulo utiliza la forma corta del nombre distinguido para un sujeto y el emisor del certificado de cliente SSL para determinar el nombre distinguido de un usuario dentro de un directorio LDAP. También es capaz de autorizar usuarios basado en los atributos de esa entrada del usuario del directorio LDAP, determinando el acceso a los activos basado en los privilegios de usuario y grupo de ese activo y negando el acceso a los usuarios con contraseñas caducadas. Se requiere el módulo mod_ssl cuando se utilice el módulo mod_authz_ldap.

ImportanteImportante
 

El módulo mod_authz_ldap no valida un usuario a un directorio LDAP usando un hash de contraseña encriptada. Esta funcionalidad es proporcionada por el módulo experimental mod_auth_ldap. Consulte la documentación en línea de mod_auth_ldap en http://httpd.apache.org/docs-2.0/mod/mod_auth_ldap.html para más detalles sobre el estatus de este módulo.

El archivo /etc/httpd/conf.d/authz_ldap.conf configura al módulo mod_authz_ldap.

Consulte el /usr/share/doc/mod_authz_ldap-<version>/index.html (reemplazando <version> con el número de versión del paquete) o http://authzldap.othello.ch/ para más información sobre la configuración del módulo mod_authz_ldap.