Universidad Politécnica

de Madrid
Escuela Técnica Superior de
Ingenieros Informáticos

Grado en Ingeniería Informática

Trabajo Fin de Grado

Virtualización del Sistema de Acceso

Abierto a Documentación Institucional
de la UPM sobre el Software GNU
Eprints.

Autor: Óscar Ortega Díaz

Tutor: Víctor Robles Forcada

Madrid, marzo 2021

Este Trabajo Fin de Grado se ha depositado en la ETSI Informáticos de la
Universidad Politécnica de Madrid para su defensa.

Trabajo Fin de Grado

Grado en Ingeniería Informática
Título: Virtualización del Sistema de Acceso Abierto a Documentación
Institucional de la UPM sobre el Software GNU Eprints.
Marzo 2021

Autor: Óscar Ortega Díaz

Tutor:
Víctor Robles Forcada
Arquitectura y Tecnología de Sistemas Informáticos
ETSI Informáticos
Universidad Politécnica de Madrid
Resumen
El presente documento se basa en el desarrollo de un proyecto para la
Universidad Politécnica de Madrid. Nuestra institución dispone de un Archivo
Digital donde alberga numerosos documentos de diversos tipos (unos 50.000)
que se han generado por personas que forman parte de ella.

En este proyecto se busca la actualización de todos los sistemas que

actualmente sustentan el Archivo Digital, los cuales están desactualizados
desde aproximadamente hace diez años. Esta actualización se realizará en
varios pasos y afectará al sistema completo: sistema operativo, software para el
servicio, bases de datos, otros programas complementarios, etc.

A su vez, se va a realizar la virtualización de las máquinas donde reside todo

este entorno, ya que, debido al tiempo y su amplio uso, cada vez tienen unas
capacidades más limitadas.

i
Abstract
The present document is based on developing a project for the Universidad
Politécnica de Madrid. Our institution has a digital archive where it stores a
huge number of documents of different kinds (about 40.000) generated by the
members of the institution.

This project aims for updating all the systems where the archive is based, which
have been out of date for about ten years. This update will be developed in
several stages and it will have affectation over all the system: operative system,
service software, databases, other complementary scripts, etc.

At the same time, a virtualization of the machines where this environment is

deployed, is going to take process. This is due to the time and the wide usage
this machine has, and also, its limited capacities.

ii
Tabla de contenidos
1 Introducción .................................................................................. 1
2 Estado del Arte ............................................................................... 4
2.1 Open Science y Open Access ............................................................ 4
2.1.1 Open Science ............................................................................ 4
2.1.2 Open Access .............................................................................. 5
2.2 Virtualización .................................................................................. 5
2.2.1 Qué es la Virtualización ............................................................. 5
2.2.2 Conceptos Fundamentales y Requisitos Hardware ...................... 6
2.2.3 Características de la Virtualización ............................................ 8
2.2.4 Ventajas e Inconvenientes de la Virtualización .......................... 11
2.2.5 Algunas Soluciones Disponibles en el Mercado Actual. .............. 13
2.2.5.1 Xen. ..................................................................................... 13
2.2.5.2 Hyper-V ............................................................................... 14
2.2.5.3 VMware ............................................................................... 15
2.2.5.4 VirtualBox............................................................................ 16
2.2.6 La Virtualización en la Universidad Politécnica de Madrid ......... 16
2.3 Eprints.......................................................................................... 17
2.3.1 Qué Es Eprints........................................................................ 17
2.3.2 Alternativas a Eprints .............................................................. 20
2.4 Apache .......................................................................................... 21
3 Desarrollo del proyecto ................................................................. 23
3.1 Trabajos realizados hasta la actualidad. ......................................... 23
3.1.1 Evaluación y Planteamientos Iniciales. ..................................... 23
3.1.2 Preparación de los Entornos Virtuales. ..................................... 24
3.1.3 Creación de las Máquinas Virtuales.......................................... 24
3.1.4 Instalación de los Paquetes Software necesarios ....................... 25
3.1.5 Pruebas Intermedias de Actualización y Correcciones. .............. 25
3.1.6 Migración de datos. ................................................................. 27
3.1.7 Revisión de Datos y Corrección de Fallos en el Archivo .............. 27
3.2 Roadmap para finalización del proyecto .......................................... 30
3.2.1 Actualización de Eprints. ......................................................... 30
3.2.2 Creación y Preparación de la Máquina de Producción................ 31
3.2.3 Posibles Actuaciones Futuras................................................... 31
4 Conclusiones ................................................................................ 32
5 Bibliografía ................................................................................... 33

iii
INDICE DE FIGURAS

Figura 1. Servicios Biblio UPM ..................................................................... 1

Figura 2. Esquema de máquinas virtuales .................................................... 6
Figura 3. Virtualización Completa................................................................. 9
Figura 4. Paravirtualización ......................................................................... 9
Figura 5. Interfaz Web de Xen Orchestra..................................................... 14
Figura 6. Administración de discos mediante Web de Xen Orchestra ............ 14
Figura 7. Interfaz de Hyper-V ..................................................................... 15
Figura 8. Directorio General Eprints ........................................................... 18
Figura 9. Contenido directorio archivos ...................................................... 18
Figura 10. Contenido archivo UPM ............................................................. 19
Figura 11. Contenido de “cfg” del archivo .................................................... 19
Figura 12. Logotipo GreenStone ................................................................. 21
Figura 13. Logotipo Eprints ........................................................................ 21
Figura 14. Logotipo de Bepress................................................................... 21
Figura 15. Logotipo OpenRepository. .......................................................... 21
Figura 16. Directorio de configuración de Apache ........................................ 22
Figura 17. Página de inicio interfaz web del Archivo .................................... 23
Figura 18. Comparativa Bulnes y máquina virtualizada directorio cfg .......... 26
Figura 19. Esquema parcial de una de las bases de datos del Archivo .......... 28
Figura 20. Página de búsqueda con errores ................................................. 29

iv
1 Introducción
La Biblioteca Universitaria tiene como misión facilitar el acceso y difusión de los
recursos de información y colaborar en los procesos de creación del
conocimiento, a fin de contribuir a la consecución de los objetivos de la
Universidad Politécnica de Madrid (UPM), según se recoge en los Estatutos de
la propia Universidad.
Biblioteca UPM cuenta con 17 puntos de servicio y el Centro de Documentación
Europea CEYDE. El espacio físico está organizado en distintos campus desde
los que se da servicio por igual a la comunidad universitaria (estudiantes,
personal docente e investigador y personal de administración y servicios) y a la
sociedad.
De esta forma, la Biblioteca Universitaria cuenta con muchísimos servicios para
la comunidad universitaria. Los servicios para los estudiantes se pueden
observar en la siguiente figura.

Figura 1. Servicios Biblio UPM

Como se puede observar, la Universidad Politécnica de Madrid dispone de un

Archivo Digital el cual alberga una amplia variedad de publicaciones realizadas
por los miembros de la institución. En él se incluyen publicaciones de diferentes
tipos como artículos, ponencias, libros, tesis, trabajos de fin de carrera, etc.
Dicho Archivo reside actualmente, en una máquina física que corre un sistema
operativo Debian 6 lanzado en el año 2011, sigue el modelo Open Access y
utiliza el paquete de software libre Eprints, que facilita la creación de
repositorios cumpliendo el mencionado modelo.
Toda la arquitectura presentada anteriormente se comenzó a construir en el año
2008 y se ha ido personalizando hasta la actualidad, sin llegar a realizarse
ninguna actualización completa del conjunto, lo cual ha conducido a una
obsolescencia general de todo el sistema, ligada a la limitación de los recursos
físicos cada vez más escasos y sobrecargados tras el paso de los años.
1
Este escenario ha impulsado a realizar una renovación general con los
siguientes objetivos:
x Virtualización de la máquina física buscando una mejor adaptabilidad
a las condiciones futuras.
x Actualización completa del sistema operativo de la máquina a su
última versión Debian 10. Versión 9 en caso de incompatibilidad entre
Eprints y Debian 10.
x Actualización del software Eprints.
x Adaptación de las personalizaciones realizadas sobre el mismo.
x Migración de la base de datos actual del Archivo.
x Preparación de un conjunto actualizable y capaz de persistir en el
tiempo con un mantenimiento mínimo y actualizaciones sencillas.
x Comprobación de scripts o programas realizados anteriormente por
los trabajadores del Archivo para la relación de datos o tareas
similares, con el fin de certificar su validez y adaptabilidad a las
nuevas versiones o búsqueda de una sustitución funcional.
En este trabajo, se reflejarán y aclararán los conceptos técnicos implicados en
el proceso, lo que se suele considerar como estado del arte; posteriormente se
realizará un desarrollo del proceso, las valoraciones e informes realizados de
manera previa al desarrollo del proyecto, las decisiones tomadas, el avance a
través de cada uno de los puntos trabajados y el estado final en el momento de
la conclusión de este trabajo.
Cabe destacar, que se trata de un proyecto largo, en el cual se manipula un
servidor que da servicio a nuestra comunidad universitaria por lo que su
desarrollo es cuidadoso y se está documentando detalladamente.
Tras superar una valoración por parte del Jefe de Área TIC del Vicerrectorado
de Estrategia y Transformación Digital, el proyecto comienza y a lo largo del
mismo ha sido necesaria la colaboración de diferentes personas que trabajan
en la estructura de la universidad. Por lo que este trabajo se está desarrollando
a la misma vez que el proyecto, y en él se recogerá el desarrollo que se haya
podido concluir hasta la fecha de la entrega. En caso de no finalizar a la vez el
trabajo y el proyecto, dada su magnitud, se indicará en alguno de los apartados
el punto concreto que se ha alcanzado, así como a su vez, se indicarán los pasos
futuros que se darán para concluir el proyecto.
Para alcanzar los objetivos anteriormente mencionados, se ha establecido una
lista de tareas a realizar durante todo el proyecto:

• Valoración del estado general del entorno en la actualidad.

• Análisis del esquema actual de la base de datos y funciones
desarrolladas sobre la misma.
• Estudio de las funcionalidades extra añadidas al software Eprints
posteriormente en formato plugin de Eprints cuya finalidad es ofrecer
mayor versatilidad y utilidades al repositorio.
• Estudio de condiciones necesarias en caso de realizar la actualización
directa sobre el sistema actual, previa a la migración a la máquina virtual.
• Estudio de una alternativa, realizando la actualización mediante una
reinstalación completa del entorno en sus últimas versiones, partiendo

2
 de las actuales en uso y pasando por las intermedias, directamente sobre
la nueva máquina.
• Actualización del sistema operativo en la máquina virtual.
• Adaptación del software actual a la máquina nueva, con la instalación
del mismo software en su versión última, pasando también por las
versiones intermedias necesarias para evitar la pérdida de datos o
funciones del sistema.
• Instalación, en la medida de lo posible, de las funcionalidades
customizadas añadidas sobre el software antiguo.
• Adaptación del esquema y funciones a la nueva versión de la base de
datos, vigilando tabla por tabla los cambios en cada actualización
respecto al punto de partida.
• Migración de los datos pasando por varias versiones intermedias
necesarias para asegurar la persistencia de todos los datos.
• Adaptación de los scripts y programas intermedios anteriormente
mencionados.
• Comprobar y certificar que el sistema queda configurado de manera que
en un futuro sea fácil y sencillamente actualizable.

