Documentos de Académico
Documentos de Profesional
Documentos de Cultura
TFG Oscar Ortega Diaz
TFG Oscar Ortega Diaz
de Madrid
Escuela Técnica Superior de
Ingenieros Informáticos
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.
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.
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
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.
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:
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.
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.
4
2.1.2 Open Access
2.2 Virtualización
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.
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 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.
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.1 Xen.
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
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.
2.2.5.3 VMware
15
2.2.5.4 VirtualBox
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
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”.
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.
19
2.3.2 Alternativas a Eprints
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.
2.4 Apache
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.
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.
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.
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.
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.
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.
25
Figura 18. Comparativa Bulnes y máquina virtualizada directorio cfg
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.
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.
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
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.
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.
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.
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.
31
4 Conclusiones
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.
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/
https://xenproject.org/users/virtualization/
https://citrixready.citrix.com/vates/xen-
orchestra.html#:~:text=Xen%20Orchestra%20is%20a%20web,to%20rule%20al
l%20your%20infrastructure.
https://docs.microsoft.com/es-es/windows-server/virtualization/hyper-
v/hyper-v-on-windows-server
https://www.vmware.com/solutions/virtualization.html
https://www.virtualbox.org/manual/ch01.html#features-overview
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
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/
https://www.eprints.org/uk/
http://wiki.eprints.org/w/Manual
https://es.wikipedia.org/wiki/EPrints
https://www.greenstone.org/index_es
https://bepress.com/
https://www.openrepository.com/
https://duraspace.org/fedora/
https://es.wikipedia.org/wiki/Fedora_Commons /
https://www.bibl.ulaval.ca/archimede/index.en.html
https://www.apache.org/
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)