DESPLIEGUE DE

APLICACIONES WEB
Desarrollo de aplicaciones web

Ilerna

ILERNA, centro autorizado con código 25002775 (Lleida), 28077294 (Madrid) y 41023090 (Sevilla) www.ilerna.es
© Ilerna Online S.L., 2021

Maquetado e impreso por Ilerna Online S.L.

© Imágenes: Shutterstock

Impreso en España - Printed in Spain

Reservados todos los derechos. No se permite la reproducción total o parcial de esta obra, ni su incorporación a un
sistema informático, ni su transmisión en cualquier forma o por cualquier medio (electrónico, mecánico, fotoco-
pia, grabación u otros) sin autorización previa y por escrito de los titulares del copyright. La infracción de dichos
derechos puede constituir un delito contra la propiedad intelectual.

Ilerna Online S.L. ha puesto todos los recursos necesarios para reconocer los derechos de terceros en esta obra
y se excusa con antelación por posibles errores u omisiones y queda a disposición de corregirlos en posteriores
ediciones.

2.a edición: diciembre 2021

 ÍNDICE
Despliegue de aplicaciones web

1. Implantación de arquitectura web................................................... 6

1.1. Arquitecturas web. Modelos..........................................................7
1.2. Servidores web y de aplicaciones. Instalación y configuración
básica............................................................................................ 12
1.3. Estructura y recursos que componen una aplicación web.
Descriptor de despliegue............................................................ 19

2. Administración de servidores web................................................. 20

2.1. Configuración avanzada del servidor web.................................. 21
2.2. Módulos: instalación, configuración y uso................................. 23
2.3. Servidores virtuales. Creación, configuración y utilización....... 26
2.4. Autenticación y control de acceso.............................................. 28
2.5. El protocolo HTTPS...................................................................... 30
2.6. Certificados. Servidores de certificados..................................... 32
2.7. Despliegue de aplicaciones sobre servidores web.................... 32

3. Instalación y administración de servidores de transferencia de

archivos........................................................................................... 34
3.1. Configuración del servicio de transferencia de archivos.
Permisos y cuotas........................................................................ 36
3.2. Tipos de usuarios y accesos al servicio....................................... 37
3.3. Modos de conexión del cliente................................................... 37
3.4. Protocolo de transferencia de archivos seguro.......................... 38
3.5. Utilización de herramientas gráficas........................................... 39
3.6. Utilización del servicio de transferencia de archivos desde el
navegador..................................................................................... 41
3.7. Utilización del servicio de transferencia de archivos en el
proceso de desarrollo de la aplicación web............................... 42

4. Administración de servidores de aplicaciones............................... 44

4.1. Arquitectura y configuración básica del servidor
de aplicaciones............................................................................ 47
4.2. Administración de aplicaciones web.......................................... 48
4.3. Autenticación de usuarios. Dominios de seguridad para la
autenticación................................................................................ 50
4.4. Administración de sesiones. Sesiones persistentes................... 51
4.5. Archivos de registro de acceso y filtro de solicitudes................ 52
 4.6. Configuración del servidor de aplicaciones para la
cooperación con servidores web................................................. 52
4.7. Despliegue de aplicaciones en el servidor de aplicaciones...... 53
4.8. Seguridad en el servidor de aplicaciones. Configuración del
servidor de aplicaciones con soporte SSL/T............................... 54

5. S
 ervicios de red implicados en el desarrollo de una aplicación web.
56
5.1. DNS. Resolución de nombres. Proceso de resolución de un
nombre de dominio..................................................................... 57
5.2. Parámetros de configuración y registros del servidor de
nombres afectados en el desarrollo............................................ 61
5.3. Servicios de directorios. Características y funcionalidad.......... 63
5.4. Archivos básicos de configuración. Interpretación y uso........... 66
5.5. Adaptación de la configuración del servidor de directorios
para el desarrollo de la aplicación. Usuarios centralizados....... 67

6. Documentación y sistemas de control de versiones....................... 68

6.1. Documentación............................................................................ 69
6.2. Herramientas externas para la generación de documentación.
Instalación, configuración y uso.................................................. 69
6.3. Instalación, configuración y uso de JavaDoc.............................. 74
6.4. Sistema de control de versiones. Seguridad de los sistemas
de control de versiones................................................................ 76
6.5. Git como sistema control de versiones....................................... 79

Bibliografía / webgrafía....................................................................... 87

Solucionario ......................................................................................... 88
1
IMPLANTACIÓN DE ARQUITECTURA WEB
 Despliegue de aplicaciones web

1.1.  Arquitecturas web.

Modelos
La era tecnológica debe su gran avance a la aparición de la
red que es capaz de conectar a todos los equipos de ámbito
mundial, como es internet. La arquitectura web (www) de
internet suministra un modelo de conexión bastante pode-
roso y flexible para que cualquier equipo se pueda adaptar
fácilmente a las necesidades de la red. Para dicha conexión
necesitamos utilizar unas aplicaciones que nos facilitarán
el proceso.

Algunas de las ventajas que han hecho que internet tenga

tanto auge es la total disposición de los datos contenidos
en cada equipo de la red. De esta forma, los contenidos
son presentados en formato normal y se localizan gracias
a unos programas rastreadores, también conocidos como
web browsers o buscadores. Estas aplicaciones encuentran
la información requerida gracias a las peticiones que van
enviando a los distintos servidores para que estos les
respondan con las páginas que más se adaptan a los pará-
metros que buscar.

Los estándares web especifican muchos de los modelos de

propósito general. Los contenidos en la web se visualizan de
una forma estandarizada, permitiendo de esta forma que
los browsers (navegadores) los interpreten correctamente.
El formato en el que están diseñados estos contenidos debe
cumplir una serie de normas para que todos los navega-
dores puedan procesarlos, por ejemplo, HTML, JavaScript,
CSS, etcétera.

Además del contenido, toda operación de transferencia por

la web debe estar estandarizada también. Cada servicio
por realizar corresponde con una serie de normas llamadas
protocolos. De esta forma, se rigen más fácilmente las
operaciones que realizar para ejecutar cualquier servicio en
internet, sin necesidad de tener en cuenta ni la tecnología
del cliente ni el sistema operativo.

PARA + INFO

El protocolo más utilizado cuando un cliente

se conecta a internet es HTTP (protocolo de
transporte de hipertexto), que permite al cliente
visualizar archivos con esa misma extensión, es
decir, páginas web.

Este protocolo también permite a los desarrolladores

crear aplicaciones y servicios para una gran comunidad
de clientes.

7
 Tema 1: Implantación de arquitectura web

Características de la arquitectura web

Los aspectos generales que destacar en una arquitectura

web son los siguientes:

• Escalabilidad: internet, además de ser una red que abar-

ca una amplitud inmensa, está formado por un conjunto
de elementos de distinta naturaleza, tales como servido-
res, enrutadores, switch y demás elementos necesarios
para la transmisión de la información. Al presentar una
gran escalabilidad, podemos fácilmente, sin realizar nu-
merosos cambios, conectarnos a distintos equipos sin
ningún tipo de problema. La red no se verá influida en nin-
guna de las características, de lo contrario, si no fuese por
su diseño escalar, habría que haber cambiado constante-
mente de equipos debido a la evolución constante de los
requerimientos que demandan los clientes, cada vez con
tecnologías más avanzadas y con velocidades más altas.
• Separación de responsabilidades: en el funcionamien-
to de las redes, se separan los distintos elementos, los
clientes y servidores, las peticiones y las respuestas. De
esta manera, se trabaja de una forma más organizada y
estructural, adaptándose cada uno a las necesidades de
la acción en este instante.
• Amplia conectividad: la conexión en una red es uno de los
objetivos primordiales. Los servidores, y los administrado-
res que los gestionan, tratan de proveer de una conexión
óptima entre cualquier cantidad de nodos, considerando
los mejores niveles de seguridad para cada caso.
• Recursos compartidos: el aprovechamiento de los re-
cursos que se comparten entre clientes hace que las
operaciones se realicen con menos elementos conecta-
dos y, por tanto, el coste para la adquisición de dispositivo
es menor. Mediante las arquitecturas de red se pueden
compartir recursos como impresoras y bases de datos,
por lo que hace que el funcionamiento de la red sea más
eficiente y económica.

8
 Despliegue de aplicaciones web

Modelo de la arquitectura web

Con el objetivo principal de comunicar dos equipos, como

mínimo podemos afirmar que la arquitectura de un sitio
web la forman la gestión de los sistemas de organización y
estructuración de los contenidos y, además, el de recupera-
ción de información y, por supuesto, la visualización de los
contenidos por parte del cliente.

En función de cómo se implementan cada una de las

capas de una aplicación web, podemos dividir el modelo
en varias capas:
• Capa de presentación: es la capa que presentará la in-
formación al usuario y aceptará las entradas o respuestas,
enviándolas a la capa de negocio.
• Capa de negocio: es la capa que gestiona la lógica de
la aplicación, recibe las peticiones de los usuarios y es
desde donde se envían las respuestas. En esta capa se
verifica que las reglas se cumplen.
• Capa de acceso a datos: es la capa más interna, la for-
man los gestores de bases de datos y se estructura de tal
manera que se almacenan los datos organizados para
que pueda ser fácilmente consultada la información y
cualquier operación tarde el menor tiempo posible.

En función de los autores, podemos distinguir otra clasifi-

cación de los modelos según su orden de aparición:
• Modelo 1: en su origen, las aplicaciones se diseñan en
lenguaje de texto (HTML). El usuario recibía la respuesta
del servidor a su petición. La presentación, el negocio y
el acceso a datos se concentraban en un mismo archivo.

9
 Tema 1: Implantación de arquitectura web

• Modelo 1.5: comenzamos a utilizar la tecnología Java

como lenguaje orientado a objetos, aparece la comunica-
ción cliente-servidor con lenguajes como JSP o servlets
con servidores web como Tomcat y amplían su funciona-
lidad. Aparece el concepto de páginas web dinámicas a
partir de los parámetros de la petición que envíe el nave-
gador. En este modelo, las capas de presentación, negocio
y acceso a datos se encuentran en las páginas JSP, lo que
facilita la programación de todas las capas creando una
separación de responsabilidades.
• Modelo 2: como evolución se incorpora el patrón MVC a
este tipo de aplicaciones, aparece la incorporación de un
elemento nuevo controlador de la navegación de la apli-
cación y la capa de negocio queda en el interior de los
archivos creados por Java, que presenta la ventaja de po-
der encapsular varios objetos.
• Modelo 2X: en este modelo tenemos la necesidad de
realizar aplicaciones para poder atender a varios clien-
tes y en varios canales, como, por ejemplo, tablet, móvil
y ordenador. En este caso, para los distintos dispositivos
utilizamos XSL y lo transformamos en XML.

Otro de los aspectos que tener en cuenta para clasificar el

modelo de la arquitectura web es según la organización y
comunicación entre sus nodos:

• Cliente-servidor: está basado en el flujo de datos entre

ordenadores (clientes) que solicitan un servicio a un or-
denador u ordenadores (servidor) centrales y disponen
de este servicio para responder a las peticiones de estos.
Existen diferentes configuraciones y estructuras del lado
del servidor para proveer de servicios a los clientes, pero
siempre se produce el flujo de información entre uno de
los clientes y uno de los servidores.

10
 Despliegue de aplicaciones web

• Peer to peer: en el modelo de igual a igual o P2P (peer to

peer), los nodos en este tipo de red tienen dos papeles:
hacen la función de servidor y a su vez de cliente frente a
otros equipos de su misma red. Todos los nodos de esta red
actúan de la misma forma, formándose una especie de
colmena en la que todos se comunican con todos, pasando
de tener un único canal de transmisión de datos hacia un
cliente a disponer de tantos como la red lo permita.

Cliente
2

Cliente Cliente
1 3

Cliente Cliente
4 n

Cliente
5

Si comparamos los dos modelos presentados, se puede

apreciar que el modelo cliente-servidor está basado en
dos roles perfectamente definidos. Su diseño es fácil de
implementar, pero tiene limitaciones por los cuellos de bo-
tella ocasionados ante una alta demanda de información
hacia el servidor.

En cambio, el modelo P2P, aunque es mucho más compli-

cado de comprender y diseñar, al permitir que cada cliente
sea a la vez servidor del resto de clientes, ofrece una ven-
taja clara en cuanto a eficiencia sobre el otro modelo.

Funcionamiento de los servicios web

El servicio web necesita tres elementos principales:

• Proveedor del servicio web: para el diseño, desarrollo y

puesta en marcha para su uso.
• Consumidor del servicio: es el elemento que accede a
dicho recurso.
• Agente del servicio: es el elemento que hace la función
de enlace para que los dos anteriores se encuentren. Se
encarga de enlazar los criterios de búsqueda con los ser-
vicios del proveedor.

11
 Tema 1: Implantación de arquitectura web

1.2.  Servidores web y de

aplicaciones. Instalación y
configuración básica
Como hemos mencionado anteriormente, una red de equi-
pos está formada por nodos. Si distribuimos nuestra de red
con el modelo cliente- servidor, disponemos de un equipo
que suministra a los demás los servicios que se pueden
realizar.

Este equipo servidor deberá estar configurado de tal

forma que pueda dar servicio a sus clientes. Una de estas
funciones es el servicio web. Tal servicio se ejecuta conti-
nuamente en el servidor a la espera de peticiones por parte
de un cliente de la red y responde a esta petición con el
contenido pedido. Dicho contenido es una página web y,
por tanto, para su visualización necesitamos la aplicación
de un navegador web.

Para realizar la instalación de un servidor web, podemos

utilizar distintas vías, como la instalación de un sistema
operativo servidor y la instalación de un servicio web a
continuación mediante un gestor de dominio.

PARA + INFO

El sistema operativo puede ser propietario o

libre.

Como opción, y para no instalar un sistema operativo server,

podemos también instalar una aplicación que hace que
la máquina sea un servidor web. Uno de los servidores
más utilizado es Apache, de código abierto y gratuito, dis-
ponible para los sistemas operativo Windows y GNU/Linux.

BUSCA EN LA WEB

Para poder descargar el servidor web, tutoriales y

demás información, podemos acceder a:

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

12
 Despliegue de aplicaciones web

Este servidor web se caracteriza por estar estructurado en

módulos, y cada uno de ellos presenta una función perfec-
tamente definida y referida a un aspecto de la aplicación
web. Para su configuración debemos acceder al archivo
.httpd, que contiene los módulos instalados y cuya funcio-
nalidad debe ser activada al arrancar el servidor.

Dependiendo de su nivel, tenemos disponibles varios mó-

dulos:

• Módulo base: se encarga de las funciones básicas.

• Multiprocesos: encargados de las peticiones, aceptán-
dolas y ejecutándolas.
• Adicionales: añaden funcionalidad al servidor.