Para finalizar este apartado, resta indicar la estructura que tiene el contenido
restante del trabajo:

- Capítulo 2. Estado del Arte. En él indicaré toda la información recabada

y que he adquirido a través de la realización de este proyecto y del trabajo,
así como conocimiento teórico de la misma y sus datos más actuales.
- Capítulo 3. Desarrollo del proyecto. Los pasos seguidos desde el estudio
inicial del estado de las máquinas y las posibilidades existentes para
solucionar la migración hasta el estado actual del proceso y los pasos
futuros para completar la migración.
- Capítulo 4. Conclusiones. Explicaré qué he aprendido de este proyecto,
tanto en el aspecto técnico como personal. Qué me ha parecido más
relevante, más complicado, etc.

3
2 Estado del Arte
En primer lugar, en este trabajo me gustaría tratar el conjunto de conceptos
adquiridos a lo largo de la realización del proyecto, centrándome en un enfoque
más teórico o científico, y que resultan de nueva adquisición con respecto a los
tratados a lo largo del grado, o sobre los que he profundizado mucho más de lo
que hice durante los estudios.
De manera más específica, haré hincapié en conceptos como el Open Science,
Open Access, la virtualización, Eprints y Apache.

2.1 Open Science y Open Access

No se puede concebir redactar sobre todos los conceptos que incluyo en este
capítulo sin hablar antes sobre las bases que han sentado y favorecido este tipo
de innovaciones. En concreto, me refiero a los estándares que siguen el Archivo,
y el software de Eprints.
Por tanto, se debe tratar en primer lugar del modelo que fundamenta ambos,
así como del movimiento que ha generado tal modelo, el Open Science.

2.1.1 Open Science

Open Science es un movimiento global cuyo objetivo es impulsar la ciencia

abierta y para todo el mundo. Se trata de posibilitar el acceso a la mayoría de
los recursos científicos publicados, para cualquier persona, favoreciendo así su
divulgación y crecimiento gracias a la actividad de quien esté interesado en
dichos recursos, ya sea un profesional o no. Impulsado por la OCDE
(Organisation for Economic Co-operation and Development) busca mejorar la
investigación en diversos ámbitos. La idea principal de esta búsqueda de la
disponibilidad es disponer de más personas que puedan tener acceso a cada
recurso, dato, documento o resultado, y así que cualquiera pueda contribuir a
generar aún más conocimiento mediante dichas publicaciones.
De este modo, la información se publica y difunde mucho más rápido, se
contribuye con la sociedad y se facilita la colaboración de los ciudadanos, se
incrementa la velocidad a la que se resuelve un problema, y se obtiene un
impacto mucho más amplio al ser el recurso extensible a cualquier persona que
lo necesite consultar y disponga como único requisito, de internet.
Este movimiento ha tomado impulso de manera más o menos reciente tras su
estandarización en 2014, sin embargo, no se trata de una nueva creación.
Engloba otros términos como son el Open Access, el Open Source, la revisión
por pares, los recursos de educación abiertos, datos de investigación abiertos,
etc. A continuación, centraré la información en el Open Access ya que es el
modelo que se aplica en concreto a este proyecto tanto en el caso del Archivo
Digital como de Eprints, siendo el último también de tipo Open Source.

4
2.1.2 Open Access

Open Access[15] es un estándar de publicación declarado en Berlín en el año

2003, el cual se encarga de regir las pautas que se deben seguir para realizar
publicaciones de carácter académico, y que busquen acogerse a este estándar,
con los beneficios que conlleva mencionados anteriormente, visibilidad,
accesibilidad, colaboración.
Este modelo también señala, de manera estricta, que las publicaciones acogidas
al mismo deben ser estrictamente de carácter académico, sin contener por tanto
ningún tipo de interés asociado, bien sea económico, político o de cualquier otro
tipo.
También se debe conocer y aceptar que toda la documentación que se
proporciona bajo este modelo es susceptible de ser descargada, modificada,
impresa, o utilizada de cualquier manera por cualquier usuario.
Las formas de publicar de este modo varían, pero dentro de los tipos que existen
lo más común es publicar en repositorios o revistas científicas que trabajen con
este tipo de modelo.
Una de las ventajas que creo más relevantes sobre este modelo además de la
fácil difusión, es la accesibilidad. El modelo favorece que todo tipo de personas
accedan a la información tengan el nivel económico que tengan, y de ese modo,
cualquiera tenga la misma oportunidad de formarse y de contribuir.

2.2 Virtualización

El primer concepto sobre el cuál cabe detenerse es el de virtualización, ya que,

sobre él, se cimienta todo el proyecto. La virtualización, aunque hemos
trabajado con ella en ciertas asignaturas del grado como herramienta para
prácticas, no es un tema tratado desde un punto de vista técnico durante la
carrera.
Es por esto, que en este apartado se dará una visión más específica, basada en
cómo funcionan los sistemas operativos virtualizados, cómo se relacionan con
el hardware, y cuáles son sus ventajas y desventajas.
En concreto, en el presente proyecto, la virtualización es muy relevante ya que
el objetivo principal más allá de la actualización del servicio es su virtualización.
Con ella se busca obtener para el Archivo Digital las ventajas que luego
comentaré más extensamente, como elasticidad en cuanto a recursos
disponibles para el sistema, facilidad para la migración y la realización de
pruebas sobre un entorno de desarrollo virtualizado con sus ventajas asociadas,
o la desubicación.

2.2.1 Qué es la Virtualización

En lo práctico, la virtualización consiste principalmente en la simulación, dentro

de una máquina física con sistema operativo y hardware propios, de varias
máquinas no reales.
De esta manera, la máquina física se concibe como un anfitrión que aloja varias
máquinas huésped, como veremos posteriormente.
5
 Esto presenta múltiples ventajas, y
permite que a partir de la máquina
anfitrión y todo su conjunto de
recursos se puedan crear diversas
máquinas con un sistema operativo
propio y unos recursos hardware a
nuestra elección que sean parte de
los recursos hardware reales.
La virtualización es un concepto
que surge en la década de 1960 de
la mano de Jim Rymarczyk, en IBM,
quien introdujo el concepto de
“time-sharing” el cual trataba de
lograr que varios usuarios
pudieran compartir el acceso a una
Figura 2. Esquema de máquinas virtuales máquina de manera simultánea y
correr varias aplicaciones en ella a
la vez, aunque su explotación real comenzaría a partir de 1990.
En una primera etapa de los años 90 se puede comenzar a hablar de
virtualización con los primeros programas en Java, ya que muchos de ellos
empiezan a poder ejecutarse en diferentes arquitecturas hardware. A finales de
la década, VMWare lanza su primer modelo de virtualización, en el cual se
virtualiza el hardware y sienta las bases del “hypervisor”, sobre el cuál se corrían
los sistemas operativos huésped. A lo largo de todo ese tiempo, el concepto de
“time-sharing” sigue evolucionando, y se desarrolla en el MIT el sistema
operativo MultiCS que trabaja fundamentado en este concepto y que
posteriormente dará lugar a UNIX.
Ya en los 2000, se lanzó Xen, el cual tiene bastante relación con este proyecto
(como veremos en su desarrollo) y posteriormente sobre 2008, Windows lanzó
Hyper-V.
Estos fundamentos se han seguido desarrollando hasta hoy en día y cada vez
se implementa en más empresas e instituciones.
A continuación, trataremos los conceptos fundamentales de la virtualización,
algunas características principales y sus tipos, posteriormente sus ventajas e
inconvenientes y, para terminar, la transformación virtual que ha ido sufriendo
nuestra universidad en este aspecto.

2.2.2 Conceptos Fundamentales y Requisitos Hardware

En torno a la virtualización, existen un conjunto de conceptos clave que es

importante conocer, para comprender bien cómo funciona esta técnica.
Los primeros dos conceptos que se deben tratar son los de host y guest, como
se conocen en inglés, aunque en castellano se denominan anfitrión y huésped.
Estos términos, se utilizan para referirse a la máquina física sobre la que
virtualizamos y a las máquinas que virtualizamos respectivamente.
En primer lugar, la máquina anfitrión. Es la máquina física en su conjunto,
software y hardware, tiene la percepción completa sobre las capacidades
hardware de las que se dispone realmente, y administra las máquinas huésped
que se crean.

6
Por otro lado, se entiende por huésped cada una de las máquinas que
virtualizamos desde el anfitrión. El huésped se percibe a sí mismo como una
máquina real, única e independiente, aunque en la realidad no sea así.
Desde el anfitrión, además de administrar las máquinas virtuales que creamos
se marcan los límites de cada una de ellas. Cuando una máquina virtual
arranca, únicamente tiene acceso a los recursos que se le proporcionan desde
el anfitrión y no tiene percepción de que existan más que éstos. Cada máquina
que creamos puede disponer de los recursos que consideremos, dentro de los
límites reales. Sin embargo, la distribución del hardware físico en estos sistemas
no es trivial.
Cada vez que se inicia un proceso de virtualización, se debe tener muy en cuenta
los requisitos hardware que debe cumplir cada máquina que se virtualiza, pero
se debe elaborar también una visión global o de conjunto. En función de la
escala de la máquina anfitrión y la profesionalidad con la que se virtualiza, esto
se vuelve cada vez más necesario.
Una virtualización a nivel usuario, en la mayoría de las ocasiones, supone
utilizar una solución software como Virtual Box para poder correr un sistema
operativo virtualizado sobre el del propio usuario con un fin concreto. En este
nivel cabe la posibilidad de que existan varias máquinas virtuales dentro de la
solución, pero el usuario no les dará probablemente un uso simultáneo por lo
que la distribución de recursos no se torna tan relevante.
Por el contrario, en un caso como podría ser el de la propia Universidad en este
proyecto o como ocurre en muchas empresas de un tamaño similar, suele
ocurrir que la institución dispone de una máquina física muy potente, con una
cantidad de recursos elevada y sobre ella se implementa la solución de
virtualización, para alojar, operar, y ofrecer servicios, de varias máquinas
virtualizadas a la vez. En este caso, la distribución software es muy importante.
Centrándonos en el caso del proyecto como ejemplo, se ha trabajado creando
dos servidores virtuales, con un sistema operativo Debian de base para el uso
de la herramienta Eprints con el fin de crear el entorno del Archivo. Estos
servidores serían dos huéspedes de un anfitrión mucho más grande
perteneciente a la Universidad y donde se alojan diversos servicios de esta.
Suponiendo que la máquina anfitriona de la universidad tiene 256 GB de RAM,
esta es consumida por todas las máquinas huésped que se ejecutan a la vez en
el anfitrión, por lo que, si no se raciona de manera adecuada, se podría llegar a
dar un colapso del anfitrión y, en consecuencia, de todos sus huéspedes. Es por
ello por lo que, por norma general, para la distribución hardware en el ejemplo
concreto de la universidad, cuando se crea una máquina virtual nueva, se le
asignan los requisitos mínimos para su funcionamiento y a partir de ahí, si se
necesita ampliar estas capacidades, se debe medir el impacto que esto puede
tener en el entorno global, y ha de estar debidamente justificado.
Aunque el caso de la Universidad era solo un ejemplo, esto se produce en todas
las empresas que emplean virtualización a una mayor o menor escala y ha de
tenerse muy en cuenta y estar muy controlado por el bien del conjunto.
Un último concepto fundamental que se debe introducir es el concepto de
hipervisor. Se llama hipervisor a la capa de software que gestiona las relaciones
como si de un intermediario se tratase, entre el hardware físico, y cada una de
las máquinas virtualizadas. Sobre él se fundamentan los dos tipos de
virtualización principales que explicaré posteriormente, la completa, y la
paravirtualización.

