PDF de programación - Tema 4 - Configuración de Servidores Web

Tema 4
Configuración de Servidores Web

En este tema vamos a ver como configurar un servidor Web. Debido a que existen varios
servidores (algunos de libre distribución y otros no), y ante al imposibilidad de poder estudiarlos
todos, hemos escogido el servidor Apache, Apache Software Fundation (http://www.apache.org),
como ejemplo de configuración. Existen varias razones: Apache es de libre distribución,
multiplataforma, heredero del original servidor de NCSA (el más extendido a mediados de los
90s) y muy completo, dándonos juego a estudiar múltiples características de configuración,
prácticamente la unión de todas las existentes.

Pero el argumento que más peso tendría en un sistema democrático es que cumple con el
requisito de tener mayoría absoluta. Esto se puede comprobar en http://www.netcraft.com/Survey
donde se puede ver el uso de distintos tipos de servidores en Internet. De todos los servidores
instalados, bastante más de la mitad son Apache, pero no sólo esto, sino que triplica
claramente a su inmediato perseguidor, los servidores web de Microsoft, que a su vez casi
triplican a la familia de servidores de Netscape.

Entre el resto de servidores que no son Apache, Microsoft o Netscape, solo vale la pena
destacar el HTTPd de W3C por tratarse precisamente de W3C, y entendiendo que este HTTPd
es un intento de implementar el estándar HTTP. Otra referencia obligatoria es el HTTPd de
NCSA (http://hoohoo.ncsa.uiuc.edu), totalmente en desuso (su equivalente ahora es Apache), que
nos sirve para poder tener una visión histórica.

Se supone que este tema va enfocado a administradores o personal autorizado para configurar
una máquina conectada a Internet, pero veremos también como ceder parte de ese control a
los propios usuarios del servidor (de una forma segura), y como estos pueden aprovecharlo.

4.1.

HTTPD

Por lo general httpd es el nombre que suele tener el servidor (Apache para windows se
invoca mediante el ejecutable apache.exe, pero esto es una excepción). Vamos a ver en este
punto de que forma, este programa, puede ser invocado.

Demonio o Angel

Respecto a cuando es invocado, existen dos estrategias: demonio o servicio inet. El modo
demonio, consiste en dejarlo permanente en memoria, atento a las peticiones HTTP que
lleguen por un puerto en concreto. Como servicio inet es cuando en la tabla de servicios existe
una entrada que determina como invocar a httpd. Inet es un demonio pendiente de varios
puertos que tiene configurados en una tabla, cuando llega una petición por un puerto de los
que tiene configurados, invoca al programa que da el correspondiente servicio. Una vez
terminado el servicio el programa termina, y no vuelve a ser invocado hasta la siguiente
petición por el puerto correspondiente.

A primera vista parece más ventajoso correr el servidor HTTP como un demonio independiente,
si el software servidor escogido nos lo permite, pues no supone un lanzamiento de un nuevo
proceso cada vez que llega una petición. La mayoría de los servidores HTTP que pueden
trabajar de esta manera mandan a subprocesos hijos atender cada una de las peticiones
HTTP, y crean un mínimo número de subprocesos que siempre están rodando, con idea de no
tener que lanzarlos en el momento de la llegada de una petición y así optimizar el tiempo de

Tema 4. Configuración de Servidores Web

respuesta. De igual manera suelen tener configurado un número máximo de peticiones a las
que poder atender a la vez, de forma la máquina no se sobrecarge y termine por venirse abajo.

En el modo servicio inet, el servidor HTTP no tiene que gestionarse como demonio, centrando
sólo sus esfuerzos en el protocolo HTTP, e ignorando cuestiones relacionadas con la
optimización y el S.O. sobre el que corre. Otra razón por la que puede interesar este segundo
sistema es porque algunos administradores de sistemas usan demonios inetd muy potentes y
seguros, algunos parcheados o adaptados por ellos mismos a sus necesidades o sus sistemas
de seguridad, de forma que el interés por que sea inetd el único demonio es casi una
necesidad.

Una última y fundamental diferencia está relacionada con el usuario como el que se comporta
el servidor. Si el servidor HTTP es lanzado por cualquier usuario, este solo puede comportarse
como tal y tendrá que trabajar puertos por encima del 1024; los menores, el 80 por ejemplo,
están reservados para el S.O., y sólo pueden ser usados por el superusuario. Por lo general,
cuando el servidor actúa como demonio, es lanzado al arrancar el S.O. por el superusuario,
para poder atender al puerto 80, y los subprocesos son lanzados como el usuario que se
indique en la propia configuración del servidor, permitiendo algunos servidores que este pueda
ser variable según circunstancias. Si es inetd el que se encarga de lanzar los subprocesos
que atienden cada una de las llamadas, éste tiene configurado en su tabla de servicios como
que usuario debe invocarlo, no importando el puerto, ya que el puerto es abierto y gestionado
por el propio proceso inetd y no por el servidor HTTP.

Como se puede intuir, servidores HTTP pueden ser varios los que se lancen en la misma
máquina, por distintos usuarios, en distintos puertos y por distintos métodos (demonio o
servicio).

HTTPD Apache

En el caso concreto del servidor Apache, este puede ser configurado como servicio inet o como
demonio independiente. A la hora de invocarlo, se puede hacer con distintos flags. Invocándolo
con el flag -? (o –h en versiones anteriores a la 1.3.3) muestra todos los flags disponibles.
Estos flags pueden también pueden ser consultados en la documentación del Apache. Apache
viene auto-documentado, esta viene por defecto en HTML en el directorio:

C:\Archivos de programa\Apache Group\Apache\htdocs\manual\

A partir de ahora esta va a ser nuestra mejor referencia siempre que hablemos en concreto del
servidor Apache. Su equivalente en la red (última actualización) es:

http://httpd.apache.org/docs/

Algunos flag interesantes son:

-d
-f
-v
-V

Especifica cual es el directorio de está instalado apache (ServerRoot).
Para especificar el fichero de configuración.
Para mostrar la versión y fecha de compilación del servidor.
Lo mismo que -v pero mostrando también con que opciones se compiló.

En el caso de windows (win32 y NT), y solo para windows:

-k start ó –s Arranca el servidor como demonio.
-k restart
-k shutdown

Para y arranca el demonio (relee el fichero de configuración).
Para el demonio.

En el caso de Windows NT, y solo Windows NT:

Instala el servidor como servicio inet (su equivalente NT).

-i

2

Tema 4. Configuración de Servidores Web

-u
-n

Desinstala como servicio inet.
Da un nombre al servicio para arrancar o pararlo (NET START <nombre>).

Como ejercicio, si usas windows, pero no NT, cambia en el menú de inicio las opciones de
instalar y desinstalar (que no tienen sentido) por una de rearrancar (más útil), para provocar
que coja los valores del fichero de configuración cuando lo cambiemos.

Módulos Apache:

Apache está construido a partir de módulos, cada uno especializado en una característica o
servicio, de forma que el servidor se pueda adaptar de una forma optima (con el mínimo código
posible) a nuestras necesidades. Por eso a la hora de compilar se puede hacer con más o
menos módulos. Al invocar al servidor con el flag –l este muestra los módulos con los que fue
compilado:

C:\Archivos de programa\Apache Group\Apache\Apache -l

Además de estos módulos, permanentemente cargados en memoria, mediante el sistema que
proporcione el S.O. (librerías compartidas o DLLs), se pueden cargar dinámicamente otros
módulos bajo demanda. Estos deben estar especificados en el fichero de configuración.

Apache puede compilarse sin ningún módulo, pero se entiende que la funcionalidad mínima la
dan una serie de módulos que se consideran básicos y con los que Apache se compila por
defecto, es decir, que para evitar tener estas funcionalidades hay que indicarlo explícitamente
en la compilación.

4.2.

Fichero de configuración

Inicialmente, Apache tenía tres ficheros de configuración distintos, encargados cada uno de
temas distintos: httpd.conf, srm.conf y access.conf. Estos
ficheros de
configuración eran leídos en este mismo orden. El primero, httpd.conf, era para determinar
como debía comportarse el servidor, con directivas del tipo donde están los ficheros de log, en
modo en el que arranca (servicio o demonio), cuantos procesos se lanzan inicialmente, etc. El
segundo, srm.conf, indicaba cuestiones relacionadas con los recursos a visualizar, tipos de
ficheros, mapeado, formas de visualizar los directorios, etc. El tercero, access.conf,
contenía directivas del tipo <Directory> que definen las autorizaciones y modos de acceso a
los recursos.

tres

En la actualidad, los tres se pueden fusionar sobre el primero, o dispersar en más de tres si se
quiere. El que sigan teniendo cada uno una responsabilidad distinta en la configuración ya no
es una exigencia, y el usuario puede mezclar directivas de distintos tipos en cada uno. La
dispersión solo tiene sentido si se van reutilizar partes de la configuración comunes a más de
un servidor en la misma máquina (o a servidores virtuales).

Otros ficheros (por defecto llamados .htaccess) pueden contener parte de la configuración.
Es el caso de que se decida ceder parte de la configuración (la relacionada con el acceso a un
recurso) al usuario propietario de ese recurso en concreto. En este caso los ficheros