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.
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:
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:
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.
 | Importante |
|---|
| | 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.
| Importante |
|---|
| | Si se est� modificando el archivo original, por favor tenga en cuenta que es de suma importancia que httpd.conf contenga la directriz siguiente: 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 https://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:
a lo siguiente:
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.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:
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�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.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.
 | Nota |
|---|
| | 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.
| 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. Consulte la documentaci�n en l�nea de mod_auth_ldap en https://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 https://authzldap.othello.ch/ para m�s informaci�n sobre la configuraci�n del m�dulo mod_authz_ldap.