7
Este software tiene como objetivo que las máquinas huésped lo vean como si de
un hardware real se tratase y ejecuten sobre él sin necesidad de alterar su
funcionamiento operativo habitual en una máquina física. Es capaz de gestionar
excepciones, lecturas y escrituras en dispositivos externos, interrupciones,
memoria principal, etc.
Existen, de manera general, dos tipos de hipervisores, los de tipo 1 o bare-metal
y los de tipo 2:
x Tipo 1, son aquellos que no necesitan un sistema operativo base para
funcionar si no que gestionan de manera directa los recursos hardware.
De esta forma, actúan como si se tratase de un sistema operativo sobre
la máquina física. Este control directo del hipervisor sobre el hardware
suele resultar una ventaja en términos de rendimiento al no tener un
sistema operativo intermediario. Simplemente, captura las llamadas que
se dan desde una máquina virtual hacia el hardware, y tras procesar qué
efecto han de tener, las ejecuta él mismo sobre el hardware con ayuda
del conjunto de drivers del que dispone.

x Tipo 2. En este caso, el hardware ya lleva un sistema operativo completo

montado encima y el hipervisor está controlado por dicho sistema
operativo. Sería un uso quizá de nivel más orientado a usuario, donde
desde el sistema operativo ejecutamos nuestra solución software, como
podría ser VirtualBox, y es ésta la que maneja las máquinas en función
de nuestras necesidades y siempre bajo la tutela del sistema operativo
base.

2.2.3 Características de la Virtualización

En primer lugar, me gustaría hacer un inciso para hablar sobre las diferentes
definiciones y características que se pueden encontrar sobre la virtualización.
El propio concepto está en sí mismo muy esparcido pero lo cierto es que no
existe ningún estándar que lo acote y resulta, además, a causa de los diferentes
ámbitos de aplicación un concepto realmente difícil de definir. Si bien es cierto
que en la literatura hay mucha convergencia en la mayoría de las características
y la forma de acotarlas que explicaré a continuación, quedan ciertos flecos
sujetos a la apreciación del profesional que lo define y del grado de
profesionalidad de la virtualización que trata.
Por tanto, todo lo que detallaré a continuación es una conjugación de
conclusiones extraídas de diferentes literaturas que aparecen indexadas en la
bibliografía, criterio personal, y criterio adquirido al estudiar y desarrollar este
proyecto.
Según indican los profesores Jesús Carretero Pérez, Félix García Carballeira y
Fernando Pérez Costoya [1] en su libro de sistemas operativos podemos
diferenciar cuatro tipos de virtualización según el middleware, a saber:
emulación hardware, virtualización completa, paravirtualización, y
virtualización a nivel sistema operativo. En todos los libros incluidos en la
bibliografía se puede conocer más sobre todos los tipos de virtualización.
En este caso, centraré el foco del desarrollo en la virtualización completa y en
la paravirtualización, ya que la combinación de ambas es la empleada para
virtualizar las máquinas de nuestra universidad, es el tipo de virtualización que

8
propone Xen, y mencionaré cómo funciona internamente la arquitectura en los
demás.
La virtualización completa es el modelo de virtualización más extendido, muy
utilizado a nivel usuario. Es también el modelo con el que he trabajado y sobre
el cual más he aprendido a lo largo del proyecto. Sin embargo, la manera de
interaccionar del hardware y los sistemas operativos huésped, era para mí a
nivel estructural, bastante desconocida.
Este modelo centra su funcionamiento en torno al hipervisor, el utilizado en el
proyecto es de tipo 1, cuyas características he mencionado anteriormente. La
capacidad del hipervisor para gestionar esta relación físico-virtual resulta
posible gracias a diferentes factores que favorecen y orquestan el
funcionamiento de este sistema. Se produce una combinación de procesamiento
directo de instrucciones por parte del procesador físico, en el cual se ejecutan
la mayoría de las instrucciones, con la traducción binaria de aquellas
instrucciones no virtualizables, las que corresponden al kernel, de manera que
pueden ejecutarse tras dicha traducción y producen los cambios necesarios en
la máquina virtual. Así esta máquina tiene un comportamiento completo
(virtualización completa) con memorias virtuales, BIOS y redes virtuales; de
modo que para la máquina virtualizada y para su sistema operativo, sólo existe
dicha máquina con su hardware asignado como si de un hardware propio se
tratase.

Figura 3. Virtualización Completa

La paravirtualización, funciona también mediante hipervisor, pero de una forma

diferente. Obliga a introducir en el sistema operativo de la máquina virtual, APIs
que regulan si determinados trabajos se ejecutan en la CPU virtual o si por el
contrario se encarga el sistema físico de ciertas tareas que puedan conllevar
mayor carga. La diferencia con la virtualización completa es que, en este caso,

Figura 4. Paravirtualización

9
el hipervisor es más “pequeño” ya que al no encargarse de procesar todo entre
el sistema operativo virtualizado y el hardware físico, si no que gran parte lo
hacen las APIs, interviene mucho menos y por tanto se le requiere menor
capacidad.
Otra diferencia fundamental que tiene respecto a la completa está en el kernel
del sistema operativo. En la completa, el kernel del sistema operativo que se
virtualiza se mantiene intacto; sin embargo, en la paravirtualización el kernel
ha de ser modificado para incluir un módulo específico correspondiente al
hipervisor que se utiliza en cada ocasión. De este modo, se adapta el sistema
operativo para que haya un correcto funcionamiento y sincronización con las
para-APIs, como también se conocen. Diversos equipos han desarrollado
posteriormente soluciones comunes para adaptar cualquier sistema operativo a
cualquier hipervisor, por ejemplo, Xen desarrolló pv-ops. Actualmente Xen,
VMware, Virtualbox, L4, y otras más, proporcionan soluciones que veremos más
adelante basadas en paravirtualización.
Tras consultar con uno de los expertos sobre virtualización de la Universidad,
quien me explicó en concreto el tipo de solución que se utiliza (Xen en nuestro
caso), cabe indicar que existen modelos intermedios o mixtos. En estas
máquinas, se implementa una paravirtualización completa asistida por
hardware, o PV sobre HVM. Es un tipo de virtualización completa pero que tiene
algunas características pertenecientes a la paravirtualización que mejoran su
rendimiento.
Por tanto, se considera una virtualización completa por un sencillo motivo, no
se modifica el kernel del sistema operativo en ningún caso, simplemente se le
añaden unos drivers para que pueda comunicarse en caso de necesidad con el
hipervisor y así tener un mejor rendimiento en ocasiones concretas. Es además
asistida por hardware, porque en este caso no se produce la traducción de
instrucciones virtuales que comenté anteriormente, si no que el
microprocesador viene ya preparado de fábrica y tiene la capacidad de dar
instrucciones “virtuales” de manera directa al sistema operativo virtualizado sin
tener que traducirlas, lo cual se refleja en una mejora consistente del
rendimiento.
En cuanto a los dos modelos restantes quiero destacar las diferencias
estructurales con respecto a los anteriores, ya que es también un conocimiento
nuevo que he adquirido gracias a la realización del estudio del estado del arte.
En primer lugar, la emulación hardware funciona de manera muy similar a la
virtualización completa, las máquinas virtuales tienen un hardware
completamente acotado y de él, algunos elementos de los cuales no se dispone,
se recrean. Por ejemplo, si un desarrollador de aplicaciones en Android o iOS
necesita probar sus aplicaciones, no dispone de diferentes modelos de móvil
para probar cómo funciona lo desarrollado en varios tamaños de pantalla o
diferentes versiones del sistema. Con la emulación hardware, se emula por
completo el dispositivo, emulamos su procesador, su memoria y todas sus
características específicas para poder realizar dichas pruebas, eso sería
considerado emulación hardware.
Por último, encontramos los contenedores, una virtualización a nivel de sistema
operativo bastante extendida también hoy en día sobre todo por las grandes
empresas. En este caso, el sistema operativo es uno, y trabaja disponiendo de
todo el hardware como consumidor único. Se encarga de dividir las instancias
necesarias para aislarlas y tratarlas de manera independiente, con el fin de
proporcionar aplicaciones (o contenedores) independientes, de las cuales

10
gestiona, además, el uso de hardware de manera limitada para reducir el efecto
que pueda tener sobre los otros contenedores que se puedan estar ejecutando
en los diferentes espacios de usuario.

2.2.4 Ventajas e Inconvenientes de la Virtualización

En mi opinión, la virtualización ofrece claras ventajas sobre el uso de máquinas

físicas para el desempeño de cualquier tarea, pero sobre todo en el caso que nos
concierne dichas ventajas son mayores aún.
En la literatura, aunque vemos definiciones muy variadas sobre los tipos de
virtualización o sus definiciones, podemos encontrar, por el contrario, una
confluencia casi total en cuanto a ventajas e inconvenientes. En este apartado,
expondré las ventajas explicadas, para posteriormente indicar cómo he
encontrado estas ventajas reflejadas en el proyecto; posteriormente detallaré lo
mismo con respecto a los inconvenientes.
Las ventajas que podemos encontrar son:
x Facilidad para el desarrollo de pruebas. Ésta es, en mi opinión, la
ventaja más reseñable de la virtualización, y sin duda, de las más
necesarias en este proyecto. La posibilidad de tener máquinas
virtuales de desarrollo sobre las que realizar todo tipo de pruebas
para comprobar funcionamientos de manera previa a su paso a
producción, es sin duda, la mejor de las ventajas. Ofrece la
posibilidad de congelar estados concretos de una máquina y
posteriormente volver a ellos tras realizar las pruebas de manera
realmente sencilla. La Universidad trabaja con Xen Orchestra para
gestionar las diferentes máquinas virtuales de las que dispone, con
él podemos realizar snapshots, una posibilidad muy versátil que
permite salvaguardar el estado de una máquina en un momento
concreto, y después devolverla al mismo, en caso de que
cualquiera de los cambios realizados haya sido infructífero o con
consecuencias negativas. Sin esta posibilidad, el tiempo que
supondría el proyecto de migración crecería considerablemente.

