Servidores virtuales con Apache

Transcripción

1 Servidores virtuales con Apache Traducción completada por los autores a partir de la traducción inconclusa de ApachES sobre el tema. Daniel Alberto Moreno Barón Francisco Fernández de Píñar López I.E.S. Al-Ándalus (ALMERÍA) 1

2 Contenidos : DOCUMENTACIÓN DE LOS SERVIDORES VIRTUALES DE APACHE 3 SOPORTE DE SERVIDORES VIRTUALES..3 DIRECTIVAS DE CONFIGURACIÓN..3 SOPORTE APACHE DE HOSTS VIRTUALES BASADOS EN NOMBRE. 3 SERVIDORES VIRTUALES BASADOS EN NOMBRE FRENTE A LOS BASADOS EN IP..3 USO DE SERVIDORES VIRTUALES SIN-IP..4 COMPATIBILIDAD CON NAVEGADORES ANTIGUOS..5 SOPORTE DE APACHE PARA SERVIDOR VIRTUAL BASADO EN IP.. 6 REQUISITOS DEL SISTEMA.6 CÓMO ACTIVARLAS EN APACHE.6 CÓMO CONFIGURAR MÚLTIPLES DEMONIOS..6 CÓMO CONFIGURAR UN SOLO DEMONIO CON HOSTS VIRTUALES..7 EJEMPLOS DE SERVIDOR VIRTUAL PARA CONFIGURACIONES COMUNES 7 CONFIGURACIÓN BASE7 CARACTERÍSTICAS ADICIONALES..8 Servidores virtuales basados en un solo nombre.8 Servidores virtuales basados en nombres más complicados..8 Servidores virtuales basados en IP.11 Servidores virtuales basados en IP y nombre.13 Servidores virtuales basados en puertos..14 Servidores virtuales usando _default_..14 Migrando un servidor virtual basado en nombre a un servidor virtual basado en IP..15 Utilizando la directiva ServerPath..16 DISCUSIÓN EN PROFUNDIDAD SOBRE CONCORDANCIA DE SERVIDORES VIRTUALES. 17 Comprobación del fichero de configuración..17 Concordancia de host virtual.20 Observaciones..21 Recomendaciones 22 2

3 Documentación de los servidores virtuales de Apache El término Host Virtual se refiere a la práctica de mantener más de un servidor en una sola máquina, así como diferenciarlos por el nombre de servidor que presentan. Por ejemplo, a menudo se desea que dos compañías que comparten un servidor de web tengan sus propios dominios, con servidores de web accesibles como y sin necesidad de que el usuario conozca más información sobre el path. Apache fue uno de los primeros servidores capaces de soportar hosts virtuales basados en IP. Las versiones 1.1 y posteriores soportan ambos host virtuales (vhost), basados en IP y basados en nombre. La última variante de host virtual se la conoce a veces como basada en host o host virtual no basado en IP. A continuación hay una lista de las páginas de la documentación, en las que se explican todos los detalles del soporte de hosts virtuales en la Versión 1.3 de Apache y posteriores. Soporte de servidores virtuales Servidores virtuales basados en nombre Servidores virtuales basados en IP Ejemplos de configuraciones habituales de servidores virtuales Estudio en detalle de la selección del servidor virtual Directivas de configuraci n <VirtualHost> NameVirtualHost ServerName ServerAlias ServerPath Para depurar la configuración de host virtual puede ser útil la opción -S en la línea de comandos. Esta opción realizará un volcado de como Apache ha analizado el fichero de configuración. El análisis atento las direcciones IP y los nombres de servidor puede ayudar a descubrir fallos en la configuración. Soporte Apache de hosts virtuales basados en nombre Servidores virtuales basados en nombre frente a los basados en IP En las primeras versiones de HTTP (como muchos otros protocolos, ej. FTP) cada host virtual en un mismo servidor necesitaba una dirección IP distinta. En algunas plataformas esto puede limitar el número de hosts virtuales que se pueden ejecutar, por cuestiones relacionadas con la disponibilidad de direcciones IP los registradores (ARIN, RIPE, y APNIC) desaconsejan decididamente su uso. 3