La licencia Apache, sobre la que se implementa este servi-

dor Apache, permite la distribución de derivados de código
abierto y cerrado a partir de su código fuente original.

13
 Tema 1: Implantación de arquitectura web

1.2.1.  Instalación de servidor web Apache

en Linux

A continuación, se detallará cómo instalar un servidor web

Apache en un servidor Ubuntu 18.04.

Paso 1: instalación de Apache

Este software se encuentra dentro del repositorio pre-

determinado de Ubuntu, por lo que es posible realizar la
instalación utilizando las herramientas convencionales de
administración de paquetes.

Lo primero que se hará será actualizar el índice local de

paquetes:

$ sudo apt update

Una vez que se han actualizado los paquetes, se procede a

instalar el paquete apache2:

$ sudo apt install apache2

Paso 2: verificar el servidor web

Al finalizar esta instalación, y ya instaladas todas sus

dependencias, Apache se inicia automáticamente. Este
proceso debería estar activo y en ejecución.

Para verificar el estado del servicio, se comprobará con el

sistema de base systemd:

$ sudo systemctl status apache2

14
 Despliegue de aplicaciones web

Debería mostrar la siguiente información conforme el ser-

vicio está activo y ejecutado:

De todas formas, la mejor forma de comprobar si se ha

iniciado correctamente es solicitar una página al servidor
Apache. Para ello, se accederá a la página por defecto de
Apache para confirmar que se encuentra en ejecución a
través de su dirección IP. Para poder conocer la dirección IP
de nuestro servidor, se puede utilizar el siguiente comando:

$ hostname -I

15
 Tema 1: Implantación de arquitectura web

Ya obtenida la dirección IP del servidor, se ingresará en la

barra de direcciones del navegador web:

http://ip_servidor

A continuación, se debería ver la página predeterminada

de Ubuntu 18.04:

Esto indica que Apache se encuentra en correcto funciona-

miento. Por otra parte, también incluye información básica
sobre la ubicación de los archivos y directorios relevantes
de Apache.

Paso 3: administración del proceso de Apache

Cuando ya se tiene el servidor web activo y ejecutándose,

se muestran algunos comandos básicos para su adminis-
tración.

Para detener el servidor web, se utilizará el siguiente co-

mando:

$ sudo systemctl stop apache2

Para iniciar el servidor web:

$ sudo systemctl start apache2

16
 Despliegue de aplicaciones web

Para detener y reiniciar el servicio utilizando un solo co-

mando:

$ sudo systemctl restart apache2

Cuando se ha realizado un cambio en la configuración, es

posible recargar Apache sin tener que reiniciar el servicio y
perder las conexiones activas:

$ sudo systemctl reload apache2

Apache por defecto, está configurado para iniciarse

automáticamente cuando se inicia el servidor. Para desha-
bilitarlo se utilizará:

$ sudo systemctl disable apache2

Para volver a habilitar que el servicio se inicie una vez

arranque el servidor, se utiliza:

$ sudo systemctl enable apache2

17
 Tema 1: Implantación de arquitectura web

1.2.2.  Servidor de aplicaciones

CONCEPTO

Podemos definir un servidor de aplicaciones

Servidor de
aplicaciones web
como la herramienta que proporciona aplicaciones
o programas a los equipos cliente de la red, medi-
youtu.be/Fq_PmP1_kro
ante una conexión HTTP.

Otra utilidad que tiene el servidor de aplicaciones es la

centralización en un equipo en concreto encargado de pro-
porcionar las aplicaciones necesarias para toda la red con
el fin de gestionar mejor el acceso a los datos.

La integridad de los datos y la centralización de las

aplicaciones en un equipo hace que el funcionamiento de
la red sea más eficiente y disminuya la complejidad en el
desarrollo de las aplicaciones.

Las actualizaciones se realizan de una forma más cómo-

da al centrarse todas las aplicaciones en el equipo. Las
aplicaciones que se concentran en este servidor suele ser
aplicaciones web de comercio electrónico o herramientas
para gestión del contenido web.

1.2.3.  Instalación de servidor de

aplicaciones Tomcat
Tomcat es un servidor que incluye tanto el servicio web, ya
que contiene el servidor Apache, como el servicio de apli-
caciones. Gestiona las peticiones HTTP y peticiones JSP o
servlet.
Antes de empezar, como prerrequisito debemos tener ins-
talado el JDK de Java, ya que este servidor lo utiliza como
conector para las aplicaciones.
• Una vez instalado, crearemos una variable de entorno
para indicar la ruta donde está instalado. Para ello, de-
bemos escribir en el terminal de nuestra máquina Linux:

JAVA_HOME=/usr/lib/jvm/java-6-openjdk/jre/
PATH=$PATH:$JAVA_HOME/bin export PATH JAVA_HOME

• Seguidamente, debemos actualizar las variables de en-

torno para que haga efecto el comando:

source /etc/profile

• Llegado este momento, descargamos el servidor para

empezar con su instalación.

18
 Despliegue de aplicaciones web

Para descomprimir el archivo guardado, podemos ejecutar:

# tar xvzf apache-tomcat-X.X.XX.tar.gz

• Una vez descomprimido, la gestión del servicio se realiza ponte a prueba

a través del script incluido llamado Catalina. Para arran-
car o parar el servidor, solo tendríamos que introducir
¿Cuál es el protocolo más
start o stop.
utilizado cuando un cliente se
• Una vez realizada la instalación, debemos acceder a conecta a internet?
cualquier navegador e introducir la URL del localhost o a) HTTP
127.0.0.1 y se debería mostrar la página de inicio de di- b) SMTP
cho servidor. c) FTP
d) DNS

1.3.  Estructura y recursos que

componen una aplicación web.
Descriptor de despliegue
Una aplicación web está diseñada por código e implementa-
da mediante unos cuantos archivos escritos en servlets, JSP,
HTML Y CSS, PHP o Javascript. Todos ellos son lenguajes
orientados a la programación web. Además, contienen
archivos de audio, vídeo o imágenes, de forma que los ser-
vidores donde se almacenan todos estos archivos tendrán
que estar organizados para empaquetar todos estos recur-
sos y ejecutarlos en varios contenedores distintos.

Una aplicación servlets es un archivo escrito en Java

encargado de realizar un servicio dentro de un servidor
web.

Se define la estructura de directorios para lograr realizar

una aplicación web. Se suele respetar la norma de asignar
al directorio raíz el nombre de la aplicación. Debemos tener
un cuidado especial con las carpetas “META-INF” y “WEB-
INF”, ya que estos directorios son de uso exclusivo del
desarrollador y, por tanto, el cliente no tendrá acceso alguno.

19
2
ADMINISTRACIÓN DE SERVIDORES WEB
 Despliegue de aplicaciones web

Internet se ha convertido en una herramienta básica para la

vida diaria, tanto para el ámbito laboral como el personal.
En esencia, el elemento básico que hace posible la conexión
a esta red mundial de equipos conectados no es más que
un equipo cliente que se conecta mediante un navegador
a un servidor web que contiene una información que al
cliente le interesa.

Esta máquina servidor puede contener la información de

varias empresas, por tanto, a grandes rasgos, funciona
como almacén de páginas web, esperando a que llegue una
petición para responder con la información requerida.

Este equipo debe estar operativo los 365 días del año las
24 horas del día, ya que no sabemos cuándo puede llegar
una petición.

2.1.  Configuración avanzada del

servidor web
Dependiendo del peso de información que contenga el
servidor, la configuración puede variar, pues se tiene que
prever la capacidad de almacenamiento con la que cuenta.

Además, también depende del contenido de las páginas

y de los lenguajes y compiladores que utilizan. No es lo
mismo una página estática donde solo se utiliza el lenguaje
HTML que otra dinámica, con llamadas a bases de datos
que también estarán almacenadas en dicho servidor.

21
 Tema 2: Administración de servidores web

El tipo de transmisión HTTP es otro de los factores que

pueden influir en la configuración, las características de la
transmisión que necesita la comunicación pueden variar
las opciones en el servidor web.

A partir de estas condiciones, realizaremos la operación

más importante e influyente del proceso, que es la elec-
ción de servidor junto con el sistema operativo que lo
controlará.

A continuación, debemos pensar también en las futuras

conexiones y aplicaciones que instalar en dicho servidor
y, por tanto, la escalabilidad y modularidad que tendrá.
Una vez instalado y configurado el servidor, ejecutaremos
el plan de prueba que comprobará el buen funcionamiento.

Para el caso más simple, debemos visualizar una página

web estática, es decir, una página que no cambia mientras
que se está visualizando en el cliente, ya que solo contiene
información en una dirección, donde el usuario final no
tiene que intervenir, solo visualizar. En este caso, el servi-
dor tiene un funcionamiento básico:

• Solo almacena información.

• Solo se necesita que el servidor web disponga de soporte
HTML/XHTML/CSS.
• En cuanto a configuración y administración, el soporte
proporcionado es básico y, por tanto, el rendimiento es
altísimo.
• El procesador tiene poco trabajo, esto hace que el coste
sea mínimo y aumente la rapidez en el acceso a la página.
• El tiempo de respuesta es muy corto.
Sin embargo, para el caso de páginas web dinámicas, ne-
cesitamos más recursos por parte del servidor, incluyendo
los servicios instalados, ya que necesitamos PHP y bases de
datos en funcionamiento.
CONCEPTO

Todos estos módulos que estamos nombrando

suponen tiempo y coste en la respuesta que
sufre el servidor, por tanto, la configuración
y administración del servidor web será
más compleja: cuantos más módulos o
lenguajes tengamos que soportar, más difícil y
complicada es la configuración.

Dependiendo de la complejidad en las tecnologías insta-

ladas en el servidor, deberemos tener más en cuenta la
seguridad en el equipo y los métodos de acceso.

22
 Despliegue de aplicaciones web

2.2.  Módulos: instalación,

configuración y uso
Las características que destacar en un servidor son la es-
tabilidad, tanto de la parte hardware como de la parte
software de la máquina, la disponibilidad de los datos de
poder acceder a ellos en cualquier momento y la posibili-
dad de insertar un módulo al equipo de tal forma que no
obstaculice el funcionamiento de los demás componentes.
Esta propiedad se llama escalabilidad.

Es muy importante poder dotar al servidor web de nuevas

funcionalidades de forma sencilla, así como tener la opción
de quitárselas. Que un servidor posea esta propiedad de
modularidad hace que sea un servidor muy utilizado, fácil
de administrar y muy manejable.

Dependiendo de las tecnologías que se necesiten en un

momento determinado, se instala su módulo correspon-
diente y, por regla general, no tiene por qué ocurrir ninguna
incidencia.

Un ejemplo de estos módulos puede ser comunicaciones

por SSL, o para soportar PHP o LDAP como administrador
de dominio.

23
 Tema 2: Administración de servidores web

2.2.1.  Módulos en Linux

En este apartado veremos una serie de operaciones que se
pueden realizar con los módulos bajo el sistema operativo
Linux, en concreto, con el servidor web Apache citado
anteriormente.

En primer lugar, iniciaremos la sesión del servidor con

el usuario administrador. Consultaremos mediante el
comando sudo apache2ctl -l dónde están cargados todos
los módulos estáticos.

A continuación, comprobaremos los módulos dinámicos,

para ello, accedemos al directorio /etc/apache2/mods-ena-
bled y observamos que todos los ficheros que existen en el
interior son enlaces simbólicos a otra carpeta:

• Si editamos un fichero .load podemos observar la cláu-

sula LoadModule seguida del módulo y la ruta donde se
carga el módulo.
• En el caso de editar un fichero .conf, se observan las eti-
quetas <ifModule nombre></ifModule> para conocer
qué módulo se va a cargar.

Con el siguiente comando podemos ver los paquetes

disponibles en el repositorio de Ubuntu para instalar los
módulos adicionales.

sudo apt-cache search libapache2-mod

A continuación, vamos a utilizar el módulo userdir, para

ello, lo primero es consultar si está habilitado el módulo.

Para ello debemos consultar el directorio /etc/

apache2/mods-enabled y utilizar la instrucción
sudo a2enmod userdir

Reiniciamos el servidor para que haga efecto.

A continuación, consultamos el fichero userdir.conf para

comprobar que está habilitado el uso de directorios perso-
nales para todos los usuarios excepto para el administrador
(root).

Comprobamos que se ha creado la carpeta /var/

www/html y que su propietario es el usuario con el
que hemos iniciado la sesión, es decir, root. Dicha
carpeta es el directorio raíz del servidor.

24
 Despliegue de aplicaciones web

2.2.2.  Módulos en Windows

A partir de la máquina servidor, vamos a consultar los
módulos tanto estáticos como dinámicos cargados por
defectos.

Para realizar esta operación, podemos ejecutar el

comando httpd -l

A continuación, visualizamos los módulos dinámicamente

al iniciar el servidor y los que están disponibles para cargar.

Como en el apartado anterior, también utilizaremos el mó-