x Portabilidad. Se refiere a la facilidad de compartir aplicaciones

entre sistemas con la misma máquina base o incluso instalar
sobre un mismo hardware varias máquinas virtuales. El hecho de
poder duplicar una máquina de manera completa en uno de sus
estados ayuda a poder disponer de un entorno para pruebas y otro
para producción y variarlos o replicarlos de manera prácticamente
inmediata.

x Desubicación. Referida a la facilidad para mover y manejar a

nuestro antojo una máquina virtual completa con el fin de cubrir
ciertas necesidades sobre todo orientadas al servicio que está
ofreciendo la máquina. En este caso, el servidor que provee el
servicio del Archivo a la comunidad reside en un servidor de
producción donde no se realiza ningún cambio. Sin embargo, se
dispone de dos máquinas de desarrollo sobre las cuales sí se
realizan los cambios oportunos. Como siempre se mantiene
persistencia entre la máquina de producción y una de pruebas,
cuando hay que cambiar algo, el proceso virtualizado, nos da la
11
 ventaja de cambiarlo sobre el servidor de pruebas mientras que el
de producción sigue activo. Una vez realizado el cambio y cuando
la máquina está lista, se hace un cambio de agujas en caliente,
para que en ese momento el servicio en producción pase a apuntar
a la máquina de pruebas quedando así ésta de pruebas y
quedando la antigua de producción como nueva de pruebas, tras
copiar en ella los cambios realizados. Esto es algo muy versátil
para evitar afectación en los servicios prestados.

x Elasticidad, los recursos físicos asignados a la máquina son

totalmente configurables siempre que estén disponibles en la
máquina real. De este modo, pude partir de una máquina con
especificaciones mínimas e ir incrementándolas de forma gradual
a medida que iba siendo necesario, favoreciendo así la
optimización de recursos de los que dispone la Universidad para
todos sus sistemas virtualizados. Lo cual, se relaciona también,
con el punto de reducción de costes, otra de las ventajas que
presenta este mecanismo.

x Aislamiento. Cualquier fallo que se produzca en una de las

máquinas virtuales, no afectará a las demás máquinas, si el fallo
se produce en la máquina física, gracias a la portabilidad, esta
puede ser sustituida rápidamente.

x Disponibilidad prácticamente inmediata en caso de cualquier fallo

del sistema o error, permitiendo reestablecer una copia de
seguridad en cuestión de minutos.

x Ahorro económico. Se produce en mayor o menor grado,

dependiendo del nivel de uso. Quizá a nivel usuario esta
característica no es tan ventajosa, sin embargo, a nivel
empresarial marca una gran diferencia. En una sola máquina de
grandes capacidades, y teniendo que mantener sólo esta, podemos
albergar múltiples máquinas que serían mucho más costosas de
mantener y ubicar, ofreciendo el mismo servicio.
En el lado de las desventajas que podemos encontrar, destacaría:
x Dimensionamiento. Un incorrecto dimensionamiento de las máquinas,
en un servidor que alberga tantas, puede provocar un colapso de los
recursos y un desaprovechamiento de estos (no mayor que en el caso de
que todas fueran físicas), llegando a provocar la necesidad de aumentar
el rendimiento y potencia de los servidores provocando un aumento de
costes.
x Coste inicial. Si bien es cierto que los costes a largo plazo se ven
reducidos, la inversión inicial en la máquina de partida puede ser
considerable, en función del nivel de servicios virtualizados que se quiera
ofrecer y el número de máquinas que se pretenda albergar en la física.
x Administración. Será necesario, además, otro nivel de administración
inexistente en los servidores al uso. En este caso, no solo ha de
administrarse la máquina física como se haría normalmente, si no cada
una de las virtuales, y la convivencia (o uso) entre todas ellas dentro de
la física.

12
Para concluir con el capítulo sobre virtualización, he recabado datos sobre la
evolución histórica de nuestra universidad hacia máquinas virtuales, gracias a
la ayuda de algunos compañeros, que detallaré en el siguiente apartado.

2.2.5 Algunas Soluciones Disponibles en el Mercado Actual.

Para finalizar el estudio sobre virtualización creo que es conveniente realizar un

tipo de bitácora que explique cómo ha avanzado la virtualización en nuestra
institución universitaria, pero antes, me gustaría destacar algunas de las
soluciones de virtualización existentes y más utilizadas hoy en día con el fin de
conocer un poco más la manera que tienen las diferentes empresas de proveer
una solución para sus clientes ante esta nueva perspectiva de la tecnología.

2.2.5.1 Xen.

En primer lugar, es obvio presentar la solución sobre la que se basa todo el

proyecto, es el caso de Xen. La información extendida sobre Xen y sus proyectos
se puede encontrar en la web de la empresa[6], o en la web específica sobre Xen
Orchestra [7].
Xen es un proyecto muy avanzado hoy en día que comenzó en 2004 como un
hipervisor creado para investigación, bajo la empresa que fundaron con este
propósito XenSource. Posteriormente fue adquirido por Citrix, quien lo convirtió
en una propuesta competitiva en el mercado, para después pasar a manos de
The Linux Foundation, quienes lo bautizarían como XenProject.
Se trata de un hipervisor de tipo 1, es Open Source y presenta diferentes
versiones comerciales según la solución buscada, como aplicaciones Open
Source, servidores, IaaS, soluciones de seguridad, etc. Si bien es cierto que tiene
un rendimiento bastante óptimo, en sus inicios sólo permitía paravirtualización
mediante el uso de las APIs en el sistema virtualizado que la propia empresa
imponía. Posteriormente y con los cambios de empresas propietarias,
evolucionó y actualmente también ofrece virtualización completa, o incluso la
solución utilizada en el proyecto que analicé con anterioridad.
En este caso en concreto, se trabaja con XenServer. Es la solución de
administración que creó Citrix para los administradores de ecosistemas
virtuales. Desde esta herramienta podemos manipular todas las máquinas
virtuales que administramos, además de hacer distribuciones de hardware para
estas máquinas. Durante el proyecto, se ha utilizado una aplicación que se basa
en XenServer, pero en un formato web de administración cuyo nombre es Xen
Orchestra. A continuación, podemos ver algunas capturas del interfaz de esta
donde apreciamos su sencillo manejo.

13
Figura 5. Interfaz Web de Xen Orchestra

Podemos apreciar que nos muestra de una forma sencilla e intuitiva una visión
general de la máquina de desarrollo utilizada y también a continuación, una
imagen para poder observar como ejemplo, lo visual y sencillo de la gestión de
discos.

Figura 6. Administración
de discos mediante Web
de Xen Orchestra

2.2.5.2 Hyper-V

La solución Hyper-V es el nombre comercial que Microsoft le atribuyó a su

hipervisor de tipo 1 bastante potente y mejorada con respecto a Virtual-PC, una
solución de tipo 2 que propuso la empresa con anterioridad.
Esta solución, no requiere necesariamente de la instalación del sistema
operativo Windows, si no que puede funcionar de manera independiente,
aunque también existe para dicho sistema la versión de Hyper-V Server para
realizar estas tareas de administración.
Desde la ventana de administración, se puede manejar múltiples características
de las máquinas como en el caso anterior y, además, ofrece la posibilidad de
ejecutar y operar, una máquina en concreto como si fuera en remoto.
La forma en la que funcionan las máquinas virtualizadas se asemeja a un tipo
de contenedores, dado que cada máquina trabaja como una partición lógica del
anfitrión. Por así decirlo, sería un tipo de virtualización anidada, estos módulos

14
son como procesos hijo del módulo principal que es el del sistema, y son
independientes entre ellos, sólo tienen en común el hardware y su origen.
Además, cabe destacar que desde 2009, esta solución soporta también el kernel
de Linux por lo que resulta mucho más polivalente, con sus ajustes necesarios
en cuanto a drivers y demás, para adaptarlo a la solución de Microsoft.

Figura 7. Interfaz de Hyper-V

2.2.5.3 VMware

La solución de VMware se trata de una solución muy polivalente con diferentes

tipos de hipervisores dado que engloba diferentes tipos de soluciones.
Quizá, a nivel usuario es la solución más conocida, ya que su propuesta VMware
player (tipo 2) es gratis y muy extendida en el ámbito educativo y doméstico.
Esta versión muy básica, permite crear máquinas virtuales con un sistema
operativo en base como podría ser generar una máquina Linux dentro de
nuestro sistema nativo Windows o viceversa. Existe una versión mejorada de
pago de la misma llamada Workstation.
Una de las características más notables precisamente de esta empresa, es su
multitud de propuestas para diferentes casuísticas. Provee virtualizaciones a
nivel de virtualización de escritorio, muy útil para empresas en los puestos de
sus trabajadores, soluciones a nivel de virtualización de red para determinadas
aplicaciones, virtualización de servidores, como podría ser el caso de XenServer
etc.
Algunas de sus soluciones también muy conocidas son VMware Cloud
Foundation, Player, Workstation, ESX (virtualización completa de
infraestructuras), entre una larga lista de soluciones.

15
2.2.5.4 VirtualBox

También ampliamente conocida por usuarios no profesionales, la solución que

propone Oracle es una herramienta software de virtualización de sistemas
operativos.
Siendo una solución software que se ejecuta sobre nuestro sistema operativo,
su actividad se centra en la emulación de otros sistemas operativos con unos
fines concretos. Su hipervisor es de tipo 2, y aunque existen algunas soluciones
más potentes de tipo cloud orientadas a empresa, la solución más extendida es
la doméstica sobre todo por ser muy intuitiva, potente y gratuita. Trabaja una
virtualización de tipo completo.
Incluye algunas características como la posibilidad de realizar snapshots
(capturas del estado de la máquina, algo que la versión gratuita de VMware no
ofrece), clonación y migración de máquinas (aunque no en caliente), o ejecutar
varias máquinas al mismo tiempo, todo ello sujeto siempre a las características
del equipo con el que trabajemos.
La versión empresarial se llama Oracle Cloud Infraestructure, y ofrece gestión
de infraestructuras cloud a un nivel mucho más profesional, aunque en este
caso sí se convierte en una solución de pago.

2.2.6 La Virtualización en la Universidad Politécnica de Madrid

Para concluir el apartado que concierne a la virtualización, me gustaría añadir

