Transcript
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
indica que todos las directivas que aparecen entre el inicio y el final () 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
. 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: •
indica que si el módulo mod ha sido instalado, se procesen las directivas incluidas en él. •
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 . 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 . Con las directivas aquí incluidas se sobreescriben las que el contenedor 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 . 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 . 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 . Tenga en cuenta que existe el contenedor 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: AuthType Basic AuthName “mi dominio” AuthUserFile /etc/apache/claves Require valid-user
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: AuthType Basic AuthName “mi dominio” AuthUserFile /etc/apache/claves AuthGroupFile /etc/apache/ficherogrupos Require group nombregrupo
•
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 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: AllowOverride None
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: AllowOverride AuthConfig
•
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 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 ![]()
. El atributo src de la etiqueta debe indicar la URL de una imagen externa al servidor Apache del laboratorio. Por ejemplo: 
• 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 de la cabecera () de HTML, del siguiente modo: •
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