dulo userdir para ello, visualizamos el fichero httpd.conf de
la carpeta del servidor Apache y quitamos el comentario
(#) a la línea correspondiente al módulo.

El paso siguiente es editar el archivo httpd-userdir.conf

para realizar las configuraciones pertinentes (por ejemplo,
cambiar la ruta de la página web personal), y de esta ma-
nera, al reiniciar el servidor, podemos visualizar una página
web personal de cualquier usuario.

25
 Tema 2: Administración de servidores web

2.3.  Servidores virtuales.

Creación, configuración y
utilización
En los apartados anteriores hemos podido comprobar el
alojamiento de varias páginas web en un servidor Apache,
todas ellas pertenecientes al mismo dominio.

A continuación veremos la configuración de hosts virtuales

para que en el mismo servidor podamos alojar varias pági-
nas pertenecientes a varios dominios.

Existen tres formas de realizar una configuración de ser-

vidores virtuales: basados en nombre, basados en IP y
basados en varios servidores principales.

Servidor virtual basado en nombres

Trabajaremos siempre desde la dirección IP de nuestro

servidor Apache. Una vez que accedamos a él, nos iremos
a la carpeta “sites-available”, donde están definidos los
servidores virtuales. Cada servidor virtual tendrá que ir
en un archivo de texto distinto en el interior de la misma
carpeta donde nos encontramos.

Este es un ejemplo de un archivo de configuración de un

host virtual, utilizando “example.com” en lugar del dominio:

<VirtualHost *:80>
ServerAdmin [email protected]
ServerName example.com
ServerAlias www.example.com
DocumentRoot /var/www/example.com.conf
ErrorLog /var/log/apache/logs/error.log
LogLevel warn
CustomLog /var/log/apache/los/acces.log.combined
</VirtualHost>

26
 Despliegue de aplicaciones web

La primera línea nos indica que todas las solicitudes en

el puerto 80 deben coincidir. En lugar del asterisco (*) es
posible indicarle una dirección IP del servidor.
• ServerAdmin muestra la información de contacto del ad-
ministrador del sitio web.
• ServerName indica el nombre del dominio del sitio web.
• ServerAlias es el nombre secundario del sitio web.
• DocumentRoot indica la carpeta raíz del sitio web.
• ErrorLog indica en qué archivo se almacenarán los errores.
• LogLevel indica el nivel de errores que serán enviados al
registro.
• CustomLog es el archivo donde se dirigirá la información
de acceso.

A continuación, para que el servidor pueda aceptar cone-

xiones de dos IP diferentes por los puertos, ejecutaremos
las cláusulas:

listen 192.168.200.250:80
listen 192.168.200.251:8080

Servidor virtual basado en direcciones IP

En este tipo de servidor debemos hacer corresponder cada

interfaz del servidor con una IP distinta. No aporta ventaja
alguna, incluso en el caso de que se modifiquen las IP del
servidor con mucha frecuencia puede convertirse en un
proceso dificultoso.

El proceso es similar al del apartado anterior, lo único que

cambia es la configuración del archivo de texto para cada
uno de los dominios. En este caso, no es necesario abrir los
puertos con la cláusula listen.

Al inicio de la configuración se indica la dirección IP del

servidor, seguida del puerto, aunque, como hemos indicado
antes, no hace falta, ya que utilizamos el puerto por defecto.
ponte a prueba
A continuación, se indica el directorio donde se van a alma-
cenar los ficheros de la página web en cuestión seguido del En una página web estática,
nombre del domino y su alias correspondiente. ¿qué ocurre con el servidor?
a) Solo almacena información
Servidor virtual basado en varios servidores b) Solo se necesita que el servidor
principales web disponga de soporte
HTML/XHTML/CSS
Este método es el más complicado de todos los que vamos c) E
 l tiempo de respuesta es muy
a definir en este apartado. Va a ser útil en el caso de desear corto
tener varios archivos de configuración de forma indepen- d) Todas las respuestas son
diente, organizando cada uno sus servidores virtuales que correctas
pudieran tener.

27
 Tema 2: Administración de servidores web

2.4.  Autenticación y control de

acceso
Limitar el acceso a determinadas páginas es unas de las
funciones que debe poder realizar un servidor web. La
política de acceso debe seguirse muy rígidamente, y han
de observarse unas normas acordes a las necesidades de
la empresa.

Cuando nos autenticamos en una web, suelen transferirse

las credenciales almacenadas en la base de datos del
servidor para comprobar si son correctas y seguras. Para
esta utilidad, suele utilizarse un gestor de bases de
datos en SQL o LDAP.

El propio protocolo HTTP proporciona un método de

autenticación básico para las peticiones que se hagan
por este medio. El procedimiento es el siguiente: ante
una petición de un cliente, mediante cualquier navegador
introduciendo una dirección web, el servidor solicita las
credenciales de la red a la que se va a conectar. Una vez
proporcionadas, el texto que viaja por la petición va a ir
sin cifrar, aunque es recomendable que para este paso se
utilice la conexión HTTPS, de esta manera, se le añade un
rasgo extra de seguridad a la conexión.

28
 Despliegue de aplicaciones web

Este paso de autenticación en la red se realiza en el archivo

.htaccess de los directorios de las páginas web. Para que
esta opción se haga efectiva, debemos tener configurado
nuestro servidor con la cláusula AllowOverride de la
siguiente manera: AllowOverride AuthConfig

Autenticación HTTP access

Para restringir el acceso a determinados usuarios desde el

servidor, debemos utilizar un método de autenticación. En
este caso lo realizaremos mediante el método access.

1. Iniciamos el servidor (para este ejemplo, utilizaremos

uno bajo Linux) y comprobamos que el módulo au-
th-basic está habilitado.
2. Creamos un fichero (htpasswd) en el que guardaremos
las credenciales de los usuarios permitidos.
3. Instalamos el paquete apache2-utils que contiene
htpasswd mediante la cláusula sudo apt-get install
apache2-utils.
4. Creamos el fichero como hemos mencionado anterior-
mente para un usuario en cuestión: sudo htpasswd -c /
etc/apache2/passwd usuario.
5. El siguiente paso es editar el fichero de configuración
000-default.conf para permitir el acceso a los usuarios
anteriormente añadidos, para ello se utilizan las eti-
quetas <RequireAll><RequiredAny>.
6. Por último, reiniciamos el servidor e intentamos acce-
der al usuario desde el navegador del cliente.

Autenticación HTTP Digest

Para este tipo de autenticación, debemos realizar el

procedimiento sobre una página web en concreto. Segui-
damente, habilitamos el módulo en cuestión (en este
caso, auth-digest) mediante sudo a2enmod auth-digest y
reiniciamos el servidor.

Como en el caso anterior, hemos de crear un fichero donde

se almacenan tanto el usuario como la contraseña de los
usuarios a los que se les está permitida la entrada. Para
realizar esta acción, debemos utilizar el comando htdigest.

Sudo htdigest -c /etc/apache2/digest dominio usuario

Como en el ejemplo anterior, debemos editar el fichero de

configuración para permitir el acceso al usuario anterior.

29
 Tema 2: Administración de servidores web

2.5.  El protocolo HTTPS

El protocolo HTTPS (protocolo de tratamientos de hiper-
texto de forma segura) realiza las operaciones pertinentes
para que la información viaje de forma segura entre las es-
Seguridad: HTTPs
taciones cliente y el servidor. Esta seguridad se implementa
youtu.be/FVAWylHZmTA mediante técnicas de encriptación de la información antes
de ser transferida desde el equipo origen.

Este aspecto es lo que diferencia a este protocolo del ante-

rior (HTTP), ya que este último no cifra la información.

Hay que tener en cuenta que el proceso de cifrado de infor-

mación requiere de un tiempo de procesamiento y de una
implementación de los métodos que ejecutar, por estas
razones, el trabajo del procesador y el tiempo de computa-
ción se ve afectado a la hora de transmitir los datos. Como
conclusión, debemos sopesar la información que desea-
mos transmitir de forma segura, ya que no es conveniente
por el gran sobreesfuerzo.

Debemos pensar qué información es importante para que

viaje de forma segura, y solo se encriptará dicha información.

Por otra parte, en ocasiones muy específicas, tenemos la

necesidad de que toda la página web sea encriptada debi-
do a la información tan sensible que contiene, por ejemplo,
el acceso a una compra por internet o la página web del
banco donde realizamos las operaciones.

30
 Despliegue de aplicaciones web

Debido a estos dos aspectos, nuestro servidor web

estará configurado para que en todo el dominio esté
cifrada su información o simplemente el intento de ac-
ceso a esta.

Para aumentar aún más la seguridad en la transmisión y

autenticación de la información, los servidores web, en
este caso, Apache, pueden emitir certificados, con la salve-
dad de que algún navegador no lo identifique y lo detecte
como peligroso, ya que no entra dentro de sus servidores
de confianza o de su lista con las entidades certificadoras.

Las grandes empresas, realizan este tipo de acciones con-

sistentes en crear un certificado propio para sus empleados,
pero solo puede acceder personal autorizado por la propia
empresa.

El método de cifrado que utiliza el protocolo HTTPS está

basado en SSL/TLS (protocolos criptográficos que propor-
cionan comunicaciones seguras por una red, comúnmente
internet), que proporciona autenticación y privacidad.

A la hora de hacer una petición en el equipo cliente para

visualizar una página web, se realiza mediante el protocolo
HTTP por defecto, sin embargo, cuando se hace una peti-
ción a un sitio web que tiene implementado el protocolo
HTTPS, es el mismo procedimiento pero con un paso adi-
cional, que es el cifrado de la información.

En cuanto el servidor recibe la petición, se traduce el nom-

bre del dominio en dirección IP mediante el servicio DNS.
A continuación, se aloja la página mediante el puerto 443
TCP, que es el que trabaja este protocolo HTTPS, y a la hora
de transferir la página al cliente es el momento de cifrar la
información de acuerdo con el certificado que el navegador
tenga asignado y firmado como seguro.

Si tenemos alojada en nuestro servidor una página web y

deseamos que se acceda mediante protocolo HTTPS, de-
bemos configurar los puertos 80 y 443 para poder recibir
peticiones de los dos protocolos existentes.

31
 Tema 2: Administración de servidores web

2.6.  Certificados. Servidores de

certificados
Después de hablar de las peticiones web mediante cer-
tificados, vamos a detallar los pasos para verificar el
certificado digital en el navegador (en concreto, en Mozilla
Firefox).

Para ello, debemos acceder al navegador y conectarnos

a una dirección de forma segura (podemos poner como
ejemplo la dirección de cualquier banco de ahorro). Si
accedemos a las configuraciones, más concretamente a
Más información, podemos consultar el certificado que
emite la información junto con el método de cifrado que
ha utilizado.

Para ver el certificado junto con la entidad que lo verifica,

debemos acceder a las opciones de configuración en la
pestaña de Opciones Avanzadas y, en el apartado de Certi-
ficados, Ver certificado.

En el caso de que el navegador no conozca el certificado

que emite la información, mostrará alguna indicación en
una pantalla de error y la posibilidad de añadir la excepción
correspondiente y confiar, mediante la acción del usuario,
en el sitio que estamos intentando visualizar.

Cada navegador tiene su procedimiento para tratar los

certificados tanto verificados como no verificados, pero
siempre desde las opciones que hemos detallado en este
apartado.

2.7.  Despliegue de aplicaciones

sobre servidores web
Los portales web que normalmente tiene que procesar los
servidores web necesitan de los siguientes elementos para
su correcto funcionamiento:

• PHP. Las páginas web han dejado de ser estáticas y

requieren que los usuarios interactúen con la propia
página para realizar un procedimiento dinámico entre
equipo y servidor. Este procedimiento se lleva a cabo
mediante el lenguaje de programación PHP y, en con-
secuencia, el servidor tiene que ser capaz de procesar
dichos comandos. Para ello, debemos configurar el ser-
vidor para tal hecho.
• SQL. Por la misma razón, la web dinámica debe cargar los
datos desde una base de datos, para lo que tiene que co-
nectarse y cargar los datos con sentencias SQL.

32
 Despliegue de aplicaciones web

Para la instalación de estos módulos adicionales debemos

realizar el siguiente procedimiento: primero, descargar la
aplicación y configurarla para que sea visible en el servidor
web. Si el equipo servidor cumple los requisitos pertinen-
tes, procederemos a la instalación. Mientras que estemos ponte a prueba
en el proceso de instalación, debemos añadir las creden-
ciales para el superusuario de la base de datos. Una vez
¿En qué se basa el método de
finalizada la instalación y su posterior configuración, ya
cifrado que utiliza el protocolo
podemos desplegar los sitios web en nuestro servidor. HTTPS?

En algunas ocasiones, para facilitar este proceso podemos a) SSL

descargar desde internet un conjunto de aplicaciones que b) TLS
concentran todo lo necesario para crear un servidor web con c) SSL/TLS
todos los módulos básicos necesarios para su ejecución. d) STL
Podemos poner como ejemplo WAMP (Windows, Apache,
MySQL y PHP) o LAMP (Linux, Apache, MySQL y PHP).

33
3
INSTALACIÓN Y ADMINISTRACIÓN DE

SERVIDORES DE TRANSFERENCIA DE ARCHIVOS
 Despliegue de aplicaciones web

En este apartado veremos la dinámica de otro protocolo y

servicio que tener en cuenta en la ejecución de un servidor.
La transferencia de fichero entre el cliente y el servi-
dor se realiza mediante el protocolo FTP (file transfer
protocol), y se utiliza para la subida, modificación o
descarga de archivos en internet.

Un servidor FTP también puede utilizarse para intercambiar

archivos en una misma red, de la misma oficina o de de-
partamentos lejanos. Supone una transferencia más rápida
con respecto a los métodos tradicionales de transmisión de
archivos.

Una vez instalado y configurado este servicio de transfe-

rencias de datos en el servidor, esperaremos las peticiones
para transferir los archivos.

La seguridad de la información ya era un aspecto para

tener en cuenta en los puntos anteriores de este manual, y
en este caso también será una característica que tendremos
que evaluar a la hora de utilizar este servicio o protocolo.

La transmisión de datos se realiza sin cifrar y cualquier

usuario no permitido podría visualizar la información sen-
sible. Actualmente, existen versiones de mejora en este
proceso como la parte segura de este protocolo, como FTPS
empleando el cifrado SSL/TLS.

35
 Tema 3: Instalación y administración de servidores de transferencia de archivos

3.1.  Configuración del servicio

de transferencia de archivos.
Permisos y cuotas
Servidor de La arquitectura que emplea este protocolo FTP es de clien-
transferencia de
te-servidor, siendo el cliente FTP el equipo que realiza la
archivos
petición y transferencia de archivos y el servidor FTP quien
youtu.be/cXbiaewPi5Q ofrece los archivos.

Es un protocolo orientado a conexión, se necesita establecer

una conexión con el servidor para empezar la transferencia
de ficheros, por lo que las credenciales para realizar la co-
nexión son un aspecto de vital importancia.

Ya hemos mencionado anteriormente la inseguridad de

este procedimiento, pero su facilidad de uso hace que en
ocasiones sea fructífera su utilización.

Este protocolo es uno de los pocos que requiere de dos

puertos TCP en el servidor para su funcionamiento; nor-
malmente, la mayoría de los protocolos utilizan un puerto
solamente. Uno de ellos es necesario para establecer el
control de la conexión y otro se utiliza para el control de
la transmisión: en este caso, se utiliza el puerto 21 para el
control de la conexión y otro para determinar el modo de
conexión.

36
 Despliegue de aplicaciones web

3.2.  Tipos de usuarios y accesos

al servicio
Ya que hemos visto que es un protocolo orientado a cone-
xión, necesitamos en primer lugar la conexión entre cliente
y servidor mediante un usuario y una contraseña. Existen
dos tipos de usuarios:
1. Usuarios anónimos: estos usuarios tienen acceso y
permisos limitados.
2. Usuarios del sistema: son aquellos usuarios que defi-
ne el servidor y tienen los permisos que hemos creado
para ello y sobre la carpeta que el servidor tiene confi-
gurado.
3. En ciertos servidores, existe un tercer tipo de usuario,
los usuarios virtuales. Es un paso intermedio entre los
dos usuarios anteriores. Sin necesidad de ser usuarios
del sistema, poseen unas credenciales para su conexión.
Los usuarios virtuales tienen su propia contraseña de-
finida en un fichero de texto para su almacenamiento.

3.3.  Modos de conexión del