4 El protocolo HTTP/1.1, y una extensión muy común del HTTP/1.0, incluyen un método que permite al servidor identificar a que nombre se accede. La versión de Apache 1.1 y posteriores soportan esta solución, así como el viejo "una dirección IP por nombre de servidor". Las ventajas de usar el nuevo soporte de hosts virtuales basados en nombre son las siguientes: permite un número prácticamente ilimitado de servidores, fácil configuración y uso, y no requiere ningún software ni hardware adicional. La principal desventaja es que el cliente debe soportar esta parte del protocolo. La últimas versiones de la mayoría de los navegadores lo cumplen, pero todavía queda una pequeña cantidad de navegadores muy antiguos que no lo soportan. Esto puede causar problemas, aunque más adelante se apuntan posibles soluciones. Uso de servidores virtuales sin-ip El uso de hosts virtuales es muy sencillo, y superficialmente se asemeja al método antiguo. La diferencia más notable entre la configuración de un host virtual basado en IP y uno basado en nombre es la directiva NameVirtualHost, que especifica que IP deberá usarse como destino de los hosts virtuales basados en nombre. Por ejemplo, suponga que tanto y apuntan a la dirección IP Simplemente tiene que añadir al fichero de configuración (la mayoría de las veces algo parecido a httpd.conf o srm.conf)un código similar al que sigue: NameVirtualHost ServerName DocumentRoot /www/dominio ServerName DocumentRoot /www/otrodominio Por supuesto, cualquier otra directiva puede (y debería) situarse en la sección <VirtualHost>. Para que funcione, sólo se necesita asegurarse de que los nombres y apuntan a la dirección IP Nota: Cuando se especifica una IP en una directiva NameVirtualHost, sólo se atenderán las peticiones a dicha IP cuando coincidan con un host virtual de la lista de <VirtualHost>. El "servidor principal" nunca será atendido desde la dirección IP especificada. Si se empiezan a usar los hosts virtuales, se debe dejar de usar el "servidor principal" como servidor independiente, en su lugar se debe usar sólo para contener directivas comunes a todos los hosts virtuales. En otras palabras, todos y cada uno de los servidores (hostname) que quiera mantener, deben tener una sección <VirtualHost>. En la versión de Apache y posteriores, se puede especificar el caracter comodín * como dirección IP en NameVirtualHost, ésta será la IP utilizada por los hosts virtuales que no tengan directiva(s) más especificas. Esto es útil para configurar servidores de los que no se conoce a priori la dirección IP, 4

5 p.ejem. porque tenga la dirección IP dinámica o porque es forma parte de un cluster de carga distribuida en al que todas las máquinas comparte el mismo fichero de configuración. Además de lo dicho, muchos servidores pueden desear que se acceda a ellos por más de un nombre. Por ejemplo, el servidor anterior puede querer ser accesible tanto como domino.tld, como www2.dominio.tld, asumiendo que ambas direcciones IP apuntan al mismo servidor. De hecho, se puede desear que todos nombres tipo dominio.tld sean atendidos por el servidor. Esto puede hacerse mediante la directiva ServerAlias puesta dentro una sección <VirtualHost>. Por ejemplo: ServerAlias dominio.tld *.dominio.tld Observe que se pueden usar * y? como caracteres comodín. También puede necesitar ServerAlias si los usuarios de su servidor local no siempre incluyen el nombre del dominio. Por ejemplo, si los usuarios locales están acostumbrados a escribir "www" o " en lugar del dominio completo " entonces necesitará añadir ServerAlias www El servidor no puede saber que dominio utilizan los clientes para la resolución de nombres, porque el cliente no proporciona esta información en la petición. Generalmente, la directiva ServerAlias es un modo de permitir que distintos nombres de servidor apunten al mismo host virtual. Compatibilidad con navegadores antiguos. Como se ha mencionado antes, todavía se usan algunos programas clientes que no envían los datos necesarios para que los hosts virtuales basados en nombre funcionen correctamente. Estos clientes siempre recibirán las páginas del primer host virtual de la lista para dicha IP (el host virtual primario basado en nombre). Hay una posible solución con la directiva ServerPath, si bien es cierto que un poco pesada. Ejemplo de configuración : NameVirtualHost ServerName ServerPath /dominio DocumentRoot /web/dominio Que es lo que significa? Significa que cualquier petición a una URL que comience con "/dominio" será atendida desde el host virtual Esto quiere decir que se puede acceder a desde cualquier cliente, también podrán acceder aunque manden un Host: header Para que esto funcione, ponga un enlace en la página principal del host virtual a Después asegúrese de que en todas las páginas usan enlaces relativos 5

