laboratorio de arquitectura de redes de comunicaciones

Universidad Politécnica de Cartagena
Escuela Técnica Superior de Ingeniería de
Telecomunicación
PRÁCTICAS DE ARQUITECTURAS
DISTRIBUIDAS
Práctica 1: SERVIDOR APACHE, HTTP
Y DOCUMENTOS HTML
Profesores:
Javier Vales Alonso
Esteban Egea López
Natalio López Martínez
1
1. OBJETIVOS
•
•
•
•
•
•
Comprender el funcionamiento de un servidor HTTP.
Comprender cómo se organizan los documentos en un servidor web.
Dotar de mecanismos de control de acceso al servidor.
Entender la estructura, la sintaxis y los elementos que componen una página
HTML.
Comprender la interrelación de HTML con HTTP y URL en la arquitectura del
WWW.
Interpretar HTML como aplicación de SGML.
2. INTRODUCCIÓN
Un servidor HTTP o servidor web es una aplicación que se encarga de servir contenidos
usando el protocolo HTTP (Hyper Text Mark-up Language). El servidor acepta
peticiones del cliente y devuelve los documentos HTML apropiados. Hay, además, una
serie de tecnologías complementarias que se encargan de aumentar la capacidad del
servidor más allá de su habilidad para entregar páginas HTML estándar, como son CGI
(Common Gate Interface), SSI (Server Side Includes) o PHP (Hypertext Preprocessor),
permitiendo dotar de contenido dinámico a los documentos HTML.
El servidor Apache (http://www.apache.org) ha sido el servidor web más popular desde
1996, actualmente se utiliza en más del 50% de los sitios web en Internet. Es una
aplicación software de libre distribución que implementa un servidor HTTP, disponible
para varios sistemas operativos, fundamentalmente UNIX, aunque hay versiones para
Windows NT. El código fuente está disponible.
Aunque hay una implementación para Windows NT, el servidor Apache está pensado y
diseñado para UNIX. Además, en estas prácticas se usará Linux, así que se describirá su
funcionamiento en un entorno UNIX.
Apache es un proceso que se ejecuta en un entorno UNIX. Es un "demonio" que se
ejecuta en segundo plano y está continuamente escuchando el puerto 80, al menos en su
configuración por defecto, esperando a atender peticiones HTTP.
Apache 1.3 es un servidor web "pre-forking", lo que quiere decir que hay un único
proceso de control responsable de lanzar varios procesos "hijos", los cuales se encargan
de escuchar un puerto determinado (habitualmente el 80) y atender peticiones. Apache
se encarga de mantener más de un proceso servidor (procesos "idle"), atentos a las
peticiones, de esta manera hay varios procesos listos para servir y se evita el tener que
crear nuevos hijos cada vez que llega una petición.
El funcionamiento es el siguiente: cuando se ejecuta Apache, se crea un proceso padre,
de control, que atiende peticiones al puerto 80. Este lanza varios procesos hijos que se
encargan de escuchar en ese mismo puerto y atender peticiones.
2
El funcionamiento de estos procesos y las reglas que tienen que aplicar a las peticiones
vienen determinados por unas directivas que se incluyen en un fichero de
configuración. Estas directivas determinan, entre otras cosas, los directorios en los que
se encuentran los documentos que van a ser servidos, el control de acceso que se le
aplicará a las peticiones, etc.
Es conveniente conocer el usuario bajo el cual se ejecutan los procesos y los privilegios
que tiene. El proceso padre se ejecuta como root puesto que se tiene que unir (bind) al
puerto 80, que es un puerto privilegiado en UNIX. Sin embargo, los procesos hijos se
ejecutan bajo un usuario menos privilegiado (normalmente el usuario www-data), para
evitar que un proceso con privilegios de root atienda peticiones que llegan a través de la
red.
Las directivas del fichero de configuración que establecen los privilegios de los usuarios
hijos de Apache. De esta manera, el proceso padre cuando crea los hijos les asigna el
usuario www-data, el cual prácticamente no tiene privilegios sobre los recursos del
sistema. Los procesos hijos tienen que tener permiso para leer los contenidos que se van
a servir pero ninguno más aparte de estos.
Los privilegios que establecen las anteriormente mencionadas directivas son también
los que heredarán los scripts CGI, así que las llamadas al sistema y a los recursos que
utilice el código de los scripts se ejecutarán con muy pocos privilegios.
En conclusión, el servidor Apache es un "demonio" que se ejecuta con privilegios de
root y se asigna al puerto 80. Una vez hecho esto, crea varios procesos hijos con los
privilegios de un usuario www-data, que se quedan escuchando el puerto 80 y atienden
las peticiones, sirviendo aquellos documentos para los cuales el usuario www-data tenga
privilegios de lectura.
Las peticiones se realizan mediante el protocolo HTTP. Es decir, el cliente le envía al
servidor un mensaje del tipo:
GET /index.html HTTP/1.0
Este mensaje le indica al servidor (uno de los procesos “hijo”) que le solicitan el
documento index.html que se encuentra en el directorio raíz de los documentos. Una
cuestión que surge inmediatamente es: ¿Cuál es el directorio raíz?
El directorio raíz es el lugar en el que se encuentran los documentos HTML que puede
servir el sitio. En el se encuentra el árbol de directorios con documentos disponibles.
Una petición del tipo www.midominio.com/index.html significa que se le está pidiendo
al sitio el documento index.html que se encuentra en el directorio raíz.
Mientras que una petición del tipo www.midominio.com/usuario/index.html, le solicita
el documento index.html que se encuentra en el directorio usuario, que a su vez estará
en el raíz.
El directorio raíz puede ser cualquier directorio de la máquina sobre la que se ejecuta
Apache. En el fichero de configuración hay una directiva (DocumentRoot) que indica
este directorio. Por ejemplo, si el valor de esta directiva es /usr/doc/htdocs, el proceso
servidor buscará un fichero llamado index.html en este directorio. Si este documento se
3
encuentra en este directorio, lo devolverá al cliente, con lo que habrá completado la
petición. En caso contrario devolverá un mensaje de error.
Toda la información relativa al servidor Apache se puede encontrar en:
http://httpd.apache.org/docs/
3. DESARROLLO DE LA PRÁCTICA
3.1 Configuración del servidor
En la práctica, la mayoría de las distribuciones de Linux incluyen Apache y lo instalan
junto con el resto del sistema operativo. La diferencia entre distribuciones es la ruta
dónde se instalan los archivos. Por ejemplo, en Debian, los archivos de configuración se
guardan en el directorio /etc/apache/.
En la práctica utilizaremos la instalación de Apache que proporciona Debian.
Una vez instalado el servidor, hay que configurar su funcionamiento. Apache se
configura mediante un único fichero de texto. Estos ficheros incluyen órdenes, llamadas
directivas, que especifican el modo de funcionamiento del servidor. Cada directiva
especifica el funcionamiento de una característica del servidor. Cada directiva tiene a su
vez una serie de opciones. El servidor, al iniciarse, lee el fichero de configuración,
establece su modo de funcionamiento de acuerdo con ellos y espera a que le lleguen
peticiones. Los ficheros de configuración sólo son leídos al iniciar el servidor, por ello,
si se modifica alguna directiva, hay que parar el servidor y volver a reiniciarlo para
que surtan efecto las modificaciones.
El fichero de configuración se encuentra en el directorio /etc/apache/ y se llama
httpd.conf. Estos ficheros contienen la configuración por defecto del servidor.
Antes de seguir adelante: HAGA UNA COPIA DE SEGURIDAD antes de modificar
alguno de estos ficheros. De ese modo siempre podrá recuperar los cambios. Si en algún
momento modificamos algo en los ficheros de configuración que perjudica el
funcionamiento del servidor, siempre podemos recurrir a estos ficheros que guardan la
configuración por defecto del servidor, para restaurar los cambios.
Las directivas que configuran el funcionamiento del servidor se encuentran en este
fichero que es leído por el servidor cada vez que se inicia. Cualquier modificación que
se haga en ellos afecta al funcionamiento del servidor. Los usaremos para configurar el
servidor a nuestro gusto.
Abra en httpd.conf con un editor de texto. Así podrá hacerse una idea de las directivas
del servidor.
Como puede comprobar el fichero httpd.conf consiste en una serie de líneas de texto,
algunas de las cuales están precedidas por el carácter #. Este carácter sirve para hacer
comentarios, el servidor no tiene en cuenta lo que aparece detrás de ellas. El resto son
directivas de Apache. El fichero incluye una amplia descripción de cada directiva, lo
cual le será muy útil.
4
Además de directivas, aparecen los contenedores. Estos se diferencian de las directivas
en que aparecen entre los caracteres <>. Un contenedor sirve para definir un contexto
de aplicación de las directivas. Por ejemplo, el contenedor <Directory
“/var/www/user”> indica que todos las directivas que aparecen entre el inicio y el final
(</Directory>) se aplican sólo a ese directorio.
En la dirección http://httpd.apache.org/docs/mod/index.html encontrará una lista de las
directivas de Apache. Allí se incluye una descripción de las mismas, así como de las
opciones que se le pueden aplicar y del contexto en el que se usan.
La sintaxis es muy importante, así que utilice la dirección anterior para comprobar que
ha escrito correctamente una directiva si tiene dudas. Los espacios en blanco, así como
los saltos de línea y los retornos de carro no son tenidos en cuenta, por lo que puede
usarlos para mejorar la legibilidad cuando modifique el fichero.
Antes de empezar a modificar el fichero httpd.conf, hablaremos sobre una cuestión
relativa a la seguridad.
Permisos para los directorios de Apache
El directorio /var/www, es el directorio raíz, es decir, es donde están los documentos
que pueden ser servidos, puede ser modificable por otros usuarios.
Los documentos HTML que coloque allí deben poder ser leídos por otros usuarios
aparte de root ya que, como hemos dicho anteriormente, los procesos hijos creados por
Apache, se ejecutan como www-data. Entonces, el usuario de www-data debe poder
tener como mínimo permiso de lectura.
Configuración del entorno
Para configurar el entorno, empezaremos a modificar httpd.conf. Habitualmente con la
configuración por defecto el servidor ya puede funcionar perfectamente.
El fichero httpd.conf está dividido en tres secciones:
• Sección 1. Configuración del entorno. Directivas relacionadas con parámetros del
propio servidor.
• Sección 2. Servidor principal. Directivas que controlan el acceso a los documentos
servidos.
• Sección 3. Virtual hosts. Directivas que afectan a servidores virtuales, si se crearan.
En nuestro caso no los crearemos así que no habrá que modificarla.
Las directivas de la Sección 1 configuran aspectos de rendimiento de Apache. EN
ESTA PRÁCTICA NO SE MODIFICARÁN. A título informativo, le resumimos las
más importantes.
ServerType. Afecta a como se ejecuta el servidor. Antes había dos posibles modos de
funcionamiento, hoy en día solo se usa el modo por defecto: standalone.
ServerRoot. Indica el directorio raíz de Apache, dónde se encuentra el ejecutable
principal.
5
Timeout, KeepAlive, MaxKeepAliveRequests, KeepAliveTimeout. Sirven para configurar
el rendimiento servidor. En principio las dejaremos por defecto. Habría que ver como
rinde el servidor en un entorno real para ajustar estos parámetros.
MinSpareServers, MaxSpareServers, StartServers, MaxClients, MaxRequestsPerChild.
Estas directivas son las que regulan el tamaño de los recursos consumidos por Apache.
Controlan cuantas instancias del servidor (hijos) se crearán para atender peticiones, el
número máximo de conexiones que se aceptarán, etc. Apache trata de adaptarse a las
condiciones, creando y eliminando hijos en función de las condiciones, manteniéndose
dentro de los parámetros indicados. Se trata de equilibrar el consumo de memoria y
CPU con el rendimiento en número y rapidez de peticiones atendidas. En general, la
configuración por defecto es aceptable. Lo que hay que hacer es observar las
condiciones del servidor e ir variándolos para adaptarse.
Como ha podido observar, es mejor dejar la configuración por defecto para el entorno
de Apache. Hay que elaborar estadísticas de funcionamiento del servidor (número
máximo de peticiones concurrentes, tiempo necesario para establecer una conexión,
consumo de recursos del procesador, etc.) y actuar en consecuencia para corregir.
Servidor principal
El siguiente grupo de directivas regula el funcionamiento del servidor principal. El
concepto de servidor principal aparece porque Apache permite definir directorios
virtuales, es decir, permite que el mismo servidor atienda peticiones dirigidas a
diferentes direcciones IP o permite que un mismo sitio (definido por una dirección IP)
pueda tener asignados diferentes nombres de dominio, atendidos por el mismo servidor.
Los servidores virtuales vienen definidos por el contenedor <VirtualHost>. En esta
práctica no se estudiarán directorios virtuales.
Veamos las directivas disponibles:
Port. Indica el puerto que se servirá. Se dejará el puerto por defecto, el 80.
User, Group. Indican el usuario y el grupo bajo el cual se ejecutarán los procesos
servidores. Debe tener como valor www-data.
Los procesos servidores se ejecutarán bajo este usuario así que sólo tendrán acceso a los
recursos permitidos para él.
ServerAdmin. Indica una dirección de correo a la que hay que dirigir las cuestiones
cuando hay un problema con el servidor.
ServerName. El nombre que usará el servidor, si este es distinto del nombre real. Este
nombre debe coincidir con la entrada en el DNS.
DocumentRoot. Indica el directorio raíz a partir del cual se servirán documentos. Por
defecto es /var/www. Hay que tener en cuenta que cualquier petición a un documento
que no esté bajo este directorio no se servirá. Por ejemplo, una petición a
www.midominio.com/opt/mm.html buscará el documento mm.html en el directorio opt a
partir del raíz indicado en esta directiva, es decir /var/www/opt.
6
A partir de este punto, empiezan a aparecer contenedores:
•
<IfModule mod> indica que si el módulo mod ha sido instalado, se procesen las
directivas incluidas en él.
•
<Directory dir> delimita el directorio para el cual se aplicarán las directivas.
Permite aplicar controles de acceso basados en directorios, es decir, quién y
cómo se puede acceder a un determinada directorio. Del control de acceso
hablaremos más adelante.
El primer contenedor que aparece es <Directory />. Establece las directivas que se
aplicarán a todos los subdirectorios a partir del raíz. Esto sirve para aplicar condiciones
de acceso y funcionamiento muy restrictivas que luego serán sobreescritas caso a caso.
Así tendremos el comportamiento del servidor controlado para cualquier directorio al
que se intente acceder.
El siguiente contendor es <Directory “/var/www”>. Con las directivas aquí incluidas se
sobreescriben las que el contenedor <Directory /> establecía. Así, mientras que el
primero sólo permite para cualquier directorio la opción FollowSimLinks, este nuevo
contenedor añade más opciones como son Indexes y MultiViews. Diríjase a la
documentación de Apache y de las directivas para saber en que consisten esas opciones.
Sigamos con las directivas:
DirectoryIndex. Esta directiva aparece dentro de un contenedor <IfModule mod_dir.c >.
Permite indicar el nombre de la página HTML que aparecerá como índice por defecto,
en orden de preferencia de derecha a izquierda. Añada:
DirectoryIndex index.html index.htm default.html
El resto de directivas se refieren a opciones para configurar los ficheros de registro.
Déjelas por el momento y busque la siguiente directiva:
Alias. Esta directiva también aparece dentro del contenedor <IfModule mod_alias.c>.
Sirve para indicar que ciertos directorios contienen documentos para ser servidos
aunque no aparezcan dentro del directorio raíz (el especificado por DocumentRoot).
Por ejemplo, la directiva Alias /icons/ “/usr/local/web/apache/icons” está diciendo
cuando haya peticiones al directorio icons los documentos sean buscados en
/usr/local/web/apache/icons.
Entonces, si no hubiera un Alias, la petición www.midominio.com/icons/foto.gif
provocaría que el servidor buscara un fichero llamado foto.gif en el directorio
/var/www/icons, es decir, bajo el raíz. Como sí que hay un alias, el fichero se busca en
/usr/local/web/apache/icons.
Después de esta directiva aparece un contenedor correspondiente al directorio nombrado
en la directiva que establece el control de acceso al directorio.
3.2 Ejecución del servidor
7
En este punto ya tenemos una primera configuración del servidor y podemos ejecutarlo.
El script apachectl permite ejecutar el servidor si se ha instalado a partir de la
compilación. En nuestro caso, como el servidor se ha instalado con Debian, tenemos un
script de arranque en /etc/init.d.
• Ejecute el siguiente comando:
%/etc/init.d/apache configtest
Este comando sirve para comprobar que la sintaxis de los ficheros de configuración es
correcta. Si hubiera cometido un error de sintaxis al escribir las directivas aparecería un
mensaje de error.
Para ejecutar el servidor:
%/etc/init.d/apache start
Ahora el servidor ya está corriendo.
• Compruebe que todo funciona correctamente. Para ello abra un navegador web y
pida la URL http://localhost.
Para detener el servidor:
%/etc/init.d/apache stop
Para reiniciar el servidor (cuando está corriendo) hay varios métodos, restart o graceful.
•
Cree un par de documentos HTML y cópielos a diversos directorios bajo el raíz
de los documentos. Compruebe que los puede obtener con el navegador.
•
Asigne permisos 740 a los documentos HTML e intente obtenerlos.
3.3 Documentos de usuario
En el apartado anterior acaba de comprobar que los documentos que puede servir
Apache deben estar en el directorio raíz que se indique en la directiva DocumentRoot.
Esta forma de organizar los documento es adecuada para un sitio web en el que hay un
solo administrador que se encarga de publicar los contenidos.
El problema es que deja de ser práctico cuando hay muchos usuarios que necesitan
publicar documentos. Piense en la Universidad, por ejemplo, si cada profesor quiere
publicar contenidos de su asignatura, tendría que enviárselos al administrador de la web
para que los colocara y organizara en directorios bajo el raíz. ¡Y hay más de 500
profesores en la UPCT!. Además tendría que actualizarlos cada cierto tiempo, etc.
Para solucionar este problema el usuario debe ser capaz de poder publicar y organizar
los documentos visibles en la web sin necesidad del administrador. La solución es
simple: cada usuario tiene asignado un directorio en el que puede colocar documentos
que serán servidos, aunque no se encuentren bajo el DocumentRoot.
8
Apache permite designar estos directorios mediante la directiva UserDir cuyo valor es
public_html.
Cuando
al
servidor
le
lleguen
peticiones
del
tipo
www.midominio.com/~usuario/index.html, el servidor buscará dentro del directorio
personal del usuario /home/usuario/public_html el archivo solicitado. Es decir, cuando
en la URL de la petición a continuación del dominio aparezca el símbolo ~ seguido de
un nombre de usuario que exista en el sistema, el servidor buscará el documento pedido
bajo el directorio public_html del usuario.
Ejemplos:
www.ait.upct.es/~eegea/productos.html devolverá el fichero productos.html que se
encuentra en /home/eegea/public_html.
www.ait.upct.es/~jvales/imagenes/foto.jpg devolverá el fichero foto.jpg que se encuentra
en el directorio /home/jvales/public_html/imagenes.
• Cree un usuario (con el comando adduser).
• Coloque documentos HTML en el public_html del usuario y compruebe que
puede visualizarlos con el navegador.
3.4 Ficheros de registro
• Abra el fichero /var/log/apache/error_log.
En este fichero se registra cualquier error que se produce en el servidor. Este fichero se
utiliza principalmente para depurar los scripts que colgamos en el sitio web. Si tiene que
programar scripts CGI o PHP, el fichero error_log es fundamental puesto que cualquier
mensaje de error que produzca el script se almacena en ese fichero. Apache proporciona
varias directivas para configurar estos ficheros.
Los ficheros de registro son muy importantes también a la hora de administrar el
servidor. El fichero access_log registra todos los accesos al servidor por lo que resulta
muy útil para obtener estadísticas procesándolo adecuadamente.
3.5 Control de acceso
Apache usa 3 criterios para gestionar quién puede acceder a los contenidos:
autorización, autentificación y control de acceso. Resumidamente, autentificación es la
verificación de que una persona es quien dice ser, autorización consiste en comprobar si
esa persona puede acceder al recurso. El control de acceso es más general que la
autorización, consiste en decidir si un recurso puede ser accedido en función de algún
parámetro adicional, además de la identidad del usuario. Por ejemplo, una persona
puede estar autorizada a acceder a un recurso, siempre y cuando lo haga entre las 8 y las
16 horas.
La autentificación y autorización son prácticamente indistinguibles en Apache. El
servidor usa 3 mecanismos para llevarla a cabo:
1. Autentificación básica.
2. Autentificación por digest
3. Autentificación en bases de datos
Sólo estudiaremos el primer tipo. Cuando se intenta acceder a un recurso protegido, el
servidor manda un mensaje al navegador diciendo que se necesita autentificación. Si el
navegador está preparado para ello, solicitará la autenticación al usuario y la enviará al
9
servidor. Como el protocolo HTTP no guarda información de estado, cada vez que se
intente acceder al mismo dominio de autentificación (es decir, al recurso protegido), el
servidor volverá a pedir credenciales. Sin embargo, el navegador almacena esta
información y las proporciona automáticamente. Si se cambia de dominio o se cierra el
navegador, el proceso volvería a comenzar.
Autentificación básica
La autentificación básica consiste en crear un fichero de texto en el que se almacenará
un nombre de usuario y una contraseña, para los usuarios que pueden acceder a un
recurso. Una vez creado, se configura el servidor para que pida autentificación cuando
se acceda a un determinado recurso. Esto se hace por medio de dos sistemas:
• Incluyendo las directivas adecuadas en un contenedor, como <Directory>. Tenga en
cuenta que existe el contenedor <Location> cuyo contexto es un URL, por lo que
puede proteger un documento individualmente.
• Creando un fichero .htaccess en el directorio que va a ser protegido.
Para crear un fichero de contraseñas utilizará la utilidad htpasswd. Este programa
genera un fichero en el que almacena un nombre de usuario y su clave cifrada.
• Ejecute:
% htpasswd –c /etc/apache/claves nombreusuario
Le pedirá que introduzca la contraseña dos veces. El parámetro c sirve para crear un
fichero por primera vez. Si quiere añadir otro usuario al fichero utilice el mismo
comando sin ese parámetro.
IMPORTANTE: Este fichero debe estar situado en un directorio con los permisos
adecuados y sólo debe poder ser leído por el servidor. Cuanto menor sea el número de
usuarios que tienen acceso a él mejor. Modifique sus permisos adecuadamente.
Ahora vamos a proteger un directorio.
•
Cree un directorio protected bajo /var/www.
•
Abra el fichero httpd.conf. Introduzca las siguientes directivas:
<Directory “/var/www/protected”>
AuthType Basic
AuthName “mi dominio”
AuthUserFile /etc/apache/claves
Require valid-user
</Directory>
Con estas directivas lo que está diciendo es que al directorio especificado se le aplique
una autentificación básica, el nombre del dominio para esa configuración, el fichero en
el que hay que buscar el usuario y, por último, que condiciones son necesarias para que
se aplique la autentificación
•
•
Reinicie el servidor e intente acceder a un documento del directorio protected.
Vuelva a intentarlo para comprobar como el navegador no le vuelve a pedir las
credenciales.
10
•
Añada otro usuario al fichero de contraseñas.
La directiva Require permite definir qué usuarios del fichero de contraseñas están
autorizados. Modifique la directiva para que sólo permita el acceso a un usuario:
Require valid-user
Cuando muchos usuarios comparten el acceso a un recurso hay un método más eficiente
para garantizar el acceso: crear un grupo (igual que en UNIX). Para ello, cree un fichero
de texto /etc/apache/ficherogrupos con la siguiente sintaxis:
nombregrupo: usuario1 usuario2
El fichero debería estar en el mismo directorio que las contraseñas y similarmente
protegido. Incluya las siguientes directivas, en el directorio que se va a proteger, de
manera que quede:
<Directory “/var/www/protected”>
AuthType Basic
AuthName “mi dominio”
AuthUserFile /etc/apache/claves
AuthGroupFile /etc/apache/ficherogrupos
Require group nombregrupo
</Directory>
•
Compruebe que el directorio sigue correctamente protegido.
De esta manera ya podemos asignar recursos a grupos y protegerlos. El otro método
para proteger un directorio es crear un fichero .htaccess en el directorio que va a ser
protegido.
Así se puede permitir que un usuario proteja como crea conveniente su propio directorio
sin que sea necesario modificar el fichero httpd.conf. Lo que hace el servidor Apache
cuando va a servir un documento es comprobar su lista de <Directory> para ver las
directivas que le va a aplicar.
Además busca los ficheros .htaccess que haya en el directorio del documento y todos
los precedentes empezando por el raíz. Las directivas especificadas en esos ficheros se
van combinando, de manera que Apache aplica a un documento las directivas
encontradas en todos los ficheros .htaccess precedentes en el árbol de directorios así
como las del fichero del propio directorio (y las definidas por los contenedores en
httpd.conf).
Este es un proceso que puede ser muy costoso puesto que para cada petición Apache
tiene que procesar estos ficheros. Para controlarlo se usa la directiva AllowOverride.
Consulte en la documentación el uso de esta directiva. Como puede comprobar Apache
deshabilita por defecto los ficheros .htacccess:
<Directory “/”>
AllowOverride None
</Directory>
De esta manera, ni siquiera se buscan los ficheros .htaccess al servir documentos. Si
esta directiva se establece a AllowOverride AuthConfig se permite el uso de directivas
11
de control de acceso en los ficheros .htaccess y Apache los procesará. Esta directiva
permite habilitar otro tipo de directivas en esos ficheros. Es conveniente tener claro qué
es lo que se permite al habilitar cierto tipo de directivas en ficheros que introducen los
usuarios. Consulte siempre la documentación de Apache antes de modificar las directiva
AllowOverride si quiere evitar problemas de seguridad.
Nosotros permitiremos que sólo se puedan usar los .htaccess en el directorio protected y
sólo para directivas de control de acceso.
• Para ello borre las directivas relativas al directorio protected en httpd.conf y
sustitúyalas por las siguientes:
<Directory “/var/www/protected”>
AllowOverride AuthConfig
</Directory>
•
Ahora cree un fichero de texto con las siguientes directivas:
AuthType Basic
AuthName “mi dominio”
AuthUserFile /etc/apache/claves
AuthGroupFile /etc/apache/ficherogrupos
Require group nombregrupo
•
Salve el fichero como .htaccess. Apache sólo permite este nombre, si quiere
darle otro nombre debe modificar la directiva AccessFileName. Compruebe los
permisos del fichero y asígneles los adecuados.
•
Intente acceder al directorio desde el navegador y compruebe que la
autentificación funciona correctamente. Compruebe también que se puede
cambiar las directivas del fichero .htaccess y se aplican sin tener que reiniciar el
servidor.
Hay que decir que la autentificación básica en Apache no es segura en ningún sentido:
auque las claves se almacenen cifradas, se transfiere desde el navegador sin cifrar, así
como todo el contenido al que se accede.
Una vez resuelto el problema de la autentificación, ahora hay que crear reglas de control
de acceso. Esto se puede hacer con las directivas Order, Deny, Allow y Satisfy. Consulte
la documentación sobre estas directivas.
Allow y Deny permiten controlar el acceso en función del nombre del host, de la
dirección del host y del nombre de la máquina. Estas directivas se usan en conjunción
con Order, que especifica cual de las anteriores directivas se evalúa primero.
Compruebe como se han usado en los contenedores del fichero httpd.conf .
• En el contenedor <Directory "/var/www"> sustituya las directivas Deny y Allow
por las siguientes:
Order allow,deny
Allow from IPaddress
En donde IPaddress es la dirección IP de uno de sus compañeros, intente acceder desde
ese ordenador y desde otros para comprobar que la directiva funciona.
12
Si se establece Order Allow, Deny se evalúan antes las directivas Allow que las Deny.
Además, el acceso está negado por defecto. Y viceversa con Order Deny,Allow: primero
las Deny y el acceso es libre por defecto.
•
Vuelva a permitir el acceso a todo el mundo en /var/www.
3.6 Ejercicio
Configure su servidor para que sea ejecutado por el usuario web con el grupo grupoweb.
Su servidor será utilizado por una empresa para alojar su sitio web. El nombre de esta
empresa es upct. La empresa quiere que al introducir su dominio en un navegador
aparezca su página principal que se llamará main.html. Además, quiere incluir un
directorio privado al que sólo puedan acceder máquinas del su red local (el laboratorio)
y siempre y cuando el usuario esté registrado con una contraseña y sea miembro de un
grupo llamado autores. La empresa quiere que el control de acceso a este directorio
pueda ser modificado sin tener que depender del administrador del servidor.
Configure su servidor para cumplir todos los requisitos de la empresa. Tenga en cuenta
los permisos de los diferentes elementos.
3.7. HTML mediante editor de textos.
Cree una página web (pagina.html) donde sólo debe incluir el mensaje “Mi primera
pagina web!!”. Utilice un editor de texto (ASCII) convencional, por ejemplo, emacs o
vi. De acuerdo a lo que aprendió en clases de teoría, debe crear esta página con su DTD,
el HEAD y el BODY. Una vez la tenga preparada, grabe la página en el directorio
public_html de su usuario de AD en el servidor labit601.upct.es. Si no existe ese
directorio, debe crearlo.
•
Desde mozilla podrá acceder a la página con la URL:
http://labit601.upct.es/~usuario/pagina.html
Donde debe cambiar usuario por lo que corresponda. Observará que carga su página
HTML, vía protocolo HTTP.
IMPORTANTE: Observe la URL que ha utilizado para solicitar el documento:
http://labit601.upct.es/~usuario/pagina.html
En esta URL se le indica al navegador que, mediante el protocolo HTTP (http://), le
solicite al servidor labit601.upct.es el documento indicado. El navegador establecerá
una conexión TCP con el servidor del laboratorio (labit601.upct.es) y posteriormente
enviará un mensaje HTTP para solicitar dicho documento.
Observe la siguiente URL:
file:///home/usuario/pagina.html
ESTE ES UN ERROR MUY COMÚN en el desarrollo de esta práctica. Esta URL es
la URL que verá en su navegador si pincha en el fichero HTML que ha creado
previamente. Esta URL indica que desde el sistema de ficheros de la máquina local
(file://) se abra el documento que se encuentra en /home/usuario/pagina.html.
13
En este caso, ni siquiera abre una conexión de red ni se utiliza el protocolo HTTP. El
navegador se limita a abrir un documento HTML local.
Si introduce la URL correcta, el Apache del servidor labit601 automáticamente
traduce la parte de la página de la URL (/~usuario/pagina.html) por la ruta:
$HOMEUSUARIO/public_html/pagina.html.
En este punto, recuerde que el criterio y la forma de traducción entre la página indicada
por la URL, y los archivos locales, es totalmente dependiente del servidor. Por tanto, es
importante entender que diferentes URL pueden ser finalmente la misma página (a
criterio del servidor).
Para finalizar este apartado, comprobará el intercambio de mensajes que se produce
entre cliente y servidor cuando se utiliza el protocolo HTTP con documentos HTML.
• Ejecute Ethereal y compruebe el intercambio de mensajes con el servidor
labit601 que se produce cuando solicita la página anterior.
• ES IMPORTANTE QUE ESTUDIE CON DETALLE EL INTERCAMBIO DE
PAQUETES ENTRE CLIENTE Y SERVIDOR, PARA ESTE EJEMPLO
SENCILLO.
• Modifique la página que ha creado e introduzca al menos una etiqueta <img>.
El atributo src de la etiqueta debe indicar la URL de una imagen externa al
servidor Apache del laboratorio. Por ejemplo: <img
src=www.google.com/images/hp0.gif>
• Solicite de nuevo su página y capture el intercambio de mensajes mediante
Ethereal.
• OBSERVE DETENIDAMENTE EL INTERCAMBIO DE MENSAJES QUE
SE HA PRODUCIDO EN ESTA OCASIÓN. COMPRUEBE CUANTAS
PETICIONES HTTP Y A QUE DIFERENTES SERVIDORES VAN
DIRIGIDAS EN ESTA OCASIÓN.
3.8. Pruebas con el protocolo HTTP
Ahora, debe realizar una prueba sin utilizar mozilla: Usando un terminal (telnet),
conéctese al puerto del servidor web de labit601 (80). Con esta acción, está
estableciendo una conexión TCP directa con el puerto 80 del servidor.
• Escriba:
GET / HTTP/1.0
•
[Doble retorno de carro]
Observe el resultado, debe saber distinguir los tres posibles componentes de una
respuesta HTTP:
1. La línea de estado: Versión HTTP + código + explicación del código en modo
texto.
2. Las cabeceras: Varios pares (Parámetro: valor).
3. El objeto transferido: Una página HTML, una imagen, un fichero de datos, etc.
14
•
Con la salida del comando anterior, busque que cabeceras están presentes
en la respuesta, y a qué se corresponde la página obtenida.
•
Repita la operación con el comando:
GET /index.html HTTP/1.0
Ahora el servidor entiende que usted solicita la página llamada index.html. Si observa
detenidamente la respuesta, comprobará que es idéntica a la anterior. En efecto, si no se
solicita una página determinada, Apache retorna index.html por defecto.
•
Por último, si desea acceder a su pagina.html, debe proceder con la orden:
GET /~usuario/pagina.html HTTP/1.0
Ahora, verifique que el contenido del objeto se corresponde con lo que ha escrito usted
en pagina.html.
3.9. Comprobación de la conformidad de los documentos
HTML es un lenguaje definido usando otro lenguaje: El SGML. Mediante SGML
especificamos un DTD para el lenguaje HTML 3.2, otro para HTML 4.0, etc. Es
importante poder comprobar si una página es "conforme" a su DTD (si está bien
declarada de acuerdo a la semántica y la sintaxis del lenguaje). Para ello, existen
aplicaciones denominadas parsers, que realizan dichas comprobaciones. Para
comprobar la conformidad de sus páginas, puede usar el parser on-line del consorcio
del WWW, ubicado en http://validator.w3.org.
•
Debe enviar la pagina que creó a dicho parser (indicando la URL de la página),
y comprobar si la sintaxis es adecuada.
En primera instancia el parser le dirá que no es posible validar la URL, puesto
que no sabe que juego de caracteres utiliza. En múltiples ocasiones, éste se indica a
través de un parámetro de HTTP (en una de las cabecera). Sin embargo, si el servidor no
está configurado para ello, o se desea indicar otra familia de caracteres, puede hacerlo a
través del elemento <meta> de la cabecera (<head>) de HTML, del siguiente modo:
<meta http-equiv=”Content-Type” content=”text/html; charset=utf-8”>
•
Ahora, edite su página, incluyendo este elemento, y vuelva a comprobar si es
HTML 3.2 válido. En caso de que exista algún error, el parser le ayudará a
encontrarlo.
•
Tiene a su disposición en http://labit601.upct.es/~ad/ejemplos/Tema2 los
ejemplos presentados en teoría correspondientes al lenguaje HTML. Estúdielos
y compruebe que entiende la estructura del elemento presentado en cada uno.
Verifique si son conformes a la especificación HTML 3.2. En caso de que
alguno no lo sea, debe encontrar el problema y corregirlo.
15