cliente
Como hemos comentado con anterioridad, el protocolo
FTP necesita dos puertos para su ejecución: uno para
definir el modo de conexión del cliente FTP y el otro es
la configuración del servidor FTP.

Al inicio del proceso, se realiza la conexión a un servidor

FTP, se abre el puerto 21 en el servidor y toda la transmisión
de los datos a los clientes se realiza a través de otro puerto
que configure el administrador de la red. Dependiendo del
modo de conexión entre el cliente y el servidor, se puede
realizar el proceso de varias formas diferentes:

• Modo activo: es el método original de transferencia de

datos. Cuando el cliente empieza el proceso de transfe-
rencia de datos mediante FTP, el servidor abre el puerto
para la dirección IP. Es el cliente quien debe aceptar las
conexiones definidas por el servidor. Este modo de co- ponte a prueba
nexión está en desuso por el crecimiento de la red de
internet y la seguridad en la transferencia. Por esta razón, ¿Cómo es la arquitectura que
se utilizaron los cortafuegos en el equipo cliente, pero emplea el protocolo FTP?
están configurados para que este tipo de conexiones in- a) Peer to peer
seguras sean rechazadas. b) Cliente-servidor
• Modo pasivo: fue creado para solucionar el problema con c) Servidor de aplicaciones
los cortafuegos, siendo el servidor quien recibe las peti- d) Servidor de aplicaciones
ciones. El cliente indica el deseo de transmitir los datos al externo
servidor y, a continuación, el cliente se conecta al puerto
en el servidor y descarga la información requerida.

37
 Tema 3: Instalación y administración de servidores de transferencia de archivos

3.4.  Protocolo de transferencia

de archivos seguro
Hemos comentado la inseguridad con la que trabaja la
conexión en FTP. Por tanto, ese aspecto es el que debe-
mos solventar para que el uso de este protocolo sea más
generalizado. En aquellos casos en los que la seguridad en
el viaje de los datos sea un aspecto importante, debemos
utilizar el protocolo FTPS. Se trata de una extensión del
protocolo anterior, pero con el cifrado SSL/TLS.

El tratamiento de seguridad adicional puede ejecutarse

de dos formas diferentes:

• Implícito o FTPS: es el cliente quien asume la seguridad

con TSL o SSL desde que realiza la conexión, es decir, an-
tes de la transferencia de información. Normalmente, usa
otros puertos en lugar del puerto 21 que utiliza de forma
habitual.
• Explícito o FTPES: el cliente se conecta al puerto 21 y
cambia a un modo seguro utilizando TSL o SSL para la
transmisión de información.
El cifrado que utiliza este procedimiento está relacionado
con el conjunto de las claves tanto pública como privada.
La primera es conocida por todo el mundo, mientras que la
siguiente solo la conoce el usuario. Ambas son necesarias
para que la comunicación sea posible, tanto para el proceso
de cifrado como para la desencriptación.

En el cifrado asimétrico podemos estar hablando de in-

dividuos o de máquinas, en nuestro caso, hablamos de
máquinas y de flujo de información entre el cliente FTP(A)
y el servidor FTP(B). Veamos la siguiente tabla como
ejemplo de funcionamiento del cifrado asimétrico:

38
 Despliegue de aplicaciones web

Para el proceso de cifrado de la información, el cliente uti-

liza la única clave que conocemos del servidor, es su clave
pública. El resultado de este proceso es lo que se envía al
servidor y, cuando le llega a este último, la clave que nece-
sita para desencriptar el mensaje y poder conocer cuál es
realmente su información es la clave privada.

Como las dos claves tienen relación, el proceso es correcto

cuando, al utilizar las dos claves, el mensaje es que el que
deseábamos enviar.

3.5.  Utilización de herramientas

gráficas
Para poner a prueba el funcionamiento de este protocolo
FTP, podemos realizarlo de varias formas:
• En el caso de tener el servidor instalado, con nuestro sis-
tema operativo server (para facilitar la administración
de la red) podemos añadir al gestor del dominio (Active
Directory en caso de Windows o LDAP en caso de Linux)
el servicio de servidor FTP y tan solo haría falta la herra-
mienta en el cliente para la transferencia.
• Otra de las opciones que podemos valorar son las herra-
mientas que existen en el mercado que no requieren de
un equipo servidor en sí y un cliente, simplemente, herra-
mientas que simulan el servidor FTP y, en otra máquina,
el cliente FTP. Un ejemplo de este caso puede ser FileZilla
(https://filezilla-project.org/).

Para cualquiera de las dos opciones que hemos comentado

para el proceso de una transferencia mediante el protocolo
FTP, en la parte del servidor debemos tener en cuenta los
siguientes aspectos:
• Debemos configurar una dirección IP para que los clien-
tes se conecten al servidor FTP. El administrador de la red
debe definir los usuarios que tienen permitida la entra-
da y la carpeta a la que tienen acceso. Cada usuario solo
puede acceder a su directorio correspondiente.
• De igual manera, debemos confeccionar una contraseña
para el usuario. Debemos dejar claro que puede que va-
ríe este paso en algunas herramientas FTP, ya que existen
programas que permiten variar la contraseña después
del primer acceso, mientras que en otras herramientas la
contraseña la define el usuario. Lo más conveniente para
el administrador es que diseñe él mismo las credenciales
de los clientes, dependiendo de sus datos.

39
 Tema 3: Instalación y administración de servidores de transferencia de archivos

• Seguidamente, especificaremos la numeración de los

puertos. Ya sabemos por anteriores apartados que exis-
ten diferentes puertos para la misma acción, pero como
normal general se utiliza el mismo por defecto.
• Por último, el administrador debe elegir la carpeta sobre
la que va a trabajar el usuario en cuestión.

En el equipo cliente, también vamos a utilizar el cliente de

FileZilla; en este caso, el servidor le proporcionará toda la
información definida anteriormente. Una vez realizada la
conexión correctamente, podremos trabajar sobre el direc-
torio asignado.

40
 Despliegue de aplicaciones web

3.6.  Utilización del servicio de

transferencia de archivos desde el
navegador
No hace falta la instalación de una herramienta para trans-
mitir datos mediante el protocolo FTP. El navegador web
también puede ejercer de cliente FTP, y esta es una de
las herramientas más utilizadas para los procesos de
transferencia de archivos.

Este proceso es muy simple (por esta razón es una de las

herramientas más utilizadas en este proceso), ya que solo
debemos acceder a la barra de direcciones y escribir “ftp://
nombredelservidorftp:puerto” en vez de “http://”, que es a
lo que estamos acostumbrados.

De esta forma, no hace falta la instalación de ninguna

herramienta. Una vez accedida, entramos en el servidor,
donde el primer paso es la ventana para que introduzcamos
el usuario y contraseña, ya que necesitamos establecer la
conexión. Para descargar los documentos simplemente
debemos elegir la opción típica Guardar enlace como.

En la imagen podemos ver la forma de acceder a un servidor FTP que no tiene

credenciales, ya que pertenece a una Administración pública.

41
 Tema 3: Instalación y administración de servidores de transferencia de archivos

3.7.  Utilización del servicio

de transferencia de archivos en
el proceso de desarrollo de la
aplicación web
Además del navegador, también es usual el hecho de uti-
lizar cualquier aplicación web en internet que disponga de
las opciones necesarias subir archivos mediante el código
fuente de un programa propio, nuestro propio portal web o
una aplicación de terceros.

El tiempo de espera en el que puedes mantener la cone-

xión entre el cliente y el servidor es lo que hay que tener
en cuenta a la hora de configurar nuestro propio sitio
web. Los parámetros como tiempo de conexión, tamaño
máximo de subida de archivos e incluso tamaño máximo
del archivo que subir es lo que hay que definir de acuer-
do con las necesidades de la empresa, y así los datos no
sufrirán el periodo de desconexión a la hora de transmitir
la información.

Actualmente, este proceso de FTP se utiliza bastante en el

procedimiento de conectarnos a un hosting externo y de-
bemos subir la página web para que sea el propio servidor
el que la cuelgue en internet.

Para futuros procesos de ampliación o mantenimiento de

este servicio, sería conveniente, a la hora de configurar
este procedimiento entre el servidor y el cliente, explicar
detalladamente todo el proceso, y cuanto más detallado
sea el documento, más beneficioso será en un futuro.

42
 Despliegue de aplicaciones web

Debido al gran auge de las páginas web, los editores, en al-

gunos casos, permiten subir el código al servidor mediante
FTP, dado que puede resultar más sencillo que el uso de
una aplicación de FTP independiente. En todo este proceso
de subida debemos pensar siempre en la seguridad de la
información.

A continuación, podemos ver algunos errores junto con

su posible solución a la hora de subir datos mediante un
servidor FTP:

• Al cliente se le muestra el error de “Acceso denegado”.

Debemos comprobar las credenciales del usuario y los
permisos para visualizar las carpetas a la que puede ac-
ceder y las operaciones que puede realizar en cada una
de ellas. ponte a prueba
• Al cliente FTP se le muestra el mensaje de que “Hay
demasiadas conexiones abiertas”. En ese caso, nos El navegador web también
aseguraremos de que el funcionamiento de las aplicacio- puede ejercer de cliente FTP.
nes abiertas no interfiera en las conexiones que vamos a a) Verdadero
realizar. Otro de los aspectos para tener en cuenta en este b) Falso
tipo de errores es la existencia de un cortafuego, ya que
este interfiere en la ejecución de la conexión.

43
4
ADMINISTRACIÓN DE SERVIDORES DE

APLICACIONES
 Despliegue de aplicaciones web

Un servidor de aplicaciones es una herramienta que

proporciona un conjunto de aplicaciones a los clientes co-
nectados a él. La centralización de las aplicaciones y la
disminución en la complejidad de la implementación de
estas hacen que este tipo de servicio sea muy utilizado, sin
embargo, al ser servidores web en su mayoría, estas aplica-
ciones están más expuestas a ataques externos.

Las aplicaciones de hoy en día tienen acceso a información

muy valiosa, como pueden ser datos bancarios, por tanto,
la seguridad se presenta como un rasgo que se debe tener
muy en cuenta, ya que el objetivo de un posible ataque
puede estar dirigido a información muy sensible.

Estos ataques se pueden clasificar con base en tres niveles:

1. Ataques a la computadora cliente.
2. Ataques al equipo servidor.
3. Ataques al flujo de información que se transmite.

En cada nivel anterior es recomendable garantizar un

mínimo de seguridad.
1. Para los equipos de los clientes podemos utilizar la
seguridad de sus navegadores y softwares que utilice
para internet. De esta forma, las transmisiones vía onli-
ne se realizarán de forma segura y libre de virus.
2. En cuanto al servidor, debemos acreditar el acceso,
controlando los usuarios que entran en el equipo, y, por
otra parte, debemos asegurar los permisos concedidos
a cada uno de ellos y que se corresponden con los roles
asignados por el administrador de la red.
3. En lo que se refiere al tránsito de la información, de
la confidencialidad de los datos, debemos asegurarnos
de que no será leída por personas ajenas al dominio,
modificada o destruida, y al mismo tiempo debemos
garantizar la seguridad en el canal por la que se trans-
mite dicha información.

Los mecanismos que se tienen que implementar para

garantizar la seguridad deben contemplar una serie de
características:
• La autenticación que permite identificar y comprobar
que el usuario está accediendo en ese instante al sistema
es una persona habilitada por el sistema. Podemos utili-
zar distintos tipos de mecanismos, desde la autenticación
básica consistente en introducir usuario y contraseña
hasta una autenticación más completa, como utilizar el
certificado digital.

45
 Tema 4: Administración de servidores de aplicaciones

• La autorización permite que, una vez dentro del sistema,

según el rol que desempeñemos, tengamos acceso a de-
terminados módulos u opciones, restringiendo el acceso
a aquellos en los que no debemos entrar.
• Otra de las características para tener en cuenta es la va-
lidación de las entradas y los comandos SQL que utilizar
para validar las consultas.

Para mejorar la seguridad de las aplicaciones web alo-

jadas en el servidor, debemos tener en consideración las
siguientes orientaciones:
• Deshabilitar aquellos servicios y cuentas que no utilice-
mos.
• Actualizar tanto el sistema operativo como las apli-
caciones, ya que estas actualizaciones contendrán los
mecanismos de defensa frente a los últimos ataques
aparecidos.
• Reforzar la filosofía de las contraseñas.
• Utilizar cortafuegos lo más actuales posible.
• Analizar los archivos de registros periódicamente.
• Llevar el control del mecanismo de cifrado que estamos
utilizando para la encriptación de los datos que transmitir.
• Cumplir severamente las normas de seguridad estableci-
das en las políticas de seguridad del sistema.

46
 Despliegue de aplicaciones web

4.1.  Arquitectura y
configuración básica del servidor
de aplicaciones
Un servidor servlet consiste en disponer un conjunto de
archivos para que los clientes puedan acceder. En un servi-
dor web, además, dispone de páginas HTML, JSP y otros
recursos que se pueden empaquetar.
CONCEPTO

Una aplicación web puede desplegarse en

diferentes servidores web, esto es gracias a las
aplicaciones servlet.

El árbol de directorio que organiza las aplicaciones web

empieza por el directorio raíz o directorio del que cuel-
gan los demás directorios del árbol, como las carpetas que
contengan los ficheros HTML y JSP, referentes a las páginas
estáticas y dinámicas respectivamente.

Dentro de estas últimas, están las subcarpetas que contie-

nen los ficheros servlets y beans, las librerías que ayudan a
implementar el código y el resto de las carpetas que contie-
nen los ficheros estáticos.

Para el despliegue de una aplicación web, debemos utilizar

uno de los siguientes métodos:

1. Método WAR: archivo comprimido que contiene todo

lo necesario para el despliegue. Es el más correcto.
2. Editar los archivos XML incluyendo los archivos web.
xml y server.xml (vamos a verlo a continuación).

En las carpetas que forman la aplicación es en las que

deben ubicarse los archivos que desplegar, como “www”,
“bin” o “src”. Por ejemplo, en “www” se alojarán los archivos
para que puedan ser ejecutados ante una petición web,
mientras que tanto en “bin” como en “src” estarán ubicados
los ejecutables y código fuente respectivamente de algún
lenguaje de programación, como, por ejemplo, Java.

El proceso para desplegar una aplicación en el servidor de

aplicaciones Tomcat es el siguiente:

1. En la carpeta “webapps” debemos copiar la carpeta

“www” de la aplicación web.
2. Crear un árbol de directorio con una carpeta principal
llamada como la aplicación que queremos ejecutar, y en
su interior crear una carpeta “web-inf” y dentro de esta
otras más internas llamadas “lib” y “clases”.

47
 Tema 4: Administración de servidores de aplicaciones

3. Dentro de la carpeta “lib” tienen que ir los archivos