un breve resumen sobre cómo ha avanzado la virtualización en nuestra
universidad y los datos que presenta hoy en día sobre este ámbito. Este
apartado creo que arrojará luz y dará una importante visualización sobre el peso
real que tiene la virtualización en nuestra institución, así como sobre la rapidez
con la que se ha abordado este ambicioso proyecto y la cantidad de servicios
que provee. Toda esta información ha sido proporcionada por la persona
encargada de supervisar todos los sistemas, quien tiene una visión completa del
histórico de virtualización en nuestra universidad.
Los primeros pasos en este proceso comenzaron en el año 2013, en aquel año,
según me comenta la persona que he mencionado, se comenzó con lo que serían
los primeros pasos de virtualización provisionando VPS (Virtual Private Server)
para algunos departamentos de la institución. Se comenzó instalando algunos
clusters, que en principio se plantearon instalar con Open Stack (otro software
de virtualización que sigue el modelo Open Source), pero en los momentos en
los que se iba a comenzar el proyecto de forma definitiva esta empresa presentó
algunos problemas de recuperación frente a desastres, por lo que se decidió
cambiar de estrategia. Se descartó también en ese momento Hyper-V dado que
Microsoft instauró una política de obligatoriedad de utilizar las máquinas de su
marca, lo cual no encajaba en el proyecto, y VMware en su caso, se descartó a
causa de su elevado coste, ya que no era asumible para la organización.
En el año 2017 se crean los dos datacenter de la universidad y se comienza a
virtualizar los sistemas de esta. Se crean los dos pools denominados Disaster
Recovery que siguen el planteamiento que su propio nombre indica, se apoya
un pool de el otro y tienen la capacidad de suplirse entre ellos en caso de
desastre en alguno de los dos, para evitar interrupciones en el servicio. Toda la
instalación y despliegue iniciales se realizaron sobre unos nodos de Magerit de

16
los que ya se disponía, para evitar aumentar los costes invirtiendo grandes
cantidades de dinero en hipervisores.
Mientras todo esto ocurría, se iban virtualizando todos los servicios generales:
el sistema de gestión académica, el de gestión económica, el servidor de correo,
el de almacenamiento cloud, etc. Se comenzó a virtualizar en primer lugar en el
mismo año 2017 con LDAP, dado que su virtualización era más simple,
siguiendo con el sistema Universitas UXXI encargado en cuestión de la
mencionada gestión académica y económica, dado que esta virtualización se
llevó a cabo a mediados del año 2018, la matriculación de ese año fue la primera
en realizarse sobre sistemas virtuales.
Por otro lado, las bases de datos se montaron en una estructura aparte. Se
realizó sobre un rack de Oracle, una en Montegrancedo y otra en el rectorado
de la universidad, y se trata de bases de datos virtualizadas que utilizan ya la
versión 8 de MySQL y disponen de una conexión entre sus dos localizaciones de
100GBits/s.
También en el año 2017 se creó el IaaS Centros, un servicio para proveer a cada
escuela de su propio espacio de máquinas virtuales para sus servicios propios
específicamente como, por ejemplo, las máquinas que se utilizan para las
prácticas. Se lleva también las VLANS de las escuelas hasta el IaaS para que
puedan disponer de su propio espacio de direccionamiento IP por cada escuela.
Para el año 2019 el 95% de las máquinas de la institución ya se encontraban
virtualizadas. Además, a raíz de toda la pandemia, se ha promocionado en la
universidad un proyecto de digitalización. En este proyecto, se han dedicado
fondos para poder aumentar las capacidades de las máquinas y así poder
ofrecer un servicio mejor, más rápido y estable. Esto ha permitido renovar los
nodos e incrementar su capacidad hasta llegar a multiplicarla por cinco. Toda
la transformación comenzó a ser efectiva en octubre del año 2020.
Para concluir, añadiré algunos datos interesantes. En la actualidad,
disponemos de más de 300 máquinas virtuales que corren en el rectorado, y
que proveen todos los servicios de administración electrónica, económica,
académica, de personal, servicios de encuestas y demás servicios de los que
dispone la universidad. Y como dato muy reseñable, somos la única universidad
de España que tiene toda su infraestructura virtualizada en su propia nube
privada.
2.3 Eprints

2.3.1 Qué Es Eprints

Eprints es un software libre de tipo Open Access utilizado para la creación de
repositorios institucionales. Su origen se remonta al año 2000, y surge en la
Universidad de Southampton con el fin de proporcionar una herramienta capaz
de administrar repositorios institucionales para albergar documentación,
publicaciones, etc. Por lo general está orientado a archivos de universidades y
bibliotecas. Se puede consultar toda la información completa en su página web
[18] .

Su código está desarrollado en Pearl y se puede ejecutar en la mayoría de los

sistemas operativos comunes, además permite incorporar numerosas
funcionalidades en formato plugin que hacen muy personalizable el repositorio
que se genera, dichos plugins también están programados en Pearl. Sin
embargo, sus páginas de navegación son HTML.

17
Sigue el protocolo OAI-PMH (Open Archive Initiative-Protocol for Metadata
Harvesting) un protocolo desarrollado en 1999 que pretende promover un
estándar para fomentar que se pueda difundir publicaciones de este tipo a
través de internet de una manera mucho más sencilla y extensible gracias a los
metadatos.
En nuestro Archivo, Eprints está instalado sobre una máquina virtual Linux
(Debian), que se comporta como servidor del repositorio. La instalación de
Eprints va ligada a una instalación de MySQL ya que se deben gestionar los
datos del repositorio a la vez que se almacenan y mantienen en una base de
datos. Además, se liga también a la instalación de Apache como servidor web
para poder manejar dentro del repositorio todas las configuraciones
relacionadas con la aplicación web a la que acceden los usuarios del repositorio.
Un detalle reseñable sobre este software es que, una vez instalado en el servidor,
permite gestionar más de un repositorio, ya que origina un conjunto de
directorios independientes para cada archivo, en el cual las configuraciones
pueden ser propias además de las genéricas que se realizan en el directorio de
Eprints, fuera de los directorios en concreto de cada archivo.
Otra característica muy interesante que ofrece como ventaja es la sencillez para
implementar paquetes de idiomas, los cuales se van actualizando cada vez que
se actualiza la versión de Eprints.
A continuación, algunas capturas en detalle para observar ejemplos de la
distribución en directorios del repositorio.
En primer lugar, el árbol de directorios de Eprints genérico para todos los
repositorios, en él, encontramos la carpeta “archives”, dentro de la cuál, se
diferencia el directorio de cada archivo de tipo Eprints que tenemos de manera
específica. Además, podemos encontrar otros directorios que contienen la
configuración genérica para todos los repositorios, como sería el directorio “cfg”
o el que alberga las configuraciones de plugins generales para todos los
repositorios, “lib”.

Figura 8. Directorio General Eprints

Dentro del directorio archivos, como se muestra a continuación se contendría

una carpeta por cada repositorio con el que trabajamos.

Figura 9. Contenido directorio archivos

18
Dentro del archivo correspondiente a cada repositorio encontramos un árbol de
directorios muy similar al general de Eprints, esto es debido a que las
configuraciones se consumen de dentro de cada repositorio, hacia los
directorios generales, por tanto, si una configuración es concreta de un
repositorio, estará en el “cfg” propio de ese repositorio, si no, estará en la carpeta
“cfg” del padre. Cierto es que muchas configuraciones, como las del idioma,
tienden a realizarse en el repositorio general excepto algunas cosas muy
específicas, con el fin de que sufran las actualizaciones en el mismo momento
que se actualiza la versión de Eprints. Esto se debe a que, tal y como podemos
leer en la documentación de Eprints, la carpeta “archives” nunca se ve
modificada por las actualizaciones y, por ende, tampoco su contenido de
configuración. Encontramos otras carpetas como “html” donde se incluyen
muchos recursos propios que luego Apache consume.

Figura 10. Contenido archivo UPM

Para concluir, una muestra de cómo sería la carpeta de configuración específica

de un repositorio en concreto, donde podemos ver por ejemplo sus
configuraciones de apache, la carpeta “lang” donde se almacenan
customizaciones de lenguaje del repositorio en cuestión, “epm” con funciones
de estadísticas y demás configuraciones específicas.

Figura 11. Contenido de “cfg” del archivo

19
2.3.2 Alternativas a Eprints

Para concluir con este apartado y completar la información sobre Eprints,

considero muy interesante realizar un breve comentario sobre las diferentes
alternativas que se utilizan alrededor del mundo.
Realmente no procede, en mi opinión, realizar un análisis en profundidad de los
beneficios o inconvenientes que presentan unos frente a otros, Eprints es el
software utilizado durante en el proyecto debido a su uso desde el inicio del
Archivo, su soporte y actualizaciones y la facilidad de la migración al usar el
mismo software que anteriormente, pero en una versión superior.
En una comparativa rápida, respaldada con las webs de cada software las
cuales dejaré en la bibliografía, podemos ver que Eprints presenta grandes
ventajas frente a sus competidores y, por tanto, creo que se hizo una gran
elección por parte del personal de la Universidad al escoger este software frente
a otros. Podemos ver que es el más extendido frente a los que compararé a
continuación. Algunas de sus ventajas frente a los otros son:
- Mayor cantidad de usuarios.
- Mayor número de idiomas disponibles que la mayoría de la competencia.
- Dispone del apartado Bazaar en su web donde se encuentran cantidad
de complementos fácilmente instalables.
- Grandes posibilidades de personalización: plugins, scripts, temas…
- Gran mantenimiento con numerosos parches de la comunidad.
- Buen sistema de logs para detectar fallos.
- Longevidad, es de los más antiguos que existen, planteado en 1999.

Tras estos detalles sobre las ventajas del software utilizado, incluyo un overview
sobre las otras alternativas Open Access que existen en el mercado con el mismo
propósito que el de Eprints:
x Greenstone[21]: Cuenta con una larga trayectoria iniciada en el año 2000
en Bélgica y es utilizado por la Organización de las Naciones Unidas y
patrocinado por la UNESCO. Su gran ventaja frente a sus competidores
es, sin duda, el hecho de tener una interfaz traducida a 60 idiomas
diferentes. Tiene un gran mantenimiento, y su uso es extendido por el
norte del continente americano, norte de Europa y sur de Asia.
x Bepress[22]: Originario de California, fue creado en el 1999 en California,
Estados Unidos. Utilizado de manera oficial en más de 600 instituciones,
su nicho son principalmente las universidades. Su uso se extiende sobre
todo por Europa y el este de Estados Unidos.
x OpenRepository/DSpace[23]: Incluyo los dos ya que realmente el software
para crear repositorios virtuales es OpenRepository, pero está basado en
DSpace que sirve para crear colecciones virtuales. Creado en 2002, es de
los de creación más reciente, quizá esto sea la causa de que, en su caso,
tenga soporte también para archivos de vídeo. Según los datos oficiales,
es utilizado por más de 2500 organizaciones y su relevancia es similar a
la de Eprints. Presenta una principal desventaja y es que su interfaz está
en inglés. Su uso se extiende por el este de Estados Unidos y el sur de
Asia mayoritariamente.
x Fedora Commons[24]: Creado en 1998 en Estados Unidos, fue de los
primeros en aparecer. Con mayor potencia inicial, hoy en día no se
mantiene, aunque sigue disponible. Su última actualización fue en 2011

20
 y encontramos una web oficial pobre y no tiene tan si quiera traducciones
a otros idiomas que no sean el inglés.
x Archimède[26]: Creado en Canadá, su uso es mucho menos extendido, por
lo que tiene menos soporte al ser un software universitario. Se encuentra
disponible únicamente en francés e inglés y cuenta con muy pocas
actualizaciones.

Figura 12. Logotipo GreenStone

Figura 13. Logotipo Eprints

Figura 14. Logotipo de Bepress Figura 15. Logotipo OpenRepository.