6 (p.ejem. "fichero.html" o "../iconos/imagen.gif") o enlaces precedidos por /dominio/ (p.ejem. " o "/dominio/misc/fichero.html"). Esto requiere un poco de disciplina, pero seguir estas normas garantiza que nuestras páginas serán visibles en todos los navegadores, viejos y nuevos. Soporte de Apache para servidor virtual basado en IP Requisitos del sistema Como indica el término basado en IP, el servidor debe tener una dirección IP distinta para cada host virtual. Esto puede lograrse en una sola máquina teniendo varias conexiones físicas de red o mediante el uso de interfaces virtuales, que soportan la mayoría de los sistemas operativos modernos (vea la documentación su sistema para más detalles, a menudo se las conoce como "ip aliases", "ifconfig" es el comando más común para activarlas). C mo activarlas en Apache Hay dos modos de configurar Apache para que soporte múltiples hosts. Una, ejecutando un demonio httpd por cada nombre de servidor, y otra, ejecutando un solo demonio que soporte todos los hosts virtuales. Use mœltiples demonios cuando: Deba separarlos por cuestiones de seguridad, tales como que la compañía1 no desee que nadie de la compañía2 sea capaz de leer sus datos si no es vía web. En este caso se necesitan dos demonios, cada uno de ellos con diferente configuración de User, Group, Listen, y ServerRoot. Pueda permitirse los requisitos de memoria y descriptores de ficheros necesarios para escuchar cada IP alias de su máquina. Sólo es posible escuchar (directiva Listen) una dirección "comodín" o una dirección particular. Así, si por cualquier razón necesita escuchar una dirección en particular, entonces necesitará escuchar cada una de las direcciones en particular. (aunque un httpd puede escuchar N-1 direcciones, y otro demonio el resto) Use un solo demonio cuando: Sea aceptable compartir la configuración del httpd en hosts virtuales. La máquina atienda muchas peticiones, en este caso mantener ejecutándose varios demonios puede disminuir significativamente el rendimiento. C mo configurar mœltiples demonios Realice una instalación separada para cada demonio. En cada instalación, use la directiva Listen en el fichero de configuración para seleccionar la dirección IP (o host virtual) a la que sirve el demonio. p.ejem. Listen Se recomienda usar la dirección IP en lugar del nombre del servidor. 6

7 C mo configurar un solo demonio con hosts virtuales En este caso, un solo demonio httpd atenderá las peticiones de servidor principal y de todos los hosts virtuales. Para definir distintos valores de las directivas ServerAdmin, ServerName, DocumentRoot, ErrorLog y TransferLog o CustomLog para distintos hosts virtuales, se utiliza en el fichero de configuración la directiva VirtualHost. Ej. <VirtualHost ServerAdmin [email protected] DocumentRoot /groups/smallco/www ServerName ErrorLog /groups/smallco/logs/error_log TransferLog /groups/smallco/logs/access_log <VirtualHost ServerAdmin [email protected] DocumentRoot /groups/baygroup/www ServerName ErrorLog /groups/baygroup/logs/error_log TransferLog /groups/baygroup/logs/access_log Se recomienda usar la dirección IP en lugar del nombre del host (vea advertencias sobre el DNS) Prácticamente cualquier directiva de configuración puede ponerse dentro de una directiva VirtualHost, con las excepciones de las que controlan la creación de procesos y unas pocas más. Para averiguar si una directiva puede usarse dentro de la directiva VirtualHost verifique su contexto buscándola en el índice de directivas. Pueden usarse User y Group dentro de una directiva VirtualHost si se usa suexec wrapper. SEGURIDAD: Cuando especifique donde escribir los ficheros log, debe ser consciente de los riesgos que supone para la seguridad que un usuario distinto al que arranca el Apache tenga permiso de escritura al mismo directorio. Vea el documento consejos de seguridad para más detalles. Ejemplos de servidor virtual para configuraciones comunes Configuraci n base Servidores virtuales basados en un solo nombre Servidores virtuales basados en nombres más complicados Servidores virtuales basados en IP Servidores virtuales basados en nombre e IP Servidores virtuales basados en puertos 7

8 Caracter sticas adicionales Utilizando la directiva _default_ vhosts Migración de un servidor virtual basado en nombre a uno basado en IP Utilizando la directiva ServerPath Servidores virtuales basados en un solo nombre Compatibilidad: Esta sintaxis se añadió en Apache Configuración: La máquina servidor tiene un nombre primario name server.domain.tld. Hay dos alias (CNAMEs) y fpara la dirección server.domain.tld. Configuraci n del servidor: Port 80 ServerName server.domain.tld NameVirtualHost * <VirtualHost *> DocumentRoot /www/domain ServerName <VirtualHost *> DocumentRoot /www/subdomain ServerName Los asteriscos representan todas las direcciones, de modo que el servidor principal no sirve ninguna petición. Debido al hecho de que está el primero en el fichero de configuración, tiene por lo tanto la más alta prioridad y puede ser visto como el servidor por defecto o primario. Servidores virtuales basados en nombres mæs complicados Configuración 1: La máquina servidor tiene una dirección IP ( ) la cual resuelve al nombre server.domain.tld. Existen dos alias (CNAMEs) y para la dirección

9 Configuraci n del servidor: Port 80 ServerName server.domain.tld NameVirtualHost DocumentRoot /www/domain ServerName DocumentRoot /www/subdomain ServerName Aparte de localhost no hay direcciones o puertos sin especificar, por tanto, el servidor principal sólo sirve peticiones a localhost. Debido al hecho de que tiene la más alta prioridad, pude ser visto como el servidor por defecto o primario. Configuración 2: La máquina servidor tiene dos direcciones IP ( y ) las cuales resuelven con los nombres server1.domain.tld y server2.domain.tld respectivamente. El alias debería ser usado para el servidor principal el cual debería además capturar cualquier dirección sin especificar. Queremos usar un servidor virtual para el alias y otro servidor virtual, con nombre de servidor debería capturar cualquier petición a los nombres de servidor del tipo *.sub.domain.tld. La dirección debería ser usada para los servidores virtuales. Configuraci n del servidor : Port 80 ServerName DocumentRoot /www/domain NameVirtualHost <VirtualHost > DocumentRoot /www/otherdomain ServerName 9

10 <VirtualHost > DocumentRoot /www/subdomain ServerName ServerAlias *.sub.domain.tld Cualquier petición a una dirección distinta de la se servirá desde el servidor principal. Una petición a con una cabecera desconocida o que no sea del tipo Host: será servida desde Configuración 3 : La máquina servidor tiene dos direcciones IP ( y ). La máquina está situada entre una red interna (intranet) y una red externa (internet). Fuera de la red, el nombre server1.domain.tld resuelve a la dirección externa ( ), pero dentro de la intranet, el mismo nombre resuelve a la dirección interna ( ). Al servidor puede hacérsele responder a peticiones internas y externas con el mismo contenido, con una sola sección VirtualHost. Configuraci n del servidor: NameVirtualHost NameVirtualHost <VirtualHost > DocumentRoot /www/server1 ServerName server1.domain.tld ServerAlias server1 Ahora las peticiones desde ambas redes se servirán desde el mismo VirtualHost Configuración 4: Usted tiene varios dominios funcionando sobre la misma IP y desea además servir múltiples puertos. Al definir los puertos en la etiqueta "NameVirtualHost", puede permitir que funcione de esa manera. Si intenta usar <VirtualHost name:port> sin la NameVirtualHost name:port o intenta usar la directiva Port, su configuración no funcionará. Configuraci n del servidor: NameVirtualHost :80 NameVirtualHost :8080 <VirtualHost :80> ServerName 10

11 DocumentRoot /www/domain-80 <VirtualHost :8080> ServerName DocumentRoot /www/domain-8080 <VirtualHost :80> ServerName DocumentRoot /www/otherdomain-80 <VirtualHost :8080> ServerName DocumentRoot /www/otherdomain-8080 Servidores virtuales basados en IP Configuración 1 : El servidor tiene dos direcciones IP ( y ) las cuales resuelven a los nombres server.domain.tld y respectivamente. El nombre del host es un alias (CNAME) para server.domain.tld y representará el servidor principal. Configuraci n del servidor: Port 80 DocumentRoot /www/domain ServerName <VirtualHost > DocumentRoot /www/otherdomain ServerName sólo se puede alcanzar a través de la dirección , mientras que sólo se puede alcanzar a través de la dirección (la cual representa nuestro servidor principal). Configuración 2: Igual que la configuración 1, pero no deseamos tener un servidor principal dedicado. 11

12 Configuraci n del servidor : Port 80 ServerName server.domain.tld DocumentRoot /www/domain ServerName <VirtualHost > DocumentRoot /www/otherdomain ServerName El servidor principal nunca puede capturar una petición, puesto que todas las direcciones IP de nuestra máquina están en uso para servidores virtuales basados en IP (sólo las peticiones a localhost pueden llegar al servidor principal). Configuración 3: La máquina servidor tiene dos direcciones IP( y ), las cuales resuelven a los nombres server.domain.tld y www-cache.domain.tld respectivamente. El nombre del host es un alias (CNAME) para server.domain.tld y representará el servidor principal. www-cache.domain.tld se convertirá en un proxy-caché escuchando por el puerto 8080, mientras que el propio servidor web usa el puerto por defecto, 80. Configuraci n del servidor : Port 80 Listen :80 Listen :8080 ServerName server.domain.tld <VirtualHost :80> DocumentRoot /www/domain ServerName <VirtualHost :8080> ServerName www-cache.domain.tld <Directory proxy:> Order Deny,Allow Deny from all 12

13 Allow from </Directory> El servidor principal nunca puede capturar una petición, puesto que todas las direcciones IP (aparte de localhost) de nuestra máquina están en uso para servidores virtuales basados en IP. El servidor WEB solo se puede alcanzar mediante la primera dirección sobre el Puerto 80 y el proxy solo en la segunda dirección por el puerto Servidores virtuales basados en IP y nombre Configuración: La máquina servidor tiene 3 direcciones IP ( , y ) las cuales resuelven a los nombres server.domain.tld, y respectivamente. La dirección debería ser usada para un par de servidores virtuales basados en nombre y las otras direcciones para servidores virtuales basados en IP. Configuraci n del servidor: Port 80 ServerName server.domain.tld NameVirtualHost DocumentRoot /www/domain ServerName DocumentRoot /www/subdomain1 ServerName DocumentRoot /www/subdomain2 ServerName <VirtualHost > DocumentRoot /www/otherdomain1 ServerName 13

14 <VirtualHost > DocumentRoot /www/otherdomain2 ServerName Servidores virtuales basados en puertos Configuración: La máquina servidor tiene una sola dirección IP ( ) las cuales resuelven al nombre Si no tenemos la opción de conseguir otra dirección u otro alias para nuestro servidor, podemos usar servidores virtuales basados en puerto si necesitamos un servidor virtual con una configuración diferente. Configuraci n del servidor : Listen 80 Listen 8080 ServerName DocumentRoot /www/domain <VirtualHost :8080> DocumentRoot /www/domain2 Una petición a sobre el Puerto 80 se sirve desde le servidor principal y una petición al Puerto 8080 se sirve desde el servidor virtual. Servidores virtuales usando _default_ Configuración 1: Capturando cada petición a cualquier IP y puerto inespecífico, por ejemplo, a cualquier combinación dirección/puerto que no es usada para cualquier otro servidor virtual. Configuraci n del servidor : <VirtualHost _default_:*> DocumentRoot /www/default Utilizando un servidor virtual con un puerto comodín, efectivamente previene que cualquier petición se dirija al servidor principal. Un servidor virtual por defecto nunca sirve una petición que hubiera sido enviada a una dirección/puerto que sea usada para servidores virtuales basados en nombre. Si la petición 14

15 no contenía ninguna cabecera Host: o era desconocida se servirá siempre desde el servidor basado en nombre que sea el primario. (el servidor virtual para la dirección/puerto que aparezca primero en el fichero de configuración). Pude usarse AliasMatch o RewriteRule para reescribir cualquier petición a una página de información o a un script. Configuración 2 : Igual que la configuiración 2, pero teniendo en cuenta que el servidor escucha en varios puertos y queremos usar un segundo servidor virtual tipo _default_ para el puerto 80. Configuraci n del servidor: <VirtualHost _default_:80> DocumentRoot /www/default80 <VirtualHost _default_:*> DocumentRoot /www/default El servidor virtual para el Puerto 80 (el cual debe aparecer antes de cualquier servidor virtual con un puerto comodín) captura todas las peticiones que fueran enviadas a una dirección IP inespecífica. En este caso, el servidor principal nunca se usa para servir una petición. Configuración 3: Queremos tener un servidor virtual para el puerto 80, pero no queremos tener otros servidores virtuales por defecto. Configuraci n del servidor : <VirtualHost _default_:80> DocumentRoot /www/default Una petición a una dirección inespecífica al Puerto 80 se servirá por el servidor virtual por defecto. Cualquier otra petición a una dirección y puerto inespecífico sera servida por el servidor principal. Migrando un servidor virtual basado en nombre a un servidor virtual basado en IP Configuración: El servidor basado en nombre con el nombre de host debería obtener su propia dirección IP. Para evitar problemas con servidores de nombres o proxys que tuvieran en su cache la dirección IP antigua para el servidor virtual basado en nombre, queremos disponer de las dos variantes durante la fase de migración. La solución es fácil, puesto que podemos sencillamente añadir la nueva dirección IP ( ) a la directiva VirtualHost. 15

16 Configuraci n del servidor : Port 80 ServerName DocumentRoot /www/domain NameVirtualHost <VirtualHost > DocumentRoot /www/otherdomain ServerName <VirtualHost > DocumentRoot /www/subdomain ServerName ServerAlias *.sub.domain.tld El servidor virtual puede ser ahora accedido a través de la nueva dirección (igual que un servidor virtual basado en IP) y a través de la antigua dirección (igual que un servidor virtual basado en nombre). Utilizando la directiva ServerPath Configuración: Tenemos un servidor con dos servidores virtuales basados en nombre. Con el fin de conectar al servidor virtual correcto, un cliente debe enviar la cabecera Host: correcta. Los antiguos clientes HTTP/1.0 no envían tal cabecera y Apache no tiene constancia de a cuál servidor virtual ha intentado conectarse el cliente (y servirá la petición desde el servidor virtual primario). Para disponer de la máxima compatibilidad possible, hay que crear un servidor virtual primario que devuelva una página sencilla conteniendo enlaces a una URL prefijo de los servidores virtuales basados en nombre. Configuraci n del servidor : NameVirtualHost # primary vhost DocumentRoot /www/subdomain RewriteEngine On RewriteRule ^/.* /www/subdomain/index.html DocumentRoot /www/subdomain/sub1 16

17 ServerName ServerPath /sub1/ RewriteEngine On RewriteRule ^(/sub1/.*) /www/subdomain$1 DocumentRoot /www/subdomain/sub2 ServerName ServerPath /sub2/ RewriteEngine On RewriteRule ^(/sub2/.*) /www/subdomain$1 Debido a la directiva ServerPath, una petición a la URL se servirá siempre desde el servidor virtual sub1. Una petición a la URL se servirá siempre desde el servidor virtual sub1 si el cliente envió una cabecera Host: correcta. If no envía una cabecera Host: correcta, el cliente obtiene la información del servidor primario. Las directivas RewriteRule se usan para asegurarse de que un cliente que haya enviado una cabecera Host: correcta pueda usar ambas variantes de la URL, es decir, con ó sin prefijo en la URL. Discusión en profundidad sobre concordancia de servidores virtuales El código de host virtuales ha sido completamente reescrito en Apache 1.3. Este documento intenta explicar qué hace exactamente Apache cuando debe decidir desde qué host virtual debe servir una petición. Con la ayuda de la nueva directiva NameVirtualHost la configuración de un host virtual es algo más fácil y seguro que con las versiones anteriores a la 1.3. Si únicamente quiere hacerlo funcionar sin entender cómo, aquí tiene algunos ejemplos. Comprobaci n del fichero de configuraci n Existe un servidor principal que consiste en todas las definiciones que están fuera de las secciones llamadas <VirtualHost>. Existen los servidores virtuales, llamados vhosts, que están definidos dentro de las secciones <VirtualHost>. Las directivas Port, ServerName, ServerPath, y ServerAlias pueden aparecer en cualquier parte dentro de la definición de un servidor. Sin embargo, cada vez que aparecen sobreescriben el valor anterior (dentro de ese servidor). El valor por defecto del campo Port para el servidor principal es 80. El servidor principal no tiene una valor por defecto para ServerPath o para ServerAlias. El valor por defecto de ServerName se obtiene de la dirección IP de los servidores. 17

18 La directiva Port del servidor principal tiene dos funciones mantenidas por compatibilidad con los ficheros de configuración de NCSA. Una de las funciones es para determinar el puerto de red por defecto al que Apache escuchará. Este valor se sobreescribe con el valor de las directivas Listen. La segunda función es para especificar el número de puerto que se usa en URIs absolutas durante las redirecciones. A diferencia del servidor principal, los puertos del host virtual NO afectan a los puertos que Apache atiende en las conexiones. Cada dirección que aparece en la directiva VirtualHost puede tener un puerto opcional. Si no se especifica, toma el valor de la declaración Port más reciente. El puerto especial * indica cualquier puerto. El conjunto completo de direcciones (incluyendo múltiples registros de tipo A búsquedas DNS) se llaman conjunto de direcciones del host virtual. A menos que se especifique una directiva NameVirtualHost para una dirección IP específica, el primer host virtual con esa dirección es tratado como un host virtual basado en IP. La versión de Apache y posteriores la dirección IP *. Si se utiliza host virtuales basados en nombre, se debe poner la directiva NameVirtualHost con la dirección IP para ese host virtual. En otras palabras; debe especificar por medio de la directiva NameVirtualHost la dirección IP que tengan los alias de host (los registros CNAMEs) de sus host virtuales basados en nombre. Se pueden utilizar múltiples directivas NameVirtualHost con un conjunto de directivas VirtualHost, pero sólo una directiva NameVirtualHost debería ser usada para cada para IP:puerto. El orden de las directivas NameVirtualHost y VirtualHost no es importante, lo quq hace que los siguientes ejemplos sean idénticos (solamente el orden de las directivas VirtualHost para un conjunto de direcciones es importante. Véalo abajo): NameVirtualHost # servidor A # servidor A <VirtualHost > # servidor C # servidor B # servidor B NameVirtualHost <VirtualHost > <VirtualHost > # servidor C # servidor D <VirtualHost > # servidor D NameVirtualHost NameVirtualHost

19 (Para mejorar la legibilidad de su fichero de configuración quizás prefiera la variante de la izquierda). Después de comprobar la directiva VirtualHost, al servidor virtual se le asigna un puerto igual al que se asignó al primer nombre en su directiva VirtualHost. La lista completa de nombre en la directiva VirtualHost es tratada como un ServerAlias (pero su valor no se sobreescribe con ninguna declaración ServerAlias) siempre que todos los nombres se resuelvan en el mismo conjunto de direcciones. Tenga en cuenta que las declaraciones Port subsiguientes para este host virtual no afectarán a los puertos asignados en el conjunto de direcciones. Durante la inicialización se genera e inserta en una tabla hash una lista para cada dirección IP. Si la dirección se utiliza en una directiva NameVirtualHost, la lista contendrá todos los host virtuales basados en nombre para esa dirección IP. Si no se definió ningún host virtual, la directiva NameVirtualHost es ignorada y se guarda un error en el fichero de logs. Si se da el caso de que se utiliza host virtual basado en IP, la tabla hash permanece vacía. Gracias a una rápida función hash, el hecho de sobrecargar una tabla hash con direcciones IP durante una petición es mínima o incluso nula. Además, la tabla está optimizada para direcciones IP que varían en su último octeto. Para cada host virtual se fijan varios valores por defecto, particularmente: 1. Si un host virtual no tiene las directivas ServerAdmin, ResourceConfig, AccessConfig, Timeout, KeepAliveTimeout, KeepAlive, MaxKeepAliveRequests, o SendBufferSize, entonces el valor respectivo se toma del servidor principal. Es decir, se hereda el último valor que tuviera en el servidor principal, cualquiera que sea. 2. La "la búsqueda de valores por defecto" que define los permisos de directorio por defecto para el host virtual se entremezclan con los que hubiera en el servidor principal. Esto incluye cualquier configuración por cada directorio para cualquier módulo. 3. Las configuraciones por servidor para cada módulo tomados del servidor principal se mezclan con el host virtual. Básicamente, el servidor principal es tratado como "por defecto" o como "base" sobre el que se levanta cada host virtual. Sin embargo, la posición de las definiciones en el fichero de configuración del servidor principal es totalmente irrelevante; el fichero de configuración es "parseado" (chequeado) una vez que la "mezcla" de valores se haya llevado a cabo. Así que, si una definición en el servidor principal aparece después de una definición en el host virtual, podría afectar a la definición del host virtual. Si el principal no tiene ningún ServerName, se usará el nombre de host de la máquina sobre la que httpd esté corriendo. Llamaremos a las direcciones devueltas por una búsqueda en DNS que aparecen en ServerName del servidor principal conjunto de direcciónes del servidor principal. Para cualquier campo ServerName no definido, el host virtual basado en nombre toma como valor por la primera dirección proporcionada por la declaración VirtualHost que define el host virtual. A cualquier host virtual que incluya _default_ se le da el mismo ServerName que el servidor principal. 19

20 Concordancia de host virtual Para una petición dada, el servidor determina qué host virtual usar de este modo: Bœsqueda en una tabla hash Cuando el cliente realiza la primera conexión, la dirección IP a la que el cliente conectó se busca en la tabla hash interna. Si la búsqueda no tiene éxito (no se encontró la la dirección IP), la petición se sirve desde el host virtual _default_, siempre que éste exista para el puerto al que el cliente envió la petición. Si esto último tampoco ha tenido éxito, la petición se sirve desde el servidor principal. En Apache y versiones posteriores, si la dirección IP no se encuentra en la tabla hash, pero sí concuerda el puerto, puede dar como resultado una entrada correspondiente a un NameVirtualHost *, que es entonces manejado como cualquier otro host virtual basado en nombre. Si la búsqueda tuvo éxito (se encontró una entrada para la dirección IP), el siguiente paso consiste en decidir si hay que tratar con un host virtual basado en IP o basado en nombre. Host virtual basado en nombre Si la entrada que se ha encontrado tiene una lista de nombres vacía, entonces significa que tenemos un host virtual basado en IP, por lo que no se realiza ninguna otra acción y la petición se sirve desde ese host virtual. Host virtual basado en nombre Si la entrada corresponde a un host virtual basado en nombre, la lista de nombres contendrá una o más estructuras de host virtuales. Esta lista contiene los host virtuales en el mismo orden en que aparecen en las directivas VirtualHost del fichero de configuración. El primer host virtual de esta lista (el primer host virtual en el fichero de configuración con la dirección IP especificada) tiene la más alta prioridad y se "apodera" de cualquier petición a un servidor desconocido o de cualquier petición sin el campo de cabecera Host:. Si el cliente proporciona un campo de cabecera Host:, entonces se busca en la lista una concordancia de un host virtual y se toma la primera ocurrencia en ServerName o ServerAlias, siendo la petición servida desde ese host virtual. Un campo de cabecera Host: puede contener un número de puerto, pero Apache siempre busca la concordancia contra el puerto real al que el cliente envió la petición. Si el cliente envió una petición HTTP/1.0 sin el campo Host:, no sabríamos a qué servidor intenta conectar, por lo que cualquier ServerPath concordará con el URI de la petición. De este modo, la primera concordancia en la lista será la usada y la petición será servida desde ese host virtual. Si no se pudo encontrar ningún host virtual que concuerde, la petición será servida por el primer host virtual cuyo puerto coincida en la lista con la IP a la que el cliente conectó, tal y como se mecionó antes. Conexiones persistentes El modo de búsqueda descrito arriba se realiza solamente una vez por cada sesión TCP/IP, mientras que la búsqueda de nombre se realiza por cada petición en una conexión persistente. En otras palabras, un 20

21 cliente puede pedir páginas desde diferentes host virtuales basados en nombre durante una única conexión persistente. URL absoluto Si la URL de una petición es absoluto y su nombre de host y puerto coiciden con el el servidor principal o uno de los host virtuales configurados y además coincide con la dirección y puerto al que el cliente envió la petición, entonces se quita el prefijo esquema/nombre host/puerto y la URL restante se sirve por el correspondiente servidor principal o host virtual. Si no concuerda, la URL permanece intacto y la petición se considera como una petición de proxy. Observaciones Un host virtual basado en nombre nunca puede interferir con un host virtual basado en IP y viceversa. Sólo se puede llegar a un host basado en IP a través de una IP de su propio conjunto de direcciones y nunca a través cualquier otra dirección. Lo mismo se aplica a host virtuales basados en nombre; sólo se puede llegar a ellos a través de direcciones IP de su conjunto de direcciones correspondiente, que debe ser definido con una directiva NameVirtualHost. Nunca se hacen chequeos a ServerAlias y ServerPath para host virtuales basados en IP. El orden de host virtuales basados en nombre/ip, _default_ y la directiva NameVirtualHost dentro del fichero de configuración no es importante. Sólo el orden de un host virtual basado en nombre para un conjunto específico de direcciones es importante. El host virtual basado en nombre que esté primero en el fichero de configuración tiene la más alta prioridad para su conjunto de direcciones. Por razones de seguridad el número de puerto pasado en el campo Host: no se usa nunca en el proceso de concordancia. Apache siempre usa el puerto real al que el cliente envió la petición. Si existe una directiva ServerPath que sea prefijo de otra directiva ServerPath que aparezca más tarde en el fichero de configuración, entonces la concordancia será contra el primero y nunca con el segundo. Esto es así asumiendo que el campo de cabecera Host: esté presente para evitar ambigûedades. Si dos host virtuales basados en IP comparten una dirección, el que aparezca primero en el fichero de configuración será con el que se concuerde. Esto puede ocurrir sin que se dé cuenta. El servidor mostrará un mensaje de aviso en el fichero de logs cuando detecte esto. Un host virtual _default_ toma una petición solamente si no hay ningún otro host virtual que coincida con la dirección IP y el número de puerto de la petición. Sólo se toma la petición si el número de puerto al que el cliente envió la petición coincide con el número de puerto de del servidor virtual _default_ que sea el Port estándar por defecto. Se puede usar un carácter comodín (por ejemplo _default_:*) para tomar peticiones a cualquier puerto disponible. En Apache y posteriores esto también sirve para host virtuales NameVirtualHost *. El servidor principal sólo se utiliza para servir peticiones cuando la dirección IP y número de puerto al que el cliente conecta no está especificado y no coincide con ningún otro host virtual (incluyendo una host virtual _default_). En otras palabras, el servidor principal solo coge peticiones para combinaciones dirección/puerto sin especificar (a menos que haya un host virtual _default_ que concuerde con ese puerto). 21

22 Nunca un host virtual _default_ o el servidor principal concuerdan con una petición que no tenga el campo Host: (o este no sea válido) cuando el cliente conectó con una dirección y puerto que sea usado por un host virtual basado en nombre, como en una directiva NameVirtualHost. Nunca debería especificar nombres DNS en las directivas VirtualHost porque forzará a su servidor a confiar en DNS para arrancar. Más aún, es una amenaza a la seguridad si no controla el DNS para todos los dominios listados. Puede encontrar más información sobre esto en los siguientes apartados. Debería fijar siempre un ServerName para cada host virtual. De otro modo se requerirá una consulta a DNS por cada host virtual. Recomendaciones Además de las recomendaciones sobre cuestiones relacionadas con DNS, aquí tiene algunas otras: Procure poner todas las definiciones que tengan que ver con el servidor principal antes de las definiciones de VirtualHost. Esto ayudará a la legibilidad de la configuración. Agrupe las definiciones correspondientes en NameVirtualHost y VirtualHost para mejorar la legibilidad del fichero de configuración. Evite ServerPaths que son prefijos de otros ServerPaths. Si no puede evitarlos, asegúrese de que el más largo prefijo (más específico) del host virtual aparezca antes en el fichero de configuración que el más corto (menos específico). Por ejemplo, "ServerPath /abc" debería aparecer después de "ServerPath /abc/def". 22