ejecutables .jar de Java que se necesite para el funcio-
namiento de la aplicación.
4. Los archivos binarios deben alojarse en el subdirectorio
“WEB-INF/classes” de Tomcat.
5. Además, en la misma carpeta debe estar un fichero
de texto llamado web.xml con las rutas de los servlets
utilizados en la aplicación.
6. Como último paso, solo nos queda acceder a la aplica-
ción mediante el navegador.

4.2.  Administración de
aplicaciones web
Para realizar las tareas de creación y despliegue de la apli-
Administración de cación en el servidor, este debe tener iniciado los servicios
aplicaciones web
de servlets y JSP.
youtu.be/jjWx7yo2h_4
La creación de dos variables de entornos nos ayudará al
manejo de las aplicaciones:

• JAVA_HOME nos indicará la ruta de los archivos en Java.

• CATALINA_HOME localizará la ubicación de los scripts
de Tomcat.

Como podemos ver en otro de los módulos de este lenguaje,

Javascript se ejecuta del lado del cliente y es interpretado por
script. Primero crearemos el siguiente árbol de directorio.

Aplic_Web/
Index.jsp
WEB-INF
classes
lib

A continuación, ejecutaremos el archivo .jsp como aplicación

web y, para terminar, haríamos una copia de la aplicación en
la ruta “$CATALINA_HOME/webapps” y desde el navegador
accedemos a localhost/Aplic_Web o 127.0.0.1/Aplic_Web.
Así ya tendríamos la aplicación funcionando.

El hecho de que la aplicación se despliegue en

varios servidores manteniendo su funcionalidad y
sin ninguna modificación de código es uno de los
objetivos que estamos persiguiendo.

48
 Despliegue de aplicaciones web

Anteriormente, hemos mencionado los archivos compri-

midos WAR. Utilizar estos archivos es la mejor forma de
implementar este tipo de utilidad. La especificación 2.2
de los servlets estandarizó los pasos que seguir para que
el despliegue de las aplicaciones se pueda llevar a cabo en
varios servidores y así poder conseguir la portabilidad del
código Java.

Además de los archivos WAR, existe otro método para

poder ejecutar la operación que tenemos entre manos.
Este método es aconsejable sobre todo porque pode-
mos aprovechar la estructura de directorios que hemos
utilizado anteriormente. Consiste en copiar la carpeta
correspondiente a nuestra aplicación en la carpeta “$CATA-
LINA_HOME/webapps”, teniendo en cuenta que la variable
$CATALINA_HOME es la ruta de los scripts que emplea
Tomcat.

Lo único en que se diferencia del método anterior es en la

creación de un fichero descriptor web.xml, que es el en-
cargado de describir las características de despliegue de
la aplicación. Este fichero lo almacenaremos en la carpeta
“WEB-INF” perteneciente a la aplicación en desarrollo.

El siguiente paso es la generación del fichero WAR y, a

continuación, acceder a la aplicación con el mismo proce-
dimiento anterior en la dirección localhost en el navegador.

49
 Tema 4: Administración de servidores de aplicaciones

4.3.  Autenticación de usuarios.

Dominios de seguridad para la
autenticación
En este punto veremos el procedimiento para configurar
los registros de acceso a un servidor de aplicaciones
Tomcat. En este caso, emplearemos el método llamado
válvula de registro de acceso de Tomcat.
Es una tecnología introducida a partir de Tomcat 4 que
permite asociar una instancia de una clase Java a un
contenedor Catalina. Dicha configuración está imple-
mentada para permitir que la clase haga una operación
de procesamiento previa a las peticiones. A estas clases
les damos el nombre de válvulas y se implementan en la
interfaz org.apache.catalina.
Estas válvulas son propias de Tomcat, por tanto, no pueden
ser utilizadas en otras herramientas servlet. Existen dife-
rentes válvulas en la herramienta Tomcat:
• Access Log Valve: crea los ficheros log para acceder a la
información de los clientes, como, por ejemplo, la sesión
o la autenticación de los usuarios.
• Remote Address Filter: esta válvula es la que compara la
IP del cliente con la expresión regular y, dependiendo del
resultado, el acceso será o no permitido.
• Request Dumper: esta herramienta de depuración des-
cribe los detalles de los registros log.
• Single Sign On: es la válvula que permite la identifica-
ción de un usuario desde cualquier dispositivo conectado
a nuestra red y, por tanto, con acceso al servidor que lo
comprueba.

50
 Despliegue de aplicaciones web

ponte a prueba

Una aplicación web no puede

desplegarse en diferentes
servidores web.
a) Verdadero
b) Falso

4.4.  Administración de sesiones.

Sesiones persistentes
Hoy en día, es muy común el manejo de sesiones activas
por parte de los usuarios en las páginas web. Cuando el
servidor donde se alojan dichas webs es un servidor de
aplicaciones Tomcat, estas están configuradas por defecto
para su mantenimiento ante posibles pérdidas de conexión
o reinicios con el servidor.

Además del control básico que se realiza sobre ellas,

podemos ampliar el control sobre dichas sesiones.
Respecto de las sesiones que todavía no han caducado,
es decir, las inactivas, es posible configurarlas para que
se almacenen en disco; de esta forma, se libera un poco
la memoria de control de las sesiones, ya que no se están
utilizando. Como consecuencia de ello, también se libera
los recursos de memoria asociados.

Al detener el servidor de aplicaciones Tomcat, las sesiones

activas se almacenan en el disco, de modo que es muy fácil
recuperarlas. Sin embargo, de las sesiones que superen un
tiempo definido, por cuestiones de seguridad, se realiza
una copia automáticamente y así también se evitan los
bloqueos de esta.

Para la gestión de las sesiones persistentes debemos rea-

lizar la configuración del elemento como un subelemento
dentro de la misma sesión; de esta forma, podremos actuar
a dos niveles, en función de cómo queremos que se apli-
que las funciones: en todas las aplicaciones o en algunas
en concreto.

Para configurar las sesiones persistentes de forma global,

debemos manipular el archivo /conf/context.xml, en cambio,
si lo que buscamos es configurar las sesiones a nivel local
a una aplicación web determinada, deberíamos adaptar el
archivo /conf/context.xml correspondiente a la aplicación.

51
 Tema 4: Administración de servidores de aplicaciones

4.5.  Archivos de registro de

acceso y filtro de solicitudes
Los ficheros de registro de este apartado los veremos sobre
una máquina Linux. Antes de empezar con el procedimien-
to, debemos visualizar la ruta donde el servidor Apache
define la configuración de estos ficheros de registro (logs).
Para ello, iniciamos sesión en el servidor Linux con un
usuario de administración, accedemos a nuestro directorio
donde se haya instalado el servidor Apache y visualizamos
el archivo 000-default.conf.

Debemos centrar nuestra atención en la directiva que indi-

ca ErrorLog, ya que será la encargada de definir la ruta del
fichero error.log junto con la cláusula Loglevel para indicar
el nivel de prioridad.

4.6.  Configuración del

servidor de aplicaciones para la
cooperación con servidores web
En este apartado veremos la administración de un servidor
de aplicaciones Tomcat Web. El primer paso es el listado
de las aplicaciones desplegadas: para ello, debemos iniciar
nuestro cliente y acceder al Tomcat Web Manager me-
diante la dirección IP configurada como la del servidor y a
continuación “manager” y “html” como directorio de ruta.
(192.168.1.1/manager/html). Después insertamos las cre-
denciales para acceder a nuestro servidor Tomcat Web.

52
 Despliegue de aplicaciones web

Una vez en el interior del servidor, podemos ver el listado

de las aplicaciones en el apartado Gestor de Aplicaciones.
El siguiente paso es iniciar las aplicaciones elegidas, pero,
antes de comenzar, debemos comprobar el estado de la
aplicación en la ventana de anterior, ya que, si accedemos
a la aplicación y no está en funcionamiento, nos dará error.
Por tanto, para poner la aplicación en marcha, debemos
acceder mediante dirección IP a la aplicación.

4.7.  Despliegue de aplicaciones

en el servidor de aplicaciones
Para el despliegue de aplicaciones usaremos el servidor
Apache Ant bajo Linux. Para ello, debemos habilitar la he-
rramienta Tomcat Web Manager de nuestro servidor Linux.
Nos acreditaremos con un usuario que tenga el rol de ma-
nager-script, ya que tenemos que acceder al modo texto.

En nuestro cliente Linux configuraremos el software Ant en

Eclipse para que podamos usar la librería Tomcat. De esta
forma, se definen las tareas para interactuar con el modo
texto de nuestro servidor mencionado anteriormente.

En dicho cliente, creamos un fichero llamado build.xml

para definir las tareas de Ant. En el proyecto donde hemos
creado el fichero se añadirá el fichero .war y las listas de
aplicaciones desplegadas en el servidor. Como último
paso, iniciaremos las aplicaciones para que se puedan
desplegar.

En el anterior apartado hemos resumido todo el proceso. A

continuación, empezaremos con la configuración del acce-
so al modo texto de Tomcat Web Manager, debemos iniciar
el servidor con un usuario con privilegio de administrador.

Como paso siguiente, editaremos el fichero tomcat-users.

xml, donde se encuentran todos los usuarios registrados en
el servidor de aplicaciones.

En este apartado configuraremos para que el usuario tenga

permisos de manager-script de la siguiente forma:

<user username=”tomcatscript” password=”despliegue” roles=”manager-script”/>

Para que la anterior configuración tenga efecto, debemos

reiniciar el servidor y, seguidamente, desde el cliente (Win-
dows o Linux) acceder a la dirección IP del servidor desde
cualquier navegador mediante el usuario creado.

Para ver la lista de aplicaciones desplegadas podemos uti-

lizar el comando list.

53
 Tema 4: Administración de servidores de aplicaciones

Otra forma de configurar el servidor de aplicaciones es

mediante el software Eclipse y su librería Ant. Para ello,
iniciaremos en nuestro cliente Windows la herramienta
Eclipse. Accederemos al menú Windows > Preferences >
Ant > Runtime.

En la lista de opciones seleccionamos Ant Home Entries y

pulsamos el botón para añadir un ejecutable (.jar) externo
y añadiremos las siguientes librerías:
1. Catalina-ant.jar
2. Tomcat-coyote.jar
3. Tomcat-util.jar
4. Tomcat-juli.jar

Para crear el fichero build.xml mediante Eclipse, lo primero

que tendremos que hacer es habilitar la vista de Ant me-
diante las siguientes opciones: Windows > Show View >
Other > Ant > Ant.

En dicha ventana, crearemos el fichero asignándole la

extensión .xml y lo posicionaremos en el directorio raíz de
nuestro proyecto.

Seguidamente, abrimos la tarea de Ant y cambiamos su

ponte a prueba configuración en la propiedad ManagerUrl, cuyo valor sería
la dirección del servidor y la carpeta “Manager/Text”.
¿Qué comando podemos usar
para ver la lista de aplica- A continuación, podremos comprobar que en la ventana
ciones desplegadas? del explorador de Eclipse aparece el nuevo fichero XML
a) apps creado anteriormente. En caso de que no aparezca, podre-
b) list mos añadirlo mediante la opción Add Builds File.
c) webapps Como último paso, nos queda probar la tarea: en la vista Ant
d) applications de Eclipse seleccionamos la opción Crear War y elegimos
el fichero correspondiente. Una vez creado, lo ejecutamos
mediante la opción Run As.

4.8.  Seguridad en el servidor

de aplicaciones. Configuración
del servidor de aplicaciones con
soporte SSL/T
Para la configuración de la seguridad en el servidor de
aplicaciones Tomcat, lo primero que debemos hacer es
asegurarnos de tener habilitado el servicio de seguridad
SSL en el host por defecto (localhost) y, a continuación,
configurar la aplicación para que solo permita conexiones
HTTPS.

54
 Despliegue de aplicaciones web

Vamos a detallar una serie de pasos para realizar la confi-

guración del servidor.

1. En primer lugar, debemos crear un almacén de clave

con certificado SSL. Para ello, es conveniente iniciar el
servidor Linux con un usuario de administrador. Utiliza-
remos la herramienta keytools para crear un certificado
autofirmado y guardarlo en nuestro almacén de clave.
Durante la creación de este certificado, tendremos que
introducir dos tipos de clave:
◦ La clave estándar.
◦ Las claves asociadas a nuestro alias en el servidor.
Para facilitar dicho proceso, pondremos la misma clave
en ambos apartados.
2. Seguidamente, debemos configurar un conector SSL en
nuestro servidor de aplicaciones, para lo que debemos
editar el fichero server.xml del servidor Linux. Para que
surta efecto, debemos reiniciar el servidor Tomcat y com-
probar que se están escuchando los puertos 8080 y 8443.

Desde un navegador de un equipo cliente, es necesario

establecer una conexión HTTPS con la dirección IP del ser-
vidor Linux. De esta forma, comprobaremos que el proceso
se ha configurado perfectamente.

Para realizar la configuración en nuestra aplicación y que

solo admita conexiones HTTPS, debemos editar la aplica-
ción y realizar la siguiente configuración:

<user-data-constraint>
<transport-guarantee>CONFIDENTIAL
</transport-guarantee></user-data-constraint> ponte a prueba

Para la configuración de la
Ahora ya podemos eliminar la aplicación del servidor de seguridad en el servidor de
aplicaciones Tomcat, ya que crearemos el ejecutable WAR aplicaciones Tomcat, debemos
con los correspondientes cambios, desplegaremos dicho fi- tener habilitado el servicio de
seguridad SSL en el host por
chero y comprobaremos el correcto funcionamiento desde
defecto (localhost).
el navegador de un equipo cliente mediante un protocolo
a) Verdadero
HTTPS.
b) Falso

Como nota aclaratoria diremos que es posible hacer

la comprobación estableciendo una conexión HTTP
a la aplicación: de esta forma, el servidor la redirige
automáticamente a una petición segura HTTPS.

55
5
SERVICIOS DE RED IMPLICADOS EN EL

DESARROLLO DE UNA APLICACIÓN WEB
 Despliegue de aplicaciones web

5.1.  DNS. Resolución de

nombres. Proceso de resolución de
un nombre de dominio
DNS son las siglas en inglés de sistema de nombres de
dominio (domain name system) y lo podemos describir
como los nombres que representan a las direcciones IP de
las páginas web. Cuando usamos la web, escribimos para
localizar las distintas páginas web unos nombres de domi-
nios como, por ejemplo, www.google.es.

Recordar estos nombres de dominios es mucho más fácil

que acordarnos de su correspondiente dirección IP, que,
para el caso de www.google.es, sería: 216.58.214.163.

Usando los nombres de dominios, si Google decidiera