2.4 Apache

Para concluir el capítulo sobre el Estado del Arte, se me antojaba necesario

realizar investigación y hablar sobre Apache. Se trata de otro conocimiento
adquirido durante la realización del proyecto, y no es que realmente lo
desconociera, si no que no sabía cómo funcionaba la estructura del servicio ni
lo realmente importante y configurable que es.
Diría que existen cuatro pilares fundamentales sobre los que se cimienta este
proyecto, a saber, Eprints, Debian, Apache y MySQL. Como ya se ha indicado,
Debian es el sistema operativo virtualizado para el servidor, Eprints es el
software para la creación y gestión de los repositorios y sus funciones y Apache
provee la funcionalidad de servidor HTTP para establecer la conexión de los
miembros al Archivo y permite configurar todo lo referente a este servicio.
MySQL se encarga de la parte relacionada con las bases de datos de todo el
Archivo, pero realmente tenía un conocimiento sobre el mismo bastante
fundamentado de los estudios de grado, por lo que realmente creo que sólo es
interesante reseñar en este trabajo, cómo se disponen e interrelacionan las
bases de datos, de lo cual hablaré en el siguiente punto.
Por tanto, como he comentado, Apache es un servidor HTTP de tipo Open Source,
creado y mantenido por la empresa Apache Software Foundation, su creación
data de 1995 y en un año aproximadamente se convirtió ya en el servidor más
importante en todo el mundo, título que aún hoy ostenta. La compañía tiene

21
muchos otros desarrollos de software, pero el que nos interesa para centrarnos
sobre el proyecto es en concreto el servidor.
Se trata de un software muy basado en la contribución de los usuarios y
totalmente entregado a su comunidad. Al ser un software tan popular, favorece
mucho encontrar soporte ante cualquier problema o dificultad para desarrollar
algo en concreto. Es multiplataforma (ampliamente incluido como servicio en
servidores Linux en general) y además funciona por módulos.
El funcionamiento por módulos es muy ventajoso para este tipo de proyectos,
ya que el programa parte de una instalación inicial mínima, a la cual se le
añaden los módulos estrictamente necesarios según las necesidades que
tengamos en cada proyecto. En concreto algunos módulos son el SSL, el proxy
ajp, deflate (para compresión de contenido), etc.
Tiene también módulos que se pueden añadir como extensiones externas y los
cuales son realmente relevantes. En este caso debo señalar dos muy relevantes
que son el mod_pearl y mod_php para páginas que contienen estos lenguajes.
Como se ha comentado anteriormente, Eprints está basado en Pearl en concreto,
y en el caso de la Universidad Politécnica, se han hecho algunas adaptaciones
de aplicaciones en PHP para el Eprints añadidas específicamente por el equipo
de la universidad en el pasado para crear algunas funciones adicionales que no
se ofrecían como plugin en el bazaar de Eprints. Estos módulos hacen de
Apache una solución realmente interesante y a medida para nuestro Archivo.
Para concluir, añadiré una breve visión sobre lo que encontramos en cuanto a
configuraciones de Apache.

Figura 16. Directorio de

configuración de Apache

Es bastante intuitiva la forma en la que se configura la página para el navegador

a través de la cual accedemos al Archivo. Primero encontramos el fichero de tipo
“conf” que permite hacer cambios más técnicos en cuanto a rutas de los archivos
de configuración y otros. Encontramos unas configuraciones predefinidas,
todas recogidas en “conf-available” y se habilitan en “conf-enabled” que es de
donde realmente tira el servicio para conocer su configuración.
Vemos también localizadas sus variables de entorno, los mods que comentaba
anteriormente distribuidos de igual manera que la configuración, en disponibles
y habilitados, configuraciones de puertos, etc.
Por último, las carpetas de “sites” resultan muy relevantes ya que en ellas
encontramos ficheros para cada servicio que está utilizando Apache y un enlace
simbólico en ellas para indicarle a Apache dónde se encuentra dentro de los
archivos de ese servicio, la configuración del servidor HTTP que debe ejecutar.
Esta configuración ha sido bastante relevante a lo largo del proyecto y es por
esto por lo que también he decidido incluirla como una vía de aprendizaje.
22
3 Desarrollo del proyecto
En este apartado me centraré en desarrollar de la manera más fiel posible la
evolución del proyecto desde que lo inicié hasta lo que he logrado avanzar a
fecha de redacción de este trabajo, para luego explorar los pasos futuros y la
idea de avance que tengo hasta llegar al punto final deseado.

3.1 Trabajos realizados hasta la actualidad.

3.1.1 Evaluación y Planteamientos Iniciales.

Para comenzar, el primer paso que tuvo lugar fue la evaluación del estado actual
del conjunto. Por una parte, debía comprender la arquitectura que ostenta el
sistema y por otra parte investigar todas sus funcionalidades.

La universidad tiene dos máquinas dedicadas a este servicio, una máquina de

desarrollo, donde se realizan las pruebas (Bulnes 1) y una máquina de
producción que provee el servicio (Bulnes 2). Ambas son máquinas físicas e
independientes que corren un sistema operativo Debian 6 lanzado en 2011. El
objetivo principal es, virtualizar estas dos máquinas dentro del CeSViMa (Centro
de Supercomputación y Visualización de Madrid) de la universidad, y a su vez
aprovechar para actualizar sus sistemas operativos hasta el máximo posible,
así como el software que gestiona el repositorio, Eprints, actualizarlo también,
junto con el software que gestiona la base de datos, y migrar todos los datos y
funcionalidades de manera exitosa sin perder ninguna de estas cosas y sin tener
que establecer cortes en el servicio.

Todo lo anterior se trata de lo relativo a la arquitectura del sistema y los

objetivos para con la misma. También, para poder cumplir dichos objetivos y
asegurar una correcta y completa funcionalidad, fue necesario explorar más en
profundidad el sistema, incluso los apartados dedicados a la investigación con
usuarios que me fueron provistos por los profesionales que trabajan con ello.
Además, leer y comprender toda la documentación de la instalación inicial, fue
necesario y de gran ayuda a la hora de emprender el camino hacia el objetivo.
Adjunto una captura de la interfaz web que ofrece el sistema actualmente.

Figura 17. Página de inicio interfaz web del Archivo

23
3.1.2 Preparación de los Entornos Virtuales.

Tras esto, el siguiente paso sería preparar las máquinas virtualizadas con las
que he trabajado para realizar el proceso de la migración. Antes de llevar a cabo
ninguna instalación, consulté la documentación de Eprints, para comprobar
qué compatibilidades ofrecía con las diferentes versiones de Debian.

Para la preparación de las máquinas había que tener en cuenta múltiples

factores, entre ellos la obsolescencia de la versión actual ha marcado en todo
momento el gran número de pasos que se han tenido que dar. Como detallaré
más adelante, el sistema actual trabaja con la versión 3.3.12 de Eprints, esto
crea muchas dependencias en cuanto a las versiones del resto del ecosistema.
Debía partir necesariamente de una instalación en la máquina virtualizada de
la misma versión de Eprints que existe en la física, para intentar asegurar el
menor riesgo posible en cuanto a fallos si utilizaba versiones posteriores. Por lo
tanto, la decisión tomada fue partir de una instalación limpia de Eprints 3.3.12.
Esta determinación y las decisiones fueron respaldadas por el estudio de la
documentación además de consultadas con el grupo de profesionales que
mantienen el servicio del Archivo actualmente, tanto la persona que trata las
bases de datos, como quienes mantienen el repositorio.

Dado que la versión a utilizar del software de Eprints data del 2013, era
necesario explorar la compatibilidad con las versiones de Debian. Habría sido
ideal poder instalar Debian 10 de manera directa y solo trabajar con las
versiones del software y no la del sistema operativo, pero como se podía esperar,
esta versión no era compatible con 3.3.12. De igual modo, no se aseguraba la
compatibilidad total con Debian 9, por lo que forzosamente el punto de partida
del sistema operativo de las máquinas virtualizadas fue finalmente, Debian 8.

3.1.3 Creación de las Máquinas Virtuales.

Tras tomar esta decisión, llegaba el momento de comenzar el proceso de

virtualización. El CeSVima utiliza Xen Orchestra para gestionar sus máquinas
virtuales tal y como he señalado en el Capítulo número dos de este trabajo.
Antes de comenzar a utilizar este sistema, recibí una formación de la mano del
profesional encargado de gestionar las máquinas en el CeSViMa, para que me
indicara cómo se gestiona todo, una serie de normas sobre el uso de recursos,
y demás instrucciones necesarias para trabajar con sus máquinas. Como es
lógico me indicó que, en una instalación inicial, lo más correcto para evitar
consumir un exceso de recursos, era realizar una instalación con poco más de
lo mínimo imprescindible para el funcionamiento del sistema. También algo
muy importante que me comentó es el funcionamiento interno de las redes de
la universidad y los diferentes niveles de conexión que tienen las máquinas. Es
una información que resultaría muy interesante añadir, pero como es
comprensible, es algo que no puedo hacer para no comprometer la seguridad de
red del sistema.

Después, me facilitó una guía que tiene redactada, donde explica de forma muy
clara cómo realizar la creación de la máquina virtual y la instalación del sistema
operativo. Esta guía hizo posible ahorrar tiempo respecto al comienzo del
proyecto. La máquina de inicio, por tanto, sería una máquina con Debian 8, y
sería la máquina equivalente a la de desarrollo física.
24
3.1.4 Instalación de los Paquetes Software necesarios

Una vez fijado el punto de partida, comencé a instalar por paquetes todo lo
necesario para igualar el estado entre la máquina de desarrollo física y la virtual
y ver cómo de factible era obtener e instalar esos paquetes actualmente. Ha
resultado muy relevante en este proyecto intentar en la medida de lo posible
realizar las instalaciones por paquetes, para así asegurar que, en el futuro, el
personal que trabaja con el Archivo pueda realizar de manera sencilla las
actualizaciones que irán surgiendo. Tras hacer unas breves configuraciones e
instalaciones iniciales llegó el momento de realizar la instalación de Eprints.
Cuando se instala Eprints 3.3.12 se instala también el paquete correspondiente
de MySQL y, además, te permite crear un repositorio, por lo que, en ese
momento y con el apoyo de la guía ya existente sobre Eprints de la primera
instalación, procedo a crear también el repositorio en limpio que se utilizará
para el servicio del Archivo.

Al iniciar la instalación por paquetes hubo un pequeño fleco, ya que la versión

de Debian aun siendo la 8, no es la misma que en Bulnes donde se utiliza la
versión 6, por lo que en primer lugar tuve que resolver varias dependencias
necesarias para realizar la instalación de Eprints en la misma versión que está
en Bulnes (3.3.12) y la de MySQL (5.6.48). En concreto, el MySQL de Bulnes es
5.1.73, pero gracias a los snapshots pude comprobar que subiendo a 5.6 no
provocaba ningún problema. Las tablas conservaban la misma estructura en
ambos con mismo formato de tablas, filas y columnas; por lo que
previsiblemente no habría ningún problema en cuanto a la migración de los
datos.

