Escolar Documentos
Profissional Documentos
Cultura Documentos
Opción X
Memoria de Residencia Profesional
Presenta:
Reyes Lomeli Walter Ivan
Control:
02490334
Mexicali B.C. Marzo 2007
I
Índice general
1. I NTRODUCCIÓN 1
2. ARQUITECTURA DE LA W EB 3
2.1. E STRUCTURA DE LA WEB . . . . . . . . . . . . . . . . . . . . . 3
2.1.1. BASES ARQUITECTURALES DE LA W EB: . . . . . . . . . 4
2.2. I DENTIFICACIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.1. B ENEFICIOS DEL URI . . . . . . . . . . . . . . . . . . . 4
2.2.2. R ELACIONES URI/R ECURSO . . . . . . . . . . . . . . . 4
2.2.3. C OLISIÓN DE URI . . . . . . . . . . . . . . . . . . . . . 5
2.2.4. A SIGNACIÓN DE URI . . . . . . . . . . . . . . . . . . . 5
2.2.5. P OSESIÓN DE URI . . . . . . . . . . . . . . . . . . . . . 5
2.2.6. E SQUEMAS DE ASIGNACIÓN . . . . . . . . . . . . . . . 6
2.2.7. I DENTIFICACIÓN INDIRECTA . . . . . . . . . . . . . . . 6
2.2.8. C OMPARACIÓN DE URI . . . . . . . . . . . . . . . . . . 6
2.2.9. A LIAS DE URI . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.10. R EUTILIZACIÓN DE LA REPRESENTACIÓN . . . . . . . . 7
2.2.11. E SQUEMAS DE URI . . . . . . . . . . . . . . . . . . . . 7
2.2.12. R EGISTRO D EL E SQUEMA DE URI . . . . . . . . . . . . 7
2.3. I NTERACCIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.1. I NTERACCIONES Y RESPONSABILIDAD INSEGURAS . . . 8
2.3.2. P ERSISTENCIA DE URI . . . . . . . . . . . . . . . . . . 8
2.4. F ORMATOS D E DATOS . . . . . . . . . . . . . . . . . . . . . . 8
II
2.4.1. T IPOS DE F ORMATOS DE DATOS . . . . . . . . . . . . . 9
2.4.2. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.3. H IPERTEXTO . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.3.1. C ARACTERÍSTICAS DEL HIPERTEXTO . . . . . 10
2.4.4. F ORMATO XML- BASADO . . . . . . . . . . . . . . . . 10
2.4.5. NAMESPACES DE XML . . . . . . . . . . . . . . . . . . 11
2.4.6. QNAMES EN XML . . . . . . . . . . . . . . . . . . . . . 11
2.5. E SPECIFICACIONES O RTOGONAL . . . . . . . . . . . . . . . . . 11
4. Apache 21
4.1. D EFINICIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.1. ¿C OMO FUNCIONA A PACHE ? . . . . . . . . . . . . . . . 22
4.2. H ISTORIA DE APACHE . . . . . . . . . . . . . . . . . . . . . . . 22
4.3. C ARACTERÍSTICAS Y VENTAJAS DEL A PACHE . . . . . . . . . . 23
III
4.4. A PACHE 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.5. P RINCIPALES M EJORAS . . . . . . . . . . . . . . . . . . . . . . 24
4.5.1. H EBRADO EN U NIX . . . . . . . . . . . . . . . . . . . . 24
4.5.2. N UEVO SISTEMA DE CONFIGURACIÓN Y COMPILACIÓN 25
4.5.3. S OPORTE MULTIPROTOCOLO . . . . . . . . . . . . . . . 25
4.5.4. S OPORTE PARA PLATAFORMAS QUE NO SON U NIX . . . 25
4.5.5. N UEVA INTERFAZ DE PROGRAMACIÓN (API) . . . . . . 25
4.5.6. F ILTROS . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.5.7. M ENSAJES DE ERROR . . . . . . . . . . . . . . . . . . . 26
4.5.8. M EJORAS EN LOS MÓDULOS . . . . . . . . . . . . . . . 26
4.6. A NTES DE INSTALAR EL S ERVIDOR W EB . . . . . . . . . . . . 28
4.7. S ERVIDOR W EB . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.7.1. I NSTALAR S ERVIDOR A PACHE . . . . . . . . . . . . . . 28
5. A RCHIVOS DE C ONFIGURACIÓN 30
5.1. M ÓDULOS DE M ULTI P ROCESAMIENTO . . . . . . . . . . . . . . 30
5.2. A RCHIVOS DEL SERVIDOR WEB A PACHE . . . . . . . . . . . . 30
5.2.1. A RCHIVO PRINCIPAL DE CONFIGURACIÓN . . . . . . . 31
5.2.1.1.
S ECCIÓN DE CONFIGURACIÓN GLOBAL . . . . 32
5.2.1.2.
S ECCIÓN DE CONFIGURACIÓN DEL SERVIDOR
PRINCIPAL . . . . . . . . . . . . . . . . . . . . 36
5.2.2. V IRTUAL H OSTS . . . . . . . . . . . . . . . . . . . . . . 45
IV
7. S ERVIDOR W EB EN EL I.T.M. 54
7.1. D EBIAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
7.2. A PACHE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7.3. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
7.4. H OST VIRTUAL BASADO EN NOMBRES: . . . . . . . . . . . . . . 56
7.5. SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.6. P ROPUESTA DE UN NUEVA PAGINA W EB . . . . . . . . . . . . . 58
V
Índice de figuras
3.1. Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2. Cliente/Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
VI
Capítulo 1
I NTRODUCCIÓN
1
Instituto Tecnológico de Mexicali 2
ARQUITECTURA DE LA W EB
3
Instituto Tecnológico de Mexicali 4
2.2. I DENTIFICACIÓN
Un objetivo de la Web, es construir una comunidad global en la cual pueda
compartir información y para conseguir este objetivo, la Web hace uso de un único
sistema global de identificación: el URI.
2.3. I NTERACCIÓN
La comunicación entre los agentes implica URIs, mensajes, y datos. Los pro-
tocolos de la web intercambian mensajes, un mensaje puede contener datos como
también metadata sobre un recurso, los datos del mensaje, y el mensaje mismo. El
Instituto Tecnológico de Mexicali 8
2.4.2. HTTP
El protocolo de transferencia de hipertexto ( HyperText Transfer Protocol) es
el usado en cada transacción de la Web. El hipertexto es el contenido de las páginas
web.
Propiedades de HTTP :
Está abierto a nuevos tipos de datos. HTTP utiliza tipos MIME (Multipart
Internet Mail Extensión) para determinar el tipo de los datos que transporta.
2.4.3. H IPERTEXTO
El hipertexto maneja información, en el cual los datos se almacenan en una
red de nodos conectados por enlaces.
Instituto Tecnológico de Mexicali 10
audio o vídeo, por ejemplo, es poco probable ser satisfecho bien a la expresión en
XML.
Los recursos se identifican con URIs. Un URI puede ser publicado sin nin-
guna representación del recurso.
Una sintaxis de URI permite que los agentes funcionen sin saber los esque-
mas de URI.
Instituto Tecnológico de Mexicali 12
Cuando dos especificaciones son ortogonal, una puede cambiar sin necesitar cam-
bios al otro incluso si se tiene dependencias. Por ejemplo, aunque la especificación
del HTTP depende de la especificación de URI, los dos pueden trabajar de forma
independiente.
Capítulo 3
L A W EB COMO ENTIDAD DE
I NTERNET
3.1. ¿Q UÉ ES I NTERNET ?
Dicho de una manera fácil, se trata de un conjunto de computadoras locali-
zadas en todo el mundo las cuales están conectadas entre sí para intercambiar
información.
Otra forma de entender mejor Internet es pensando en ella como una gran red
mundial de computadoras formada por pequeñas redes conectadas unas con otras
intercambiando información entre ellas. Internet es una red libre ya que cualquier
persona puede tener acceso a ella desde cualquier lugar.
El tener acceso a información que se encuentra repartida por todo el mundo
como si se encontrara en una sola computadora es una de las características que
hacen de Internet una potente herramienta para el intercambio de información y
para la comunicación, por ejemplo, un documento de una computadora en Méxi-
co, puede tener referencias a otro documento en Japón. En la figura figura 3.1 se
muestra un pequeño ejemplo de como varias pequeñas redes se encuentran conec-
tadas entre si intercambiando información.
13
Instituto Tecnológico de Mexicali 14
3.6. E XPLORADORES W EB
Un explorador es un programa con el cual se puede acceder y visualizar los ar-
chivos que se encuentran dentro e Internet. Antes de que llegaran los exploradores
era necesario tener conocimiento de una gran cantidad de órdenes que permitían el
acceso a todos los recursos de Internet. Los exploradores hacen que la utilización
de Internet sea una tarea cómoda y sencilla.
Para visualizar los recursos de Internet es necesario tener un explorador Web
Instituto Tecnológico de Mexicali 18
3.8. E STRUCTURA DE LA W EB
Antes de iniciar con el diseño de un sitio Web hay que tener bien definido cuál
va a ser el propósito del sitio, que información contendrá y la audiencia de la que
dispondrá.
* Estructura de árbol o jerárquica: Se tiene una página principal (raíz) de
la cual se abren unas secciones (ramas) las cuales contienen gran cantidad páginas
web (hojas).
* Estructura lineal: A partir de una página principal se accesa a las siguientes
páginas una tras otra como si fuera un libro.
* Estructura en red: Las páginas que forman el sitio Web se enlazan unas
con otras sin ningún tipo de jerarquía.
Instituto Tecnológico de Mexicali 19
3.9. A RQUITECTURA W EB
Los arquitectos Web diseñan los sitios Web. Los sitios Web deben estar inte-
grados por Bases de datos, servidores, redes, componentes de backup y seguridad,
etc.. para obtener como resultado final un sitio que resuelva las necesidades de las
personas.
En el desarrollo Web se requieren de conocimientos de lenguajes programa-
ción y estructura de bases de datos, el protocolo TCP/IP, el lenguaje HTML y
muchos otros.
3.10. V ENTAJAS DE LA W EB
Es bastante fácil de usar.
3.11. ¿Q UÉ ES LA ACCESIBILIDAD W EB ?
La Accesibilidad Web permite que personas puedan entender, navegar e inter-
actuar con la Web.
La Web es importante para diferentes aspectos de la vida: educación, empleo,
comercio, entretenimiento y muchos otros.
3.12. ¿Q UÉ ES LA W EB S EMÁNTICA ?
La Web Semántica es una Web extendida, en la que el usuario en Internet
podrá encontrar respuestas a sus preguntas de forma más rápida y sencilla gracias
a una información mejor definida, utiliza lenguajes que resuelven los problemas
ocasionados por una Web carente de semántica en la que, en ocasiones, el acceso
a la información se hace una tarea difícil[7].
Apache
4.1. D EFINICIÓN
Apache es un servidor Web potente y flexible que funciona en distintas pla-
taformas y entornos, estas hacen que a menudo sean necesarias diferentes carac-
terísticas o funcionalidades, o que una misma característica o funcionalidad se
realice de diferente manera para obtener una mayor resultado. El diseño modular
de Apache permite a los administradores de sitios Web elegir que características
se van a incluir en el servidor al seleccionar los módulos que se van a cargar, ya
sea al compilar o al ejecutar el servidor.
21
Instituto Tecnológico de Mexicali 22
Apache trabaja con gran cantidad de Perl, PHP y otros lenguajes de script.
4.5.6. F ILTROS
Los módulos de Apache pueden comportarse como filtros que actúan sobre el
flujo de contenidos tal y como salen del servidor o tal y como son recibidos por el
servidor. Esto permite, por ejemplo, que el resultado de un script CGI sea analiza-
do por las directivas Server Side Include usando el filtro INCLUDES del módulo
mod_include. El módulo mod_ext_filter permite que programas externos actúen
como filtros casi del mismo modo que los CGIs pueden actuar como handlers.
mod_auth_ldap: Este módulo permite que se pueda usar una base de datos
LDAP para almacenar las credenciales en la autenticación básica HTTP.
4.7. S ERVIDOR W EB
Antes de la instalación y configuración del servidor apache, necesitábamos un
dominio para la web que nos rediriga la IP del servidor Web deseado.
Necesitamos dos servidores DNS, uno que sera el encargado de traducir los
nombres de dominio a IPs y viceversa y otro servidor que traduja el dominio a la
IP donde se tiene pensado poner el servidor web.
A RCHIVOS DE C ONFIGURACIÓN
30
Instituto Tecnológico de Mexicali 31
2. error.log: Aquí se almacenan los errores que ocurren dentro del servidor.
1. Configuración global.
Instituto Tecnológico de Mexicali 32
Cuando instalamos Apache nos instala un fichero con la configuración por defec-
to, este fichero suele ser /etc/apache2/apache2.conf
En el caso de que en nuestra distribución de GNU/Linux no este en el mismo
sitio siempre podremos recurrir a finad:
____________________________________________________
debian:~# find / -name httpd.conf /
etc/apache/httpd.conf
debian:~#
En algunas distribuciones se puede encontrar en:
/etc/apache/conf/httpd.conf
____________________________________________________
***************************************************************************
### Section 1: Global Environment
ServerType standalone
ServerRoot /etc/apache
LockFile /var/lock/apache.lock
PidFile /var/run/apache.pid
ScoreBoardFile /var/run/apache.scoreboard
TimeOut 300
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15
MinSpareServers 5
MaxSpareServers 10
StartServers 5
Instituto Tecnológico de Mexicali 33
MaxClients 150
MaxRequestsPerChild 100
Listen 80
LoadModule config_log_module /usr/lib/apache/1.3/mod_log_config.so Load-
Module mime_magic_module /usr/lib/apache/1.3/mod_mime_magic.so LoadMo-
dule mime_module /usr/lib/apache/1.3/mod_mime.so LoadModule negotiation_module
/usr/lib/apache/1.3/mod_negotiation.so LoadModule status_module /usr/lib/apache/1.3/mod_status.so
....
ExtendedStatus On
***********************************************************************
ServerType standalone.
Estatus: Nuclear.
Contexto: Configuración del Servidor.
Esta directiva indica la forma en que Apache arranca. Tiene dos opciones:
Por ejemplo, Para hacer una petición al servidor de una página Web que contiene
tres imágenes, se hacen 4 peticiones, una para la página y una por cada imagen.
Al tener activadas las conexiones persistentes, permite hacer todas las peticio-
nes a través de la misma conexión sin tener que negociar nuevas conexiones. La
respuesta del servidor es más rápida obteniendo un mejor rendimiento.
Esta directiva admite dos opciones:
Instituto Tecnológico de Mexicali 35
Listen: Indica los puertos en los que el servidor Web aceptará las peticio-
nes entrantes. Por defecto, el Servidor Apache HTTP está configurado para
escuchar en el puerto 80.
1. On, activado.
2. Off, desactivado.
***************************************************************************
### Section 2: ’Main’ server configuration
Port 80
User www-data
Group www-data
ServerAdmin
ServerName
DocumentRoot /var/www
<Directory />.......... </Directory>
<Directory /var/www/>.......... </Directory>
<IfModule mod_userdir.c>......... </IfModule>
<Directory /home/*/public_html>.......... </Directory>
<IfModule mod_dir.c>......... </IfModule>
AccessFileName .htaccess
<Files ~ "^\.ht">Order allow,deny Deny from all </Files>
UseCanonicalName On
Instituto Tecnológico de Mexicali 37
TypesConfig /etc/mime.types
DefaultType text/plain
<IfModule mod_mime_magic.c>......... </IfModule>
HostnameLookups Off
ErrorLog /var/log/apache/error.log
LogLevel warn
LogFormat " %h %l %u %t \" %r\" %>s %b" common
CustomLog /var/log/apache/access.log common
ServerSignature On
Alias /icons/ /usr/share/apache/icons/
<Directory /usr/share/apache/icons>.......... </Directory>
ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
<Directory /usr/lib/cgi-bin/>.......... </Directory>
<IfModule mod_autoindex.c>......... </IfModule>
<IfModule mod_mime.c>......... </IfModule>
AddDefaultCharset on
<IfModule mod_setenvif.c>......... </IfModule>
<IfModule mod_perl.c>......... </IfModule>
<Location /doc>order deny,allow deny from all allow from 127.0.0.0/255.0.0.0
Options Indexes FollowSymLinks MultiViews
</Location>
***********************************************************************
En el caso de que un módulo se carge, esta directiva se utiliza para especificar las
acciones a realizar.
Port 80:
Estatus: Nuclear.
Contexto: Configuración del Servidor.
User:
Estatus: Nuclear.
Contexto: Configuración del Servidor y directivas VirtualHost.
Establece el nombre de usuario para el proceso del servidor y determina qué ar-
chivos pueden acceder al servidor. Cualquier archivo que no esté accesible a este
usuario tampoco estará disponible para los clientes conectándose al Servidor Apa-
che HTTP.
Group:
Estatus: Nuclear.
Contexto: Configuración del Servidor y directivas VirtualHost.
Esta directiva indica el grupo del usuario bajo el cual se ejecuta el servidor.
Instituto Tecnológico de Mexicali 39
ServerAdmin:
Estatus: Nuclear.
Contexto: Configuración del Servidor y directivas VirtualHost.
ServerName:
Estatus: Nuclear.
Contexto: Configuración del Servidor y directivas VirtualHost.
DocumentRoot:
Estatus: Nuclear.
Contexto: Configuración del Servidor y directivas VirtualHost.
AccessFileName:
Estatus: Nuclear.
Contexto: Configuración del Servidor y directivas VirtualHost.
Sirve para especificar el nombre de los archivos de control de acceso para los
directorios. Es posible especificar los controles de acceso mediante las directivas
<Directory ...>... </Directory>pero también se puede hacerse con el uso de los
Instituto Tecnológico de Mexicali 40
UseCanonicalName:
Estatus: Nuclear.
Contexto: Configuración del Servidor, directivas VirtualHost, Directory y
ficheros de control de acceso .htaccess.
Aquí servidor Web utiliza los valores de las directivas ServerName y Port para
construir URL’s de redireccionamiento, los cuales aparecen en los mensajes de
error por ejemplo, y para suministrarse la a programas CGI.
Esta directiva tiene dos opciones:
1. On, activado. El servidor formará las URL’s a partir del documento pedido
por el cliente.
TypesConfig:
Estatus: módulo mod_mime.so.
Contexto: Configuración del servidor.
Nombra el archivo que configura la lista por defecto de asignaciones tipo MIME
(extensiones de nombres de archivo a tipos de contenido. Cuando no se tenga una
ruta absoluta se toma como relativa a ServerRoot.
Instituto Tecnológico de Mexicali 41
Los tipos MIME son los Tipos Multimedia de Internet y son gestionados por
I.A.N.A. (Autoridad de Números de Asignación de Internet) [1].
DefaultType:
Estatus: Nuclear.
Contexto: Configuración del Servidor, directivas VirtualHost, Directory y
ficheros de control de acceso .htaccess.
Especifica el tipo MIME por defecto de los archivos de los que no pueda ser
determinado su tipo.
HostnameLookups:
Estatus: Nuclear.
Contexto: Configuración del Servidor y directivas VirtualHost y Directory.
Habilita o no, la búsqueda de los nombres de los clientes por resoluciones inversas
de DNS. HostnameLookups se puede configurar a on, off o double.
Si se configura HostnameLookups a on, el servidor automáticamente resuelve
las direcciones IP para cada conexión. Resolver las direcciones IP significa que
el servidor hace una o más conexiones a un servidor DNS, añadiendo sobrecarga
por procesamiento.
Si HostnameLookups es configurado a double, el servidor realiza búsquedas
inversa doble del DNS, añadiendo aún más sobrecarga.
Para ahorrar recursos en el servidor, HostnameLookups es configurado a off
por defecto.
ErrorLog:
Estatus: Nuclear.
Contexto: Configuración del Servidor y directivas VirtualHost.
Esta directiva indica cual es el archivo en el que se almacenarán los log de error
del servidor. Por defecto, esta directriz es configurada a /var/log/apache/error.log
Instituto Tecnológico de Mexicali 42
LogLevel:
Estatus: Nuclear.
Contexto: Configuración del Servidor y directivas VirtualHost.
LogFormat:
Estatus: módulo mod_log_config.so.
Contexto: Configuración del Servidor y directivas VirtualHost.
Define nuestros propios formatos para los archivos de log del sistema permitién-
donos especificar varios formatos de log con la información que queramos.
Las siguientes son las opciones de formato si la directriz CustomLog:
%h (dirección IP del post remoto o nombre de la máquina). Lista la dirección
IP de la máquina remota del cliente solicitante. Si HostnameLookups es configu-
rada a on, el nombre de máquina del cliente es registrado a menos que no este
disponible desde el DNS.
%l (rfc931). No se usa. Un guión [-] aparece en el campo de registro para este
campo.
%u (usuario autenticado). Si se requiere autenticación, lista el nombre del
usuario registrado. Usualmente, esto no se utiliza, por tanto aparece un guión [-]
en el archivo de registro para este campo.
%t (fecha). Lista la fecha y hora de la solicitud.
%r (cadena de la solicitud). Lista la cadena de la solicitud exactamente como
viene del navegador o cliente.
Instituto Tecnológico de Mexicali 43
%s (estado). Lista el estado de código HTTP el cual fue devuelto al host clien-
te.
%b (bytes). Lista el tamaño del documento.
%\" %{Referer}i\" (referencia). Lista la dirección URL de la página web que
refiere el máquina cliente al servidor Web.
%\" %{User-Agent}i\" (agente usuario). Lista el tipo de navegador Web que
está realizando la solicitud.
CustomLog:
Estatus: módulo mod_log_config.so.
Contexto: Configuración del Servidor y directivas VirtualHost.
ServerSignature:
Estatus: Nuclear.
Contexto: Configuración del Servidor, directivas VirtualHost, Directory y
ficheros de control de acceso .htaccess.
Añade una línea que contiene la versión del Servidor Apache HTTP y el Server-
Name para cualquier documento generado por el servidor, tales como mensajes
de error devueltos a los clientes. Por defecto ServerSignature está configurada a
on pero también se puede configurar a off o a EMail.
Esta directiva tiene tres opciones:
1. On, Apache agrega el nombre del servidor y la versión como una especia de
firma a las páginas de error generadas automáticamente.
Alias:
Estatus: módulo mod_alias.so.
Contexto: Configuración del Servidor y directivas VirtualHost.
ScriptAlias:
Estatus: módulo mod_alias.so.
Contexto: Configuración del Servidor y directivas VirtualHost.
Esta directiva hace lo mismo que la directiva Alias pero esta vez para directo-
rios de scripts CGI. Normalmente, no es una buena idea colocar los scripts CGI
dentro de DocumentRoot, donde podrían, ser visualizados como documentos de
texto. Por esta razón, la directriz ScriptAlias diseña un directorio especial fuera
del directorio DocumentRoot para contener ejecutables del servidor y scripts. Es-
te directorio es conocido como un cgi-bin y se configura por defecto a /cgi-bin/
/usr/lib/cgi-bin/.
AddDefaultCharset On.
Estatus: Nuclear.
Contexto: Configuración del Servidor y directivas VirtualHost.
1. Por nombre. Todos los hosts virtuales tienen la misma dirección IP con
nombres distintos.
<VirtualHost></VirtualHost>:
Dentro de estas directivas se incluye cualquier otra que haga refenrencia a este
host particular. Asocia una dirección IP y número de puerto para cualquier máqui-
na virtual basada en nombres. El hospedaje virtual basado en nombres permite a
un Servidor Apache HTTP servir a dominios diferentes sin usar múltiples direc-
ciones IP.
Instituto Tecnológico de Mexicali 46
D IRECTIVAS :
Document Root
NameVirtualHost
Sercver Alias
ServerName
ServerPath
<VirtualHost>
ServerName:
Es fácil mantener varios sitios web con diferentes nombres de dominio tan
solo con definir varios alias (CNAME). Por ejemplo, suponga que está sirviendo
el dominio www.dominio.tld y quiere añadir el host virtual www.otrodominio.tld,
que apunta a la misma dirección IP. Entonces, lo único que tiene que hacer es
añadir lo siguiente:
+++++++++++++++++++++++++
NameVirtualHost 111.22.33.44
<VirtualHost 111.22.33.44>
ServerName www.dominio.tld
DocumentRoot /www/dominio
</VirtualHost>
<VirtualHost 111.22.33.44>
ServerName www.otrodominio.tld
DocumentRoot /www/otrodominio
</VirtualHost>
+++++++++++++++++++++++++
También puede optar por especificar una dirección IP explícitamente en lu-
gar de usar un * en las directivas NameVirtualHost y <VirtualHost>. Por ejem-
plo, puede hacer esto para hacer funcionar diferentes hosts virtuales basados en
nombres en una dirección IP, o basados en IPs, o un conjunto de hosts virtuales
basados en nombres en otra dirección. También puede que quiera que se acceda
a un determinado sitio web usando diferentes nombres. Esto es posible con la di-
rectiva ServerAlias, puesta dentro de la sección <VirtualHost>. Por ejemplo, en
el primer bloque <VirtualHost>de arriba, la directiva ServerAlias indica la lista
de nombres que pueden usarse para acceder a un mismo sitio web: ServerAlias
dominio.tld *.dominio.tld entonces las peticiones para todos los hosts en el domi-
nio dominio.tld serán servidas por el host virtual www.dominio.tld. Los carácteres
comodines * y ? pueden usarse para encontrar equivalencias con los nombres. La
mayor parte de las directivas pueden ponerse en esos containers y cambiarán solo
la configuración del host virtual al que se refieran. Las directivas de configura-
Instituto Tecnológico de Mexicali 48
ción se usan única y exclusivamente si sus valores no son sustituidos por alguno
de los parámetros de configuración del host virtual. Cuando llega una petición,
el servidor primero verifica si se está usando una dirección IP que coincide con
el valor de la directiva NameVirtualHost. Si es el caso, mirará en cada sección
<VirtualHost>cuya IP coincida e intentará encontrar si el valor de la directiva Ser-
verName o de la directiva ServerAlias coincide con el nombre del sitio web de
la petición. Si encuentra una coincidencia, usa la configuración de ese servidor.
Si no la encuentra, usa el primer host virtual de la lista cuya dirección IP coin-
cida con el de la petición. Como consecuencia, el primer host virtual de la lista
es el que se usa por defecto. La directiva DocumentRoot del servidor principal
no se usará nunca cuando una dirección IP coincida con el valor de la directiva
NameVirtualHost. Si quiere usar una configuración especial para peticiones que
no coinciden con ningún host virtual en concreto, ponga esa configuración en una
sección <VirtualHost>y póngala la primera en el fichero de configuración.
Capítulo 6
AUTENTICACIÓN , AUTORIZACIÓN
Y C ONTROL DE ACCESO
49
Instituto Tecnológico de Mexicali 50
Para poder definir este tipo de autenticación, es necesario seguir dos pasos:
AuthName:
Define un nombre para la zona protegida. Una vez que un usuario introdujo cre-
denciales válidas para esta zona, cualquier recurso dentro de esta zona sera acce-
dido con las mismas credenciales.
AuthType:
AuthUserFile:
Require:
Instituto Tecnológico de Mexicali 51
Define que nombres de usuario del fichero tienen derechos de acceso. Valid-user
sería un caso especial refiriendose a cualquier usuario del fichero.
.htacces
AuthName Protegido
AuthType Basic
AuthUserFile /etc/httpd/conf/db_usersrequire
valid-user
6.3. L OS P RERREQUISITOS
Las directivas deben ir en el archivo de configuración principal del servidor.
Si se usan archivos .htaccess, se debe hacer una configuración en el servidor para
poner directivas de autentificación en estos archivos. La directiva AllowOverride,
especifica cuáles directivas pueden ser colocadas en los archivos de configuración
por directorios.
Para la autentificación, necesita una directiva AllowOverride como la siguien-
te:
AllowOverride AuthConfig
S ERVIDOR W EB EN EL I.T.M.
7.1. D EBIAN
Una de mis propuestas en cuanto al Sistema Operativo para este proyecto es
Debian y uno de mis motivos es por el ahorro económico, hay que tener en cuenta
que el precio de una licencia es muy alto. Además, que este Sistema Operativo
funciona en casi todas la computadoras personales, incluyendo algunos modelos
antiguos. Otra de las razones por las cuales llegue a la decisión de proponer De-
bian es por que su instalación es muy sencilla, la instalación la podemos hacer
directamente desde un CD, DOS o discos flexibles incluso a través de Internet.
Los archivos FTP se actualizan diariamente y una de las ventajas que tiene
Debian es que se puede estar actualizando de una manera muy sencilla, sólo se
tiene que ejecutar apt-get update y apt-get upgrade desde la consola, es necesario
estar actualizándolos cada semana.
Debian te brinda seguridad y privacidad ya que en Linux no hay virus, que
afectan casi exclusivamente a los sistemas Windows. El hecho de que el códi-
go fuente esté disponible para todo el mundo, garantiza el derecho de cualquier
persona o empresa a continuar su desarrollo.
54
Instituto Tecnológico de Mexicali 55
7.2. A PACHE
Las diferentes plataformas y los diferentes entornos, hacen que sean
necesarias diferentes características , o que una misma característica se utilice de
diferente manera para obtener una mayor eficiencia.
Por obvias razones, mi propuesta para resolver esta situación es instalando
el Servidor Web APACHE en el Instituto Tecnológico de Mexicali. Como ya lo
he mencionado anteriormente en este proyecto, Apache esta diseñado para que su
configuración sean de forma modular y su diseño le permite funcionar en una gran
variedad de plataformas adaptándose a distintos entornos, la ventaja de Apache es
que tu puedes elegir que módulos se van a cargar, al compilar o al ejecutar el
servidor.
Otra de las razones por el cual elegí el servidor Web Apache, es por que Apa-
che es de código fuente abierto gratuito sin tener que pagar por licencias, como
código fuente abierto quiero decir, que si quiero ver que es lo que estoy instalando
como servidor , lo puedo saber.
Para la instalación de Apache también es muy sencillo, solo se tiene que es-
cribir desde la consola apt-get apache2.
Con Apache es posible tener un Control de Acceso para evitar que personas
tengan acceso a datos o recursos, una manera de llevar acabo esto es con el acceso
restringido por usuario y password creando un fichero, el cual tendrá los usuarios
y los passwords que tendrán acceso a dichos recursos y definiendo las zonas a
restringir. Para permitir el acceso a mas de una persona se usa la directiva Auht-
GroupFile y tendríamos que crear un archivo de grupo para asociar los nombres
de grupo con una lista de usuarios que pertenecen a ese grupo.
Además ya se cuenta con la versión Apache 2.0, la cual contiene muchas me-
joras y novedades convirtiéndolo en el mejor servidor de páginas Web y lo de-
muestra al ser el líder y número uno en los últimos años.
Instituto Tecnológico de Mexicali 56
7.3. PHP
rar Apache para que reconozca los diferentes nombres de host. Es fácil mante-
ner varios sitios Web con diferentes nombres de dominio, por ejemplo, suponga-
mos que tenemos el dominio: www.dominio.tld y queremos añadir el host virtual
www.otrodominio.tld, con la misma dirección IP. Entonces, lo haremos de la si-
guiente manera:
NameVirtualHost 111.22.33.44
<VirtualHost 111.22.33.44>
ServerName www.dominio.tld
DocumentRoot /www/dominio
</VirtualHost>
<VirtualHost 111.22.33.44>
ServerName www.otrodominio.tld
DocumentRoot /www/otrodominio
</VirtualHost>
(para mayor información mirar la sección 5.2.2).
7.5. SSL
Es una buena idea pensar en SSL, ya que ofrece servicios de seguridad cifran-
do los datos intercambiados entre el servidor y cifrando la clave de sesión. Cada
vez que se haga una transacción se va a generar una clave de sesión distinta, de
tal manera que cuando una transacción es atacada, no habrá problema ya que la
siguiente transacción será con una clave distinta.
Como ventajas tenemos que el SSL proporciona cifrado de datos, autentica-
ción de servidores, integridad de mensajes y autenticación de cliente para cone-
xiones TCP/IP. El Protocolo SSL Handshake utiliza el Protocolo SSL Record y el
puerto abierto para comunicarse de forma segura con el cliente. Durante el proto-
colo SSL Handshake, el cliente y el servidor intercambian mensajes para negociar
las mejoras de seguridad. Una manera de explicarlo es así:
Instituto Tecnológico de Mexicali 58
La producción de clave de sesión será la usada para cifrar los datos inter-
cambiados.
2. Información y Contenidos.
3. Navegación fácil
4. Rapidez.
Cuando una página tarda en aparecer en la pantalla es por que tiene muchas
animaciones, imágenes, gráficas, etc. que sólo hacen mas lenta la navega-
ción. Yo pondría imágenes pero no deforma exagerada, en ocasiones estar
esperando que una página se cargue resulta molesto.
5. Información actualizada.
CONCLUSIONES y T RABAJO
F UTURO
8.1. S ERVIDOR W EB
Dado el análisis hecho, puedo concluir lo siguiente:
Apache "NO" solo es el servidor Web excelente, la forma en que esta confi-
gurado hacen que cada vez mas servidores confíen en este programa, además está
diseñado para ser un servidor Web potente y flexible el cual funciona en una gran
cantidad de plataformas y entornos.
Además como Apache es una tecnología de código fuente abierto me permitió
ver que es lo que estaba instalando como servidor, sin ningún secreto.
Comparando este servidor Web con los demás servidores me dí cuenta que
Apache es sin duda el mejor servidor de paginas Web, y lo demuestra al ser el líder
y numero uno en los últimos años (60 % del total de servidores http de Internet.)
61
Instituto Tecnológico de Mexicali 62
[8] José Angel de Bustos Pérez, Archivos Importantes para Apache. Software
Foundation, www.augcyl.org/glol/apache2.html, Agosto 1998.
[9] L. Masinter, RFC397, The data URL scheme. Internet Engineering Task
Force, www.ietf.org/rfc/rfc2397.txt, Agosto 1998.
63
Instituto Tecnológico de Mexicali 64