cambiar su dirección numérica, el usuario no notaría
cambio alguno, ya que el nombre de dominio seguiría
siendo el mismo. La nueva dirección numérica se enlazaría
con el nombre de dominio y seguirá existiendo la conexión.

DNS es un servicio cliente/servidor que se diferencia de

los otros servicios cliente/servidor en que estos servicios
se ejecutan por sí mismos, sin necesidad de ninguna apli-
cación exterior. Admitirá resolución de nombres para otras
aplicaciones de red y servicios que lo necesiten.

Normalmente, el proveedor de internet nos proporciona

direcciones para usar con los servidores DNS. En el momento
en que una aplicación de usuario pide conectarse con un
dispositivo remoto por nombre, el cliente DNS solicitante
manda una petición a uno de esos servidores de nombre
con el fin de resolver el nombre en una dirección numérica.

57
 Tema 5: Servicios de red implicados en el desarrollo de una aplicación web

Cuando escribimos un nombre de dominio, lo hacemos

escribiendo una serie de caracteres y puntos.

Vamos a describir cada parte de un nombre de dominio, en

este caso, http://www.google.es:

• Primero, los puntos separan los dominios y subdominios;

comenzando desde la parte derecha a izquierda, tendre-
mos dominios de primer nivel y dominios de segundo
nivel, tercer nivel, etcétera, denominados subdominios:
– .es: es un dominio de primer nivel y tiene como signifi-
cado que es un servidor español.
– google: es un subdominio, en este ejemplo, un dominio
de segundo nivel bajo .es que identifica el nombre de la
empresa.
– www: es un subdominio, un dominio de tercer ni-
vel bajo google que identificará el equipo donde está
catalogada la página web. Es el dominio www que el
servidor DNS redirecciona a la IP del servidor web.

www.google.es

subdominio subdominio dominio

58
 Despliegue de aplicaciones web

• Segundo, http:// es el protocolo de hipertexto que nos

permite la visualización de la página web en el navegador.

Los dominios deben cumplir una serie de

requisitos gramaticales:
• Solo pueden estar compuestos de letras,
números y guiones.
• No pueden empezar y terminar en guiones.
• Deben tener menos de 63 caracteres y más de
uno o dos dependiendo del dominio de primer
nivel.

Funcionamiento del servicio DNS

Para comprobar el funcionamiento de este servicio, vamos

a usar unas herramientas que nos van a permitir realizar
consultas en los servidores: los comandos nslookup y dig.
Con estas herramientas podremos realizar varias accio-
nes, como comprobar el funcionamiento del servicio DNS,
obtener información y verificación de que los servidores
funcionan correctamente.

Para ello, lo primero que tendremos que hacer será iniciar

sesión en nuestra consola. Después utilizamos el comando
nslookup para obtener las direcciones IP que estén asocia-
das al nombre DNS www.andalucia.org:

nslookup www.andalucia.org

Al ejecutar este comando comprobamos que el servidor

DNS que nos responde es el que está configurado en nues-
tras propiedades TCP/IP del equipo. También veremos que
existen distintas IP asociadas al nombre de dominio, así
como la respuesta que obtenemos no es autorizada.

Como segundo paso podremos usar el comando nslookup

para obtener los nombres de dominio que irán asociados a
la dirección 217.12.28.57.

nslookup 217.12.28.57

Otra tarea que podemos realizar será obtener las IP aso-

ciadas al nombre DNS www.andalucia.org preguntando al
servidor DNS 8.8.4.4.

nslookup www.andalucia.org 8.8.4.4

59
 Tema 5: Servicios de red implicados en el desarrollo de una aplicación web

Si usamos una versión Linux, podremos ejecutar los si-

guientes comandos:

• Obtención de direcciones IP asociadas a un nombre

DNS: nslookup [nombreDNS].
• Obtención de direcciones IP asociadas a un nombre
DNS usando el comando dig: dig [nombreDNS].
• Uso del comando dig para obtener nombres de domi-
nios asociados a una dirección IP: dig -x [dirección IP].
• Uso del comando dig para obtener direcciones IP que
estén asociadas a un nombre de dominio preguntando
al servidor 8.8.4.4: dig @8.8.4.4 [nombreDominio]

Ahora procederemos a realizar la instalación y configu-

ración de un servidor DNS en Microsoft Windows 2019
Server:

Instalación

Para realizar la instalación, lo primero que tendremos que

hacer será iniciar sesión en Microsoft Windows Server
como administrador. Pulsaremos en Inicio y seleccionamos
Administrador del Servidor.

En el árbol que nos aparece a la izquierda, debemos selec-

cionar Funciones. Nos aparecerá una ventana en la parte
derecha y hacemos clic donde pone Agregar Funciones.

Leemos la información que nos proporciona y pulsamos en

Siguiente para continuar. Elegimos la función Servidor DNS
y pulsamos en Siguiente.

Nos dará información sobre lo que nos ofrece el servidor

y cosas para tener en cuenta. Pulsamos en Siguiente. Una
vez realizados estos pasos, pulsaremos en Instalar para
proceder a la instalación del servidor.

Cerraremos el asistente al finalizar el proceso de instala-

ción. Nos mostrará el resumen de funciones y en la parte
izquierda aparecerá un enlace para el servidor DNS. Obser-
varemos que el servidor DNS se ha iniciado.

Iniciaremos un terminal, ejecutamos el comando netstat -a

-n y comprobamos que el servidor está a la escucha en los
puertos 53 TCP y UDP.

A través del menú Inicio > Herramientas Administrati-

vas se ha creado una entrada DNS que nos va a permitir
acceder a la consola del servidor.

Se habrá creado también una excepción en el firewall de

Windows para el servidor DNS.

60
 Despliegue de aplicaciones web

Configuración

Por defecto, el servidor solo se habrá configurado como

caché respondiendo a consultas recursivas.

Para comprobar que el servidor DNS resuelve correcta-

mente los nombres de dominios, configuraremos el cliente
para que use el servidor DNS instalado en la máquina local
utilizando 127.0.0.1.

5.2.  Parámetros de
configuración y registros del
servidor de nombres afectados en
el desarrollo
Configuraremos el servidor DNS anterior para que funcione
como primario y de forma local, no funcionará ni dará ser-
vicio a equipos de internet.

Este servidor funcionará como maestro usando el dominio

dawXX.net, sin permitir actualizaciones dinámicas, y será
servidorwXX.dawXX.net.

Vamos a configurar los siguientes nombres de dominio:

• Desarrollw7XX.dawXX.net asociado a la dirección IP
192.168.1.X6.
• servidorlinuxXX.dawXX.net asociado a la dirección IP
192.168.1.X7.
• servidorw2019XX.dawXX.net asociado a la dirección IP
192.168.1.X8.

61
 Tema 5: Servicios de red implicados en el desarrollo de una aplicación web

Configuraremos también algunos alias:

• ns.dawXX.net será un alias de servidorw2019XX.dawXX.
net.
• asterix.dawXX.net será un alias de desarrollow7XX.
dawXX.net.
• obelix.dawXX.net será un alias de servidorlinuxXX.dawXX.
net.
• panoramix.dawXX.net será un alias de servidorw2019.
dawXX.net.

Para configurar un sufijo en el servidor DNS, iniciaremos

sesión en el servidor Windows con el usuario administrador.

Accederemos a Inicio y en Equipo pulsamos el botón

derecho del ratón para pulsar nuevamente en Propie-
dades. Una vez que nos muestre la ventana, pincharemos
sobre Configuración avanzada del sistema. Accedemos
a la pestaña Nombre de equipo y pulsamos en Cambiar.
Pinchamos en Más y en Sufijo DNS principal del equipo
introducimos dawXX.net. Aceptaremos los cambios y
reiniciamos el equipo.

Configuración de la zona de resolución directa

Iniciamos sesión en el servidor como administrador.

Seguidamente accederemos a la consola del servidor DNS

desde Inicio > Herramientas Administrativas > DNS. Hare-
mos clic derecho del ratón sobre Zonas de búsqueda directa
y seleccionamos Zona nueva.

Pulsamos en Siguiente y seleccionamos Zona principal para

pulsar de nuevo en Siguiente. En la siguiente ventana intro-
ducimos dawXX.net como nombre de la zona. Dejaremos
seleccionada la opción Crear un archivo nuevo con este
nombre y dejaremos el nombre que nos viene por defecto.

Elegimos la opción No admitir actualizaciones dinámicas

y pulsamos en Siguiente para después pulsar en Finalizar.

Una vez que hemos terminado, observaremos que se ha

creado una entrada en Zonas de búsqueda directa con el
nombre de la zona (dawXX.net).

Si pinchamos sobre esa zona, se abre una consola de recur-

sos que se han creado automáticamente. Se ha añadido la
zona de registro SOA y un registro NS.

Hacemos clic sobre el registro SOA y observamos sus

propiedades. Después hacemos clic sobre el registro NS y
observamos sus propiedades. El campo dirección IP apare-
cerá desconocido porque no se ha creado un registro A para
el nombre servidorw2019.dawXX.net.

62
 Despliegue de aplicaciones web

Para crear los registros A hacemos clic sobre la zona dawXX.

net con el botón derecho del ratón y seleccionamos Host
nuevo. Introducimos el nombre y la IP, y si estuviese creada
una zona de resolución inversa podríamos marcar la opción
Crear registro del puntero (PTR) asociado.

Comprobar la configuración

Para comprobar la configuración usamos el comando ns-

lookup en el servidor DNS resolviendo las consultas sobre
los nombres de la zona dawXX.net.

5.3.  Servicios de directorios.

Características y funcionalidad
A través de los directorios vamos a ser capaces de localizar
información y nos definirán qué tipo de información alma-
cenarán y de qué manera.

Estos directorios también presentarán alguna serie de

problemas:

• Son directorios estáticos e inflexibles. La información

impresa no podrá ser actualizada si se produce alguna
modificación. Los directorios digitales, en cambio, po-
drán ser consultados o actualizados en tiempo real.
• Son inseguros. Será difícil controlar quién accede a la in-
formación impresa. Sin embargo, los directorios digitales
pueden ser fácilmente controlados, permitiendo el acce-
so solamente al que disponga de la clave de acceso.

63
 Tema 5: Servicios de red implicados en el desarrollo de una aplicación web

Por tanto, los directorios digitales nos van a permitir:

• Encontrar información de forma más fácil.

• Gestionar la información de forma más eficaz y al ins-
tante. Varios usuarios pueden actualizar la información
en tiempo real y las aplicaciones asociadas pueden acce-
der a ella.
• Controlar la seguridad en el acceso a la información.
Podemos controlar la seguridad con la gestión de cer-
tificados para su creación, distribución, destrucción o
ubicación.

Los directorios se diferencian del servicio DNS en:

• Los directorios no realizan una acción concreta,

mientras que los servidores DNS traducen nombres de
dominios a direcciones IP.
• En los directorios la información no es fija y los servido-
res DNS sí poseen una estructura fija.
• Los directorios permiten actualizaciones, mientras
que el servicio DNS no.
• Los servicios de directorio utilizan un protocolo UDP,
mientras que el servicio DNS opera con protocolos TCP.

Aunque tengan diferencias, es normal encontrarlos traba-

jando juntos en distintas aplicaciones, como servidores de
correo, gestión de proyectos, etcétera.

Organización del directorio LDAP

El servicio de directorio puede ser de dos tipos: centrali-

zado o distribuido.

• Si es centralizado, un solo servidor ofrece todo el ser-

vicio de directorios, respondiendo a todas las consultas.
• Si es distribuido, serán varios servidores los que propor-
cionan el servicio de directorio. En este caso, los datos
podrán ser fraccionados y/o replicados.

El directorio LDAP tendrá una estructura en forma de árbol

llamada DIT. Cada entrada va a describir un objeto. A la ruta
completa a una entrada la llamaremos DN y las partes más
pequeñas se llamarán RDN.

Una clase objeto (objectclass) es una descripción general

de un tipo de objeto. Todos los objetos deberán tener un
atributo objectclass. Los valores de los atributos los podrán
cambiar los clientes, pero no podrán eliminar el atributo.

64
 Despliegue de aplicaciones web

CONCEPTO

Un esquema nos define qué tipo de objetos podemos

almacenar, qué atributos podrá contener, cuáles son
opcionales y el formato de dichos atributos.
ponte a prueba

Los dominios pueden empezar

Existirán dos tipos de objetos: contenedor y hoja. y terminar en guiones.
a) Verdadero
• El tipo contenedor, como su nombre indica, podrán con-
b) Falso
tener a su vez distintos objetos, como, por ejemplo, el
directorio “root”.
• El tipo de objeto hoja se encuentra al final de una rama y
carecerá de objetos subordinados.

Al comienzo de la rama se encontrará el directorio raíz lla-

mado “root” al que le podrán seguir los elementos de nivel
inferior c (country), dc (domainComponent) u o (organiza-
tion).

A continuación, vemos una imagen de ejemplo de un nivel

de jerarquías LDAP:

DIT

Root

RDN dc=org dc=com dc=es

RDN dc=ejemplo

RDN ou=People ou=consultas

RDN uid=upruebas uid=upruebas2

DN:=uidupruebas,ou=People,dc=ejemplo,dc=com

65
 Tema 5: Servicios de red implicados en el desarrollo de una aplicación web

5.4.  Archivos básicos de

configuración. Interpretación y
uso
En todo servidor, debemos tener una herramienta para
administrar los diferentes servicios (servicio directorio).
La importancia de dicha herramienta es fundamental para
desplegar nuevas aplicaciones basadas en la cooperación
entre las distintas aplicaciones ya instaladas y el servicio
de directorios.

Este servicio de directorios puede actuar como aplicación

para la autenticación de usuario, proveedor del servicio
dhcp o gestor del dominio, entre otros.

En el sistema operativo Linux, a este gestor de directorios

se lo denomina LDAP. A continuación, vamos a ver los di-
ferentes pasos necesarios para la instalación de uno de
ellos, en este caso, el Open LDAP.

Esta herramienta se llevará a cabo mediante un usuario

root y, como requisito, es necesario tener configurada una
IP al servidor junto con un nombre al equipo.

Inicialmente, tenemos que actualizar, en el repositorio de

nuestro dispositivo, tanto el sistema operativo como los pa-
quetes necesarios para el funcionamiento del Open LDAP.
Dicha instalación incluye la solicitud de una contraseña de
administración que nos servirá para la configuración en el
paso siguiente.

A continuación, podemos seguir con el proceso de con-

figuración en el que se incluye toda la configuración del
servidor en un directorio base, teniendo como ventaja que
las futuras modificaciones se realizarían sin tener que rei-
niciar el servicio. La configuración se realiza en el directorio
base “enconfig” en lugar de hacerlo en el fichero sldap.
conf, donde lo hemos realizado en anteriores versiones.