3.1.5 Pruebas Intermedias de Actualización y Correcciones.

Tras esto, con la máquina limpia, comienzo una prueba de actualizar Eprints a
la última versión dentro de la 3.3 que es la 3.3.16 con el fin de comprobar que
tal y como se indicaba en la documentación de Eprints sólo se modificaban
algunos directorios en concreto (y se excluían de la actualización, algunos muy
relevantes que contenían la configuración del archivo), siempre respaldado por
un snapshot en Xen Orchestra por si llegara la necesidad de revertir los cambios.

Tras comprobar que realmente la actualización conservaba los ficheros del

Archivo y solo modificaba los correspondientes a Eprints en general, comencé a
documentar qué diferencias había entre Bulnes en 3.3.12 y la virtual en 3.3.16,
en cuanto a directorios, ficheros y sobre todo en las bases de datos originales.
Este proceso era largo pero necesario para luego poder detectar con mayor
agilidad los errores que se pudieran producir por cambios de directorio de algún
fichero, cambios de enlaces simbólicos, discordancias entre versiones, etc.

Dado que este proceso es complicado de redactar, simplemente estableceré

algunas comparaciones que permitan visualizar la cantidad de ficheros y
directorios procesados. En concreto el directorio “cfg” de “archives”, en su
versión original de la instalación limpia y la versión completa de Bulnes, con
4069 archivos sólo en el interior de esta. Aún siendo comparaciones aplicadas
con métodos recursivos, el proceso ha resultado largo y complicado.

25
Figura 18. Comparativa Bulnes y máquina virtualizada directorio cfg

Se puede apreciar en este ejemplo la gran diferencia existente sólo en uno de

los directorios propios del Archivo, en el cual aparte de localizar cambios en los
archivos iniciales (normalmente mediante el comando diff de manera recursiva),
debía también cribar los archivos que no fueran necesarios y se pudiera evitar
su migración.

Terminado este proceso de comprobación, revertí el snapshot de la máquina

virtual a la versión de Bulnes (de nuevo, 3.3.12) para poder realizar la migración
de datos.

Antes de la migración, y con la máquina ya revertida, hubo que realizar algunas

adaptaciones más y resolver dependencias específicas, del tipo de las que
indicaba arriba. Por ejemplo, había algunos archivos que Apache ahora los
consumía desde su configuración como un archivo de tipo “.conf”, y en el
momento en que se desarrolló esta versión antigua de Eprints eran texto plano,
por lo que Apache no los reconocía, esto se pudo resolver cambiando las
terminaciones de dichos archivos, y sus enlaces simbólicos dentro de la
configuración de Apache en la carpeta “sites-enabled” que comenté en el
capítulo dedicado a este servicio. Los cambios realizados en este aspecto para
sincronizar las diferentes versiones con las que estaba trabajando, fueron
numerosos, pero creo que se sale del objetivo de este documento, y por supuesto,

26
quedan documentados en cualquier caso en la guía técnica de la actualización
que estamos en proceso de elaborar el personal que trabaja con el Archivo y yo.

Decidí redactar la guía técnica anteriormente citada por si en algún momento a

posteriori se detectaba algún pequeño bug localizado, resultara más fácil de
comprender y solventar al personal que trabaja con el Archivo.

3.1.6 Migración de datos.

Resueltas las discordancias que he comentado, el personal y yo, decidimos

conjuntamente que la mejor opción para el paso siguiente, teniendo ya
alineadas las versiones de Eprints entre lo físico y lo virtual, sería migrar los
datos de la base de datos actual, a nuestra máquina. Llegado este punto, y
previo a la migración de los datos, era necesario ampliar el espacio de disco de
la máquina virtual, dado que, hasta el momento solo disponía del asignado en
la instalación inicial. A su vez, aumentamos el número de cores y de RAM de la
máquina ya que iba algo justa en algunos procesos y desde luego este en
concreto requeriría mayor capacidad de cómputo que los anteriores además de
bastante tiempo. En esta ocasión la documentación de la instalación en físico
resultó de gran ayuda de nuevo, ya que tal y como se indicaba en ella, y pude
comprobar, la máquina tenía dos discos auxiliares de los cuales, uno de mayor
capacidad almacenaba la base de datos en sí, y el otro almacenaba todos los
datos específicos de Eprints. Para este proceso, resultó de mucha ayuda
conocimientos adquiridos en asignaturas como Administración de Sistemas
Informáticos o Sistemas Operativos.

Teniendo ya la máquina preparada para migrar datos, me puse en contacto con

el profesional que se encarga de gestionar todas las bases de datos para la
Universidad. Al ser algo delicado de manejar por la relevancia de los datos, y
dado que se debían sacar del sistema físico de manera directa, el encargado de
las bases de datos generó un archivo para poder ejecutar un dump de la base
de datos en la máquina virtual. Al existir y manejarse varias bases de datos
relacionadas con el archivo, hubo que realizar una migración por fases, dado
que, en el primer intento, migramos todas juntas y obtuvimos precisamente
diversos errores relacionados con ubicaciones de archivos que no se
encontraban en las rutas esperadas, o ubicaciones donde se indicaba guardar
ciertos archivos que no tenían la misma estructura en el árbol de directorios.

Terminada esta migración, ya se disponía de una primera versión preliminar de

la web (apuntando obviamente a la IP de la máquina virtual, no a la física). En
ella, se podían observar diferentes fallos que Apache no procesaba bien, debidos
a las customizaciones utilizadas, a diferencias en los paquetes de idiomas,
algunas funciones no se ejecutaban correctamente, sobre todo búsquedas, etc.
Pero también se podían consultar ya, los archivos que había migrado de manera
satisfactoria.

3.1.7 Revisión de Datos y Corrección de Fallos en el Archivo

Lo siguiente, fue realizar una revisión de todas las tablas migradas de la base
de datos, para comprobar que se conservaban de forma satisfactoria los enlaces
entre diferentes elementos, y resolver algunos problemas de codificación.

En este apartado me gustaría ilustrar la complejidad de las bases de datos

analizadas durante el proceso y comparadas, tabla a tabla entre la instalación

27
limpia y la instalación en Bulnes con la siguiente captura. Se trata de la
representación de aproximadamente una cuarta parte del diagrama generado a
partir de una de las tres bases de datos que maneja el Archivo.

Figura 19. Esquema parcial de una de las bases de datos del Archivo

Aunque resulta imposible plasmar gráficamente el estado de estas bases de

datos, veo este ejemplo suficientemente ilustrativo como para comprender la
magnitud de las tablas sobre las que he trabajado y lo difícil que ha resultado
comparar sus entradas y buscar diferencias entre sus versiones para
posteriormente documentarlas antes de realizar los cambios.

La idea tratada en conjunto con todo el equipo sobre el planteamiento de

actuación es alinear de forma completa todo, sin que haya ningún fallo, antes
de seguir actualizando, con el fin de no arrastrar dichos fallos y generar aún
fallos mayores en las siguientes versiones. Antes de esto, realicé una marcha
atrás de todo el servidor, para asegurar una instalación limpia y comprobar si
todos los pasos de la guía de instalación funcionaban de manera correcta para
llegar al punto en el que se encontraba la máquina, y sin que faltara ninguno.

Realizado todo lo anterior, proseguí con el fin de devolver toda la funcionalidad

a la web trabajando en los siguientes fallos:

x Elaborar scripts que realizaran búsquedas para los paquetes de idiomas.

Dichos paquetes contenían líneas que no se estaban mostrando bien
traducidas en la versión en castellano de la web, por lo que hubo que
realizar adaptaciones en los archivos XML que se consumen al traducir
la página.
x Solventar las diferencias de directorios y nombres de algunas variables
provocadas por las diferentes versiones de Perl que trabajan en Debian 6
y 8.
x Reinstalar en la máquina nueva desde el denominado Bazaar de Eprints,
repositorio con el software de diferentes plugins, todos aquellos plugins
que estaban dando fallos. Para ello, debimos habilitar en la máquina el
proxy que permite instalar paquetes desde ese repositorio.

28
 x Resolver problemas con el apartado de investigación. Estos problemas
surgían debido a un cambio en las rutas donde se encontraban y donde
Apache los localizaba. Tuve que instalar también los módulos que no se
encontraban de PHP en Apache para que pudiera leer los archivos de
variables de esta parte de la web, que se encontraban en el mentado
formato.

En las últimas semanas, la línea de trabajo ha sido alineada con los

profesionales de la biblioteca que se encargan de la parte más técnica. Ellos
conocen cómo deben funcionar todos y cada uno de los apartados del repositorio,
qué funcionalidades deben tener, y cómo deben comportarse en concreto. A
continuación, observamos la página de búsqueda de la web en desarrollo
(banner amarillo indica que es desarrollo), y vemos fallos de visualización de
determinados elementos:

Figura 20. Página de búsqueda con errores

Hemos estado recabando información sobre algunas cosas que no funcionaban

y tratando de localizar de manera conjunta, fallos en rutas, fallos en plugins,
en traducciones, etc.

Hubo que resolver también recientemente fallos de:

x Búsqueda avanzada en los datos de la web. Los resultados que se

mostraban no eran todos los disponibles, o no se realizaba un filtrado
correcto, o directamente no se obtenía resultado alguno.
x Visualización de los resultados de la búsqueda en el formato que se debe.
x Funcionalidades de estadísticas. Ofrecidas como una customización
completamente propia de nuestro repositorio, no mostraban de manera
correcta los gráficos de los datos que se consultaban.

29
 x Almacenamiento incorrecto de identificadores al dar de alta nuevas
documentaciones.
x Errores al general fichero XML para consulta de los DOIs (identificadores
de documentos).
x Fallos de visualización de etiquetas.
x Errores en importaciones de documentación.
x Pérdida de ciertas materias dentro de las disponibles en el Archivo.
x Fallos en el autorrellenado.

Estos y algunos fallos más, es estrictamente necesario resolverlos antes de

poder continuar con la migración y actualización.

Como comentaba, la línea de trabajo actual se centra en esto y está resultando

un proceso ciertamente largo a causa de la dificultad para localizar el origen de
determinados fallos y la necesidad de sincronizar tiempos de trabajo con el
personal que está colaborando conmigo en la resolución de estas incidencias.

3.2 Roadmap para finalización del proyecto

Dada la complejidad de este proceso, resulta evidente que aún quedan pasos
por realizar que no han podido ser recogidos en fecha en este trabajo. Al
desarrollar de manera virtual este repositorio que va a dar un servicio público
a la nuestra comunidad universitaria, cada cambio, cada paso ha de ser tomado
con precaución y documentado debidamente. A todo ello, le añade complejidad
el hecho de trabajar sobre un sistema obsoleto desde hace bastantes años.
Por tanto, y a pesar de encontrarnos en este punto, dado que la línea de
actuación en adelante está planteada y aceptada por el equipo, indicaré a
continuación todos los pasos que se plantea seguir y que debo terminar con una
fecha tentativa de mediados de agosto de este año 2021.
Quizá comenzaría señalando, que, en mi opinión, el proyecto lleva un avance
del 60 o 70%. No se trata de un porcentaje exacto, pero es totalmente cierto que
los pasos dados, eran en el planteamiento inicial los que suponían más
dificultad por términos de obsolescencia, migraciones de datos, etc. Los pasos
en adelante los detallaré a continuación, pero opino que una vez esté todo
correctamente encarrilado en la situación actual lo siguiente debería fluir
mucho mejor.

