Esta sección es para aquellos migrando 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 3, entonces el nuevo archivo de configuración para el paquete Servidor Apache HTTP 2.0 será 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:
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 |
La sección del entorno global del archivo de configuración contiene directivas que afectan la operación general del 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.
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 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:
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 (o en inglés, server-pool). 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 incluídos 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 directivas que en Servidor Apache HTTP 1.3, por tanto, las siguientes directivas 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 directivas aceptadas por el MPM worker son las mismas que aquellas aceptadas por el MPM prefork, los valores para esas directivas 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.
![]() | Importante | |
---|---|---|
Para utilizar el MPM worker, cree el archivo /etc/sysconfig/httpd. En el archivo añada la directiva siguiente:
|
Para mayor información sobre el tema de MPMs, consulte la documentación siguiente en el sitio web de la Apache Software Foundation:
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 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 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.
![]() | 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). |
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.
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 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.
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 dado 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, consulte los siguientes sitios web de la Apache Software Foundation:
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:
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, consulte los siguientes sitios web de la Apache Software Foundation:
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, consulte los siguientes sitios web de la Apache Software Foundation:
Para usar un mensaje codificado con la directiva ErrorDocument, el mensaje tiene que aparecer en un par de dobles comillas
Por ejemplo, el siguiente ejemplo es una directiva 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 directiva ErrorDocument del ejemplo anterior.
Para mayor información, consulte los siguientes sitios web de la Apache Software Foundation:
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 más nformació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:
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 gestionainicialmente 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 directiva 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 directiva AcceptPathInfo 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, consulte los siguientes sitios web de la Apache Software Foundation:
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 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, el siguiente ejemplo es una 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 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 directivas SSLLog y SSLLogLevel han sido eliminadas. El módulo mod_ssl obedece las directivas ErrorLog y LogLevel. Para más información sobre estas directivas, consulte la Sección 10.5.34 y la Sección 10.5.35.
Para mayor información, consulte los siguientes sitios web de la Apache Software Foundation:
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 directivas similares a las versiones anteriores del módulo mod_proxy, pero se recomienda que verifique cada directiva antes de migrar cualquier configuración caché.
Para mayor información, consulte los siguientes sitios web de la Apache Software Foundation:
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 directiva 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 como antes, la directiva Options +Includes es aún requerida para el contenedor <Directory> o en el archivo .htaccess.
Para mayor información, consulte los siguientes sitios web de la Apache Software Foundation:
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:
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 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.
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.
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 de una manera diferente. Consulte la Sección 10.2.4 para más información sobre filtros.
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 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. Cambie al antiguo comportamiento colocandoregister_globals a On en el archivo /etc/php.ini.
Para mayor información sobre estos temas, consulte los siguientes sitios web:
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 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.
![]() | Importante |
---|---|
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, el cual no está incluido con Red Hat Enterprise Linux. Consulte el sitio web de la Fundación de Software Apache en http://www.apache.org/ 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) para más información sobre la configuración del módulo mod_authz_ldap.