Dentro de este directorio base, podemos encontrar cuatro

esquemas instalados por defecto. El árbol completo de este
servicio de directorios LDAP se genera a partir de dichos
esquemas, donde se definen los árboles de clases y atri-
butos permitidos para la organización del dominio. Una
vez configurado el servicio, debemos comprobar su estado
mediante el comando service seguido de sus diferentes
opciones:

• start, para arrancar el servicio.

• stop, para apagar el servicio.
• restart, para reiniciar el servicio.

66
 Despliegue de aplicaciones web

5.5.  Adaptación de la
configuración del servidor de
directorios para el desarrollo
de la aplicación. Usuarios
centralizados
La administración de usuarios y grupos con este servicio de
directorios LDAP se realiza de una forma sencilla mediante
el paquete ldapscripts, en el que se incluyen una serie de
paquetes para toda la gestión del dominio.

Como primer paso, debemos instalar el paquete mediante

la orden:

sudo apt-get install ldapscripts

A continuación, debemos editar el fichero de configuración

de este paquete para personalizarlo conforme a nuestras
necesidades. Lo realizaremos comentando las característi- ponte a prueba
cas oportunas.
En Linux, la administración
Para finalizar la instalación, introduciremos una contraseña de usuarios y grupos con el
para conectarnos a este servidor LDAP. Dicha contraseña se servicio de directorio LDAP,
introduce en el archivo ldapscripts.passwd. ¿mediante qué paquete se
realiza?
Mediante el uso y comandos de estos scripts, podremos a) ldap
crear, modificar y borrar tanto usuarios como grupos. b) openldap
También podemos optar por la creación de usuarios por c) ldapscripts
lotes. Esta opción la realizaremos subiendo en un archivo d) ldapp
de texto una serie de usuarios para automatizar más fácil-
mente su creación en nuestro servicio de directorios.

67
6
DOCUMENTACIÓN Y SISTEMAS DE CONTROL
 VERSIONES
DE
 Despliegue de aplicaciones web

6.1.  Documentación
A la hora de realizar la documentación, deberemos tener en
cuenta tres aspectos:

• La interfaz: es el canal a través el cual el usuario (del ni-

vel especificado) se comunica con un software de nivel
más bajo, con su propio equipo, una máquina remota, un
dispositivo o un usuario, entre otras opciones.
• La implementación: indicará el funcionamiento de cada
componente o función. Será útil para quienes depuren o
actualicen los bloques de código de la aplicación.
• Toma de decisiones: se indicará por qué se ha decidido
realizar cada acción de la aplicación. Es interesante a la
hora de implementar la aplicación por los desarrolladores.

¡RECUERDA!

La implementación no será necesaria transcribirla

fuera del código, en cambio, la interfaz sí sería
recomendable pasarla a un manual de uso.

El inconveniente de este tipo de documentación es que, si

se realiza cualquier cambio o modificación del código, hay
que reflejarlo en el manual de uso.

Podemos automatizar este proceso para que se genere la

documentación a través del código fuente usando herra-
mientas como, por ejemplo, phpDocumentor.

6.2.  Herramientas externas para

la generación de documentación.
Instalación, configuración y uso
Existen varias herramientas que nos permitirán generar
documentación automática a partir de un código. El están-
dar para Java es JavaDoc, aunque para PHP tendremos la
herramienta phpDocumentor.

La documentación es una parte importante del proyecto,

tanto como el código, ya que gracias a ella podremos más
adelante mantener la aplicación y, si trabajamos en equipo,
conocer y saber el funcionamiento de las partes realizadas
por el resto del grupo.

phpDocumentor nos va a ayudar a generar esa docu-

mentación de una forma similar a como lo hace JavaDoc.

69
 Tema 6: Documentación y sistemas de control de versiones

Mediante comentarios o etiquetas sencillas, definiremos lo

que realiza cada clase, cada método o función del código.

Nos permitirá generar la documentación de varias formas y

en distintos formatos, como desde la línea de comandos, la
interfaz web o el código.

En cualquier caso, tendremos que indicar los siguientes

parámetros:

• Directorio donde se encuentra el código.

• De forma opcional, los paquetes que queremos docu-
mentar, ficheros incluidos o excluidos.
• Directorio donde generaremos la documentación
• Si esta documentación será pública (solo interfaz) o in-
terna (se mostrarán bloques private y comentarios).
• Formato de salida de la documentación:
– HTML
– PDF
– XML
Como alternativa a phpDocumentor podemos usar Doxy-
gen, se trata de un programa que trabaja en PHP mientras
que phpDocumentor es una colección de código.

Funcionamiento de phpDocumentor

En phpDocumentor, la información será distribuida en blo-

ques DocBlock que se colocarán justo antes del elemento
que se documentará, y el formato será:

* Descripción breve (una sola línea)

/**
*Comentario extenso
*Cada línea irá con *
*/
<- Se ignorará esta línea

Los elementos para documentar podrán ser:

• Define.
• Function.
• Class.
• Class vars.
• Include/require/include_once/require_once.
• Global variables.
Usando la marca @package podremos documentar a nivel
global el fichero.

70
 Despliegue de aplicaciones web

En cada DocBlock podemos incluir marcas que tendrán

distintos significados, como pueden ser:
• @access: si es private, no se genera documentación. Se
usa para generar documentación sobre la interfaz, pero
no sobre la implementación.
• @author: indica el autor del código.
• @copyright: información de derechos.
• @deprecated: este elemento indicará que el elemen-
to no se deberá usar, ya que en futuras versiones puede
quedar obsoleto.
• @example: ruta hacia un fichero PHP.
• @ignore: impide que se documente un determinado ele-
mento.
• @internal: se muestra información en la documentación
interna, pero no debería aparecer en la documentación
pública.
• @link: incluir un enlace a un recurso.
• @see: crea enlaces internos.
• @since: indica que el elemento está disponible desde
una determinada versión del paquete.
• @version: indica la versión actual del elemento.
• @global: indica el uso de variables globales.
• @param: documenta parámetros que reciben una fun-
ción.
• @return: muestra el valor devuelto por una función.

71
 Tema 6: Documentación y sistemas de control de versiones

Instalación de phpDocumentor

Para la instalación, empezaremos en una máquina en la

que tendremos instalado la versión Ubuntu 20.04.1.

Antes de empezar, comprobaremos que PHP y Apache

funcionan de forma correcta, realizando las siguientes
pruebas:

1. Para comprobar que Apache sirve peticiones, introdu-

cimos en el navegador http://localhost y tendría que
aparecernos el mensaje “It Works!”.
2. Para comprobar que PHP funciona correctamente, po-
dremos escribir desde la línea de comandos echo “10” |
php y nos tendría que dar como resultado 10.
3. Para comprobar que Apache ejecuta código PHP, en
la carpeta “/var/www/html” creamos un archivo al que
llamaremos phpinfo.php y que contendrá el siguiente
texto:

<?php
phpinfo();
?>

Después, en el navegador escribimos http://localhost/

phpinfo.php y deberíamos encontrar información sobre las
características de Apache y PHP de nuestro equipo.

Una vez que hemos comprobado que funciona correcta-

mente, procederemos a la instalación de phpDocumentor.
Comenzaremos instalando el paquete php-pear me-
diante el gestor de paquetes apt: #apt-get install php-pear.

Antes de eso, podemos configurar phpDocumentor para

indicarle a pear la carpeta donde estará el contenido web,
que en este caso será “/var/www: #pear config-set data_dir
/var/www”.

72
 Despliegue de aplicaciones web

Ahora sí podemos proceder a la instalación de phpDo-

cumentor: #pear install –alldeps PhpDocumentor. O
también podremos descargarnos dicho paquete con los
siguientes comandos, y después descomprimirlo:

#Wget sourceforge.Net/projects/phpdocu/files/
phpdoc/phpdocumentor-1.4.3/Phpdocumentor-
1.4.3.Tgz

Cuando finalicemos la instalación, indicaremos un direc-

torio de salida cambiando el propietario a www-data para
que pueda trabajar sin limitaciones:

#mkdir /var/www/docs
#chown www-data /var/www/docs

En el navegador podemos comprobar que la instalación ha

sido satisfactoria si escribimos http://localhost/PhpDocu-
mentor/ y nos muestra el programa.

Configuración de PhpDocumentor

Una vez instalado, podemos trabajar con él de dos formas:

1. A través de la línea de comandos, usando el siguiente

código:

#phpdoc -o [formato_documentacion] -d
[carpeta_proyectos_php] -t [carpeta_
archivos_documentacion]

EJEMPLO

#phpdoc -o HTML:frames:phpedit -d /var/www -t /

var/www/docs/

2. Desde el entorno web.

Para ello debemos configurarlo accediendo a la ruta
donde hemos instalado phpDocumentor para duplicar
el archivo default.ini y cambiándole el nombre por pro-
yecto.ini.
Este archivo lo editaremos estableciendo una ruta
donde guardar la documentación y una ruta en la que
se encontrarán los archivos del proyecto. Para la prime-
ra cambiaremos el valor de target y para la segunda el
de directory.
Para crear la documentación, escribimos en nuestro
navegador la ruta http://localhost/PhpDocumentor/,
vamos al menú para escoger la opción Config, seleccio-
namos el fichero del proyecto y pulsamos en Go para
generar la documentación.

73
 Tema 6: Documentación y sistemas de control de versiones

6.3.  Instalación, configuración y

uso de JavaDoc
Javadoc es un estándar que se usa para documentar las
clases de Java. Siguiendo una serie de reglas, podemos
documentar todo un código. El principal objetivo es que la
información de las clases no se quede obsoleta con el paso
del tiempo, por eso, los comentarios deberán ir insertados
en el código. Esta herramienta extraerá los comentarios del
código y generará una documentación en HTML.
Los comentarios dirigidos a Javadoc comienzan con /** y
terminan con */, cada línea comenzará con *. También re-
conocerá las etiquetas que comenzarán con @ y que irán
situadas al principio de una línea.
Hay dos tipos de etiquetas: de bloque e inline.
1. Las de bloque solo se pueden usar en la sección de
etiquetas que siguen a la descripción principal. Son de
la forma: @etiqueta.
2. Las inline se pueden usar tanto en la descripción prin-
cipal como en la sección de etiquetas. Tienen la forma
de {@tag}.

74
 Despliegue de aplicaciones web

Instalación de Javadoc

Partiremos de la misma forma que con phpDocumentor,

desde una distribución Debian 6.0.1Squeeze.

Vamos a trabajar sobre el entorno de Eclipse, para proceder

a la instalación ejecutaremos desde un terminal el sigui-
ente código:

#apt-get install eclipse

Si accedemos al menú, en la sección Project veremos que

podemos seleccionar Generate Javadoc…, donde podre-
mos generar la documentación y, además, indicar la ruta
donde queremos que la guarde.

Documentando con Javadoc

Los documentos de Javadoc están destinados a describir

las funciones de clases y métodos para que otro programa-
dor lo lea y utilice la clase correspondiente.

Los comentarios deberán incluir unos indicadores que co-

miencen con @ y que se colocan al comienzo de la línea.
Se podrán usar, por ejemplo, para indicar la versión (@ver-
sion) o el autor (@author). No es obligatorio su uso, por lo
que un método podría ir sin indicadores.

La lista de indicadores podemos observarla en el apartado

de phpDocumentor.

Creación y uso de plantillas de código

Javadoc nos permite generar fácilmente páginas HTML

con el contenido de comentarios utilizando ciertas
convenciones en el código de Java (como es empezar un
comentario con /** y finalizarlo con */). De este modo, ha
sido creada la API de Java.

Las plantillas:

• Son sugerencias de código que van asociadas a una pa-

labra clave.
• En el IDE Netbeans están definidas en Preferences > Op-
tions > Editor > Code Templates.
• Nos pueden ahorrar mucho trabajo.
• Se utilizan nombres similares a los constructores en Java
(try, for, while, etcétera).
• Es posible definir y crear nuestras propias plantillas.
• Existen plantillas Javadoc predefinidas.

75
 Tema 6: Documentación y sistemas de control de versiones

Estarán compuestas por un nombre, descripción, contexto

en función del lenguaje y un pattern, que será el código de
la plantilla. En el código podremos usar texto fijo o unas
variables predefinidas, como, por ejemplo:

• $ (cursor): posición del cursor.

• $ (enclosing_type): tipo de la clase.
• $ (enclosing_method): nombre del método.
• $ (year): año en curso.
• $ (time): hora en curso.

ponte a prueba

A la hora de realizar la documentación, es necesario

transcribir la implementación fuera del código.
a) Verdadero
b) Falso

76
 Despliegue de aplicaciones web

6.4.  Sistema de control de

versiones. Seguridad de los
sistemas de control de versiones
Cuando realizamos un proyecto, si queremos ir cambiando,
modificando o sustituyendo código anterior u obsoleto
por otro más nuevo, podemos hacerlo, pero deberemos ir
guardando la versión actual del proyecto antes de cual-
quier modificación. Esa versión sabemos que funciona y
podemos recuperarla en cualquier momento para trabajar
sobre ella.

Podemos realizar la copia manualmente copiando el

directorio, pero no es la mejor forma de hacerlo. Para ello
existen herramientas, los sistemas de control de versiones,
que se encargarán de realizar copias de las distintas versio-
nes en un directorio. Cada vez que se realiza una copia, nos
pedirá que añadamos un comentario.

Al guardar las distintas versiones, podemos obtener fácil-

mente cualquiera de ellas, ver los comentarios añadidos o
incluso compararlas entre sí.

Es recomendable su uso al realizar proyectos entre varios

desarrolladores para obtener así las versiones del proyecto
desde un mismo sitio común, aunque también es útil si se
realiza de forma individual para controlar las distintas ver-
siones de nuestro proyecto.

Conceptos básicos

Existen varios conceptos básicos para que entendamos el

funcionamiento del control de versiones:

• Revisión: visión en un momento dado del estado de ar-

chivos y directorios. Pueden tener asociados metadatos.
• Copia de trabajo: archivos y directorios controlados por
el control de versiones que está en edición activa.
• Rama de trabajo: conjunto ordenado de revisiones. La
revisión más reciente se denomina principal.
• Repositorio: donde se almacenan las revisiones. Puede
ser un archivo, base de datos, etcétera.
• Conflicto: ocurre cuando varias personas realizan cam-
bios sobre un mismo archivo. Los sistemas de control de
versiones solo informan del conflicto, el proceso para so-
lucionarlo se denomina resolución.
• Cambio: modificación en un archivo bajo control de re-
visiones.
• Parche: lista de cambios generada al comparar revisiones.

77
 Tema 6: Documentación y sistemas de control de versiones

Con el sistema de control de versiones conseguiremos tener

el repositorio siempre actualizado. Trabajaremos sobre una
copia local y después actualizaremos el repositorio con
dicha copia.