3.2.1 Actualización de Eprints.

Cuando se finalice todo el proceso de adaptación y resolución de errores en el
que nos encontramos, el siguiente punto por abordar es la actualización de
Eprints a la versión 3.3.16. Previamente, revertiré de nuevo a un punto
intermedio hasta donde la guía de instalación está comprobada de nuevo, para
comprobar otra vez los pasos desde entonces hasta ahora y verificar que esté
todo bien documentado.
Según lo comprobado que he indicado arriba en el paso previo a la migración
de datos, este paso de actualizar sólo modificará los archivos referentes a la
configuración genérica del software de Eprints, pero en ningún momento
modifica los archivos propios del repositorio del Archivo. Por tanto, la
actualización sólo constará de la instalación del paquete nuevo.

30
Después de esta instalación, se deberá comprobar de nuevo si efectivamente
todo continúa correcto y los datos y la web se pueden consultar de manera
satisfactoria.
Esta versión, sería la última compatible con Debian 8, por lo tanto, para
continuar actualizando lo siguiente que se hará será actualizar el sistema
operativo de la máquina a Debian 9, también compatible con 3.3.16, pero
recordemos que no con 3.3.12 de Eprints. En principio, los paquetes que incluye
este sistema operativo (su MySQL, Apache…), se encuentran en las mismas
versiones con las que estoy trabajando en Debian 8, por tanto, esta
actualización del sistema operativo no debería generar ningún tipo de conflicto.
Alcanzado este punto, la máquina de desarrollo se encontraría en la última
versión documentada y respaldada por la comunidad como última
completamente estable y fiable.

3.2.2 Creación y Preparación de la Máquina de Producción.

Entonces, sería el momento de la máquina de producción. Este paso no debería

ser muy costoso, ya que se creará una máquina con las mismas prestaciones
que la de desarrollo, pero dedicada a producción. Esta máquina tendrá como
diferencia principal, el disco dedicado al almacenamiento de los datos, ya que,
en producción, la cantidad de datos existentes es mayor que en desarrollo y
además, algunos datos de prueba existentes en desarrollo no aparecen en
producción. Este disco se llenará con los datos que se manejan en producción
de nuevo con la ayuda del especialista en bases de datos y realizando un dump
de los datos por fases, como se hizo en desarrollo. Además, las redes de las que
dispondrá serán también otras, de nuevo por protocolos de seguridad y de
funcionamiento, que difieren entre desarrollo y producción, en concreto sobre
la accesibilidad desde el exterior a las máquinas.

Cuando esta máquina esté lista y probada, se podrá realizar un cambio de

agujas entre la física y la virtual de producción para que pase realmente a ser
accesible para el público y así proceder a retirar la máquina física del servicio.
Justo en el momento de hacer este cambio, se realizará de nuevo una
sincronización de los datos que migrará únicamente los datos nuevos respecto
a la migración total para así tener la máquina en su estado último antes de
realizar el cambio. En ese momento, el objetivo principal del proyecto estará
cumplido.

3.2.3 Posibles Actuaciones Futuras.

En adelante, las próximas vías serían, de nuevo con la máquina de desarrollo,

intentar actualizar Eprints a su versión más reciente de todas, Eprints 3.4.
Realizar pruebas sobre dicha versión, y de comprobar su correcto
funcionamiento, actualizarla también en producción. Si con todo eso aún
sobrara tiempo del proyecto, se intentaría realizar una actualización a Debian
10 en desarrollo, aunque no se llegaría a pasar a producción y tendría que
probarse a fondo por el equipo, ya que no se asegura ningún tipo de fiabilidad
ni consistencia.

31
4 Conclusiones

Para finalizar, me gustaría añadir las conclusiones que he extraído de la

realización de este trabajo, tanto personales como técnicas.

Las conclusiones que puedo detallar de forma completa son por el momento en
cuanto a la parte de desarrollo del trabajo de fin de grado. El proyecto de
migración como tal, aún se encuentra en ejecución por lo que intentaré elaborar
unas conclusiones preliminares, previas a la finalización.

En primer lugar, tanto el proyecto en el que estoy implicado, como la realización

de este trabajo en sí, me resulta altamente interesante debido a su objetivo y
desarrollo. La administración de sistemas ha sido siempre una de mis salidas
laborales preferidas y algo que me ha resultado muy interesante a lo largo de
toda la carrera. Este proyecto, ha impulsado mi aprendizaje en esta área
facilitado además por el apoyo de grandes profesionales que trabajan para
nuestra Universidad, así como el propio “hands-on” que supone realizar una
labor de este calibre por ti mismo.

Al redactar este documento, he podido recapacitar sobre la cantidad de

conceptos y conocimientos teóricos y prácticos que he podido adquirir gracias a
participar en este proyecto, además de plasmar la labor que estoy y estamos
realizando para la Universidad y todas las personas que la componen.

Técnicamente hablando, el aprendizaje también es amplio. El Archivo se

encontraba en una situación algo extrema debido a la limitación de las
tecnologías de base. En mi opinión es una labor muy importante, participar en
esta fase de actualización e innovación de los servicios de la Universidad, en dar
un paso más hacia el futuro y conseguir proponer e implantar un modelo técnico
que permita realizar un mantenimiento mucho más sencillo y a su vez riguroso
sobre todo el servicio y las máquinas donde reside. Toda esta situación te
permite darte cuenta de lo realmente importante que es en nuestras tecnologías
hoy en día, el hecho de mantener un rigor en cuanto a actualizaciones, la forma
de gestión de cambios, la documentación, y muchas otras cosas que quizá se
habían dejado un poco de lado en este caso como ocurre en muchos otros.

Tengo la seguridad de que, si el Archivo se hubiera ido actualizando paso a paso,

no sería necesario tanto tiempo para realizar la migración como está ocupando,
y la virtualización se hubiera acometido de una manera algo menos costosa. A
su vez, tengo la certeza de que el trabajo concluirá con éxito y quedará todo
documentado de manera precisa por si en el futuro fuera necesario realizar de
nuevo estas actualizaciones o alguna migración más.

Sin duda ha sido toda una experiencia de gran aprendizaje que he tratado de
plasmar de la manera más fiel posible en este documento.

32
5 Bibliografía
[1] Jesús Carretero Pérez, Félix García Carballeira, Fernando Pérez Costoya,
“Virtualización” en Sistemas Operativos: Una Visión Aplicada Vol. 2, 3 ed.,
Madrid, España,2020.
[2] Shashank Mohan Jain, “Virtualization Basics” en Linux Containers and
Virtualization, 1 ed., Apress, Berkeley, CA. 2020.
[3] Shashank Mohan Jain, “Hypervisors” en Linux Containers and Virtualization,
1 ed., Apress, Berkeley, CA. 2020.
[4] San Murugesan, Irena Bojanova, “Virtualization: an onverview” en
Encyclopedia of Cloud Computing, 1ª ed., Wiley, 2016.
[5] Citrix Main Site [Online]. Disponible:

https://www.citrix.com/es-es/

[6] XenProject Main Site [Online]. Disponible:

https://xenproject.org/users/virtualization/

[7] Xen Orchestra, Citrix Marketplace Site [Online]. Disponible:

https://citrixready.citrix.com/vates/xen-
orchestra.html#:~:text=Xen%20Orchestra%20is%20a%20web,to%20rule%20al
l%20your%20infrastructure.

[8] Benjamin Armstrong (2016, octubre 7), Hyper-V en Windows Server.

[Online]. Disponible:

https://docs.microsoft.com/es-es/windows-server/virtualization/hyper-
v/hyper-v-on-windows-server

[9] VMware, Solutions-Virtualization Site [Online]. Disponible:

https://www.vmware.com/solutions/virtualization.html

[10] VirtualBox, Virtualization Manual [Online]. Disponible:

https://www.virtualbox.org/manual/ch01.html#features-overview

[11] Universidad de Castilla-La Mancha, Open Science [Online]. Disponible:

https://www.uclm.es/areas/biblioteca/investiga/openscience/openscience2
[12] Orion, What is Open Science? [Online]. Disponible:

https://www.orion-openscience.eu/resources/open-science
[13] European Comission, The EU’s Open Science Policy [Online]. Disponible:

https://ec.europa.eu/info/research-and-innovation/strategy/goals-research-
and-innovation-policy/open-science_en

[14] Foster, What is Open Science? Introduction [Online]. Disponible:

https://www.fosteropenscience.eu/content/what-open-science-introduction

33
[15] Vicerrectorado de Tecnologías de la Información y Servicios Web (2010
octubre 28), Política de Acceso Abierto de la UPM. Disponible:

http://oa.upm.es/docs/POLITICA_OA_UPM.pdf
[16] Eprints, Open Access [Online]. Disponible:

https://www.eprints.org/uk/index.php/flavours/openaccess/
[17] Budapest Open Access Initiative [Online]. Disponible:

https://www.budapestopenaccessinitiative.org/

[18] Eprints [Online]. Disponible:

https://www.eprints.org/uk/

[19] Manual Eprints. Eprints Repository Software [Online]. Disponible:

http://wiki.eprints.org/w/Manual

[20] Wikipedia. Eprints [Online]. Disponible:

https://es.wikipedia.org/wiki/EPrints

[21] Greenstone Main Site [Online]. Disponible:

https://www.greenstone.org/index_es

[22] Bepress Main Site [Online]. Disponible:

https://bepress.com/

[23] OpenRepository Main Site [Online]. Disponible:

https://www.openrepository.com/

[24] Lyrasis Main Site. Fedora Commons [Online]. Disponible:

https://duraspace.org/fedora/

[25] Wikipedia. Fedora Commons [Online]. Disponible:

https://es.wikipedia.org/wiki/Fedora_Commons /

[26] Université Laval, Archimède [Online]. Disponible:

https://www.bibl.ulaval.ca/archimede/index.en.html

[27] Apache Main Site, Apache [Online]. Disponible:

https://www.apache.org/

[28] Wikipedia. Servidor HTTP Apache [Online]. Disponible:

https://es.wikipedia.org/wiki/Servidor_HTTP_Apache

34
Este documento esta firmado por
Firmante CN=tfgm.fi.upm.es, OU=CCFI, O=Facultad de Informatica - UPM,
C=ES
Fecha/Hora Thu Jun 03 16:22:00 CEST 2021
Emisor del [email protected], CN=CA Facultad de
Certificado Informatica, O=Facultad de Informatica - UPM, C=ES
Numero de Serie 630
Metodo urn:adobe.com:Adobe.PPKLite:adbe.pkcs7.sha1 (Adobe
Signature)