Procedimiento habitual

El procedimiento general en un sistema control de versiones

es el siguiente:

1. Descarga del fichero inicial:

◦ Para empezar, debemos bajarnos los ficheros del re-
positorio.
◦ Solo se hará la primera vez que usemos los ficheros.

2. Ciclo de trabajo:
◦ Modificación de los ficheros.
◦ Actualización de los ficheros. Serán actualizados de
forma local para luego ser subidos al repositorio.
◦ Resolución de conflictos. Si existen conflictos, infor-
mará a los usuarios para su resolución.
◦ Actualización de ficheros en el repositorio. Modifica-
ción de los ficheros en el repositorio. Se comprueba
que las versiones estén actualizadas.

Entre las tareas que podemos realizar en el sistema de con-

trol de versiones, destacaremos:
• Realizar copias del proyecto al mismo tiempo.
• Realizar cambios en ficheros.
• Comparar diferentes versiones.
• Unir cambios realizados por distintos usuarios sobre los
mismos ficheros.
• Actualizar la copia local con la copia del servidor.
• Mantener distintas ramas de un proyecto.

78
 Despliegue de aplicaciones web

Sistemas de control de versiones centralizados y

distribuidos

La forma más simple de realizar una copia de los archi-

vos de un proyecto es copiar todo el directorio a otro
sabiendo la fecha en que se realizó. Aunque este método
es simple, es propenso a errores. Para un mejor control de
las copias de versiones, los programadores realizaron un
sistema de control de versiones locales.

Una herramienta muy popular fue la llamada RCS. Se basa

en la copia de parches, es decir, diferencias de archivos
de una versión a otra en un formato especial en el disco,
pudiendo recrear cómo son los distintos archivos sumando
los parches.

Un problema con el que se encuentran los desarrolladores

es el hecho de tener que colaborar con varios desarrolla-
dores a la vez. Para solventar este problema, se crearon
sistemas de control de versiones centralizados (CVS).
Se contendrán los archivos en un único servidor y varios
clientes se descargarán los archivos desde ese lugar.

Una de las ventajas es que cada desarrollador sabrá en

qué está trabajando el resto de las personas del proyec-
to. También tendrá como desventaja que, al ser un servidor
centralizado, en el momento en que ese servidor deje de
funcionar, el resto de las personas que se encuentren
trabajando sobre ese proyecto no podrán realizar su
trabajo, o se puede perder toda la información almacena-
da en caso de fallo.

Es así como aparecen los sistemas de control de versiones

distribuidos (DVCS). En ellos, los clientes no descargan
únicamente la última versión de los archivos, sino que
los replicarán continuamente al repositorio. En el caso de
que falle el servidor, cualquier cliente puede restaurar los
elementos del repositorio. Cada vez que realizamos una
descarga, se realiza una copia completa de todos los datos.

79
 Tema 6: Documentación y sistemas de control de versiones

6.5.  Git como sistema control de

versiones
Git es un sistema de control de versiones que está escrito
en C y que se hizo popular debido a ser elegido para el ker-
nel de Linux. Fue creado en 2005 y su uso es muy sencillo,
aunque conserva todas las cualidades iniciales.

Además, es muy rápido, es eficiente en grandes proyectos

y posee una gran capacidad para crear sistemas de rami-
ficación.

Git almacena los datos como un conjunto de instantáneas.

Cada vez que realizamos algún cambio, Git deja refleja-
do el estado actual de los archivos y hace una referencia
a ese estado.

Cada operación que realiza la hace de forma local, nece-

sitando solamente archivos y recursos locales. Además,
posee integridad, ya que todo es verificado antes de ser
almacenado, siendo imposible realizar cualquier cambio
sin que Git lo detecte.

Funcionamiento

Los archivos en Git pueden encontrarse de tres formas:

• Confirmado: archivos almacenados de manera segura en

la BD local.
• Modificado: archivo modificado sin ser confirmado en la
BD.
• Preparado: archivo marcado en la versión actual y listo
para la próxima confirmación.

De esta forma, podemos encontrarnos con tres secciones

principales dentro de Git:

1. Directorio de Git: almacena metadatos y BD de objetos

para el proyecto. Será la carpeta que se copie al realizar
la copia de un repositorio a otro.
2. Directorio de trabajo: copia de una versión del pro-
yecto.
3. Área de preparación: archivo que almacena la infor-
mación que irá en la próxima confirmación.

Los pasos de trabajo en el uso de Git serán: primero, modi-

ficar archivos en el directorio de trabajo; segundo, preparar
los archivos añadiendo instantáneas en el área de prepara-
ción; y tercero, confirmar los cambios.

80
 Despliegue de aplicaciones web

Instalación de Git

La instalación de Git la haremos sobre una máquina que

corre con Debian 6.0.1Squeeze.

Debemos disponer de ciertas librerías: curl, zlib, openssl,

expat y libiconv. Para realizar la instalación de estas libre-
rías podemos ejecutar:

#wget http://kernel.org/pub/software/scm/
git/git-1.7.6.tar.bz2

Una vez hemos descargado las librerías procedemos a rea-

lizar la instalación de Git ejecutando el siguiente comando:

#apt-get install libcurl4-gnutls-dev libex-

patl-dev gettext libz-dev

O si no queremos hacerlo desde los comandos, podemos

ir directamente a su página web y descargarlo de forma
manual: http://git-scm.com

Cuando ha finalizado la descarga, procedemos a la com-

pilación e instalación del paquete siguiendo los siguientes
pasos:

#tar -xjvf git-1.7.6.tar.bz2

#cd git-1.7.6
#apt-get build-dep git-core
#apt-get install libssl-dev
#make prefix=/usr/local all doc
#make prefix=/usr/local install install-doc

Para comprobar que la instalación se ha realizado correcta-

mente, ejecutamos el siguiente comando:

#git –version

Y tendría que devolver lo siguiente: git versión 1.7.6.

81
 Tema 6: Documentación y sistemas de control de versiones

Configuración de Git

Podemos ver las opciones de configuración de Git tanto

del lado del cliente como del lado del servidor. Nos cen-
traremos en las del cliente y veremos las más comunes
utilizadas a la hora de trabajar con Git.

Para consultar todas las opciones disponibles de configu-

ración, podemos acceder con el siguiente comando:

$ git config –help

Mediante la herramienta git config obtendremos distintas

variables de configuración que van a controlar el aspecto y
funcionamiento de Git.

La primera acción que realizaremos al instalar Git será

establecer un nombre de usuario y dirección de correo
electrónico. Esta información será usada al realizar las con-
firmaciones de cambios (commits).

$ git config --global user.name “alumno”

$ git config --global user.email alumno@
ejemplo.com

Al usar la opción --global se definirá esta información para

todo lo que hagamos en el sistema y no tendremos que
indicarlo de nuevo. Para cambiar los datos de esta infor-
mación, escribiremos el comando sin la opción --global en
dicho proyecto.

82
 Despliegue de aplicaciones web

Ahora debemos indicar el editor de texto que se iniciará al

escribir algún mensaje. Si no decimos nada, se abrirá por
defecto el editor Vi o Vim, pero si queremos que se inicie
otro, por ejemplo, Emacs, escribiremos el siguiente código:

$ git config --global core.editor emacs

Si necesitamos cualquier ayuda, Git nos permite acceder a

los manuales de tres formas distintas:

$ git help <comando>

$ git <comando> --help
$ man git-<comando>

Debido a la importancia de los navegadores web, pasare-

mos a instalar y configurar el entorno web de Git. Como ya
tendremos instalado el servidor Apache en nuestro orde-
nador, pasaremos a instalar el entorno web con el siguiente
comando:

# apt-get install gitweb

Crearemos los directorios:

# mkdir /home/usuario/git
# mkdir /home/usuario/www_git

Ahora tendremos que editar el fichero gitweb situado en el

directorio de Apache:

# nano /etc/apache2/conf.d/gitweb

Escribiremos lo siguiente:

Alias /git /home/usuario/www_git

<Directory /home/usuario/www-git >
Allow from all
AllowOverride all
Order allow, deny
Options +ExecCGI
DirectoryIndex gitweb.cgi
<files gitweb.cgi>
SetHandler cgi-script
</files>
</directory>
SetEnv GITWEB_CONFIG /etc/gitweb.conf

Moveremos los archivos de gitweb al directorio de Apache

creado:

# mv -v /usr/share/gitweb/* /home/usuario/www_git
# mv -v /usr/lib/cgi-bin/gitweb.cgi /home/usuario/www_git

83
 Tema 6: Documentación y sistemas de control de versiones

Haremos los siguientes cambios en el archivo de configu-

ración de gitweb:

#nano /etc/gitweb.conf
$projectroot = ‘/home/usuario/git/’;
$git_temp = “/tmp”;
#$home_link = $my_uri || “/”;
$home_text = “indextext.html”;
$projects_list = $projectroot;
$stylesheet = “/git/gitweb.css”;
$logo = “/git/git-logo.png”;
$favicon = “/git/git-favicon.png”;

Para finalizar, debemos recargar Apache:

# /etc/init.d/apache2 reload

La siguiente operación que tendremos que realizar será la

de crear una carpeta del proyecto:

# cd /var/cache/git/
# mkdir proyecto.git
# cd proyecto.git

Crearemos un repositorio para el proyecto según nuestras

necesidades:

# git init

Este comando nos devolverá un mensaje similar a: “Initia-

lized empty Git repository in /var/cache/git/proyecto.git/.
git/”, comprobaremos que en el directorio git existen una
serie de archivos que estarán asociados al proyecto crea-
dos automáticamente.
# echo “Una breve descripción del proyecto” > .git/description
# git config –global user.name «Tu nombre»
# git config –global user.email “[email protected]”

Si se han creado archivos nuevos en el repositorio antes

del commit, usaremos el siguiente comando para que sean
añadidos a la carpeta del repositorio:

#git add .

Ahora sí podremos realizar el commit:

# git commit -a

Marcaremos el archivo del repositorio exportado usando

git-daemon-export-ok:

# git daemon –base-path=/var/cache/git –

detach –syslog –export-all

84
 Despliegue de aplicaciones web

Para iniciar el servicio de Git que ejecuta un servidor para

hacer público nuestro repositorio, ejecutamos el siguiente
comando:

# cd /var/cache/git/proyecto.git
# touch .git/git-daemon-export-ok

Para finalizar, debemos darle permisos de escritura a algún

usuario que no sea root para que sea capaz de realizar
cambios en el repositorio:

#adduser usuariogit
#passwd usuariogit
#chown -Rv usuariogit:usuariogit /var/cache/git/proyecto.git

Para acceder al repositorio podemos hacerlo desde los

comandos usando: #git clone git://servidor/proyecto.git
proyecto, o desde el navegador con la siguiente dirección:
http://localhost/git/.

• Para borrar archivos desde un punto concreto podemos

usar: $ git log.
• Para saltar a un estado anterior escribiremos: $ git reset
–hard SHA1_HASH.
• Para restaurar algún archivo lo agregaremos al final del
comando: $ git checkout SHA1_HASH algun.archivo otro.
archivo.
• Obtendremos una copia del proyecto escribiendo: $ git
clone git://servidor/ruta/a/los/archivos.

85
 Tema 6: Documentación y sistemas de control de versiones

Seguridad documentación en Git

Cada directorio de trabajo en Git es un repositorio no de-

pendiente. Cada acceso se realiza a través del protocolo
Git, montado sobre SSH o usando HTTP, aunque no será
necesario usar ningún servidor web.

Git permite que los desarrolladores puedan subir sus pro-

yectos al repositorio sin que sean revisados. Para que un
repositorio público pueda ser usado de esa forma, será
necesario que ejecutemos el comando push. Primero crea-
remos un repositorio público y habilitaremos los siguientes
ponte a prueba accesos:

• Acceso directo por sistema de ficheros con permisos de es-

Cada vez que realizamos algún
critura para el usuario sobre el directorio del repositorio.
cambio, Git deja reflejado el
estado actual de los archivos • Acceso remoto vía SSH (consultar man git-shell) y per-
y hace una transferencia a ese misos de escritura para el usuario sobre el directorio del
estado.
repositorio.
a) Verdadero
• Acceso HTTP con WebDav debidamente configurado.
b) Falso
• Acceso mediante protocolo Git con el servicio recei-
ve-pack activado en el git daemon.

86
BIBLIOGRAFÍA / WEBGRAFÍA
” García Sánchez, Á.; Sanz Rodríguez, J. (2016). Despliegue de aplicaciones web. Editorial
Garceta.
solucionario
1.3.  Estructura y recursos que componen una 4.8.  Seguridad en el servidor de
aplicación web. Descriptor de despliegue aplicaciones. Configuración del servidor de
aplicaciones con soporte SSL/T
¿Cuál es el protocolo más utilizado cuando un
cliente se conecta a internet? Para la configuración de la seguridad en el
a) HTTP. servidor de aplicaciones Tomcat, debemos tener
habilitado el servicio de seguridad SSL en el
host por defecto (localhost).
2.3.  Servidores virtuales. Creación,
a) Verdadero.
configuración y utilización;
En una página web estática, ¿qué ocurre con el
5.3.  Servicios de directorios. Características
servidor?
y funcionalidad
d) Todas las respuestas son correctas.
Los dominios pueden empezar y terminar en
guiones.
2.7.  Despliegue de aplicaciones sobre
b) Falso.
servidores web
¿En qué se basa el método de cifrado que utiliza
5.5.  Adaptación de la configuración del
el protocolo HTTPS?
servidor de directorios para el desarrollo de
c) SSL/TLS. la aplicación. Usuarios centralizados
En Linux, la administración de usuarios y grupos
3.3.  Modos de conexión del cliente con el servicio de directorio LDAP, ¿mediante
¿Cómo es la arquitectura que emplea el qué paquete se realiza?
protocolo FTP? c) ldapscripts.
b) Cliente-servidor.
6.3. Instalación, configuración y uso de
3.7.  Utilización del servicio de transferencia JavaDoc
de archivos en el proceso de desarrollo de la A la hora de realizar la documentación, es
aplicación web necesario transcribir la implementación fuera
El navegador web también puede ejercer de del código.
cliente FTP. b) Falso.
a) Verdadero.
6.5. Git como sistema control de versiones
4.3.  Autenticación de usuarios. Dominios de Cada vez que realizamos algún cambio, Git deja
seguridad para la autenticación reflejado el estado actual de los archivos y hace
Una aplicación web no puede desplegarse en una transferencia a ese estado.
diferentes servidores web. a) Verdadero.
b) Falso.

4.7.  Despliegue de aplicaciones en el

servidor de aplicaciones
¿Qué comando podemos usar para ver la lista
de aplicaciones desplegadas?
b) list.