ESCUELA SUPERIOR DE INGENIERÍA

Transcripción

1 ESCUELA SUPERIOR DE INGENIERÍA INGENIERÍA TÉCNICA EN INFORMÁTICA DE GESTIÓN ClonUCA, gestión de clonaciones y de copias de seguridad Ismael Cano Sánchez 5 de julio de 2012

2

3 ESCUELA SUPERIOR DE INGENIERÍA INGENIERO TÉCNICO EN INFORMÁTICA DE GESTIÓN ClonUCA, GESTIÓN DE CLONACIONES Y DE COPIAS DE SEGURIDAD Departamento: Lenguajes y Sistemas Informáticos Director del proyecto: Daniel Molina Cabrera Autor del proyecto: Ismael Cano Sánchez Cádiz, 5 de julio de 2012 Fdo: Ismael Cano Sánchez

4

5 Índice general 1. Motivación y contexto del proyecto Introducción Estableciendo objetivos y criterios Evaluación de herramientas Norton Ghost PING SystemRescueCD Acronis True Image Home[5] FOG Project OpenGnSys REDO Clonezilla[7] Resumiendo Conclusiones Herramientas de desarrollo Introducción Utilizar herramienta existente Crear una herramienta nueva La decisión esta tomada: ClonUCA Expectativas de ClonUCA Compatibilidad Sistemas de Ficheros Gestor de Arranque Copias de Seguridad Autonomía Estabilidad Eficiencia Usabilidad Licencia Adaptabilidad Planificación del proyecto Organización temporal Fase de inicio, [59 días] Fase de ejecución, [296 días] Fase de documentación, [296 días] Fase de control, [296 días] I

6 Fase de finalización, [29 días]: Análisis Metodología de Desarrollo Especificación de requisitos Requisitos funcionales Requisitos de interfaces externas Requisitos de rendimiento Modelo de casos de uso Diagramas de casos de uso Descripción de casos de uso Diseño Introducción Diseño de la capa de lógica de la aplicación Diseño de la capa de presentación Implementación Introducción Scripts de ClonUCA Lenguaje y Herramientas Utilizadas Estructura de directorios Sistema Base Desarrollo de la maqueta del live-cd o Fase: Minimizar o Fase: Interfaz Gráfica o Fase: Integración entre el live-cd y ClonUCA Pruebas Introducción Hitos conseguidos Guardar/Restaurar desde un recurso de red Guardar/Restaurar desde un dispositivo local Cliente/Servidor P2P Cliente/Servidor Multicast Clonación Local Sistema de Backup Caso especial: Centro de clonado con servidor PXE-ClonUCA Resumiendo Conclusiones Conclusiones Personales Conocimientos Adquiridos Objetivos Cumplidos Futuro del Proyecto A. Montaje de un servidor PXE con ClonUCA 101 A.1. Introducción A.2. Configuración servidor PXE II

7 B. Creación de un live-usb con ClonUCA 107 B.1. Introducción B.2. Configurar live-usb con ClonUCA C. Manual de usuario 111 C.1. Introducción C.2. Menú Principal C.3. Guardar Imagen C.4. Restaurar Imagen C.5. Servidor de Clonación C.6. Cliente de Clonación C.7. Clonación Local C.8. Sistema de Backup D. GNU Free Documentation License APPLICABILITY AND DEFINITIONS VERBATIM COPYING COPYING IN QUANTITY MODIFICATIONS COMBINING DOCUMENTS COLLECTIONS OF DOCUMENTS AGGREGATION WITH INDEPENDENT WORKS TRANSLATION TERMINATION FUTURE REVISIONS OF THIS LICENSE RELICENSING ADDENDUM: How to use this License for your documents Bibliografia y referencias 149 Anexos 151 III

8 IV

9 Indice de figuras 1.1. Ejemplo de aula de informática de la UCA Logo de Norton Ghost Captura de pantalla de Norton Ghost Logo de PING Captura de pantalla de PING Captura de pantalla de System Rescue CD Logo de SystemRescueCD Logo de Acronis True Image Home Captura de pantalla de Acronis True Image Home Logo de FOG Project Captura de pantalla de FOG Project Captura de pantalla de OpenGnSys Logo de OpenGnSys Logo de REDO Captura de pantalla de REDO Logo de Clonezilla Captura de pantalla de Clonezilla Logo de ClonUCA Ejemplo de captura de pantalla de ClonUCA ClonUCA cumple con la licencia GPLv Gráfico de sectores con organización temporal del proyecto Gráfico de sectores con organización temporal de la fase de inicio Gráfico de sectores con organización temporal de las fases de ejecución, documentación y control Gráfico de sectores con organización temporal de la fase de finalización Diagrama de Gantt con planificación temporal del proyecto Diagrama de caso de uso: primera iteración Diagrama de caso de uso: segunda iteración Diagrama de caso de uso: tercera iteración Diagrama de caso de uso: cuarta iteración Representación gráfica del proceso de Guardar/Restaurar una imagen Representación gráfica del proceso de clonado en local Representación gráfica del proceso de clonado por red Representación gráfica del proceso de backup Diagrama de estructura del menú principal Diagrama de estructura de la función guardar imagen V

10 6.7. Diagrama de estructura de la subfunción almacén local Diagrama de estructura de la subfunción almacén NFS Diagrama de estructura de la subfunción almacén SMB Diagrama de estructura de la subfunción almacén SSH Diagrama de estructura de la función restaurar imagen Diagrama de estructura de la función clonación local Diagrama de estructura de la función servidor clonación Diagrama de estructura de la función servidor unicast Diagrama de estructura de la función servidor multicast Diagrama de estructura de la función servidor P2P Diagrama de estructura de la función cliente clonación Diagrama de estructura de la función cliente unicast Diagrama de estructura de la función cliente multicast Diagrama de estructura de la función cliente P2P Diagrama de estructura de la función sistema backup Diagrama de estructura de la función realizar backup Diagrama de estructura de la función restaurar backup Boceto del Menú Principal Boceto de las funciones Guardar y Restaurar Boceto de la función Clonar Localmente Boceto de las funciones Servidor y Cliente Boceto de las funciones Backup y Restore Esquema de la estructura del live-cd: sistema base y los scripts de ClonUCA Logo de Python Logo de wxpython Estructura de los directorios de los scripts de ClonUCA Imagen para el splash del live-cd de ClonUCA Aula de Informática del aulario del Campus de Jerez Portátil del seminario 0.3 del edificio Multiusos del Campus de Jerez Portátil del aula 1 del Aulario del Campus de Jerez Portátil Toshiba NB200 para el préstamo de los alumnos Centro de clonación con portátiles Toshiba NB A.1. Esquema gráfico del funcionamiento de un Servidor PXE con ClonUCA B.1. Captura de pantalla del proceso de particionamiento de una memoria USB B.2. Captura de pantalla de la aplicación UNetbootin C.1. Manual de usuario: pantalla inicial de ClonUCA C.2. Manual de usuario: función Guardar Imagen C.3. Manual de usuario: función Guardar Imagen en Local C.4. Manual de usuario: Creamos un directorio en almacen C.5. Manual de usuario: proceso de creación de una imagen con partclone C.6. Manual de usuario: función Guardar Imagen en recurso NFS C.7. Manual de usuario: función Guardar Imagen en recurso SSH C.8. Manual de usuario: función Guardar Imagen en recurso SMB C.9. Manual de usuario: función Restaurar Imagen C.10. Manual de usuario: función Restaurar Imagen desde Local C.11. Manual de usuario: función Restaurar Imagen desde recurso NFS VI

11 C.12. Manual de usuario: función Restaurar Imagen desde recurso SSH C.13. Manual de usuario: función Restaurar Imagen desde recurso SAMBA C.14. Manual de usuario: proceso de restauración de un partición con partclone C.15. Manual de usuario: función Servidor de Clonación C.16. Manual de usuario: función Servidor de Clonación por Unicast C.17. Manual de usuario: proceso de envío de clonación unicast con partclone C.18. Manual de usuario: función Servidor de Clonación por Multicast C.19. Manual de usuario: función Servidor de Clonación por P2P C.20. Manual de usuario: El servidor P2P comprueba el fichero.torrent C.21. Manual de usuario: El servidor P2P termina el proceso de envío por P2P C.22. Manual de usuario: función Cliente de Clonación C.23. Manual de usuario: función Cliente de Clonación por Unicast C.24. Manual de usuario: proceso de recibir clonación por unicast con partclone C.25. Manual de usuario: función Cliente de Clonación por Multicast C.26. Manual de usuario: función Cliente de Clonación por P2P C.27. Manual de usuario: El cliente esta descargando con Bittorrent la imagen de clonación. 132 C.28. Manual de usuario: El cliente ha terminado de descargar la imagen de clonación C.29. Manual de usuario: función de Clonación Local C.30. Manual de usuario: función de Sistema de Backup C.31. Manual de usuario: función de Backup en Almacén Local C.32. Manual de usuario: función de Backup en Almacén NFS C.33. Manual de usuario: función de Backup en Almacén SSH C.34. Manual de usuario: función de Backup en Almacén SAMBA C.35. Manual de usuario: función de Backup en Almacén de Red C.36. Manual de usuario: función de Restore desde Almacén Local C.37. Manual de usuario: función para elegir el fichero de Backup para su restauración C.38. Manual de usuario: función de Restore desde Almacén de Red VII

12 VIII

13 Indice de tablas 1.1. Estadísticas del número de equipos de la UCA. Año Características generales de los sistemas de clonado Características generales de los sistemas de clonado (Continuación) Criterios: (1) Compatibilidad, (2) Sistemas de Ficheros, (3) Gestores de Arranque, (4) Copias de Seguridad, (5) Autonomía, (6) Estabilidad, (7) Eficiencia, (8) Usabilidad, (9) Adaptabilidad y (10) Licencia Evaluando ClonUCA respecto a los criterios establecidos: (1) Compatibilidad, (2) Sistemas de Ficheros, (3) Gestores de Arranque, (4) Copias de Seguridad, (5) Autonomía, (6) Estabilidad, (7) Eficiencia, (8) Usabilidad, (9) Adaptabilidad y (10) Licencia IX

14 X

15 Capítulo 1 Motivación y contexto del proyecto 1.1. Introducción En el mundo de los ordenadores, existen multitud de empresas, instituciones, administraciones, etc., que poseen una gran cantidad de ordenadores. Qué ocurre cuando hay que formatear un equipo, instalar nuevo software, hacer actualizaciones, etc...? Y cuando son 10? Y cuando son 100? Si la mayoría de los ordenadores fueran diferentes entre si, habría que afrontar esta tarea uno por uno, resultando un trabajo muy laborioso y lento. Pero que ocurriría si la mayoría de los ordenadores fueran iguales o prácticamente iguales, que con instalar, configurar o actualizar uno, podríamos clonar ese equipo al resto de los ordenadores. Figura 1.1: Ejemplo de aula de informática de la UCA 1

16 Y esta situación la vamos a encontrar principalmente en el ámbito de la enseñanza y de la administración pública, donde podemos encontrar por un lado aulas o salas de informáticas, como la que podemos ver en la figura 1.1, con un gran número de ordenadores todos iguales, destinados al aprendizaje, y por otro lado, podemos encontrar grandes áreas de trabajo: administración, secretaria, personal, departamentos, contabilidad, etc..., donde los usuarios poseen ordenadores idénticos y con las mismas necesidades de software. Por tanto, se hace evidente la necesidad de buscar una herramienta que nos ayude a agilizar la tarea de instalación, configuración y actualización del software de los ordenadores. Concretando un poco en el ámbito de la Universidad de Cádiz y con datos estadísticos referidos al año 2011 recogidos en el Anexo I que podemos encontrar en la siguiente dirección URL: Nos encontramos con el siguiente número de equipos informáticos reflejados, de una forma resumida, en la siguiente tabla 1.1. Equipos por Campus Algeciras Cádiz Jerez Puerto Real Total PAS y Directivos PDI Aulas de Informática Aulas de Docencia PARIS y PAP Portátiles Préstamo Total Tabla 1.1: Estadísticas del número de equipos de la UCA. Año 2011 De los datos referidos en la tabla podemos extraer algunas conclusiones interesantes. Teniendo en cuenta que los datos son del año 2011 y que durante el año 2012 el número de equipos debe aumentar, y esperando que el proceso continúe al alza en los años venideros, se hace cada más necesario, por no decir imprescindible, un software que nos ayude a gestionar fácilmente esta ingente cantidad de equipos. Analizando un poco el tipo de los equipos descubrimos que hay dos grupos diferentes. Por un lado están todos aquellos que se incluyen en las aulas de informática, aulas de docencia, portátiles de préstamo, PAP y PARIS. Estos equipos responden al siguiente patrón: suelen ser equipos iguales y los usuarios no guardan información personal en los mismos, por lo tanto se adaptan perfectamente a aplicaciones de clonación masiva. Otra característica importante es que los sistemas operativos pueden ser Windows, Linux o ambos, por tanto el sistema tiene que ser capaz de gestionar ambos sistemas operativos. Por otro lado están los equipos de PAS, PDI y Directivos. Aquí los equipos son más heterogéneos, aunque cada vez la tendencia es a lo contrario. Además en estos equipos los usuarios si guardan información personal. Por tanto, el sistema adecuado para la gestión de los mismos es aquel que sea capaz 2

17 de realizar clonaciones individuales, o una mezcla de clonaciones masivas de un sistema básico y luego poder hacer copias de seguridad de los datos personales Estableciendo objetivos y criterios El objetivo fundamental es el de desarrollar una herramienta informática que permita gestionar el proceso de clonación y de copias de seguridad de una forma eficaz y eficiente, atendiendo principalmente a las necesidades indicadas en la Universidad de Cádiz. De todas formas estas necesidades siempre pueden ser extrapoladas a cualquier otro ámbito, por tanto, la herramienta también deberá dar una respuesta a las mismas. Después de definir el objetivo, vamos a establecer una serie de criterios fundamentales que la herramienta desarrollada debe cumplir, y esos son los siguientes: Compatibilidad: Es fundamental que la aplicación sea capaz de gestionar sistemas Windows como Linux. De nada vale tener una aplicación extraordinaria en sistemas Windows y que luego no sea capaz de gestionar un Linux, o viceversa. Sistemas de Ficheros: Este criterio va en relación con el anterior, la aplicación tiene que soportar los sistemas de ficheros más comunes tanto en Windows como en Linux. Y estos son: FAT y NTFS en Windows, y EXT2, EXT3, EXT4, Reiserfs, JFS y XFS en Linux. Gestor de Arranque: También está en relación con los anteriores, de nada vale que pueda gestionar un sistema de ficheros si luego en la restauración del mismo, el gestor de arranque no funciona y no puede arrancar el sistema. La restauración del gestor de arranque de Windows es trivial, y lo hacen todos, pero los gestores de arranque de Linux es diferente. La aplicación debería soportar GRUB y GRUB2, y en menor medida LILO, ya que es un poco antiguo y no se usa mucho. Copias de Seguridad: Dado los requisitos iniciales es muy importante que el sistema pueda hacer copias de seguridad de los equipos, como complemento del sistema de clonado. Autonomía: Este criterio es fundamental, ya que estamos buscando un sistema lo más autónomo posible, para así evitar riesgos a la hora de clonar equipos. Por poner un par de ejemplos. Qué ocurre si nuestro sistema de clonado solamente esta basado en la red, y en un determinado momento se ha caído la red?. Pues que no se puede trabajar, y si nuestro sistema esta montado sobre un sistema operativo y por cualquier motivo éste falla y echa abajo el sistema?. Pues lo mismo, que no se puede trabajar. La solución es buscar un sistema totalmente autónomo, con multitud de opciones a la hora de guardar las imágenes de clonado. Lo primero lo podemos conseguir con un live-cd y lo segundo ya dependerá de la implementación de cada aplicación. 3

18 Estabilidad: La estabilidad está relacionada con el soporte que la herramienta tiene. En otras palabras, la herramienta tiene que estar soportada, mantenida y actualizada. Tiene que haber un equipo humano que dé soporte ante cualquier incidencia, que sea capaz de ir corrigiendo los errores, y también que vaya actualizando la herramienta conforme a las nuevas necesidades de hardware y software. Eficiencia: Lo que buscamos es un sistema rápido, tanto en el manejo como a la hora de la puesta en marcha. No nos interesa un sistema grande que consuma muchos recursos, sino todo lo contrario, un sistema ágil y liviano, que pueda ejecutarse en equipos modestos y no haga falta tener la última tecnología para poder trabajar decentemente. Usabilidad: La eficiencia no tiene que estar reñida con la usabilidad. El sistema tiene que ser agradable de usar, no solo por su rapidez, sino por su entorno. Los sistemas en modo texto se ven bastantes antiguos, dan la sensación de que son más complicados de usar, no quiere decir que lo sean, pero lo aparentan. Por tanto sería interesante que la aplicación estuviera integrada en un entorno gráfico para mayor facilidad de uso. Adaptabilidad: Este criterio aglutina dos conceptos, uno se refiere a facilidad con la que el sistema pueda ser modificado por el usuario final, para adaptarlo a sus necesidades, actualizarlo con nuevos componentes y para añadirle o quitarle alguna funcionalidad. Y el otro, se refiere a las posibilidades que puede ofrecer la herramienta a la hora de afrontar una tarea, es decir, tiene que poner a disposición del usuario diferentes formas resolutivas, y es este en última instancia, quién elije la más apropiada. Licencia: Y el criterio anterior no sería posible si la aplicación no tuviera una licencia Software Libre[1]. Es fundamental que el sistema de gestión de clonado y copias de seguridad responda a este tipo de licencia, especificado en la norma Licencia Pública General de GNU (GPL)[25]. Y no solo por cumplir el criterio de la adaptabilidad, sino también porque comparto toda la filosofía que hay detrás del Software Libre. Además la Universidad de Cádiz también apoya toda esta corriente a través de su Oficina de Software Libre, OSLUCA ( Sería incoherente buscar aplicaciones con licencia privativa para resolver la problemática expuesta hasta ahora. Una vez establecido el objetivo y los criterios, se realizará una búsqueda, en el capítulo 2, de aquellas herramientas existentes en la actualidad. Con objeto de analizarlas y contrastarlas con el objetivo y los criterios establecidos. Esta evaluación nos va a permitir sacar conclusiones para el desarrollo de nuestra herramienta. En los siguientes capítulos se detalla el proceso de desarrollo de ClonUCA, una herramienta para la gestión de clonación y copias de seguridad. 4

19 Capítulo 2 Evaluación de herramientas Una vez decidido el desarrollo de una nueva herramienta de gestión de clonaciones y de copias de seguridad, vamos a evaluar en este capítulo, atendiendo al objetivo y los criterios establecidos en el capítulo anterior, las distintas herramientas que actualmente podemos encontrar para gestionar clonados y copias de seguridad de los equipos microinformáticos. Existe mucha variedad, hablando conceptualmente, o formas diferentes de enfocar el problema por parte de los distintos sistemas, con sus bondades y su defectos, pero de todos ellos siempre podemos sacar conclusiones que nos ayuden al desarrollo de la herramienta. A continuación vamos a ir desgranando los diferentes sistemas de clonado y de copias de seguridad que podemos encontrar Norton Ghost Vamos a empezar con el Norton Ghost[12] porque es un sistema muy conocido y difundido, lleva en el mercado aproximadamente desde 1997 con la version Norton Ghost 3.1 y todavía la empresa Symantec lo mantiene y lo desarrolla, ahora mismo la última versión estable es Norton Ghost 15 y data de Abril del Ha sido la referencia en el mundo del clonado y por eso debe ser estudiado y evaluado. Figura 2.1: Logo de Norton Ghost Como podemos comprobar en su página web, Norton Ghost es un software comercial, es decir, tenemos que abonar 69,99 euros para poder utilizarlo. Como principales características podemos co- 5

20 mentar que para poder utilizarlo hay que instalarlo en un Windows XP, Vista o 7, por lo tanto se utilizará principalmente para hacer clonados de sistemas Windows, aunque es capaz de entender particiones de sistemas de ficheros de Linux: EXT2 y EXT3, no es capaz de restaurar los gestores de arranque propios de Linux, LILO y GRUB. También puede realizar copias de seguridad de archivos o carpetas concretas, no hace falta que hagamos una imagen de un disco duro o partición al completo. Figura 2.2: Captura de pantalla de Norton Ghost Valoración: Norton Ghost fue de las primeras herramientas de clonación y copias de seguridad, y por tanto lleva una gran trayectoria, ahora bien, actualmente no responde a ciertas características fundamentales, como el no soportar sistemas Linux, así como no cumplir con la licencia Software libre GNU GPL PING En 2004 la empresa EFFITEK desarrolla este software para dar una alternativa que sea Software libre al famoso Norton Ghost. Como muestra, un botón, las siglas de PING (Partimage Is Not Ghost)[14] dan fe de ello. Ahora mismo la última versión estable es la que fue liberada en Abril del

21 Figura 2.3: Logo de PING Como principales características podemos comentar que es una live-cd muy pequeña, unos 25 MiB, por tanto el arranque es rápido. Al ser una live-cd, es un sistema autónomo, no necesitamos instalarlo para que funcione. Está basado en la utilidad de clonado partimage ( org/main_page), por tanto hay sistemas de ficheros que no están soportados, como por ejemplo: EXT4 y NTFS. Además no posee un entorno gráfico amigable en el que trabajar, como podemos observar en la siguiente captura de imagen. Figura 2.4: Captura de pantalla de PING Valoración: A pesar de ser una herramienta tremendamente ágil, es muy poco conocida. Esto es debido en parte a que no tiene un interfaz agradable e intuitivo. Y tampoco da respuestas a la totalidad de las situaciones. 7

22 2.3. SystemRescueCD Podríamos decir que SystemRescueCD[17] es como el PING pero a lo grande, es decir, es una live-cd pero bastante más pesada, unos 397 MiB, y no solo incluye software de clonado, sino que aporta más utilidades que pueden ser necesarios para en ciertos casos, como: sistemas de particionado (GNU Parted, Gparted), software de recuperación de datos (TeskDisk, PhotoRec), antivirus, navegadores, etc. Todo este software hace que el sistema sea muy pesado. Figura 2.5: Captura de pantalla de System Rescue CD La primera versión estable de SystemRescueCD fue la y fue liberada en Julio del Actualmente la última versión estable es la ha sido liberada en Junio del Figura 2.6: Logo de SystemRescueCD Al ser una live-cd, el tiempo que se tarda en arrancarla, con sus 397 MiB, puede ser bastante elevado, una vez que tenemos el sistema arrancado, éste se vuelve muy lento, a menos que sea una máquina muy potente, ya que necesita muchos recursos. Al igual que PING, utiliza partimage para el proceso de clonado, pero esta vez asistido con otras utilidades como fsarchiver, por tanto el abanico de sistemas 8

23 de ficheros soportados es mayor, se puede decir que los soporta todos. También podemos destacar que utiliza un entorno gráfico con lo que la interacción con la aplicación es más amigable. Entre las aplicaciones que posee, podemos destacar a dar, es un aplicación que nos permite hacer copias de seguridad. Valoración: Nos encontramos ante una herramienta muy completa que puede solucionar casi cualquier situación. Pero es esto mismo su principal desventaja, al querer ser tan completa y abarcarlo todo, es sumamente compleja y nos encontramos con un sistema pesado, lento y ineficiente Acronis True Image Home[5] Esta aplicación comercial, por tanto de pago, cuesta 49,95 euros la licencia y como características mas reseñables, podemos decir que es una aplicación para entornos Windows (XP, Vista o 7), tenemos que instalarla, no es autónoma. Tiene limitaciones con los sitemas de ficheros de Linux, como dice en su documentación: "Los sistemas de archivos Ext2/Ext3/Ext4, ReiserFS y Linux SWAP son compatibles sólo para operaciones de copia de seguridad/recuperación de disco o partición. No es posible utilizar Acronis True Image Home 2012 para operaciones a nivel de archivo con estos sistemas de archivos (copia de seguridad, recuperación, búsqueda de archivos, como tampoco para montaje de imagen y recuperación de archivos desde imágenes). Tampoco puede realizar copias de seguridad en discos o particiones con estos sistemas de archivos". Figura 2.7: Logo de Acronis True Image Home Pero hay algo reseñable que aporta Acronis True Image Home que es la posibilidad de hacer copias de seguridad, aparte de las imágenes de clonado, Norton Ghost también hacer copias de seguridad, pero no a este nivel, ya que Acronis True Image Home tiene multitud de posibilidades, copias de seguridad incrementales y diferenciales, copias de seguridad de archivos, copias de seguridad activas y de reserva, etc. Esto es algo que hay que tener en cuenta porque puede ser una herramienta muy poderosa. 9

24 La primera versión de Acronis True Image Home que salió a la luz fue la 6.0 en el año 2000, actualmente la última versión estable es la 2012 que fue publicada en Octubre del Valoración: Es una excelente herramienta orientada a sistemas Windows, no se ha desarrollado para Linux. Además es un software privativo, por lo que deja de tener valor para estudio. Lo único que puede aportar al estudio es el buen sistema de copias de seguridad. Figura 2.8: Captura de pantalla de Acronis True Image Home 2.5. FOG Project FOG[9] es un sistema basado en Linux y cumple la licencia GNU GPL. Se utiliza para gestionar imágenes de clonado de sistemas Windows XP, Windows Vista y Linux, este último con algunas limitaciones que comentaremos más adelante. Figura 2.9: Logo de FOG Project 10

25 Para hacer funcionar FOG hay que instalarlo en alguna distribución Linux: Debian, Ubuntu, Fedora, etc. Se recomienda utilizar un servidor dedicado, con suficiente espacio en disco para alojar las imágenes de clonado, así como una tarjeta de red gigabit. Es un sistema cliente/servidor basado en TFTP y PXE, que se gestiona a través de una interfaz web con PHP. De todo esto podemos extraer que no es sistema autónomo, si se nos cae el servidor o la red, no podemos gestionar las imágenes de clonado. Es un sistema diseñado básicamente para trabajar con imágenes de sistemas Windows, puede trabajar con imágenes de Linux, pero solo con sistemas de ficheros EXT2, EXT3 y Reiserfs, y no puede recuperar los gestores de arranque de Linux (LILO y GRUB). Figura 2.10: Captura de pantalla de FOG Project El proyecto FOG es interesante porque aporta una nueva perspectiva a la hora de abordar estos problemas, pero hay aspectos que no soluciona. La primera versión de FOG que salió a la luz fue la 0.01 en Agosto de 2007, actualmente la última versión estable se liberó en Julio del 2011 y corresponde a la versión Valoración: Fog Project es una herramienta del tipo cliente/servidor, con sus ventajas e inconvenientes. En sus inicios sólo soportaba sistemas Windows, pero recientemente ha adquirido soporte para algunos siste- 11

26 mas de ficheros propios de Linux. Resumiendo, es una herramienta todavía en fase de desarrollo con mucho margen de mejora OpenGnSys El proyecto OpenGnSys[13] surge de la necesidad existente en algunas universidades españolas de gestionar imágenes de clonado de una forma eficiente y eficaz. Concretamente OpenGnSys integra tres proyectos anteriormente desarrollados en diferentes universidades: Brutalix (Universidad de Zaragoza) EAC (Universidad de Málaga) Hydra (Universidad de Sevilla) El concepto que se utiliza es muy similar al proyecto FOG, es decir un modelo cliente/servidor gestionado por web. Actualmente el proyecto acaba de liberar la versión 1.0.3, pero posee una agenda importante de desarrollo donde esperan ir agregando nuevas funcionalidades. Básicamente OpenGnSys es como el proyecto FOG pero sin las limitaciones de éste. Es decir, podemos afirmar que soporta todos los sistemas de ficheros que hay tanto en Windows como en Linux por la utilización de las aplicaciones partimage y partclone ( Figura 2.11: Captura de pantalla de OpenGnSys Además es capaz de recuperar los gestores de arranque de Linux (LILO, GRUB y GRUB2). También permite hacer clonaciones en Unicast, Multicast y P2P. Se contempla la posibilidad que puede funcionar en modo offline, por si en algún momento la red se cae. Se puede desplegar tanto en Linux como en Windows. 12

27 Figura 2.12: Logo de OpenGnSys Valoración: Partimos del mismo concepto que Fog Project, pero con un respaldo mucho mayor, el de tres Universidades españolas, con muchos años de trabajo en el campo de los sistemas de clonado (Brutalix, Hydra, EAC). Es todavía un proyecto muy novel, acaban de publicar la versión 1.0.3, pero con muchas expectativas para consolidarse y ser un referente REDO Hasta la liberación de la versión REDO[16] era un sistema para hacer clonaciones que estaba construido sobre una live-cd muy pequeña y vistosa como xpud. Pero a partir de la versión la herramienta REDO está construida sobre Ubuntu, esta decisión se toma para dar mayor estabilidad a la herramienta, pero a costa de incrementar notablemente el peso de la live-cd. En la actualidad la última versión liberada es la y se produjo en Enero del Figura 2.13: Logo de REDO El software de clonado viene de la mano de la aplicación partclone, por tanto soporta la mayoría de sistemas de ficheros, tanto de Windows como de Linux. Como características mas reseñables podemos destacar la simplicidad de la herramienta, es muy intuitiva y fácil de usar. Otro aspecto a destacar es que es un sistema que cumple con la licencia GPLv3 y al ser una live-cd es un sistema completamente autónomo. De la versión podíamos destacar la ligereza de la live-cd, solo 75 MiB, por lo que se ejecutaba muy rápido, pero ahora en la versión basada en Ubuntu, llegamos a los 224,5 MiB por lo que el sistema deja de ser tan liviano y rápido. 13

28 Figura 2.14: Captura de pantalla de REDO Valoración: Estamos ante un proyecto nuevo, todavía en fase de desarrollo, que está sufriendo cambios estructurales. Y con estos nuevos cambios ha perdido la agilidad que lo caracterizaba. Además no podemos olvidar que tiene carencias importantes Clonezilla[7] Hemos dejado para el final el sistema más completo de todos. Es una live-cd con licencia GNU GPL, en realidad son varias Live-CD, basadas en Ubuntu o en Debian, y de esta última tenemos versiones para distintos microprocesadores: amd64, i686 y i486. Figura 2.15: Logo de Clonezilla 14

29 El proyecto Clonezilla está formado por aplicaciones complementarias, la primera es la live-cd, y la segunda es un sistema cliente/servidor llamado Clonezilla Server Edition. La versión live-cd es un sistema autónomo para la generación de imágenes y para el clonado se utilizan las aplicaciones: partclone, partimage y dd, esto hace que podamos trabajar con todos los sistemas de ficheros conocidos. Otra característica es que soporta los gestores de arranque: LILO, GRUB y GRUB2. También permite guardar las imágenes de clonado en ubicaciones locales (particiones locales, discos externos por USB, CD y DVD), así como en ubicaciones en red (NFS, SMB y SSH), y también hacer clonados de dispositivo a dispositivo, en modo local, como en red por medio de unicast. Figura 2.16: Captura de pantalla de Clonezilla Clonezilla Server Edition añade principalmente a la versión live-cd, la posibilidad de hacer clonaciones masivas por medio de multicast. Esto se consigue instalando Clonezilla Server Edition en un Linux. La última versión estable se liberó en Mayo del 2012 y es la Clonezilla es un sistema estable con muchos años de desarrollo y podemos afirmar que es el sistema de referencia si estamos hablando de Software Libre. Valoración: Clonezilla, es una herramienta muy potente que esta siendo la referencia en estos momentos. Es un sistema muy estable en el que continuamente el equipo de desarrollo esta incorporando mejoras. Pero a pesar de ello la herramienta necesita un lavado de cara, una interfaz nueva más fácil e intuitiva. Además no soporta hacer clonaciones en P2P, ni tampoco posee un sistema de copias de seguridad Resumiendo A modo de resumen, en las siguientes tablas se hace un desglose de todas las características de las aplicaciones analizadas. 15

30 Aplicación Norton Ghost PING Sistemas de Ficheros Gestor de Arranque Soportado Tipos de Clonado Destino de la Imagen de Clonado Sistema de Backup Entorno Gráfico Tamaño del Sistema Sistema Autónomo, Live-CD FAT NTFS EXT2 EXT3 FAT EXT2 EXT3 Reiserfs JFS XFS HFS System RescueCD FAT NTFS EXT3 EXT3 Reiserfs JFS XFS Acronis True Image Home FAT NTFS LILO GRUB Local Local HD USB CD DVD FTP Si, aunque muy simple HD USB SMB NFS SSH FTP No HD USB CD DVD SMB NFS SSH FTP Si, con la utilidad dar HD USB CD DVD FTP Si, diferencial, incrementales, etc FOG Project OpenGnSys REDO Clonezilla FAT NTFS EXT2 EXT Reiserfs FAT NTFS EXT2 EXT3 EXT4 Reiserfs JFS XFS GRUB GRUB2 Unicast Multicast P2P Servidor FOG Servidor OpenGnSys FAT NTFS EXT2 EXT3 EXT4 Reiserfs JFS XFS LILO GRUB HD USB SMB FTP No No No No Si No Si Si No No No No FAT NTFS EXT2 EXT3 EXT4 Reiserfs JFS XFS LILO GRUB GRUB2 Local Unicast Multicast HD USB CD DVD SMB NFS SSH 119,7 MiB 25,3 MiB 397,0 MiB 181,7 MiB 60,7 MiB 46,4 MiB 224,5 MiB 112,2 MiB No Si Si No No No Si Si Tabla 2.1: Características generales de los sistemas de clonado 16

31 Aplicación Norton Ghost PING Tipo de Licencia Ventajas Inconvenientes Valoración System RescueCD Acronis True Image Home FOG Project OpenGnSys REDO Clonezilla Comercial GNU GPL GNU GPL Comercial GNU GPL GNU GPL GNU GPL GNU GPL Entorno gráfico. Facilidad de uso. Soporta Backups Licencia comercial. No soporta EXT4, Reiserfs, etc. Ni LILO y GRUB Ha sido la referencia en entornos Windows, pero no da un respuesta adecuada a sistemas Linux Live-CD muy rápida. Software Libre Sin entorno gráfico. No soporta EXT4 Sistema liviano y ágil, pero esta desfasado Entorno gráfico. Software Libre. Muchas utilidades adicionales Live-CD muy pesada En su fortaleza esta su debilidad, abarca tanto, que se hace muy pesado Entorno gráfico. Facilidad de uso. Soporta Backups con muchas posibilidades Licencia comercial. No soporta sistema de ficheros Linux. Ni LI- LO y GRUB Un buen proyecto para Windows, pero no esta orientado a Linux. Es software privativo Sistema gráfico, gestión por web No soporta LILO y GRUB. No soporta EXT4 Proyecto joven en fase de desarrollo con margen de mejora Sistema gráfico, gestión por web Sistema en Desarrollo. No es autónomo Pretende ser la referencia. Todavía esta en fase de desarrollo, pero tiene un amplio respaldo de desarrolladores Sistema gráfico intuitivo y rápido. No soporta unicast, multicast y P2P Es un proyecto joven, aun en fase de desarrollo. Ha perdido la frescura y agilidad inicial que le caracterizaba Sistema muy completo y estable (basado en Debian) Sin entorno gráfico, poco intuitivo. No soporta P2P Es el referente del momento en Software Libre, pero con deficiencias de en el interfaz Tabla 2.2: Características generales de los sistemas de clonado (Continuación) 17

32 A modo de aclaración sobre la información mostrada en la tablas, explicaremos los conceptos más confusos que son Tipos de Clonado y Destino de la Imagen de Clonado. El primero se refiere a la capacidad de clonar un dispositivo, ya sea una partición o un disco duro completo, directamente en otro dispositivo, sin tener que generar una imagen de clonado. El segundo concepto se refiere al lugar donde podemos guardar una imagen de clonado para su posterior uso. A continuación se presenta la tabla 2.3, a modo de resumen, donde se aprecia con claridad el cumplimiento de los criterios por parte de las herramientas analizadas. Aplicación Criterios Norton Ghost (1) (2) (3) (4) (5) (6) (7) (8) (9) (10) PING System RescueCD Acronis True Image Home FOG Project OpenGnSyS REDO Clonezilla Tabla 2.3: Criterios: (1) Compatibilidad, (2) Sistemas de Ficheros, (3) Gestores de Arranque, (4) Copias de Seguridad, (5) Autonomía, (6) Estabilidad, (7) Eficiencia, (8) Usabilidad, (9) Adaptabilidad y (10) Licencia Conclusiones Una vez evaluadas todas las herramientas a la luz de los criterios y anotado sus virtudes y sus defectos, llega el momento de decidir que camino debemos tomar para desarrollar la herramienta de gestión de clonaciones y copias de seguridad. Ante esta disyuntiva hay dos opciones posibles: La primera pasa por completar, mejorar, optimizar, etc. alguna de las herramientas evaluadas, para así, desarrollar una aplicación basada en una de ellas pero que sí cumpla con todos los criterios exigidos. Y la segunda opción sería la de desarrollar una aplicación totalmente nueva, que cumpla con los criterios fijados y con el objetivo establecido. La solución a esta disyuntiva la veremos en el capítulo siguiente. 18

33 Capítulo 3 Herramientas de desarrollo 3.1. Introducción Llegados a este punto hay que tomar una decisión importante, hay qué escoger que camino vamos a seguir para la consecución del objetivo planteado. Podemos optar por agregar aquellas funcionalidades que nos hacen falta a una herramienta ya existente, o bien, podemos desarrollar una herramienta que cumpla con todos los criterios establecidos Utilizar herramienta existente Si escogemos bien la herramienta base nos será más fácil agregar las funciones requeridas, esto nos obliga a tener que elegir entre aquellas aplicaciones con licencia GNU GPL, ya que las de las aplicaciones comerciales no disponemos del código fuente para poder modificarlo. Esto hace que descartemos Norton Ghost y Acronis True Image Home. Otro aspecto importante a considerar es que la herramienta tiene que ser lo más autónoma posible, no se puede depender de que si algún día existen problemas en la red, no se puede realizar el trabajo requerido. Por tanto, las aplicaciones FOG Proyect y OpenGnSys las tenemos que descartar por estar orientadas a entornos de cliente/servidor y la transformación a un sistema autónomo se antoja muy complicado, por no decir imposible. Si elegimos la herramienta PING como sistema base, tendremos muchas dificultades en mejorar la aplicación, ya que esta se basa en el proyecto Linux From Scratch (LFS), que consiste en la construcción de distribuciones Linux totalmente personalizables a través de los ficheros fuentes, más información en la siguiente dirección: Esta elección se antoja muy complicada de asumir, dado el gran nivel de esfuerzo que va a requerir la construcción del sistema desde los ficheros fuentes. Por otro lado tenemos la herramienta System RescueCD, que como hemos comentado anteriormente, es una aplicación muy compleja y sobrepasa con creces las funcionalidades requeridas. Y por eso, es muy lenta y pesada, no posee la agilidad que queremos. Habría que eliminar aquellas funcionalidades que no nos hacen falta, para intentar obtener una herramienta ágil y fácil de usar. 19

34 Para el final nos quedan dos herramientas muy interesantes: REDO y Clonezilla. Éstas se complementan muy bien, todo lo que no tiene una lo tiene la otra y viceversa. La herramienta que estamos buscando sería una conjunción de estas dos. Pero el proceso de juntar estas dos herramientas en una sola puede ser caótico y muy laborioso, por tanto esta opción tampoco es satisfactoria Crear una herramienta nueva La otra posibilidad es la de desarrollar íntegramente una herramienta nueva. De este modo nos aseguramos lo siguiente: Controlar exhaustivamente el desarrollo de la aplicación desde el principio hasta al fin. Integrar en una sola aplicación todas las funcionalidades requeridas. Conseguir una herramienta eficaz para la consecución del objetivo marcado. Mayor comprensión de la problemática a resolver. Todo esto requiere de un gran esfuerzo de investigación, planificación, análisis, diseño, programación, pruebas, etc... Pero a la larga este esfuerzo llevará, con toda seguridad, a la obtención de la herramienta deseada La decisión esta tomada: ClonUCA Evidentemente la decisión más correcta es la de desarrollar íntegramente una herramienta nueva, a pesar del enorme trabajo que ello va a suponer. Lo de poner ese nombre a la aplicación, es muy fácil, como esta problemática se da en la Universidad de Cádiz, aunque es perfectamente extrapolable a otros entornos, y el autor del proyecto es uno de los responsables del mantenimiento de las aulas de informática del Campus de Jerez de la UCA, la herramienta que se va a desarrollar nace con el siguiente nombre: ClonUCA(Clonaciones en la UCA), no es muy original, pero si representativo de lo que aspira ofrecer. Figura 3.1: Logo de ClonUCA 20

35 3.3. Expectativas de ClonUCA El sistema de gestión de clonaciones y copias de seguridad llamado ClonUCA, no pretende ser el mejor en todos los aspectos evaluables, porque eso sería imposible, solo se quiere conseguir una herramienta lo suficientemente buena que nos permita desarrollar la tarea de clonar equipos informáticos y hacer copias de seguridad de una forma eficaz y eficiente, que no es otro que el objetivo marcado en el primer capítulo. Para saber si la herramienta va a cumplir el objetivo vamos a ir aplicando los criterios establecidos a ClonUCA, y veremos como se irán cumpliendo con todos ellos Compatibilidad ClonUCA pretende conseguir la compatibilidad con sistemas Windows y Linux, es decir, ClonUCA tiene que ser capaz de hacer clonaciones tanto de sistemas Windows como Linux. Para conseguir esto, vamos a utilizar básicamente la siguiente herramienta: partclone: Está diseñada para trabajar sobre Linux y es software que cumple con la licencia GNU GPL, y nos permite hacer clonaciones de sistemas Windows, Linux, MacOS, FreBSD, etc. Para el propósito de ClonUCA nos vamos a centrar en los sistemas Windows y Linux. Sobre partclone podemos tener más información en la siguiente dirección web: Con la utilización de la herramienta partclone nos aseguramos la compatibilidad exigida con los sistemas Windows y Linux Sistemas de Ficheros Este criterio está totalmente ligado al criterio de la compatibilidad, y por tanto, para poder cumplir con el mismo, ClonUCA va a utilizar la herramienta explicada con anterioridad. Como se puede ver en su página web, partclone es capaz de trabajar con los sistemas de ficheros más utilizados, concretamente: Linux: Ext2, Ext3, Ext4, Reiserfs, Reiser4, Xfs, Jfs y Btrfs Windows: NTFS y FAT Con este repertorio de compatibilidad de sistemas de ficheros nos aseguramos que podemos hacer clonaciones de casi la totalidad de los equipos informáticos Gestor de Arranque El poder gestionar el gestor de arranque es un poco más complicado, ya que hay que gestionar por un lado el gestor de arranque de sistemas Windows y por otro el de los sistemas Linux. En sistemas Windows basta con guardar el MBR y luego restaurarlo, pero en sistemas Linux hay que reinstalar el GRUB, ya sea GRUB o GRUB2. Por tanto, ClonUCA tiene que llevar integrado el GRUB y GRUB2, para poder reinstalarlo en los sistemas Linux. Se descarta el gestor de arranque LILO, porque es muy antiguo y prácticamente no se usa. 21

36 Copias de Seguridad Para poder hacer copias de seguridad vamos a integrar en ClonUCA la siguiente herramienta: dar: Es otra herramienta con licencia GNU GPL que trabaja sobre Linux, y nos va a permitir hacer copias de seguridad tanto de sistemas Windows como Linux. Para más información podemos visitar la siguiente dirección web: Con dar nos aseguramos complementar a ClonUCA con una poderosa herramienta para hacer copias de seguridad Autonomía Para poder cumplir con el criterio de la autonomía, ClonUCA va a ser un sistema live-cd, es decir, va a ser totalmente autónomo, para su funcionamiento no va a depender de nada, bueno, solamente de que en el ordenador en el que se ejecute funcione correctamente. Y esto se consigue construyendo ClonUCA como un live-cd, que luego se podrá utilizar desde un CD-ROM, un DvD-ROM o una memoria USB. Para construir un live-cd vamos a utilizar el proyecto live helper de Debian. Esta herramienta nos va a permitir construir una live-cd basada en la distribución Debian de Linux. Una vez creado el sistema live-cd podemos incluir la herramienta ClonUCA en la misma, con lo que obtenemos un sistema totalmente autónomo. Podemos obtener más información del proyecto live helper en la siguiente dirección web: Estabilidad ClonUCA va a estar desarrollado sobre una plataforma Debian, por tanto, queda fuera de lugar alguna duda sobre la estabilidad del sistema, ya que se considera a esta distribución de Linux como la más estable y probada, siendo la referencia para otras distribuciones que están basadas en ella, como por ejemplo Ubuntu. Cualquier nueva actualización de kernel y de software que tenga Debian, se podrá incorporar a ClonUCA Eficiencia Para conseguir que ClonUCA sea una herramienta eficiente, hay que conseguir que sea un sistema pequeño, para que la ejecución del mismo sea lo más rápida posible. Por tanto se ha estimado que el live-cd de ClonUCA deberá ocupar dentro del rango comprendido entre los 100 MiB y los 130 MiB. Con esto se obtendría una live-cd totalmente eficiente, que podemos ejecutarla en máquinas antiguas. 22

37 Usabilidad La eficiencia no tiene que estar reñida con la usabilidad, ClonUCA pretende ser sistema eficiente y su vez fácil de usar, para ello el live-cd llevará integrado un entorno gráfico, de modo, que la interfaz sea lo más amigable posible. A continuación, podemos ver en la figura 3.2 a modo de ejemplo el aspecto visual que nos encontraríamos al iniciar ClonUCA. Figura 3.2: Ejemplo de captura de pantalla de ClonUCA Para conseguir esto se va implementar en el live-cd un gestor de ventanas para sistemas gráficos X-windows. Se ha pensado utilizar el gestor de ventanas icewm, ya que es bastante ligero en cuanto a uso de memoria RAM, CPU y espacio de disco. Podemos tener más información sobre icewm en la siguiente dirección web: Licencia La licencia de ClonUCA no podía ser de otra manera que no fuera GNU GPLv3[25], por tanto va a ser Software Libre, ya que está intentando dar una respuesta a una problemática concreta que se da en la Universidad de Cádiz, la cual es perfectamente identificable en otras áreas: colegios, institutos, administraciones, grandes empresas, etc. Bajo este contexto de enseñanza y divulgación, sería un contrasentido que ClonUCA fuera un software privativo, ya que lo interesante es que la herramienta pueda ser evaluada, modificada y mejorada por aquellas personas que en su día la utilicen. 23

38 Adaptabilidad Al ser ClonUCA un software con licencia GPLv3 (figura 3.3), cumple, en parte, con el criterio de la adaptabilidad. Porque el código fuente de ClonUCA va a estar disponible a la comunidad, y por tanto toda aquella persona que lo crea oportuno tiene la posibilidad de modificar y adaptar ClonUCA a sus necesidades específicas. Figura 3.3: ClonUCA cumple con la licencia GPLv3 La otra parte del cumplimiento de este criterio, se deberá a las diversas posibilidades u opciones que ofrecerá ClonUCA al usuario, para realizar las tareas de clonados y de backup. Como por ejemplo: posibilidad de generar imagenes de clonación o copias de seguridad y poder guardarlas en multitud de recursos (discos duros locales, memorias USB, recursos de red NFS, SAMBA o SSH). O también, poder clonar directamente, ya sea entre dispositivos locales o entre dispostivos de red, a través, de protocolos unicast, multicast o P2P, etc. 24

39 Capítulo 4 Planificación del proyecto 4.1. Organización temporal En este apartado se va a exponer cual ha sido la planificación del proyecto, y más concretamente su organización temporal. Detallaremos las distintas fases de la planificación, tanto a nivel ejecutivo como a nivel temporal. Para ilustrarlo podemos consultar el diagrama de D-Gantt de la figura 4.5. Para tener otro punto de vista y por tanto una visión más exacta de la organización temporal, podemos mirar el siguiente gráfico de sectores de la figura 4.1. Figura 4.1: Gráfico de sectores con organización temporal del proyecto Fase de inicio, [59 días] El objetivo fundamental de esta fase es el valorar y estudiar la viabilidad de proyecto. A su vez, esta fase, se puede desglosar en cuatro etapas: Idea del proyecto, [15 días]: La idea de hacer un proyecto sobre un sistema de gestión de clonado y copias de seguridad ha estado rondando en la mente del autor durante un largo periodo de 25

40 tiempo, pero es sobre estas fechas donde se formaliza la idea de una forma más concreta. Así que se define el ámbito y el objetivo del proyecto para presentarlo al tutor. En estas fechas también buscamos el tutor de proyecto. Entrevista con el tutor, [4 días]: En este periodo realizamos una entrevista con el tutor del proyecto, para exponerle de una forma convincente cual sería el alcance, los objetivos, las ideas, etc., que tenemos acerca del proyecto. Para así, conseguir que el tutor acepte la tutorización del proyecto. Búsqueda de bibliografía, [29 días]: Durante esta etapa se trata de buscar toda la bibliografía y documentación posible, que nos pueda aportar información útil para la realización del proyecto. Principalmente esta información la buscaremos por internet. Planificación, [11 días]: Y por último, en la etapa de planificación se establece un esquema cronológico de todos lo procesos que se tiene que llevar a cabo para la realización del proyecto. Para ilustrar esta fase, se presenta el siguiente diagrama de sectores de la figura 4.2. Figura 4.2: Gráfico de sectores con organización temporal de la fase de inicio Fase de ejecución, [296 días] Es la fase más larga y la que requiere un mayor esfuerzo y concentración, ya que es la fase en la que se desarrolla el proyecto. Dado que el desarrollo del proyecto se adapta a un enfoque incremental, hemos seguido este enfoque a la hora de la ejecución. Se han establecido cuatro iteraciones que se desarrollan a continuación: 1 o Iteración: Guardar/Restaurar imagen, [64 días]: Esta primera iteración nos servirá para hacer una aproximación al desarrollo, con el fin de establecer la estructura que debe seguir todo el 26

41 proceso, también nos ayudará a determinar la viabilidad del mismo. Por este motivo, la primera iteración se va a encargar de desarrollar un aspecto básico: ClonUCA debe ser capaz de guardar una imagen de un dispositivo local, ya sea una partición o un disco duro completo, en algún sitio que puede ser una partición local o un recurso de red (NFS, SAMBA o SSH). ClonUCA también tiene que ser capaz de realizar el proceso inverso, restaurar la imagen. Por todo esto, esta primera iteración va a estar dividida en las etapas clásicas de cualquier desarrollo: análisis, diseño, implementación y pruebas. 2 o Iteración: Clonar localmente, [32 días]: En este iteración se incrementará la funcionalidad del desarrollo con la capacidad que tiene que tener ClonUCA de clonar directamente, sin necesidad de crear ninguna imagen, un dispositivo local desde otro dispositivo local. La duración de esta iteración es bastante menor porque se puede reutilizar mucha información de la primera iteración. De todas formas, sigue estando divida en las cuatro etapas clásicas 3 o Iteración: Clonar por red, [161 días]: Con esta iteración se pretende dotar a ClonUCA con la capacidad de hacer clonaciones directas, pero a través de la red, usando los siguientes protocolos: unicast, multicast y P2P. Para ello se tiene que establecer un protocolo de comunicación entre el servidor y el cliente. Esta es la parte más delicada de esta iteración, ya que en las dos anteriores podemos aprovechar la mayor parte de la información. Por todo ello, esta iteración es la que más tiempo requiere y va seguir aferrándose a las cuatro etápas clásicas: análisis, diseño, implementación y pruebas. 4 o Iteración: Copias de seguridad, [39 días]: La última iteración consiste en añadirle a ClonUCA la funcionalidad de poder realizar y restaurar copias de seguridad. Al igual que las iteraciones anteriores, esta también esta dividida en las cuatro etapas clásicas. En la siguiente figura 4.3 se presenta un diagrama de sectores que engloba la organización temporal de las fases de ejecución, documentación y control. Figura 4.3: Gráfico de sectores con organización temporal de las fases de ejecución, documentación y control 27

42 Fase de documentación, [296 días] Esta fase abarca el mismo periodo que la fase anterior, es una actividad en paralelo, porque a la vez que se va desarrollando la fase de ejecución, se va generando una documentación inherente a esta fase, como diagramas, gráficos, etc. Toda esta documentación nos va a servir para elaborar la memoria del proyecto Fase de control, [296 días] Al igual que la fase de documentación, la fase de control se desarrolla en paralelo a la fase de ejecución, y consiste en llevar un control sobre el desarrollo en la generación del proyecto. Este control tiene que realizarlo el autor y estar supervisado por el tutor del proyecto Fase de finalización, [29 días]: La última fase de la planificación consiste en rematar todos los detalles del proyecto, para poder defenderlo ante el tribunal. Esta fase la podemos dividir en dos bloques. Revisión con el tutor, [15 días]: Consiste en que el tutor del proyecto revise todo el trabajo realizado, para comprobar que cumple con los objetivos y criterios establecidos inicialmente. Preparación del material, [14 días] Y por último, pero no menos importarte, hay que terminar de preparar la memoria para llevarla a impresión y encuadernación. Una vez hecho esto, hay que entregar todo el material a la Universidad para su posterior defensa ante el tribunal. En la siguiente figura 4.4 se expone un diagrama de sectores con la organización temporal de la fase de finalización. Figura 4.4: Gráfico de sectores con organización temporal de la fase de finalización 28

43 A modo de resumen y para tener una idea más clara de la planificación de todo el desarrollo, se puede ver el siguiente diagrama de Gantt de la figura 4.5. Figura 4.5: Diagrama de Gantt con planificación temporal del proyecto 29

44 30

45 Capítulo 5 Análisis 5.1. Metodología de Desarrollo Para hacer el desarrollo de ClonUCA se ha seguido una metodología incremental o iterativa. Esto va a permitir ir desarrollando la aplicación en pequeños pasos, controlando en todo momento la calidad del software y obteniendo ya en las primeras iteraciones funcionalidades del sistema. Primero realizaremos una especificación de requisitos para conocer las condiciones funcionales, de interfaces y de rendimiento que tiene que cumplir el desarrollo. Después de esto, pasaremos a definir los casos de uso de la aplicación. Para simplificar la documentación del análisis, se va a exponer de una manera conjunta el análisis de todas las iteraciones, de este modo tendremos una visión más global y amplia del mismo Especificación de requisitos Requisitos funcionales ClonUCA tiene que cumplir con los siguientes requisitos funcionales: El sistema tiene que ser totalmente autónomo, tiene que funcionar independientemente del sistema operativo subyacente, para evitar cualquier tipo de incidencia. El sistema tiene que ser capaz de realizar clonados, imágenes de clonación y copias de seguridad de la mayoría de los sistemas de archivos conocidos: FAT, NTFS, EXT2, EXT3, EXT4, Reiserfs, JFS y XFS. Gestionar los gestores de arranque más utilizados, el del Windows y el GRUB y GRUB2 de Linux. Gestionar los recursos locales de almacenamiento, ya sea, con conexiones IDE, SATA o USB. Tanto para poder realizar las operaciones propias de clonado y copia de seguridad, como para utilizarlos de almacén donde guardar las imágenes de clonación y las copias de seguridad. 31

46 Poder comunicarse con servidores NFS, SMB y SSH, para establecer estos recursos de red como almacenes donde poder guardar las imágenes de clonación y las copias de seguridad. Poder establecer una arquitectura cliente/servidor para realizar las clonaciones por red, usando los protocolos: Unicast, Multicast y P2P Requisitos de interfaces externas Los requisitos de interfaces externas requeridos por ClonUCA son muy básicos, y son los siguientes: El sistema tiene que tener una interfaz gráfica amable y a la vez sencilla de usar. El sistema podrá ser manejado tanto por el teclado como por el ratón, y deberá estar optimizado para que su funcionamiento no requiera muchos pasos por parte del usuario Requisitos de rendimiento Entendiendo por requisitos de rendimiento aquellos que ClonUCA tiene que tener para cumplir con las expectativas marcadas. Entonces, los requisitos son los siguientes: Cualquier ordenador tiene que ser capaz de ejecutar la aplicación, a pesar de no ser el último modelo, y de una forma fluida y eficaz. Utilizar los mínimos recursos posibles para conseguir un funcionamiento óptimo. Conseguir realizar la tarea en el menor tiempo posible Modelo de casos de uso Una vez que conocemos los requisitos de la aplicación y realizado un estudio sobre los mismos, llegamos a la obtención de los casos de uso. Primero dibujaremos los diagramas de casos de usos, para posteriormente, especificar los mismos de una forma más detallada. 32

47 Diagramas de casos de uso Figura 5.1: Diagrama de caso de uso: primera iteración Figura 5.2: Diagrama de caso de uso: segunda iteración Figura 5.3: Diagrama de caso de uso: tercera iteración 33

48 Descripción de casos de uso Caso de uso: Guardar imagen en local Figura 5.4: Diagrama de caso de uso: cuarta iteración Descripción: Guardar la imagen de clonado de un dispositivo local, ya sea un disco duro completo o una partición, y guardarla en una partición local. Actores: Usuario Escenario principal: 1. El usuario elige el dispositivo, del cual quiere hacer la imagen. 2. El usuario elige la partición local donde desea guardar la imagen. 3. El sistema monta la partición. 4. El usuario elige una carpeta dentro de la partición, que servirá para guardar la imagen de clonado. 5. El sistema guarda la imagen de clonado en la carpeta elegida por el usuario. Escenario Alternativo: 3.a El sistema no puede montar la partición. 3.b El sistema detecta que no hay espacio suficiente en la partición para guardar la imagen de clonado. Caso de uso: Guardar imagen en recurso NFS Descripción: Guardar la imagen de clonado de un dispositivo local, ya sea un disco duro completo o una partición, y guardarla en recurso de red NFS. 34

49 Actores: Usuario y Servidor NFS Escenario principal: 1. El usuario elige el dispositivo, del cual quiere hacer la imagen. 2. El usuario introduce en el sistema los datos correspondientes al recurso de red del servidor NFS: nombre o la dirección IP, y el nombre del recurso compartido. 3. El sistema comprueba que se puede utilizar el recurso de red y lo monta en una carpeta. 4. El usuario elige una carpeta dentro del recurso NFS, que servirá para guardar la imagen de clonado. 5. El sistema guarda la imagen de clonado en la carpeta elegida por el usuario. Escenario Alternativo: 3.a El sistema no puede montar el recurso NFS del servidor. 3.b El sistema detecta que no hay espacio suficiente en el recurso NFS para guardar la imagen de clonado. Caso de uso: Guardar imagen en recurso SMB Descripción: Guardar la imagen de clonado de un dispositivo local, ya sea un disco duro completo o una partición, y guardarla en recurso de red Samba. Actores: Usuario y Servidor SMB Escenario principal: 1. El usuario elige el dispositivo, del cual quiere hacer la imagen. 2. El usuario introduce en el sistema los datos correspondientes al recurso de red del servidor SMB: nombre o la dirección IP, el nombre del recurso compartido, usuario y contraseña. 3. El sistema comprueba que se puede utilizar el recurso de red y lo monta en una carpeta. 4. El usuario elige una carpeta dentro del recurso SMB, que servirá para guardar la imagen de clonado. 5. El sistema guarda la imagen de clonado en la carpeta elegida por el usuario. Escenario Alternativo: 3.a El sistema no puede montar el recurso SMB del servidor. 3.b El sistema detecta que no hay espacio suficiente en el recurso SMB para guardar la imagen de clonado. 35

50 Caso de uso: Guardar imagen en recurso SSH Descripción: Guardar la imagen de clonado de un dispositivo local, ya sea un disco duro completo o una partición, y guardarla en recurso de red SSH. Actores: Usuario y Servidor SSH Escenario principal: 1. El usuario elige el dispositivo, del cual quiere hacer la imagen. 2. El usuario introduce en el sistema los datos correspondientes al recurso de red del servidor SSH: nombre o la dirección IP, el nombre del recurso compartido, usuario y contraseña. 3. El sistema comprueba que se puede utilizar el recurso de red y lo monta en una carpeta. 4. El usuario elige una carpeta dentro del recurso SSH, que servirá para guardar la imagen de clonado. 5. El sistema guarda la imagen de clonado en la carpeta elegida por el usuario. Escenario Alternativo: 3.a El sistema no puede montar el recurso SSH del servidor. 3.b El sistema detecta que no hay espacio suficiente en el recurso SSH para guardar la imagen de clonado. Caso de uso: Restaurar imagen desde local Descripción: Restaurar un dispositivo, ya sea un disco duro completo o una partición, desde una imagen, la cual está almacenada en una partición local. Actores: Usuario Escenario principal: 1. El usuario elige el dispositivo que desea restaurar. 2. El usuario elige la partición donde se encuentra la imagen de clonado. 3. El sistema monta la partición. 4. El usuario elige la carpeta donde se encuentra la imagen del clonado. 5. El sistema restaura el dispositivo a través de la imagen de clonado. Escenario Alternativo: 3.a El sistema no puede montar la partición. 5.a El sistema detecta que la carpeta elegida no tiene ninguna imagen válida de clonado. 5.b El sistema detecta que el dispositivo a restaurar es menor que el dispositivo origen de la imagen de clonado. 36

51 Caso de uso: Restaurar imagen desde recurso NFS Descripción: Restaurar un dispositivo, ya sea un disco duro completo o una partición, desde una imagen, la cual está almacenada en un recurso NFS. Actores: Usuario y Servidor NFS Escenario principal: 1. El usuario elige el dispositivo que desea restaurar. 2. El usuario introduce en el sistema los datos correspondientes al recurso de red del servidor NFS: nombre o la dirección IP, y el nombre del recurso compartido. 3. El sistema comprueba que se puede utilizar el recurso de red y lo monta en una carpeta. 4. El usuario elige la carpeta donde se encuentra la imagen del clonado. 5. El sistema restaura el dispositivo a través de la imagen de clonado. Escenario Alternativo: 3.a El sistema no puede montar el recurso NFS del servidor. 5.a El sistema detecta que la carpeta elegida no tiene ninguna imagen válida de clonado. 5.b El sistema detecta que el dispositivo a restaurar es menor que el dispositivo origen de la imagen de clonado. Caso de uso: Restaurar imagen desde recurso SMB Descripción: Restaurar un dispositivo, ya sea un disco duro completo o una partición, desde una imagen, la cual está almacenada en un recurso Samba. Actores: Usuario y Servidor SMB Escenario principal: 1. El usuario elige el dispositivo que desea restaurar. 2. El usuario introduce en el sistema los datos correspondientes al recurso de red del servidor SMB: nombre o la dirección IP, el nombre del recurso compartido, usuario y contraseña. 3. El sistema comprueba que se puede utilizar el recurso de red y lo monta en una carpeta. 4. El usuario elige la carpeta donde se encuentra la imagen del clonado. 5. El sistema restaura el dispositivo a través de la imagen de clonado. Escenario Alternativo: 3.a El sistema no puede montar el recurso SMB del servidor. 5.a El sistema detecta que la carpeta elegida no tiene ninguna imagen válida de clonado. 5.b El sistema detecta que el dispositivo a restaurar es menor que el dispositivo origen de la imagen de clonado. 37

52 Caso de uso: Restaurar imagen desde recurso SSH Descripción: Restaurar un dispositivo, ya sea un disco duro completo o una partición, desde una imagen, la cual está almacenada en un recurso SSH. Actores: Usuario Servidor SSH Escenario principal: 1. El usuario elige el dispositivo que desea restaurar. 2. El usuario introduce en el sistema los datos correspondientes al recurso de red del servidor SSH: nombre o la dirección IP, el nombre del recurso compartido, usuario y contraseña. 3. El sistema comprueba que se puede utilizar el recurso de red y lo monta en una carpeta. 4. El usuario elige la carpeta donde se encuentra la imagen del clonado. 5. El sistema restaura el dispositivo a través de la imagen de clonado. Escenario Alternativo: 3.a El sistema no puede montar el recurso SSH del servidor. 5.a El sistema detecta que la carpeta elegida no tiene ninguna imagen válida de clonado. 5.b El sistema detecta que el dispositivo a restaurar es menor que el dispositivo origen de la imagen de clonado. Caso de uso: Clonar localmente Descripción: Clonar un dispositivo local en otro dispositivo, ya sea un disco duro completo o una partición. Actores: Usuario Escenario principal: 1. El usuario elige el dispositivo origen del clonado. 2. El usuario elige el dispositivo destino del clonado. 3. El sistema clona el contenido del dispositivo origen en el dispositivo destino. Escenario Alternativo: 3.a El sistema detecta que el dispositivo destino es menor que el dispositivo origen. Caso de uso: Generar clonado por unicast Descripción: Distribuir por red utilizando un protocolo unicast, el contenido de un dispositivo local, ya sea un disco duro completo o una partición. 38

53 Actores: Usuario y Cliente unicast Escenario principal: 1. El usuario elige el dispositivo origen del clonado. 2. El sistema publica información del dispositivo origen de clonado. 3. El sistema recibe una respuesta del cliente unicast 4. El sistema distribuye por red el contenido dispositivo origen. Escenario Alternativo: 4.a El sistema aborta el clonado, porque el cliente ha cancelado el proceso. 4.b El sistema aborta el clonado porque no recibe respuesta de cliente. Caso de uso: Recibir clonado por unicast Descripción: Recibir por red utilizando un protocolo unicast, el contenido de un dispositivo alojado en un servidor, ya sea un disco duro completo o una partición, para clonar un dispositivo local Actores: Usuario y Servidor unicast Escenario principal: 1. El usuario elige el dispositivo que quiere ser clonado. 2. El usuario proporciona la dirección IP del servidor unicast. 3. El sistema comprueba que el servidor unicast esta disponible. 4. El sistema comprueba la compatibilidad entre el dispositivo del servidor unicast y el dispositivo local. 5. El sistema manda una respuesta al servidor unicast 6. El sistema recibe por red el contenido del dispositivo origen del servidor unicast. Escenario Alternativo: 3.a El servidor unicast no esta disponible. 4.a El dispositivo del servidor unicast y el del local son incompatibles. 5.a El sistema manda una respuesta de cancelación al servidor unicast. Caso de uso: Generar clonado por multicast Descripción: Distribuir por red utilizando un protocolo multicast, el contenido de un dispositivo local, ya sea un disco duro completo o una partición. Actores: Usuario 39

54 Escenario principal: 1. El usuario elige el dispositivo origen del clonado. 2. El usuario introduce un grupo multicast. 3. El sistema publica información del dispositivo origen de clonado. 4. El usuario ordena iniciar el proceso. 5. El sistema distribuye por red el contenido dispositivo origen. Escenario Alternativo: 4.a El sistema aborta el clonado, porque no ha recibido ninguna orden. Caso de uso: Recibir clonado por multicast Descripción: Recibir por red utilizando un protocolo multicast, el contenido de un dispositivo alojado en un servidor, ya sea un disco duro completo o una partición, para clonar un dispositivo local Actores: Usuario y Servidor multicast Escenario principal: 1. El usuario elige el dispositivo que quiere ser clonado. 2. El usuario proporciona la dirección IP del servidor multicast. 3. El sistema comprueba que el servidor multicast esta disponible. 4. El sistema comprueba la compatibilidad entre el dispositivo del servidor multicast y el dispositivo local. 5. El sistema se queda a la espera. 6. El sistema recibe por red el contenido dispositivo origen del servidor multicast. Escenario Alternativo: 3.a El servidor multicast no esta disponible. 4.a El dispositivo del servidor multicast y el del local son incompatibles. 5.a El sistema cancela el proceso. Caso de uso: Generar clonado por P2P Descripción: Distribuir por red utilizando un protocolo P2P, el contenido de un dispositivo local, en este caso de un disco duro completo. Actores: Usuario Escenario principal: 1. El usuario elige una partición para utilizarla de caché. 2. El usuario elige el disco duro origen del clonado. 40

55 3. El sistema publica información del dispositivo origen de clonado. 4. El sistema genera una imagen del disco duro y a la guarda en la caché. 5. El sistema distribuye por P2P la imagen almacenada en la caché. Escenario Alternativo: 4.a El sistema aborta el clonado por errores con la caché. Caso de uso: Recibir clonado por P2P Descripción: Recibir por red utilizando un protocolo P2P, el contenido de un disco duro alojado en un servidor, para clonar un disco duro local. Actores: Usuario y Servidor P2P Escenario principal: 1. El usuario proporciona la dirección IP del traker (servidor P2P). 2. El usuario elige el disco duro que quiere ser clonado. 3. El sistema comprueba que el servidor P2P esta disponible. 4. El sistema comprueba la compatibilidad entre el dispositivo del servidor P2P y el dispositivo local. 5. El sistema recibe por P2P la imagen del disco duro origen del servidor P2P y la almacena en la caché. 6. El sistema restaura el disco duro local desde la imagen que hay en la caché. Escenario Alternativo: 3.a El servidor P2P no esta disponible. 4.a El dispositivo del servidor P2P y el local son incompatibles. Caso de uso: Realizar un backup en local Descripción: Realizar una copia de seguridad de una carpeta local y guardarla en una partición local. Actores: Usuario Escenario principal: 1. El usuario elige la partición local donde desea guardar la copia de seguridad. 2. El sistema monta la partición. 3. El usuario elige una carpeta dentro de la partición, que servirá para guardar la copia de seguridad. 4. El usuario elige la carpeta a la que se le va a hacer una copia de seguridad. 41

56 5. El sistema guarda la copia de seguridad. Escenario Alternativo: 2.a El sistema no puede montar la partición. 5.a El sistema detecta que no hay espacio suficiente en la partición para guardar la copia de seguridad. Caso de uso: Realizar un backup en recurso NFS Descripción: Realizar una copia de seguridad de una carpeta local y guardarla en un recurso de red NFS. Actores: Usuario y Servidor NFS Escenario principal: 1. El usuario introduce en el sistema los datos correspondientes al recurso de red del servidor NFS: nombre o la dirección IP, y el nombre del recurso compartido. 2. El sistema comprueba que se puede utilizar el recurso de red y lo monta en una carpeta. 3. El usuario elige una carpeta dentro del recurso NFS, que servirá para guardar la copia de seguridad. 4. El usuario elige la carpeta, de la cual se quiere hacer la copia de seguridad. 5. El sistema guardará la copia de seguridad. Escenario Alternativo: 2.a El sistema no puede montar el recurso NFS del servidor. 5.a El sistema detecta que no hay espacio suficiente en el recurso NFS para guardar la copia de seguridad. Caso de uso: Realizar backup en recurso SMB Descripción: Realizar una copia de seguridad de una carpeta local y guardarla en un recurso de red SAMBA. Actores: Usuario y Servidor SMB Escenario principal: 1. El usuario introduce en el sistema los datos correspondientes al recurso de red del servidor SMB: nombre o la dirección IP, el nombre del recurso compartido, usuario y contraseña 2. El sistema comprueba que se puede utilizar el recurso de red y lo monta en una carpeta. 3. El usuario elige una carpeta dentro del recurso SMB, que servirá para guardar la copia de seguridad. 4. El usuario elige la carpeta, de la cual se quiere hacer la copia de seguridad. 42

57 5. El sistema guardará la copia de seguridad. Escenario Alternativo: 2.a El sistema no puede montar el recurso SMB del servidor. 5.a El sistema detecta que no hay espacio suficiente en el recurso SMB para guardar la copia de seguridad Caso de uso: Realizar Backup en recurso SSH Descripción: Realizar una copia de seguridad de una carpeta local y guardarla en un recurso de red SSH. Actores: Usuario y Servidor SSH Escenario principal: 1. El usuario introduce en el sistema los datos correspondientes al recurso de red del servidor SSH: nombre o la dirección IP, el nombre del recurso compartido, usuario y contraseña 2. El sistema comprueba que se puede utilizar el recurso de red y lo monta en una carpeta. 3. El usuario elige una carpeta dentro del recurso SSH, que servirá para guardar la copia de seguridad. 4. El usuario elige la carpeta, de la cual se quiere hacer la copia de seguridad. 5. El sistema guardará la copia de seguridad. Escenario Alternativo: 2.a El sistema no puede montar el recurso SSH del servidor. 5.a El sistema detecta que no hay espacio suficiente en el recurso SSH para guardar la copia de seguridad. Caso de uso: Restaurar backup desde local Descripción: Restaurar una carpeta desde una copia de seguridad, la cual esta almacenada en una partición local. Actores: Usuario Escenario principal: 1. El usuario elige la partición donde se encuentra almacenada la copia de seguridad. 2. El sistema monta la partición. 3. El usuario elige la carpeta donde se encuentra almacenada la copia de seguridad. 4. El usuario elige la carpeta que debe ser restaurada. 5. El sistema restaura la carpeta a través de la copia de seguridad. Escenario Alternativo: 2.a El sistema no puede montar la partición. 5.a El sistema detecta que la carpeta elegida no tiene ninguna copia de seguridad válida. 43

58 Caso de uso: Restaurar backup desde recurso NFS Descripción: Restaurar una carpeta desde una copia de seguridad, la cual esta almacenada en un recurso NFS. Actores: Usuario y Servidor NFS Escenario principal: 1. El usuario introduce en el sistema los datos correspondientes al recurso de red del servidor NFS: nombre o la dirección IP, y el nombre del recurso compartido. 2. El sistema comprueba que se puede utilizar el recurso de red y lo monta en una carpeta. 3. El usuario elige una carpeta dentro del recurso NFS, en la cual esta almacenada la copia de seguridad. 4. El usuario elige la carpeta, de la cual se quiere restaurar la copia de seguridad. 5. El sistema restaura la copia de seguridad. Escenario Alternativo: 2.a El sistema no puede montar el recurso NFS del servidor. 5.a El sistema detecta que la carpeta elegida no tiene ninguna copia de seguridad válida. Caso de uso: Restaurar backup desde recurso SMB Descripción: Restaurar una carpeta desde una copia de seguridad, la cual esta almacenada en un recurso SAMBA. Actores: Usuario y Servidor SMB Escenario principal: 1. El usuario introduce en el sistema los datos correspondientes al recurso de red del servidor SMB: nombre o la dirección IP, el nombre del recurso compartido, usuario y contraseña. 2. El sistema comprueba que se puede utilizar el recurso de red y lo monta en una carpeta. 3. El usuario elige una carpeta dentro del recurso SMB, en la cual esta almacenada la copia de seguridad. 4. El usuario elige la carpeta, de la cual se quiere restaurar la copia de seguridad. 5. El sistema restaura la copia de seguridad. Escenario Alternativo: 2.a El sistema no puede montar el recurso SMB del servidor. 5.a El sistema detecta que la carpeta elegida no tiene ninguna copia de seguridad válida. 44

59 Caso de uso: Restaurar backup desde recurso SSH Descripción: Restaurar una carpeta desde una copia de seguridad, la cual esta almacenada en un recurso SSH. Actores: Usuario y Servidor SSH Escenario principal: 1. El usuario introduce en el sistema los datos correspondientes al recurso de red del servidor SSH: nombre o la dirección IP, el nombre del recurso compartido, usuario y contraseña. 2. El sistema comprueba que se puede utilizar el recurso de red y lo monta en una carpeta. 3. El usuario elige una carpeta dentro del recurso SSH, en la cual esta almacenada la copia de seguridad. 4. El usuario elige la carpeta, de la cual se quiere restaurar la copia de seguridad. 5. El sistema restaura la copia de seguridad. Escenario Alternativo: 2.a El sistema no puede montar el recurso SSH del servidor. 5.a El sistema detecta que la carpeta elegida no tiene ninguna copia de seguridad válida. 45

60 46

61 Capítulo 6 Diseño 6.1. Introducción En el diseño vamos a utilizar una estructura arquitectónica de dos capas, descartando la capa de gestión de datos ya que no tiene sentido en el desarrollo de la herramienta. Por tanto, vamos a dividir el diseño en las siguientes capas: Capa de lógica de la aplicación: va a ser la encargada de implementar las funcionalidades del sistema. Para ello vamos a utilizar notación de la metodología estructurada. Capa de presentación: va a definir el modo de interactuar del usuario con el sistema. Para tener una visualización exacta del sistema, y por tanto, comprenderlo mejor, vamos a representar los casos de uso con figuras, para que nos ayuden en la tarea de realizar el diseño. Figura 6.1: Representación gráfica del proceso de Guardar/Restaurar una imagen 47

62 Figura 6.2: Representación gráfica del proceso de clonado en local Figura 6.3: Representación gráfica del proceso de clonado por red 48

63 Figura 6.4: Representación gráfica del proceso de backup 6.2. Diseño de la capa de lógica de la aplicación La notación empleada a la hora de realizar el diseño de la capa de lógica de la aplicación, es una notación estructurada, concretamente, hemos utilizado los diagramas de estructuras para desarrollar esta fase. A continuación se presentarán los diagramas de estructuras obtenidos en la fase de diseño, derivados de los casos de uso de la fase de análisis. El primer diagrama de estructura es el del menú principal (figura 6.5). Este nos permitirá elegir qué acción queremos ejecutar. Figura 6.5: Diagrama de estructura del menú principal 49

64 La primera acción elegida en este caso, es la de guardar una imagen de clonación. El diagrama de estructura que describe este proceso es el de la figura 6.6. Al lugar elegido para guardar la imagen lo hemos llamado almacén, el cual puede ser tanto un dispositivo local como un recurso de red (NFS, SMB o SSH). Figura 6.6: Diagrama de estructura de la función guardar imagen En los siguientes diagramas de estructuras (figuras 6.7, 6.8, 6.9 y 6.10) se describen los procesos de montaje sobre almacén de los distintos dispositivos locales o de red (NFS, SMB o SSH). Estas subfunciones descritas en estos diagramas de estructuras serán utilizados en otros diagramas de estructuras de otras funciones. 50

65 Figura 6.7: Diagrama de estructura de la subfunción almacén local Figura 6.8: Diagrama de estructura de la subfunción almacén NFS 51

66 Figura 6.9: Diagrama de estructura de la subfunción almacén SMB Figura 6.10: Diagrama de estructura de la subfunción almacén SSH 52

67 Después de describir la función de guardar imagen de clonación, se presenta el diagrama de estructura de la función restaurar dispositivo desde una imagen de clonación (figura 6.11). Esta función realiza el proceso de restaurar un dispositivo con la imagen de clonación, la cual, se encuentra en el almacén. Esta función utiliza las subfunciones descritas en los diagramas de estructuras de las figuras 6.7, 6.8, 6.9 y Figura 6.11: Diagrama de estructura de la función restaurar imagen 53

68 Ahora llega el turno de describir las funciones que van a permitir hacer clonaciones directas, es decir, sin guardar imágenes. Estas pueden ser clonaciones locales o de red. En primer lugar se va describir la función de clonación local. En el siguiente diagrama de estructura se representa dicha función (figura 6.12). Es decir, clonamos el contenido de un dispositivo local de origen en otro dispositivo local de destino. Figura 6.12: Diagrama de estructura de la función clonación local 54

69 En segundo lugar se va a describir las funciones de clonación a través de la red. Estas clonaciones van a seguir un esquema de cliente/servidor. Para empezar, se representa el diagrama de estructura de la función "servidor clonación"(figura 6.13), que no es más que una función que nos permite escoger qué protocolo va a utilizar el servidor de clonación. Figura 6.13: Diagrama de estructura de la función servidor clonación Los siguientes tres diagramas de estructuras van a representar cada uno de los protocolos (unicast, multicast y P2P) que puede utilizar el servidor de clonación: Generar clonado por unicast (figura 6.14): Representa la función de distribuir por unicast el clonado de un dispositivo local. Generar clonado por multicast (figura 6.15): Representa la función de distribuir por multicast el clonado de un dispositivo local. Generar clonado por P2P (figura 6.16): Representa la función de distribuir por P2P el clonado de un dispositivo local. 55

70 Figura 6.14: Diagrama de estructura de la función servidor unicast 56

71 Figura 6.15: Diagrama de estructura de la función servidor multicast 57

72 Figura 6.16: Diagrama de estructura de la función servidor P2P 58

73 Ahora toca el turno de representra el diagrama de estructura de la función cliente de clonación (figura 6.17), que no es más que una función que nos permite escoger qué protocolo va a utilizar el cliente de clonación. Figura 6.17: Diagrama de estructura de la función cliente clonación Los siguientes tres diagramas de estructuras van a representar cada uno de los protocolos que puede utilizar el cliente de clonación: Recibir clonado por unicast (figura 6.18): Representa la función de recibir por unicast, por parte del cliente, el clonado para un dispositivo local. Recibir clonado por multicast (figura 6.19): Representa la función de recibir por multicast, por parte del cliente, el clonado para un dispositivo local. Recibir clonado por P2 P (figura 6.20): Representa la función de recibir por P2P, por parte del cliente, el clonado para un dispositivo local. 59

74 60 Figura 6.18: Diagrama de estructura de la función cliente unicast

75 Figura 6.19: Diagrama de estructura de la función cliente multicast 61

76 Figura 6.20: Diagrama de estructura de la función cliente P2P Para terminar se representan los diagramas de estructuras relativos al proceso de creación y restauración de backup, concretamente: Función sistema de backup (figura 6.21): Representa el menú de selección de los procesos de creación o restauración de bakcup. Realizar backup (figura 6.22): Representa el proceso de creación de una backup. Restaurar backup (figura 6.23): Representa el proceso de restaurar una carpeta a través de una copia de backup. 62

77 Figura 6.21: Diagrama de estructura de la función sistema backup Figura 6.22: Diagrama de estructura de la función realizar backup 63

78 Figura 6.23: Diagrama de estructura de la función restaurar backup 6.3. Diseño de la capa de presentación El diseño de la capa presentación es un proceso clave a la hora de realizar este proyecto, porque se tiene que cumplir con uno de los criterios establecidos, el de la usabilidad. Se pretende conseguir un diseño simple, efectivo y sobre todo fácil de usar, que nos permita interactuar con la aplicación de un modo intuitivo. A la hora de realizar la capa de presentación hemos utilizado una herramienta de creación de bocetos, concretamente la versión de pruebas de Balsamiq Mockups ( Con esta herramienta hemos confeccionado los bocetos de las pantallas de la aplicación. Como resultado de este proceso se han desarrollado unos bocetos muy sencillos. A continuación describiremos los principales bocetos obtenidos. Menú Principal El menú principal representado en el siguiente boceto (figura 6.24), está compuesto por seis elementos que se identifican con las seis acciones principales de la aplicación: 64

79 Guardar: Nos da paso a la función de guardar una imagen de clonación. Restauar: Nos proporciona la función de restaurar desde una imagen de clonación. Servidor: Establece el equipo como servidor de clonación. Cliente: Establece el equipo como cliente de clonación. Clonación Local: Nos permite realizar clonaciones entre dispositivos locales. Bakcup: Lanza la aplicación de realizar o restaurar copias de seguridad de carpetas locales. Figura 6.24: Boceto del Menú Principal Guardar-Restaurar Las funciones guardar y restaurar comparten el mismo boceto (figura 6.25), que consiste en elegir dónde se va a guardar la imagen de clonación o dónde está almacenada la imagen de clonación, desde la que se quiere restaurar un dispositivo local. Por tanto nos aparecen los siguientes elementos: Local: La creación o restauración se va a realizar en un, o desde un, dispositivo local. El proceso para guardar una imagen en local consiste en elegir el dispositivo del que queramos realizar una imagen de clonación, este dispositivo puede ser tanto un disco duro completo como una partición, y guardar dicha imagen de clonación en un dispositivo local, ya sea una partición, una memoria USB o un disco duro externo. El proceso de restaurar la imagen es justamente el proceso inverso. NFS, SMB y SSH: En este caso, la creación o restauración se llevará a cabo en, o desde, un recurso de red, que puede ser NFS, SMB o SSH. Es el mismo proceso que en modo local, salvo que en este caso, el lugar donde se va a guardar la imagen de clonación va a ser un recurso de red, a elegir entre NFS y SSH, si el recurso de red es un sistema Linux, o SMB si el recurso se encuentra en un sistema Windows. 65

80 Figura 6.25: Boceto de las funciones Guardar y Restaurar Clonación Local El siguiente boceto (figura 6.26) corresponde al proceso de clonar localmente, y consta solamente de dos elementos: Dispositivo Origen: Va a mostrar los dispositivos locales disponibles que pueden ser el origen de la clonación. Dispositivo Destino: Mostrará los dispositivos locales que pueden ser clonados. Figura 6.26: Boceto de la función Clonar Localmente 66

81 Servidor-Cliente La funciones Servidor y Cliente comparten el mismo boceto (figura 6.27), ya que sólo sirve para elegir qué protocolo de red se va a utilizar a la hora de realizar la clonación. Por tanto, en el boceto aparecen los siguientes elementos, que se corresponden con los distintos protocolos de red: unicast: Elegimos el protocolo unicast para realizar la clonación. El equipo que ejerza de Servidor deberá mostrar los dispositivos locales, que se utilizaran como origen de la clonación, así como la dirección IP del equipo. Por su parte, en el equipo Cliente deberá comprobar que el dispositivo local elegido es compatible con el dispositivo origen del Servidor, en ese caso, se quedará esperando a que el Servidor inicie el proceso de clonación. multicast: Elegimos el protocolo multicast que es muy similar al protocolo unicast, salvo que en el Servidor hay que indicar una dirección IP especial, que se conoce como grupo multicast. Y en cuanto a los Clientes la diferencia principal es que puede haber una multitud de clientes en vez de uno solo. P2P: Y por último, podemos elegir el protocolo P2P. Dado que realizar una clonación al vuelo utilizando el protocolo P2P no es factible, porque generar un fichero torrent de un dispositivo con multitud de ficheros es imposible, se ha optado por generar un fichero torrent de una imagen de clonación. Así el proceso queda del siguiente modo. En el Servidor P2P elegimos una partición que la utilizaremos de caché, en la que guardaremos la imagen de clonación de un dispositivo local, a continuación generaremos el fichero torrent, publicamos la dirección IP del Servidor y lo dejamos activo para enviar paquetes. Por otro lado, en el Cliente P2P debemos conocer la IP del Servidor y el dispositivo local que queremos clonar con la imagen del Servidor, si los dispositivos son compatibles, el cliente obtiene por el protocolo P2P una imagen de clonación y restaura localmente el dispositivo con la imagen obtenida. Figura 6.27: Boceto de las funciones Servidor y Cliente 67

82 Backup-Restore En el siguiente boceto (figura 6.28) sirve para elegir qué función se va a realizar: la de crear un backup de una carpeta, o la de restaurar una carpeta a través de un backup guardado con anterioridad. También hay que elegir en qué lugar vamos a guardar el backup, o desde qué lugar vamos a restaurar el backup. Tenemos los siguientes elementos: Backup/Restore: Lo primero que hay que hacer es decidir qué proceso vamos a realizar: un backup o una restauración de backup. Local: Los ficheros de backup los guardaremos en un dispositivo local. El proceso es similar al explicado anteriormente, en el proceso de guardar-restaurar una imagen de clonación en una partición local, salvo que en este caso estamos trabajando con carpetas en vez de con dispositivos de almacenamiento (discos duros, memorias USB, etc.) NFS, SMB y SSH: En este caso, se guardará el backup, o se restaurará, en un recurso de red, que puede ser NFS, SMB o SSH, dependiendo si estamos en una red Linux o Windows. Figura 6.28: Boceto de las funciones Backup y Restore 68

83 Capítulo 7 Implementación 7.1. Introducción El capítulo de la implementación del sistema consta de dos áreas claramente diferenciadas: por un lado tenemos que codificar los scripts de ClonUCA y por otro, tenemos que construir un live-cd donde los scripts de ClonUCA puedan ejecutarse. En la siguiente figura 7.1 se representa la estructura que tiene que tener el live-cd, donde se aprecian claramente las dos áreas: el sistema base y los scripts de ClonUCA. Figura 7.1: Esquema de la estructura del live-cd: sistema base y los scripts de ClonUCA 69

84 7.2. Scripts de ClonUCA En un principio, la tarea de implementar los scripts de ClonUCA se desarrolló con scripts de bash y apoyados con Xdialog[21] para mostrar las ventanas. Pero esta idea fue descartada principalmente porque las ventanas representadas con Xdialog no ofrecían un aspecto atractivo, además de ser un sistema muy poco flexible a la hora de desarrollar la interfaz de ventanas Lenguaje y Herramientas Utilizadas Finalmente se opta por implementar ClonUCA en un lenguaje de programación de alto nivel, concretamente se elige Python[15] para este propósito. El motivo de esta decisión esta basado en lo siguiente: Python es un lenguaje que destaca por su uso en herramientas de administración de casi cualquier distribución de Linux, está perfectamente integrado en las mismas, y aporta mucha estabilidad y seguridad al utilizarlo para desarrollar cualquier aplicación. Existe una biblioteca gráfica, llamada wxpython[19], que permite crear una interfaz de ventanas muy atractivas y con mucha flexibilidad. Utiliza una licencia Python Software Foundation License (PSFL)[3] que es compatible con la licencia GPL. A continuación se detallan las características principales del lenguaje y las herramientas utilizadas en la implementación de ClonUCA. Pyhton Es un lenguaje de programación de alto nivel cuya filosofía hace hincapié en una sintaxis muy limpia y que favorezca un código legible. Se trata de un lenguaje de programación multiparadigma, esto significa que más que forzar a los programadores a adoptar un estilo particular de programación, permite varios estilos: programación orientada a objetos, programación imperativa y, en menor medida, programación funcional. Otros paradigmas están soportados mediante el uso de extensiones. Python usa tipado dinámico y conteo de referencias para la administración de memoria. Una característica importante es la resolución dinámica de nombres; es decir, lo que enlaza un método y un nombre de variable durante la ejecución del programa (también llamado ligadura dinámica de métodos). Otro objetivo del diseño del lenguaje es la facilidad de extensión. Se pueden escribir nuevos módulos fácilmente en C o C++. Python puede incluirse en aplicaciones que necesitan una interfaz programable. Aunque la programación en Python podría considerarse en algunas situaciones hostil a la programación funcional tradicional del Lisp, existen bastantes analogías entre Python y los lenguajes minimalistas de la familia Lisp como puede ser Scheme. Figura 7.2: Logo de Python 70

85 Los usuarios de Python se refieren a menudo a la Filosofía Python que es bastante análoga a la filosofía de Unix. El código que sigue los principios de Python de legibilidad y transparencia se dice que es pythonico. Contrariamente, el código opaco u ofuscado es bautizado como no pythonico ( unpythonic en inglés). Estos principios fueron descritos por el desarrollador de Python, Tim Peters en El Zen de Python. wxpython wxpython es un binding de la biblioteca gráfica wxwidgets para el lenguaje de programación Python. La biblioteca wxwidgets se caracteriza por ser multiplataforma, por lo que su uso junto a Python permite el desarrollo rápido de aplicaciones gráficas multiplataforma. Siendo un binding, wxpython usa la misma licencia de software libre que wxwidgets (LGPL) la cual es una licencia aprobada por la Fundación del Software Libre y la Open Source Initiative. Figura 7.3: Logo de wxpython Geany Para desarrollar todos los scripts de Python hemos utilizado el Geany, que es un IDE ligero con resaltado de sintaxis, autocompletado, emulador de terminal integrado y soporte de multidocumentos Estructura de directorios La distribución de los directorios que engloban los scripts de ClonUCA viene representada en la figura 7.4, siendo el contenido de los mismos el siguiente: Guardar: En este directorio están los scripts de las funciones generales que realizan la tarea de guardar una imagen de clonación de un dispositivo. Restaurar: Aquí encontramos los scripts inversos a los anteriores, es decir, las funciones generales que realizan la restauración de un dispositivo a través de una imagen de clonación. Servidor: Contiene los scripts de las funciones que establecen que el equipo va a ejercer la funciones de servidor en la tarea de la clonación por red. Cliente: Contiene los scripts de las funciones que establecen que el equipo va a ejercer las funciones de cliente en la tarea de la clonación por red. 71

86 Clonar: En este directorio están los scripts que permiten realizar clonaciones locales entre dispositivos locales. Backup: Aquí encontramos todos los scripts relacionados con las funciones de backup y restauración de backup. Funciones: En este directorio están todos los scripts que realizan funciones intermedias o específicas, que son utilizadas por las funciones generales descritas en los directorios anteriores. Hemos optado por hacerlo así, principalmente porque hay muchas funciones específicas que son compartidas por las generales. Iconos: En este directorio están los iconos que aparecen en las ventanas de ClonUCA. Hay que indicar que están basados en los iconos de Gnome 2.30, por tanto, cumplen con la licencia Software Libre. Para realizar el diseño de los iconos se ha utilizado una aplicación de diseño vectorial, también bajo licencia Software Libre, llamada inskcape[11]. Y por último, comentar la existencia de dos scripts: menu_prinpipal.py, que se utiliza para iniciar la herramienta ClonUCA y apagar.py que es un script para realizar el proceso de apagado o reinicio del equipo. Figura 7.4: Estructura de los directorios de los scripts de ClonUCA 72

87 Para finalizar esta sección, indicar que todos los scripts escritos con Python no se van mostrar por razones obvias, sino que se adjuntan en el CD-ROM N o 2, anexo en esta memoria Sistema Base Ahora vamos a describir el proceso de desarrollo del sistema base. Este apartado es fundamental para la consecución del objetivo y los criterios establecidos, ya que muchos de ellos dependen primordialmente de cómo esté desarrollado el sistema base del live-cd. La primera decisión importante es elegir qué herramienta vamos a utilizar para construir el live-cd. Después de investigar, hemos llegado a la conclusión de que la herramienta que se adapta mejor a nuestras necesidades es live-helper. Esta herramienta está diseñada para trabajar en sistemas Debian y nos permitirá crear un live-cd basado en Debian de una forma fácil y sencilla, para obtener más información de esta herramienta podemos acceder a la siguiente URL: Desarrollo de la maqueta del live-cd A continuación se va a detallar la instalación, configuración y utilización de la herramienta live-helper. Es un proceso que se explica como documentación para que el lector pueda relizar su propia live-cd, pero que no es absolutamente necesario para el usuario final de ClonUCA. Aclarado esto, decir que, live-helper está diseñada para trabajar sobre una distribución Debian, por tanto, la vamos a instalar sobre la versión estable de Debian, denominada squeeze. Para llevar a cabo este proceso, debemos ejecutar los siguientes comandos con permisos de administrador: $ apt-get update $ apt-get updgrade $ apt-get install live-helper Una vez instalado el live-helper, tenemos que buscar algunos paquetes imprescindibles para la creación del live-cd. Y estos son, en primer lugar partclone, que es la herramienta que vamos a utilizar para realizar las clonaciones. Podemos descargar la última versión estable de la siguiente dirección: El otro software imprescindible es el paquete non-free que contiene los drivers de las tarjetas de red de Realtek. Este paquete es muy importante ya que sin él no podríamos utilizar las tarjetas de red de los equipos más modernos y por tanto las funcionalidades de ClonUCA que estén relacionadas con la red, no se podrían realizar. El paquete concreto que vamos a utilizar es el de la versión de squeeze de Debian, y lo podemos descargar de la siguiente URL: all.deb Aquí hay que hacer un inciso, ya que estamos utilizando un paquete non-free y esto significa que el paquete no cumple con DSFG[8]. Normalmente ocurre cuando no se suministra el có- 73

88 digo fuente. Concretamente, en este caso el suministrador del paquete incluye su propia licencia (/usr/share/doc/firmware-realtek/copyright). La mostramos a continuación porque así lo requiere el autor del paquete: 1 The binary firmware may be downloaded from linux-firmware.git. 2 3 Files: realtek/rtl_nic/rtl8168d-*.fw 4 Copyright: 2010, Realtek Semiconductor Corporation 5 License: Binary redistribution (Realtek permissive) 6 Permission is hereby granted for the distribution of this firmware 7 data in hexadecimal or equivalent format, provided this copyright 8 notice is accompanying it Files: realtek/rtl8192e/*, realtek/rtl8192su/*, realtek/rtlwifi/* 11 Copyright: , Realtek Semiconductor Corporation 12 License: Binary redistribution (Realtek restrictive) 13 All rights reserved Redistribution. Redistribution and use in binary form, without 16 modification, are permitted provided that the following conditions are 17 met: * Redistributions must reproduce the above copyright notice and the 20 following disclaimer in the documentation and/or other materials 21 provided with the distribution. 22 * Neither the name of Realtek Semiconductor Corporation nor the names of its 23 suppliers may be used to endorse or promote products derived from this 24 software without specific prior written permission. 25 * No reverse engineering, decompilation, or disassembly of this software 26 is permitted Limited patent license. Realtek Semiconductor Corporation grants a world-wide, 29 royalty-free, non-exclusive license under patents it now or hereafter 30 owns or controls to make, have made, use, import, offer to sell and 31 sell ("Utilize") this software, but solely to the extent that any 32 such patent is necessary to Utilize the software alone, or in 33 combination with an operating system licensed under an approved Open 34 Source license as listed by the Open Source Initiative at 35 The patent license shall not apply to 36 any other combinations which include this software. No hardware per 37 se is licensed hereunder DISCLAIMER. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND 40 CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, 41 BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND 42 FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE 43 COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, 44 INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, 45 BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS 46 OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND 47 ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR 48 TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE 49 USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH 50 DAMAGE. Entendemos que en ningún momento estamos violando la licencia, por lo que utilizaremos dicho paquete para la realización de la aplicación. Una vez que hemos descargados los paquetes, tenemos que crear una carpeta (por ejemplo: sistema_base), y los copiamos dentro de la carpeta. Una vez dentro de la carpeta ejecutamos el script sistema_base.sh. $ mkdir sistema_base $ cp partclone_0.2.16_i386.deb sistema_base/ 74

89 $ cp firmware-realtek_0.28+squeeze1_all.deb sistema_base/ $ cd sistema_base $./sistema_base.sh Indicar que todos los scripts desarrollados son Software Libre y cumplen con la licencia GNU General Public License, version 3 (GPL-3.0)[25], para hacer visible esto, todos los scripts incluyen la siguiente licencia. 1 # 2 # This program is free software: you can redistribute it and/or modify 3 # it under the terms of the GNU General Public License as published by 4 # the Free Software Foundation, either version 3 of the License, or 5 # any later version. 6 7 # This program is distributed in the hope that it will be useful, 8 # but WITHOUT ANY WARRANTY; without even the implied warranty of 9 # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 10 # GNU General Public License for more details # You should have received a copy of the GNU General Public License 13 # along with this program. If not, see < # Copyright (C) 2012 Ismael Cano Sanchez - ismael.cano@uca.es El contenido del script sistema_base.sh es el siguiente: 1 # Script que permite crear una sistema minimo de un live-cd 2 # utilizando la herramienta live-helper. 3 4 #!/bin/bash 5 6 echo Configuramos live-helper... 7 lh config a i386 -d squeeze -k 686 -p minimal bootappend-live 8 "locales-es" --username root --hostname clonuca --packages 9 "xserver-xorg xinit x11-xserver-utils icewm portmap grub2 10 nfs-common smbfs sshfs netcat iputils-ping udpcast 11 bittorrent-gui dosfstools ntfsprogs reiserfsprogs ntfs-3g 12 wget thttpd xterm dhcp3-client dar nano localepurge 13 deborphan lzma gparted xfs_progs reiser4progs 14 jfs_utils epdfview" -b iso echo agregamos partclone 17 cp partclone_0.2.16_i386.deb config/chroot_local-packages echo agregamos firmware-realtek 20 cp firmware-realtek_0.28_all.deb config/chroot_local_packages echo Construimos el sistema basico, paciencia lh build El proceso de creación del live-cd es un poco lento, ya que tiene que bajarse los paquetes y configurarlo todo, cuando termina nos deja un fichero binary.iso con un tamaño aproximado de 206 MiB, que es la ISO del live-cd. También tenemos dos directorios: binary: Donde se encuentra la ISO descomprimida. chroot: es el directorio donde se encuentra descomprimido todo el sistema del live-cd. Con esto ya tenemos una maqueta básica con la que poder trabajar. Ahora hay que realizar un trabajo de personalización y optimización para conseguir que el live-cd cumpla con el objetivo y los criterios establecidos, y para ello vamos a seguir un proceso de 3 fases: 75

90 1 o fase, minimizar: Va a consistir en eliminar todo aquello que no sea imprescindible para el funcionamiento del live-cd (programas, documentación, etc.) 2 o fase, interfaz gráfica: La maqueta de live-cd no posee un gestor de ventanas que nos permita interactuar gráficamente con la aplicación. En esta fase se configurará el gestor de ventanas icewm. 3 o fase, integración entre el live-cd y ClonUCA: Por último, vamos adaptar el live-cd para que los scripts de ClonUCA puedan realizar sus funciones. Proceso de personalización y creación del live-cd Para poder realizar la personalización del live-cd tendremos que trabajar en un entorno chroot sobre el directorio chroot, para ello ejecutaremos los siguientes comandos: $ cp /etc/resolv.conf chroot/etc/ #para poder tener red $ chroot chroot $ mount -t proc none /proc $ mount -t sysfs none /sys Una vez que hayamos terminado de realizar los cambios pertinentes, tenemos que salir del entorno chroot, para ello ejecutamos lo siguiente: $ umount /proc $ umount /sys $ exit Ahora que tenemos el sistema personalizado, tendremos que construir de nuevo el live-cd. Nos hacen falta las siguientes herramientas: squashfs-tools y genisoimage. $ apt-get install squashfs-tools genisoimage Para crear en live-cd vamos a utilizar un sencillo script llamado makeiso.sh, al que le tenemos que pasar como argumento el nombre que queremos darle a la ISO del live-cd. $./makeiso clonuca Tras la ejecución del comando anterior obtenemos un fichero llamado clonuca.iso, que es la ISO del live-cd. El contenido del script makeiso.sh lo podemos ver a continuación. 1 # Script que permite construir un live-cd, a partir del directorio chroot 2 3 #!/bin/bash 4 5 # Hacemos limpieza 6 rm -r chroot/var/cache/localepurge 7 rm chroot/var/cache/apt/*bin 8 rm chroot/var/lib/apt/lists/* 9 rm -r chroot/var/lib/deborphan 10 rm chroot/var/cache/debconf/*old 11 rm chroot/var/lib/dpkg/*old # Regeneramos los scripts 14 rm -r chroot/opt/clonuca/* 15 cp -r chroot/opt/clonuca 16 rm -r chroot/opt/clonuca/*~ 17 rm -r chroot/opt/clonuca/*.pyc 18 rm -r chroot/opt/clonuca/*/*~ 19 rm -r chroot/opt/clonuca/*/*.pyc 76

91 20 21 # Regeneramos el filesystem.squashfs 22 rm binary/live/filesystem.squashfs 23 mksquashfs chroot/ binary/live/filesystem.squashfs # Construimos la imagen ISO 26 cd binary 27 genisoimage -r -V "$1" -cache-inodes -J -l -b isolinux/isolinux.bin 28 -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table 29 -o../$1.iso. 30 cd o Fase: Minimizar Vamos a someter al live-cd a un proceso de adelgazamiento para obtener un sistema lo más rápido y liviano posible. Para conseguirlo vamos a seguir los siguientes pasos: Eliminación de ficheros innecesarios Primero, podemos eliminar los paquetes.deb de instalación que se encuentran en la cache, ya que una vez instalado el sistema no nos hacen falta. $ rm chroot/var/cache/apt/archives/*.deb Segundo, borramos los ficheros de arranque de la live-cd que se encuentran dentro del directorio chroot, ya que para utilizar la live-cd se usan los que están dentro del directorio binary. $ rm chroot/vmlinuz $ rm chroot/boot/vmlinuz $ rm chroot/initrd.img $ rm chroot/boot/initrd.img Tercero, borramos toda la documentación y manuales del live-cd. $ rm -r chroot/usr/share/doc $ rm -r chroot/usr/share/doc-base $ rm -r chroot/usr/share/info $ rm -r chroot/usr/share/man Y por último, también podemos borrar todos los ficheros de configuración de dispositivos que no vamos a utilizar. $ rm -rf chroot/lib/modules/ /kernel/sound/* $ rm -rf chroot/lib/modules/ /kernel/net/atm $ rm -rf chroot/lib/modules/ /kernel/net/bluetooth $ rm -rf chroot/lib/modules/ /kernel/net/appletalk $ rm -rf chroot/lib/modules/ /kernel/net/wimax $ rm -rf chroot/lib/modules/ /kernel/net/wireles $ rm -rf chroot/lib/modules/ /kernel/drivers/net/appletalk $ rm -rf chroot/lib/modules/ /kernel/drivers/net/arcnet $ rm -rf chroot/lib/modules/ /kernel/drivers/net/tokenring $ rm -rf chroot/lib/modules/ /kernel/drivers/net/tulip $ rm -rf chroot/lib/modules/ /kernel/drivers/net/wimax $ rm -rf chroot/lib/modules/ /kernel/drivers/net/wireles $ rm -rf chroot/lib/modules/ /kernel/drivers/atm $ rm -rf chroot/lib/modules/ /kernel/drivers/bluetooth $ rm -rf chroot/lib/modules/ /kernel/drivers/inifiniband $ rm -rf chroot/lib/modules/ /kernel/drivers/isdn $ rm -rf chroot/lib/modules/ /kernel/drivers/media 77

92 Configuración de las locales Lo que pretendemos conseguir con esto, es configurar el live-cd solo con el idioma en español, así podemos eliminar todas las locales que no vayamos a necesitar. El modo de realizarlo consiste en reconfigurar las locales y seleccionando solo: es_es.utf-8 y es_es. Este procedimiento hay que hacerlo en un entorno chroot, con los siguientes comandos: $ dpkg-reconfigure localepurge $ localepurge $ dpkg-reconfigure locales Luego podemos borrar los ficheros de configuracion de las locale: $ mv chroot/usr/share/locale/es../ $ mv chroot/usr/share/locale/en../ $ rm -R chroot/usr/share/locale/* $ mv chroot/usr/share/es chroot/usr/share/locale/ $ mv chroot/usr/share/en chroot/usr/share/locale/ Eliminación de paquetes A pesar de haber construido un live-cd con el mínimo número de paquetes posibles, aún podemos eliminar manualmente algunos paquetes innecesarios para conseguir un live-cd lo más liviano posible. Esta operación hay que realizarla dentro de un entorno chroot, donde ejecutaremos los siguientes comandos: $apt-get remove libgl1-mesa-dri $apt-get remove openssh-blacklist $apt-get remove openssh-blacklist-extra $apt-get remove samba-common-bin $apt-get remove hicolor-icon-theme $apt-get remove xfonts-utils $apt-get remove deborphan $apt-get remove locales $apt-get remove nano $apt-get remove cron $apt-get remove os-prober $apt-get autoremove o Fase: Interfaz Gráfica Para mejorar la interacción del usuario con la aplicación hay que configurar la interfaz gráfica del live-cd, esto se reduce a configurar las X-windows y un gestor de ventanas, que en nuestro caso va a ser el icewm. Configuración de las X-windows Al configurar las X-windows pretendemos establecer un marco homogéneo, que se pueda ejecutar en todos los ordenadores, independientemente de las características hardware de los mismos, es decir, que sea válido tanto para ordenadores antiguos como para los últimos modelos. Esto lo vamos conseguir estableciendo una configuración muy básica: resolución de 1024x768, 24 bits de profundidad de color, etc. Para configurar las X-windows hay que generar el fichero xorg.conf y guardarlo en la siguiente ruta:/chroot/etc/x11/xinit/xorg.conf. Esto se consigue ejecutando el siguiente comando: 78

93 $ dpkg-reconfigure -phigh xserver-xorg Posteriormente hay que modificar el fichero /chroot/etc/x11/xinit/xserverrc para que arranque las X-windows con la configuración proporcionada por el fichero xorg.conf. Quedando del siguiente modo. 1 #!/bin/sh 2 3 exec /usr/bin/x11/x -dpi 75 -br -nolisten tcp -config 4 /etc/x11/xinit/xorg.conf Configuración del gestor de ventanas: icewm Para mejorar la interacción con ClonUCA vamos a personalizar el gestor de ventanas icewm. Para ello vamos a instalar el tema IceClearLooks, que lo bajaremos de la siguiente dirección: Una vez bajado, eliminaremos los temas que vienen por defecto con icewm, para posteriormente descomprimir el fichero bajado del enlace, y para terminar lo borraremos. Esto lo conseguiremos con los siguientes comandos: $rm -r chroot/usr/share/icewm/themes/* $tar xzvf chroot/usr/share/icewm/themes/96346-iceclearlooks.tar.gz $rm chroot/usr/share/icewm/themes/96346-iceclearlooks.tar.gz Para terminar de configurar icewm tenemos que indicarle que IceClearLooks es el tema predeterminado, para ello creamos el siguiente fichero: chroot/etc/x11/icewm/theme, con el siguiente contenido. 1 Theme="IceClearlooks/default.theme" o Fase: Integración entre el live-cd y ClonUCA Para poder ejecutar los scripts de ClonUCA hay que realizar algunos cambios más, tanto en el live-cd como en el gestor de ventanas icewm. Estos cambios se pueden resumir en las siguientes actuaciones: Directorios específicos de ClonUCA Integración de ClonUCA con icewm Ficheros de arranque del live-cd 79

94 A continuación vamos a ir desglosando cada una de las actuaciones indicadas anteriormente. Directorios específicos de ClonUCA Para poder utilizar los scripts de ClonUCA en el live-cd tenemos que crear unos directorios específicos: /almacen: este directorio lo va a utilizar ClonUCA para montar tanto los recursos locales como de red, y así poder utilizar el directorio /almacen para guardar las imágenes de clonación. /opt/clonuca: en este directorio es dónde van a estar almacenados todos los scripts de ClonUCA. /root/grub: y por último, este directorio se va a utilizar para guardar el paquete de instalación de la versión antigua del GRUB. Esto es así, porque el live-cd está configurado con GRUB2, pero habrá casos en los que haga falta utilizar GRUB en vez de GRUB2, en ese caso se desinstala el que viene en el live-cd y se instala la versión antigua. El paquete de la versión antigua del GRUB la podemos obtener de la siguiente dirección URL: El modo de crear los directorios descritos anteriormente es con la ejecución de los siguientes comandos: $ mkdir chroot/almacen $ mkdir chroot/opt/clonuca $ mkdir chroot/root/grub $ cp grub _i386.deb chroot/root/grub/ Integración de ClonUCA con icewm Lo primero que vamos a configurar es el fichero de arranque de icewm. Este nos permitirá iniciar automáticamente ClonUCA y configurar el teclado en español. Dicho fichero es.icewm/startup y lo guardaremos en el directorio del root, esto es así, porque el live-cd esta configurado para que arranque con la sesión de root. Para poder ejecutar el.icewm/startup en el arranque tiene que tener permiso de ejecución y su contenido es el siguiente: 1 #.icewm/startup 2 # 3 # fichero de configuracion de icewm que nos permite configurar 4 # el teclado y lanzar al inicio ClonUCA 5 6 setxkbmap -layout es,es -model pc105 & 7 python /opt/clonuca/menu_principal.py Otros ficheros que hay que modificar para integrar ClonUCA con icewm son los referidos a la configuración de los menús, las barras de tareas y preferencias. Estos se encuentran en el siguiente directorio: chroot/etc/x11/icewm y a continuación se listan el contenido de los mismos con las modificaciones realizadas. 1 # /etc/x11/icewm/menu 2 # This is an example for IceWM s menu definition file. 3 # 4 # Place your variants in /etc/x11/icewm or in $HOME/.icewm 80

95 5 # since modifications to this file will be discarded when you 6 # (re)install icewm. 7 8 prog ClonUCA /usr/share/icewm/imagenes/icono_clonuca.png python /opt/clonuca/menu_principal.py 9 prog "Manuel ClonUCA" /usr/share/icewm/imagenes/ayuda.png epdfview /opt/clonuca/manual_clonuca.pdf 10 prog Gparted /usr/share/icewm/imagenes/gparted.png gparted 11 prog Terminal /usr/share/icewm/imagenes/xterm.png xterm -ls 12 prog Apagar /usr/share/icewm/imagenes/apagar.png python /opt/clonuca/apagar.py 1 # /etc/x11/icewm/toolbar 2 # This is a default toolbar definition file for IceWM 3 # 4 # Place your personal variant in $HOME/.icewm directory. 5 6 prog ClonUCA /usr/share/icewm/imagenes/icono_clonuca.png python /opt/clonuca/menu_principal.py 7 prog "Manuel ClonUCA" /usr/share/icewm/imagenes/ayuda.png epdfview /opt/clonuca/manual_clonuca.pdf 8 prog Gparted /usr/share/icewm/imagenes/gparted.png gparted 9 prog Apagar /usr/share/icewm/imagenes/apagar.png python /opt/clonuca/apagar.py 1 # /etc/x11/icewm/preferences 2 3 TaskBarShowMailboxStatus=0 # 0/1 4 5 TaskBarShowWorkspaces=0 # 0/1 6 7 TaskBarShowShowDesktopButton=0 # 0/1 8 9 # Show Start menu on task bar 10 TaskBarShowStartMenu=0 # 0/ # Show window list menu on task bar 13 TaskBarShowWindowListMenu=0 # 0/ # Show programs submenu 16 ShowProgramsMenu=0 # 0/ # Show settings submenu 19 ShowSettingsMenu=0 # 0/ # Show focus mode submenu 22 ShowFocusModeMenu=0 # 0/ # Show themes submenu 25 ShowThemesMenu=0# 0/ # Show logout submenu 28 ShowLogoutMenu=0 # 0/ # Show the help menu item 31 ShowHelp=0 # 0/ # Show logout submenu 34 ShowLogoutSubMenu=0 # 0/ # Show the window menu item 37 ShowWindowList=0 # 0/ # Menu icon size 40 MenuIconSize=32 # [8-128] # Dimension of the small icons 43 SmallIconSize=32 # [8-128] 81

96 44 45 # Dimension of the large icons 46 LargeIconSize=32 # [8-128] WorkspaceNames=" ClonUCA " DesktopBackgroundImage="/usr/share/icewm/imagenes/fondo_clonuca.png" Ficheros de arranque del live-cd Para poder tener una live-cd totalmente integrada o personalizada con ClonUCA hay que modificar algunos ficheros del directorio binary/isolinux. Primero modificaremos el fichero live.cfg del siguiente modo: 1 # live.cfg 2 3 label live to RAM 4 menu label Live to RAM 5 kernel /live/vmlinuz 6 append initrd=/live/initrd.img boot=live config username=root hostname=clonuca 7 quiet toram vga= label livefailsafe to RAM 10 menu label Live (failsafe) to RAM 11 kernel /live/vmlinuz 12 append initrd=/live/initrd.img boot=live config username=root hostname=clonuca 13 noapic noapm nodma nomce nolapic nomodeset nosmp vga=normal toram label live 16 menu label Live 17 kernel /live/vmlinuz 18 append initrd=/live/initrd.img boot=live config username=root hostname=clonuca 19 quiet vga= label livefailsafe 22 menu label Live (failsafe) 23 kernel /live/vmlinuz 24 append initrd=/live/initrd.img boot=live config username=root hostname=clonuca 25 noapic noapm nodma nomce nolapic nomodeset nosmp vga=normal También tendremos que modificar el fichero isolinux.cfg para que el live-cd arranque automáticamente la opción por defecto transcurrido 5 segundos desde el inicio. 1 # isolinux.cfg 2 3 include menu.cfg 4 default /isolinux/vesamenu.c32 5 prompt 0 6 timeout 50 Para terminar la personalización del live-cd podemos sustituir la imagen del bootsplash por una relacionada con ClonUCA, como por ejemplo la imagen expuesta a continuación (figura 7.5). 82

97 Figura 7.5: Imagen para el splash del live-cd de ClonUCA Con esto ya hemos terminado el proceso de creación, integración con ClonUCA y optimización del Sistema-Base. 83

98 84

99 Capítulo 8 Pruebas 8.1. Introducción El proceso de pruebas ha sido un tanto atípico, ya que no se ha planificado una batería de pruebas, propiamente dicha, sino más bien ha sido un proceso retroalimentado, en el que a medida que ClonUCA se enfrentaba a un problema, se han ido probando las distintas funcionalidades de la herramienta. En otras palabras, dado que mi trabajo profesional se lleva a cabo en el Campus de Jerez de la Universidad de Cádiz, como responsable de las aulas de informática, se ha procurado siempre utilizar ClonUCA desde sus inicios, para realizar la tarea de clonación de los equipos informáticos de las aulas. En este proceso, cada vez que ClonUCA se enfrentaba a una nueva tarea y surgían errores, siempre se solucionaban hasta que ClonUCA realizaba satisfactoriamente la función. Ha sido un proceso iterativo en el que ClonUCA ha ido creciendo en funcionalidad a medida que ha tenido que dar respuesta a más necesidades. Al final se ha conseguido que ClonUCA sea la herramienta de referencia en el Campus de Jerez para realizar las clonaciones Hitos conseguidos Para entender como ClonUCA se ha convertido en la herramienta de referencia, se van a exponer a continuación las actuaciones más relevantes donde se ha utilizado ClonUCA, agrupadas por las funcionalidades de la herramienta. Comentar que en todas las pruebas realizadas se ha comprobado que tanto la restauración de una imagen, como la clonación de un dispositivo y la recuperación de una copia de seguridad, se han realizado correctamente, es decir, que la copia ha sido igual que el original Guardar/Restaurar desde un recurso de red Esta funcionalidad ha sido la más utilizada a lo largo de las pruebas realizadas. Consiste básicamente en guardar una imagen de clonación en un recurso de red, y luego poder restaurar dicha imagen en los equipos que sean necesarios. A continuación se desglosan los casos en los que ha sido utilizada. 85

100 Aulas de Informática del Aulario En el Aulario del Campus de Jerez disponemos de cuatro aulas de informática con 31 equipos por aula, como se aprecia en la figura 8.1, en total son 124 ordenadores, con las siguientes características: Procesador AMD Athlon XP 2400 Memoria RAM 512 MBytes Disco duro 40 GBytes Tarjeta de red Ethernet 100 Mbits Estos equipos disponen de dos sistemas operativos: Windows XP SP3 y Debian squeeze. El gestor de arranque que se utiliza es el GRUB. Todos los años, cuando se inicia de curso hay que actualizar el software que se va a utilizar durante todo el curso. Para realizar esta tarea se opta por clonar los equipos. Concretamente, en Septiembre de 2011 se utilizo ClonUCA de una forma muy satisfactoria. El proceso fue el siguiente, se guardó una imagen de clonación de un equipo en un recurso SAMBA, para luego ir restaurando dicha imagen en cada equipo del aula. ClonUCA fue capaz de guardar/restaurar las particiones Windows y Linux, así como restaurar el gestor de arranque GRUB. Figura 8.1: Aula de Informática del aulario del Campus de Jerez Aula de Informática de portátiles de Multiusos En el edificio Multiusos del Campus de Jerez hay una aula de portátiles, como el que se puede ver en la figura 8.2. Son 30 portátiles con las siguientes características: 86

101 Procesador Intel Pentium T4400 Memoria RAM 4 GBytes Disco duro 320 GBytes Tarjeta de red Ethernet Gigabit En este aula nos encontramos en una situación idéntica a la de las aulas de informática descritas anteriormente, es decir, poseen el mismo software y hay que actualizarlo antes de iniciar el curso académico. La única diferencia reside en los equipos en sí, ya que ahora son portátiles más modernos que los equipos que hay en las aulas de informática. En este caso, ClonUCA también realizó la tarea de guardar/restaurar las imágenes sin ningún tipo de problemas. Figura 8.2: Portátil del seminario 0.3 del edificio Multiusos del Campus de Jerez Aula de Informática de portátiles del Aulario En el aulario del Campus de Jerez, también existe una aula de portátiles (véase la figura 8.3) que se utiliza para dar docencia. Por tanto también hay que actualizar el software de los equipos cada vez que se inicia el curso. 87

102 Figura 8.3: Portátil del aula 1 del Aulario del Campus de Jerez Las características principales de estos portátiles son: Procesador Intel Pentium T4500 Memoria RAM 4 GBytes Disco duro 640 GBytes Tarjeta de red Ethernet Gigabit Como se puede apreciar, según las características, son casi idénticos a los portátiles del seminario 0.3, salvo por el software, en este caso llevan instalado un Windows 7 Home Premium 64 bits y Debian squeeze. El proceso de clonación se realizó sin ningún problema, solo mencionar que fue más lento ya que el tamaño de la imagen es mucho mayor, por ser Windows 7 un sistema operativo mucho mayor que Windows XP. Aulas de Docencia Multimedia Repartidas por todo el Campus de Jerez se encuentran las aulas de docencia multimedia. Son aulas que disponen de un ordenador y cañón, para poder impartir la docencia. En software que hay instalado es muy básico: paquete ofimático, navegadores, visor de PDF, antivirus, codecs de audio y video, etc, pero es conveniente actualizarlo todos los años para un correcto funcionamiento. Esta tarea se realiza a través de la clonación de los equipos. En total hay 49 aulas divididas en tres grupos, atendiendo a las características hardware de los ordenadores: Grupo 1: 26 ordenadores Procesador AMD Athlon XP 2400 Memoria RAM 512 MBytes 88

103 Disco duro 40 GBytes Tarjeta de red Ethernet 100 Mbits Grupo 2: 9 ordenadores Procesador Intel Celeron 2400 Mhz Memoria RAM 512 MBytes Disco duro 80 GBytes Tarjeta de red Ethernet 100 Mbits Grupo 3: 14 ordenadores Procesador Intel Pentium E5300 Memoria RAM 4 GBytes Disco duro 500 GBytes Tarjeta de red Ethernet Gigabit En los equipos de los grupos 1 y 2 hay instalado Windows XP y en los del grupo 3, Guadalinex V6. El proceso de clonación ha sido como el hasta ahora explicado: primero se guarda una imagen de clonación en un recurso de red NFS o SAMBA, para posteriormente ir restaurando la imagen en cada equipo. ClonUCA ha realizado todo proceso de manera satisfactoria y sin ningún tipo de incidencia Guardar/Restaurar desde un dispositivo local A continuación se detalla el caso en el que se utilizó esta funcionalidad, por la imposibilidad de realizarla utilizando un recurso de red. PARIS y PAP Los PARIS son puestos informáticos que se encuentran en la biblioteca, se usan principalmente para realizar consultas sobre el catálogo, bases de datos, revistas electrónicas, etc. Y los PAP son puestos de acceso público con conexión a internet, para ser utilizados por los alumnos. Por tanto el software que se utiliza en ambos es similar, en el caso del Campus de Jerez, se ha optado por instalar Ubuntu LTS, con las herramientas básicas: navegador, paquete ofimático, visor de PDF, etc. Y este software va instalado en unos ordenadores con las siguientes características de hardware: Procesador AMD Athlon XP 2400 Memoria RAM 512 MBytes Disco duro 40 GBytes Tarjeta de red Ethernet 100 Mbits 89

104 A la hora de realizar la clonación de estos equipos nos encontramos con el problema de que los recursos de red NFS o SAMBA utilizados para guardar las imágenes de clonación, no eran accesibles desde los PARIS y los PAP, porque pertenecen a VLAN distintas. Los PARIS y PAP pertenecen a la VLAN pública, y por política de la UCA, desde esta VLAN no se puede tener acceso a otro equipo que esté en otra VLAN. Dado que los PARIS y PAP están muy dispersos por la biblioteca y ante la imposibilidad de utilizar un recurso de red como almacén de imágenes de clonación, se optó, para resolver esta situación, por guardar la imagen de clonación en un dispositivo USB. Para, a continuación, ir restaurando localmente desde la imagen almacenada en el dispositivo USB Cliente/Servidor P2P Siguiendo el orden lógico de las funcionalidades de ClonUCA, se detalla el proceso en el que se utilizó la función de realizar clonaciones por red utilizando el protocolo P2P. Aula de Formación de Biblioteca En la biblioteca del campus de Jerez existe un aula de informática con 24 puestos, con el mismo software que existe en las aulas de informática del aulario. La razón de ser, es la de ofrecer a los alumnos la posibilidad de practicar con el software instalado en las aulas de informática, sin la restricción del horario, ya que este aula es de uso libre para los usuarios de la biblioteca. El hardware principal de los ordenadores es el siguiente: Procesador AMD Athlon XP 2400 Memoria RAM 512 MBytes Disco duro 40 GBytes Tarjeta de red Ethernet 100 Mbits Al igual que los PARIS y los PAP, este aula de formación se encuentra en la VLAN pública, por lo que no tiene acceso a los recurso NFS y SAMBA donde se guardan las imágenes de clonación. A continuación se describe el proceso elegido para clonar todos los equipos del aula: 1. Cogemos un equipo del aula y lo conectamos a una VLAN que si tenga acceso a los recursos de red. 2. Dado que el hardware es casi idéntico al de los equipos de las aulas de informática, restauramos con ClonUCA el equipo con la imagen de clonación de las aulas de informática. 3. Con la utilidad Gparted que viene incluida en ClonUCA, creamos una partición nueva. Con el propósito de utilizarla de partición caché, para realizar una clonación utilizando el protocolo P2P. 4. Cuando termina todo este proceso, devolvemos el equipo a su sitio y lo arrancamos con ClonUCA y establecemos el equipo como servidor de clonación P2P. 5. Arrancamos el ClonUCA en el resto de equipos del aula y los establecemos como clientes de clonación P2P. 6. Se ejecuta el proceso de clonación por P2P, cuando se termina, se reinician los equipos y se da por finalizada la clonación. 90

105 El motivo de utilizar la clonación por P2P se sustenta en la imposibilidad de utilizar los recursos de red y en que es muy penoso clonar uno por uno los 24 equipos desde una imagen almacenada en un dispositivo USB. Con la clonación por P2P se consigue un proceso eficiente y eficaz Cliente/Servidor Multicast Siguiendo con los procedimientos de clonación por red, se va a exponer la función de clonación por red utilizando un protocolo multicast. Hay que indicar que no se ha documentado ninguna prueba utilizando el protocolo unicast, por ser un procedimiento análogo al protocolo multicast. Seminario 1.2 de Multiusos En el seminario 1.2 del edificio multiusos del campus de Jerez, se instalaron 8 equipos de nueva generación que se van a destinar a la docencia de herramientas relacionadas con el diseño gráfico. Estos equipos disponen de un sistema dual, con Windows 7 64 bits y Ubuntu LTS 64 bits. Las características hardware son las siguientes: Procesador AMD Phenom II x3 965 Memoria RAM 8 GBytes Disco duro 1 TByte SATA 3 Tarjeta de red Ethernet Gigabit Para realizar la clonación de estos equipos se ha optado por utilizar el protocolo multicast, podíamos haber utilizado un protocolo unicast, pero para obtener una clonación más rápida elegimos la primera opción. El proceso seguido se detalla a continuación: 1. Instalamos y configuramos un equipo con todo el software requerido. Este equipo es el que va a ejercer de servidor de clonación. 2. Para no interferir en la red de la UCA, montamos una red local con un switch gigabit de 16 puertos y un servidor DHCP. En esta red local conectamos los 8 equipos. 3. Arrancamos todos los equipos con el ClonUCA. 4. Establecemos el equipo que va a ejercer de servidor y el resto serán los clientes. 5. Y por último, damos comienzo al proceso de clonación por multicast. Aprovechando que teníamos instalada la infraestructura de la red local, decidimos realizar pruebas de velocidad de clonación, para ello utilizamos la partición de Windows 7 que tenía un tamaño de 32,8 Gbytes. Los resultados obtenidos han sido los siguientes: Mbits con compresión: En primer lugar, utilizamos latiguillos de red de categoría 5, por lo que la velocidad máxima soportada era de 100 Mbits, aunque el switch fuera gigabit. Obtuvimos una velocidad de transferencia media de 90 Mbits/s, la clonación se realizo en un tiempo de 27 minutos. 2. Gigabit con compresión: En este caso, utilizamos latiguillos de red de categoría 6, por lo que velocidad de toda la red era de 1000 Mbits. Con esta configuración obtuvimos una velocidad de transferencia media de 140 Mbits/s, y la clonación completa se realiza en 17 minutos y medio. Con lo que se obtiene una ganancia de velocidad del 155 % respecto a una red de 100 Mbits. 91

106 3. Gigabit sin compresión: Por último, sobre una red completa gigabit, elegimos no utilizar el algoritmo de compresión para realizar la clonación, obteniendo una velocidad de transferencia de 395 Mbits/s, en un tiempo de 11 minutos. Un resultado muy bueno debido a la infraestructura de red gigabit y las características hardware de los equipos Clonación Local A continuación se detalla el proceso en el que se utilizó la funcionalidad de la clonación local de ClonUCA. Centro de Control y Seguridad El centro de control y seguridad de la UCA posee una oficina en el edificio de Servicios Comunes del Campus de Jerez. Para realizar su trabajo disponen de un equipo informático con el siguiente hardware: Procesador AMD Semprom 2600 Memoria RAM 1 GByte Disco duro 40 GBytes Tarjeta de red Ethernet 100 Mbits En un momento dado, el disco duro se quedo sin espacio libre, y no se podía borrar ninguna información. La única solución factible era la de migrar toda la información a un disco duro de mayor tamaño, y para realizar esta tarea de un modo eficaz y eficiente se utilizó la herramienta de clonación local de ClonUCA. El proceso utilizado se detalla a continuación: 1. Conectamos al ordenador un disco duro nuevo de mayor tamaño, en este caso uno de 160 GBytes. 2. Arrancamos el equipo con ClonUCA. 3. Seleccionamos la clonación en local, con el dispositivo de 40 GBytes como dispositivo origen, y el nuevo disco como dispositivo destino. Y lanzamos la clonación local. 4. Cuando el proceso ha terminado, tenemos que redimensionar la partición del disco de 160 GBytes, ya que en el proceso de clonación, el disco nuevo se utiliza la tabla de particiones del disco antiguo. Para llevar a cabo esta tarea se utiliza la herramienta Gparted que viene incluida en ClonUCA Sistema de Backup Como última funcionalidad de ClonUCA se detalla el caso en el que hemos utilizado la creación de copias de seguridad y su posterior restauración. Secretaría y Administración En Diciembre del 2011 se renovaron los 12 equipos de Secretaría y Administración del Campus de Jerez. Los equipos nuevos eran reutilizados, provenían del desmantelamiento de un aula de informática, los cuales tenían las siguientes características: Procesador AMD Athlon 64 X Memoria RAM 2 GBytes 92

107 Disco duro 250 GBytes Tarjeta de red Ethernet 100 Mbits El proceso de instalar los equipos nuevos tuvo dos fases: La primera fue la de clonar todos los equipos con una imagen de clonación previamente generada con ClonUCA. La segunda fase consistía en migrar los datos de las cuentas de usuario desde el ordenador antiguo al nuevo, para ello se utilizo la herramienta de Copia de Seguridad de ClonUCA. En el ordenador antiguo se creaba una copia de seguridad de la carpeta personal de usuario, la cual se guardaba en un recurso de red. A continuación, se restauraba dicha copia de seguridad en el ordenador nuevo Caso especial: Centro de clonado con servidor PXE-ClonUCA El centro de clonado es un caso especial, ya que no es una funcionalidad de ClonUCA, sino, más bien un derivado, que nos permite realizar clonaciones masivas. A continuación se detalla el caso en el que se utilizó este método. Portátiles de Préstamo de Biblioteca En la biblioteca del campus de Jerez hay 90 portátiles destinados a ser prestados a los alumnos, como el que se puede ver la figura 8.4. Una vez al año hay que actualizar el software de estos equipos, compuesto por un sistema dual con Windows XP y Ubuntu LTS y el software instalado en ellos es básico: paquete ofimático, navegadores, visor de PDF, java, codecs de video y audio, compresor, etc. Figura 8.4: Portátil Toshiba NB200 para el préstamo de los alumnos Las características hardware principales son las siguientes: Procesador Intel Atom N Mhz Memoria RAM 1 GByte Disco duro 160 GBytes 93

108 Tarjeta de red Ethernet Gigabit A la hora de clonar estos equipos nos encontramos que carecían de lector de CD-ROM, por tanto no podíamos utilizar el live-cd de ClonUCA. Podríamos haber optado por crear un live-usb con ClonUCA (ver apéndice B), y así arrancar desde el USB, pero realizar esta operación en 90 portátiles uno a uno, podía ser una tarea lenta y penosa. Dado que los portátiles soportan la opción de arrancar por tarjeta de red, se optó por crear un centro de clonado, como el que se puede ver en la figura 8.5. Figura 8.5: Centro de clonación con portátiles Toshiba NB200 Un centro de clonado sirve para realizar muchas clonaciones simultaneas a través de una red local. En nuestro caso, hemos utilizado un switch gigabit de 16 puertos para dar soporte a la red. En un puerto del switch hemos conectado un servidor PXE con ClonUCA (ver apéndice A) y en el resto de puertos del switch hemos conectado los portátiles. Al arrancar los portátiles se conectaban con el servidor PXE y este les mandaba el ClonUCA por la red. Una vez que ClonUCA había arrancado, se iniciaba el proceso de restauración del equipo, a través de una imagen de clonación. En este caso, dicha imagen, se encontraba almacenada en un recurso de red NFS proporcionado por el mismo servidor PXE. Con este método se han conseguido realizar las clonaciones de los 90 portátiles de una forma rápida y eficaz, al poder hacer clonaciones en grupo Resumiendo A lo largo de todas las pruebas realizadas con ClonUCA hemos podido contrastar que la herramienta ha sido capaz de realizar con satisfacción cada una de las tareas para las que ha sido desarrollada, pudiendo operar tanto en equipos antiguos como en nuevos y con variedad de sistema operativos soportados. En total se han documentado las pruebas realizadas sobre 404 ordenadores y todas ellas han sido satisfactorias, es decir, todos los equipos que han sido clonados o restaurados han dado como resultado una copia exacta del original. 94

109 Además, de las pruebas documentadas, hay que señalar que ClonUCA se utiliza habitualmente en el Campus de Jerez, para las tareas de restauración de software de equipos, de un modo plenamente funcional y satisfactorio. 95

110 96

111 Capítulo 9 Conclusiones 9.1. Conclusiones Personales Sacar conclusiones de un proyecto de estas características puede ser un tanto delicado, ya que no es un proyecto típico de gestión y por tanto no es el desenlace lógico de haber estudiado la carrera de Ingeniería Técnica en Informática de Gestión, cosas de la vida. Y en la mía se presentó la oportunidad de trabajar como técnico informático especialista en la Universidad de Cádiz, teniendo que aparcar los estudios de la carrera para consolidar el puesto de trabajo en unas oposiciones. Una vez hecho esto, retomé mi actividad académica para terminar lo que había empezado. Y es en el desarrollo de mi trabajo profesional, donde surge la necesidad de afrontar el problema de gestionar el software instalado en las aulas de informática de una manera eficiente y eficaz. Y este es el embrión del Proyecto de Fin de Carrera. La consecución de este proyecto ha sido un camino largo, que se ha prolongado en el tiempo en exceso, y han aflorado muchas dificultades personales que han ido torpedeando el desarrollo del proyecto, donde las planificaciones se venían abajo y había que retomar la actividad una y otra vez. Por todo esto, me siento satisfecho de haber superado las trabas del camino y poder concluir el desarrollo de este proyecto. Donde he aprendido que la constancia y la capacidad de trabajo y sacrificio son fundamentales para el desarrollo de cualquier proyecto Conocimientos Adquiridos A parte de las enseñanzas personales adquiridas, también he tenido que desempolvar y volver a estudiar apuntes de la carrera, para refrescar los conocimientos, y poder llevar a cabo el desarrollo del proyecto. En todo este proceso he adquirido un conocimiento más profundo de las siguientes áreas: Python: Dado que el lenguaje de programación utilizado en el desarrollo ha sido python[15], que junto con las librerías gráficas wxwidgets[20], se le conoce como wxpython[19]. He tenido que estudiarlo desde el principio porque me era totalmente ajeno, adquiriendo un conocimiento sobre él lo suficientemente amplio, como para poder realizar el desarrollo del proyecto. Debian Live[23]: Magnífica utilidad con la que se ha conseguido crear una live-cd para alojar ClonUCA. Con un poco de práctica se pueden conseguir generar live-cd basadas en Debian, totalmente personalizadas y así adaptadas a las necesidades de cada uno. 97

112 Linux: Dado que crear una live-cd, es como crear una nueva distribución de Linux, el conocimiento adquirido para desarrollar el proyecto sobre los entresijos de Linux, el Kernel[22] y más concretamente sobre la distribución Debian, han sido amplios y profundos. Inkscape y Gimp: Estas herramientas de diseño gráfico las he utilizado para diseñar los iconos, el logo y el fondo de pantalla de ClonUCA. También, para editar las capturas de pantalla que acompañan a esta memoria. L A TEX[2]: Esta memoria ha sido generada con LATEX, con lo que hemos tenido que aprender y profundizar en el conocimiento del mismo Objetivos Cumplidos Al terminar el desarrollo del proyecto se ha evaluado el cumpliiento del objetivo y los criterios establecidos en la sección 1.2 de esta memoria. A tenor de las pruebas realizadas durante el desarrollo del mismo, podemos asegurar que ClonUCA cumple con el objetivo general inicialmente marcado, así como con los criterios establecidos, tal y como se puede apreciar en la tabla 9.1. Aplicación Criterios ClonUCA (1) (2) (3) (4) (5) (6) (7) (8) (9) (10) Tabla 9.1: Evaluando ClonUCA respecto a los criterios establecidos: (1) Compatibilidad, (2) Sistemas de Ficheros, (3) Gestores de Arranque, (4) Copias de Seguridad, (5) Autonomía, (6) Estabilidad, (7) Eficiencia, (8) Usabilidad, (9) Adaptabilidad y (10) Licencia La muestra de que ClonUCA ha cumplido, con creces, con los objetivos marcados, es que durante todo este proceso de desarrollo, se ha convertido, para los técnicos especialistas de informática del Campus de Jerez, en la herramienta de referencia para realizar las clonaciones y copias de seguridad. Basta con mirar el número de equipos en los que se ha actuado en la realización de las pruebas. A parte de los objetivos técnicos, están los objetivos personales, y estos también han sido conseguidos Futuro del Proyecto El futuro del proyecto pasa por un mantenimiento y actualización continua, para que siga siendo una herramienta útil para la comunidad 1. A continuación se esbozan algunas líneas de trabajo que pueden ayudar en esta tarea: Un elemento interesante para mejorar la herramienta sería el de optimizar el kernel de ClonUCA. Este proceso tiene dos vías de trabajo. La primera consistiría en compilar un kernel adaptado y optimizado a las necesidades de ClonUCA, así obtendríamos una herramienta más liviana y más eficaz. Y la segunda sería la de utilizar el algoritmo de compresión lzma para comprimir el sistema de ficheros squash, que es el que se utiliza para trabajar con live-cd. Actualmente se utiliza el 1 El proyecto se encuentra a disposición de la comunidad en la Forja de RedIRIS: projects/clonuca/ 98

113 algoritmo gzip, pero con lzma se obtendría un ratio de compresión mucho mayor, por lo que el tamaño que ocuparía ClonUCA sería sensiblemente menor. Otro factor a tener en cuenta, es el de desarrollar ClonUCA para la plataforma de 64 bits. Ya que actualmente todos los procesadores soportan esa arquitectura y sería bueno aprovechar todo el potencial que ofrece migrar a 64 bits. Y por último, dado que los ordenadores de Apple[6] se están haciendo un hueco más importante, por lo menos en la Universidad de Cádiz, sería conveniente que ClonUCA pudiera dar una respuesta eficiente y eficaz en la gestión de clonaciones y copias de seguridad de estos equipos. 99

114 100

115 Apéndice A Montaje de un servidor PXE con ClonUCA A.1. Introducción En esta sección trataremos de argumentar qué sentido tiene montar un servidor PXE[26] con ClonUCA y cómo se realiza dicho proceso. A grandes rasgos un sistema PXE es un entorno de cliente/servidor, en los que los equipos clientes arrancan con lo que les ofrece el servidor PXE. El proceso se detalla a continuación: El firmware del cliente (una tarjeta de red) trata de encontrar un servicio de redirección PXE en la red para recabar información sobre los servidores de arranque PXE disponibles. Tras analizar la respuesta, el firmware solicitará al servidor de arranque apropiado el file path de un network bootstrap program(nbp), lo descargará en la memoria RAM del ordenador mediante TFTP, probablemente lo verificará, y finalmente lo ejecutará. En la figura A.1 se aprecia con más claridad el funcionamiento de un servidor PXE en general, y en particular, un servidor PXE con ClonUCA. Y qué sentido puede tener esto? Pues lo que se pretende es conseguir arrancar ClonUCA sin necesidad de utilizar un live-cd por los siguientes motivos: Alternativa al live-cd: Aunque un lector de CD es un periférico muy común en los ordenadores, se tiende a la desaparición del mismo, por diferentes motivos: lentitud de lectura, alta probabilidad de fallo de lectura, daños en la superficie del CD, etc... Por eso es interesante disponer de una alternativa para ejecutar ClonUCA, ya que nos podemos encontrar equipos sin unidad de CD o simplemente que no funciona. Centro de clonación masivo: Con un servidor PXE de ClonUCA y un switch se puede montar un sistema de clonación masivo, en el que poder realizar las operaciones de clonación de muchos equipos a la vez, de una forma rápida y eficaz. Gestión aulas de informática: Si los ordenadores de las aulas de informática arrancan por red contra un servidor PXE con ClonUCA, el proceso de clonación y restauración se agiliza mucho respecto a un arranque individual con live-cd. 101

116 Figura A.1: Esquema gráfico del funcionamiento de un Servidor PXE con ClonUCA A.2. Configuración servidor PXE A continuación explicaremos como montar un servidor PXE. Dado que ClonUCA está basado en un sistema Debian, vamos a seguir la misma línea, y vamos montar el servidor PXE en la última versión estable de Debian, la squeeze. Ni que decir tiene, que un servidor PXE se puede configurar en cualquier distribución, siendo el proceso muy parecido. El software que vamos a utilizar es el siguiente: dhcp3-server: Servidor DHCP para dar una dirección IP a los clientes. tftpd-hpa: Servidor FTP para ofrecer el NBP a los clientes. syslinux[24]: Contiene pxelinux que nos permite gestionar el arranque PXE. 102

117 lighttpd: Servidor HTTP para hacer disponible la imagen de ClonUCA a los clientes. Utilizamos el protocolo HTTP porque es más rápido que el FTP. nfs-kernel-server: Servidor NFS para poder crear un recurso de red NFS, que nos sirva para alojar las imágenes de clonación. Para instalar dicho software ejecutaremos los siguientes comandos: $ apt-get update $ apt-get upgrade $ apt-get install tftpd-hpa dhcp3-server lighttpd syslinux nfs-kernel-server Servidor DHCP Para que el servidor DHCP funcione, tiene que tener una dirección IP estática. Esto lo conseguimos modificando el fichero /etc/network/interfaces del siguiente modo: 1 # This file describes the network interfaces available on your system 2 # and how to activate them. For more information, see interfaces(5). 3 4 # The loopback network interface 5 auto lo 6 iface lo inet loopback 7 8 # The primary network interface 9 allow-hotplug eth0 10 iface eth0 inet static 11 address netmask gateway auto eth0 Una vez que tenemos el servidor con una dirección IP estática, ya podemos configurar el servidor DHCP. Para ello modificaremos el fichero /etc/dhcp3/dhcpd.conf añadiéndole las siguientes líneas: 1 # 2 # Sample configuration file for ISC dhcpd for Debian 3 # 4 # $Id: dhcpd.conf,v /05/21 00:07:44 peloy Exp $ 5 # authoritative; 9 10 subnet netmask { 11 range ; 12 option routers ; 13 option domain-name "domino.com"; 14 option domain-name-servers ; 15 next-server ; 16 filename "pxelinux.0"; 17 } Servidor FTP El directorio de trabajo del servidor FPT es: /srv/tftp, y es aquí donde debemos realizar algunas operaciones para configurar el servidor FTP. En primer lugar tendremos que copiar dos ficheros, provenientes del paquete syslinux, que nos servirán para configurar el arranque con un entorno gráfico. Para ello ejecutaremos los siguientes comandos: 103

118 $ cp /usr/lib/syslinux/pxelinux.0 /srv/tftp/ $ cp /usr/lib/syslinux/vesamenu.c32 /srv/tftp/ A continuación creamos el directorio de trabajo de PXE y el directorio donde vamos a guardar los ficheros de la live-cd de ClonUCA(filesystem.squashfs, vmlinuz y initrd.img). No hay que olvidarse de copiar la imagen que vamos a utilizar de fondo de pantalla, podemos utilizar la misma que viene en el live-cd: $ mkdir /srv/tftp/pxelinux.cfg $ mkdir /srv/tftp/clonuca $ cp filesystem.squashfs /srv/tftp/clonuca/ $ cp vmlinuz /srv/tftp/clonuca/ $ cp initrd.img /srv/tftp/clonuca/ $ cp splash.png /srv/tftp En el directorio de trabajo tenemos que generar el siguiente fichero: /srv/tftp/pxelinux.cfg/default, el cual nos permitirá configurar el arranque PXE. A continuación se muestra el listado de dicho fichero: 1 #Fichero configuracion PXE 2 3 default vesamenu.c32 4 timeout 70 5 prompt 0 6 noescape MENU MARGIN 5 9 MENU COLOR UNSEL 7;32;41 #c # MENU COLOR TIMEOUT_MSG 7;32;41 #c # MENU COLOR TIMEOUT 7;32;41 #c # MENU background splash.png ALOWOPTIONS MENU TITLE SERVIDOR PXE CON CLONUCA label local 20 MENU LABEL Arrancamos el sistema local 21 localboot label clonuca_modoseguro 24 MENU LABEL ClonUCA a modo seguro 25 KERNEL clonuca/vmlinuz 26 APPEND initrd=clonuca/initrd.img boot=live live-config union=aufs noswap 27 nopromt fetch= 28 username=root hostname=clonuca noapic noapm nodma nomce nolapic 29 nomodeset nosmp vga=normal toram label clonuca 32 MENU LABEL ClonUCA 33 KERNEL clonuca/vmlinuz 34 APPEND initrd=clonuca/initrd.img boot=live union=aufs noswap nopromt 35 vga=788 toram fetch= 36 username=root hostname=clonuca Servidor HTTP Para configurar el servidor HTTP lo único que tenemos que hacer es indicarle que va a utilizar el mismo directorio de trabajo que el servidor FTP. Esto lo conseguimos modificando el fichero (etc(lighttpd/ligttpd.conf) añadiéndole la siguiente línea: 104

119 1 ## a static document-root, for virtual-hosting take look at the 2 ## server.virtual-* options 3 4 server.document-root = "/srv/tftp" Con todo lo explicado hasta ahora tendríamos un servidor PXE con ClonUCA plenamente funcional, pero podemos añadir una característica importante para hacerlo más completo: Dedicar un espacio de disco del servidor PXE para almacenar las imágenes de clonación. Esto lo podríamos conseguir configurando un servidor NFS, SAMBA o SSH. Aquí lo vamos a explicar con el servidor NFS. Servidor NFS Lo único que tenemos que asegurarnos es de tener un directorio con espacio suficiente y con permiso de escritura para todos los usuarios. Una vez que tenemos esto y suponiendo que al directorio lo hemos llamado /almacen_imagenes, modificaremos el fichero /etc/exports añadiéndole la siguiente línea: 1 # /etc/exports: the access control list for filesystems which may be exported 2 # to NFS clients. See exports(5). 3 4 /almacen_imagenes / (rw,sync,no_subtree_check) 105

120 106

121 Apéndice B Creación de un live-usb con ClonUCA B.1. Introducción El por qué de configurar una memoria USB para que pueda ser utilizada como una live-usb ClonUCA responde a la necesidad de dar respuesta al mayor número de situaciones a las que se tiene que enfrentar ClonUCA. En la actualidad, se esta comprobando que las unidades de CD tienen una tendencia a desaparecer de los equipos informáticos, como hemos explicado en el capítulo anterior. Wn cambio, todos los ordenadores vienen equipados con entradas USB, con la capacidad de arrancar desde un dispositivo USB. Por tanto es muy interesante poder implementar una live-usb con ClonUCA. El poder utilizar una memoria USB para arrancar ClonUCA, nos abre una nueva vía de trabajo, y es la de poder utilizarla como lugar de almacenamiento para las imágenes de clonación y de los backups. Y esto es posible por dos razones fundamentales: La primera son las tasas de velocidad de lectura y escritura que alcanza la memorias USB, hacen posible que el proceso se realice en un tiempo razonable. Y la segunda razón, es la capacidad de almacenamiento de las memorias USB, actualmente podemos encontrar memorias con unas capacidades que oscilan entre los 8 y 32 GB, y el live- CD de ClonUCA no ocupa más de 130 MiB, por lo que es perfectamente asumible crear una live-usb con ClonUCA. Y si además, la memoria USB es lo suficientemente grande, podemos utilizarla para guardar las imágenes de clonación o los backups de un ordenador. B.2. Configurar live-usb con ClonUCA Existen multitud de formas de crear un live-usb. Después de estudiarlas nos hemos decantado por unas herramientas que podemos instalar en la versión squeeze de Debian. La razón fundamental es la de ser coherente y seguir todo el desarrollo del proyecto dentro del mismo entorno de software. Las herramientas que vamos a utilizar son las siguientes: Gparted[10]: Es una aplicación que nos permite gestionar particiones de dispositivos de almacenamiento. UNetbootin[18]: Es una utilidad para crear live-usb. syslinux: Contiene vesamenu.c32 que nos permite configurar el arranque de live-usb en modo gráfico. 107

122 Para instalar estas herramientas en una versión squeeze de Debian, debemos ejecutar los siguientes comandos: $ apt-get update $ apt-get upgrade $ apt-get install gparted unetbootin syslinux GParted Con GParted vamos a conseguir realizar dos particiones en una memoria de USB, con el propósito de utilizar una para instalar ClonUCA y la otra como almacén, para guardar las imágenes de clonación y los backups. En nuestro caso hemos utilizado una memoria USB de 32 GB, con dos particiones: la primera de 512 MB y el resto para la segunda partición. Hay que indicar que las particiones las hemos formateado en FAT32, por ser el sistema de ficheros con el que trabaja UNetbootin. A continuación se muestra una captura del proceso de particionamiento con GParted (figura B.1). Figura B.1: Captura de pantalla del proceso de particionamiento de una memoria USB UNetbootin Una vez que ya tenemos la memoria USB bien particionada, ya podemos crear una live-usb con ClonUCA. Para ello utilizaremos la herramienta UNetbootin. Es muy fácil de utilizar (figura B.2), en nuestro caso hay que seguir los siguientes pasos: 1 o Marcar la opción DiscoImagen. 2 o Elegir ISO, como formato de imágenes. 108

123 3 o Buscar una imagen ISO de ClonUCA que queramos utilizar en el live-usb. 4 o Indicar que partición del USB vamos a utilizar. Figura B.2: Captura de pantalla de la aplicación UNetbootin Una vez que ha concluido el proceso ya tenemos un live-usb con ClonUCA plenamente funcional, pero todavía queda realizar algunos cambios para que tenga coherencia con la identidad visual de ClonUCA. Estos consisten básicamente en cambiar el modo texto del arranque por un modo gráfico, en el que podamos poner una imagen de splash con el logo de ClonUCA. Para ello ejecutaremos los siguientes comandos: $ rm /dev/sdb1/menu.c32 $ cp /usr/lib/syslinux/vesamenu.c32 /dev/sdb1 $ cp splash.png /dev/sdb1 También cambiaremos el menú de arranque. Para ello modificaremos el fichero /dev/sdb1/syslinux.cfg con el siguiente contenido. 1 # syslinux.cfg 2 # configuracion de menu del live-usb ClonUCA 3 4 default vesamenu.c32 5 prompt 0 6 timeout 50 7 noescape #MENU MARGIN 5 10 MENU BACKGROUND splash.png 11 # Set the color for unselected menu item and timout message 12 MENU COLOR UNSEL 7;32;41 #c # MENU COLOR TIMEOUT_MSG 7;32;41 #c # MENU COLOR TIMEOUT 7;32;41 #c # MENU COLOR HELP 7;32;41 #c # MENU TITLE ClonUCA desde USB label ClonUCA 20 MENU LABEL ClonUCA to RAM 21 kernel /ubnkern 109

124 22 append initrd=/ubninit boot=live config username=root 23 hostname=clonuca quiet toram vga= label ClonUCA modo seguro 26 MENU LABEL ClonUCA to RAM en modo seguro 27 kernel /live/vmlinuz 28 append initrd=/ubninit boot=live config username=root 29 hostname=clonuca noapic noapm nodma nomce nolapic 30 nomodeset nosmp vga=normal toram Con esto obtenemos una live-usb con la identidad visual de ClonUCA. 110

125 Apéndice C Manual de usuario C.1. Introducción En en este capítulo se explicará detalladamente como se realizan todas las funciones de ClonUCA. En primer lugar comentar que ClonUCA puede iniciarse de tres formas distintas, las cuales, ya han sido explicadas en los capítulos anteriores: Live-CD: Servidor-PXE: Live-USB: Una vez iniciado ClonUCA nos aparece una pantalla como la que se muestra en la figura C.1 Figura C.1: Manual de usuario: pantalla inicial de ClonUCA 111

126 En la barra de tareas, que se encuentra en la parte inferior de la pantalla, nos encontramos con los siguientes iconos: Menú principal de ClonUCA. Aunque el menú principal es arrancado automáticamente al iniciar ClonUCA, podemos lanzarlo desde aquí. Manual de usuario de ClonUCA, al cliquear en este icono se abre el manual de usuario. Gparted: gestión de particiones. Con esta utilidad podemos gestionar las particiones de los discos duros: modificar el tamaño, eliminar o crear particiones, etc. Apagar equipo. Al cliquear en el icono nos aparecerá una ventana con las opciones de apagar o reiniciar el equipo. C.2. Menú Principal El otro elemento que nos encontramos en la pantalla inicial es una ventana que contiene el menú principal de ClonUCA. Este menú nos muestra las principales funciones que puede desempeñar ClonUCA, siendo estas las siguientes: Guardar Imagen: Eligiendo esta opción nos abrirá una ventana donde aparecen todas las opciones de la función guardar una imagen. Restaurar Imagen: Esta opción nos permitirá elegir todas las opciones relacionadas con la función de restaurar una imagen. Servidor de Clonación: Va a establecer el equipo como un servidor de clonación, y nos permitirá elegir qué protocolo va a utilizar el servidor para realizar la clonación. Cliente de Clonación: Establece el equipo como cliente de clonación, es decir va a recibir la clonación desde un servidor. También hay qué elegir que protocolo va a utilizar, que tendrá que ser el mismo que utilice el servidor. Clonación Local: Nos permitirá realizar clonaciones entre dispositivos locales. Sistema de Backup: Lanza una ventana donde aparecen todas las opciones de las funciones de backup y de restauración de backup. A continuación se irá detallando cada una de las opciones expuestas. 112

127 C.3. Guardar Imagen Al elegir la función Guardar Imagen, nos aparecerá la ventana indicada en la figura C.2. En ella podemos elegir el lugar donde vamos a guardar la imagen de clonación: Local: Cuando queramos guardar la imagen en un dispositivo de almacenamiento local, ya sea una partición de un disco duro, una memoria USB o un disco duro USB. NFS: Si el equipo tiene red y disponemos de un servidor Linux con una carpeta compartida en NFS, podemos utilizarla para almacenar la imagen de clonación. SSH: Es el mismo caso que el anterior, salvo que, para utilizar un recurso compartido por SSH hay que tener una cuenta de usuario. SAMBA: En este caso, para almacenar la imagen de clonación se ha elegido el recurso compartido por SAMBA. Este viene dado principalmente por un servidor Windows, aunque también se puede configurar un servidor Linux. Figura C.2: Manual de usuario: función Guardar Imagen Guardar Imagen en Local En la ventana de la función Guardar Imagen en Local, representada en la figura C.3, nos aparecen los siguientes elementos: Dispositivo Origen: Primero, el sistema nos muestra todos los dispositivos locales que hay en el equipo, y hay que elegir uno. Partición Destino: Segundo, el sistema nos muestra las particiones locales que podemos utilizar para guardar la imagen del dispositivo origen. 113

128 Algoritmo de compresión: También podemos elegir si queremos utilizar un algoritmo de compresión. Por defecto se utiliza el algoritmo gzip, porque ofrece el mejor ratio de compresión y velocidad. Pero se puede utilizar el algoritmo lzma si se quiere conseguir que la imagen tenga un tamaño menor, esto puede ser interesante si no hay mucho espacio disponible para almacenar la imagen, pero al recurrir a este algoritmo, el proceso de creación se ralentiza mucho. También se puede optar por no comprimir la imagen. En este caso el proceso es muy rápido pero el tamaño de la imagen es muy grande. Esto es apropiado cuando no tengamos problemas de espacio de almacenamiento y queramos un proceso rápido. Borrar pagefile.sys y hiberfile.sys: Por último, si estamos haciendo una imagen de un sistema Windows, podemos borrar el pagefile.sys y el hiberfile.sys, ya que estos ficheros ocupan mucho espacio. Con esto obtenemos una imagen más pequeña y a la hora de restaurarla no hay problema, porque el Windows restaura estos ficheros cuando inicia el sistema. Figura C.3: Manual de usuario: función Guardar Imagen en Local Cuando hayamos pulsado el botón Siguiente el sistema montará la Partición Destino en la carpeta local almacen. A continuación, nos mostrará una ventana (figura C.4) para crear un directorio, en el cual guardaremos la imagen de clonación. Hay que indicar que al directorio hay que darle un nombre representativo, por ejemplo: el nombre del equipo + sistema operativo + fecha. Para que el día que se vaya a restaurar la imagen podamos encontrarla con facilidad. 114

129 Figura C.4: Manual de usuario: Creamos un directorio en almacen Una vez se crea el directorio se lanza el proceso de creación de la imagen, como se aprecia en la siguiente figura C.5. Al finalizar el sistema muestra un mensaje de Proceso Terminado. Figura C.5: Manual de usuario: proceso de creación de una imagen con partclone 115

130 Guardar Imagen en NFS Si disponemos de un recurso de red NFS en un entorno Linux, podemos utilizarlo para almacenar las imágenes de clonación. Esta función viene representada en la figura C.6, en ella aparecen los siguientes elementos: Dispositivo Origen: Primero, el sistema nos muestra todos los dispositivos locales que hay en el equipo, y hay que elegir uno. Servidor NFS: Segundo, debemos introducir la dirección IP o el nombre del servidor. Recurso NFS: Tercero, introduciremos el nombre del recurso NFS que vamos a utilizar de almacén. Algoritmo de compresión: También podemos elegir si queremos utilizar un algoritmo de compresión. En este caso, como en los casos en los que se guarda una imagen de clonación en un recurso local, puede ser interesante elegir el algoritmo lzma. El motivo radica en que normalmente se pueden restaurar a la vez más de un equipo, por tanto, si conseguimos que la imagen sea lo más pequeña posible, conseguiremos que el proceso de restauración sea más rápido, ya que el servidor tendrá que enviar menos información por la red. Utilizaremos el algoritmo gzip cuando el proceso de restauración sea de uno en uno, y por último, no comprimiremos la imagen cuando no haya problemas de espacio en el recurso de red y cuando todo la red sea gigabit. Borrar pagefile.sys y hiberfile.sys: Esta opción ya ha sido explicada en el apartado anterior. Figura C.6: Manual de usuario: función Guardar Imagen en recurso NFS Guardar Imagen en SSH En este caso, si disponemos de un recurso de red SSH en un entorno Linux lo podemos utilizar para guardar las imágenes de clonación. Esta función esta representada en la siguiente figura C

131 Figura C.7: Manual de usuario: función Guardar Imagen en recurso SSH Como podemos apreciar existen ciertos elementos que hemos visto con anterioridad. Para no repetir la misma información sólo se van a describir aquellos elementos novedosos, los demás son los mismos que en la función de guardar en recurso NFS, sólo hay que cambiar NFS por SSH: Usuario y Contraseña: Para utilizar un recurso SSH, es necesario identificarse con el servidor SSH, por tanto es imprescindible tener una cuenta, con un usuario y contraseña. Guardar Imagen en SAMBA Si nos encontramos en un entorno Windows, en el que existe un equipo Windows que comparte una carpeta, o en un entorno Linux en el que se comparte una carpeta por SAMBA, podemos utilizar dicha carpeta para almacenar las imágenes de clonación. Esta función se representa en la figura C.8. El interfaz de la función es el mismo que en el caso de un recurso SSH, y la única diferencia es que para hacer uso de un recurso SAMBA no es necesario identificarse siempre. Por tanto no es obligatorio introducir el usuario y contraseña, salvo que el recurso lo requiera. 117

132 Figura C.8: Manual de usuario: función Guardar Imagen en recurso SMB C.4. Restaurar Imagen El proceso de restaurar una imagen es el proceso inverso al de guardar una imagen, por tanto, las figuras que representan a esta función son prácticamente idénticas a la función de guardar una imagen, salvo por la excepciones que a continuación se comentan: Dispositivo Destino: En este caso tenemos que elegir qué dispositivo local vamos a restaurar. Algoritmo de Compresión: En el proceso de restaurar una imagen no hay que elegir el algoritmo de compresión a utilizar, ya que el sistema detecta automáticamente el algoritmo utilizado en la compresión de la imagen y lo utiliza en la restauración. Borrar pagefile.sys y hiberfil.sys: Como en el caso anterior, no da lugar a borrar los ficheros pagefile.sys y hiberfil.sys, por tanto esta opción no aparece en el proceso de restauración de imagen. Crear directorio: En este caso no hay que crear un directorio para guardar la imagen, sino hay que elegir uno que contenga una imagen de clonación para restaurarla. A continuación se muestran las figuras que componen la función de Restaurar Imagen: Figura C.9: Nos muestra los lugares donde puede estar almacenada la imagen, para su restauración. Hay que elegir uno de ellos. Figura C.10: La restauración se va a realizar desde una imagen que se encuentra almacenada en un dispositivo local (partición, memoria USB o un disco duro USB). 118

133 Figura C.9: Manual de usuario: función Restaurar Imagen Figura C.10: Manual de usuario: función Restaurar Imagen desde Local 119

134 Figura C.11: Muestra los pasos a seguir para restaurar un dispositivo local desde una imagen de clonación que se encuentra almacenada en un recurso de red NFS. Figura C.12: En este caso la imagen se encuentra almacenada en un recurso de red SSH. Figura C.13: Es el caso similar a los anteriores, salvo que, el recurso de red es SAMBA. Figura C.14: Y por último, una vez que se ha elegido la imagen a restaurar, se lanza el proceso de restauración con partclone, como se aprecia en la figura. Cuando el proceso ha terminado el sistema muestra un mensaje de Proceso Terminado. Figura C.11: Manual de usuario: función Restaurar Imagen desde recurso NFS 120

135 Figura C.12: Manual de usuario: función Restaurar Imagen desde recurso SSH Figura C.13: Manual de usuario: función Restaurar Imagen desde recurso SAMBA 121

136 Figura C.14: Manual de usuario: proceso de restauración de un partición con partclone C.5. Servidor de Clonación Al elegir esta opción, estamos estableciendo que el equipo donde se esta ejecutando ClonUCA va a ejercer la función de servir por red la clonación de un dispositivo local. Así de este modo, podemos clonar por red el dispositivo de un equipo cliente. En este caso no se genera ninguna imagen de clonación, que posteriormente tengamos que guardar, sino que directamente se clona un dispositivo local de un cliente con la información recibida directamente del dispositivo local del servidor. Existen tres protocolos diferentes a la hora de clonar por red, siendo estos los siguientes: Unicast: Conocido como protocolo punto a punto, en este caso la clonación por red se establece entre un servidor y un cliente, es decir, se establece una conexión directa entre el servidor y el cliente, en la que el servidor manda la clonación directamente al cliente, y este clona su dispositivo local con la información mandada por el servidor. Multicast: También conocido como protocolo multipunto, en el que el servidor puede mandar la clonación a una multitud de clientes, sin que tenga que mandar información repetida. La forma de funcionar de este protocolo es que el servidor manda un único paquete de información, pero todos los clientes reciben ese paquete sin que el servidor tenga que mandar una paquete por cada cliente. Este protocolo es muy eficaz cuando se quieren clonar multitud de equipos, pero hay redes que no lo soportan. PeerToPeer o P2P: Este protocolo se utiliza cuando hay que clonar muchos equipos y la red no soporta realizar una clonación por multicast. A continuación se muestra en la figura C.15 las opciones detalladas anteriormente. 122

137 Figura C.15: Manual de usuario: función Servidor de Clonación Servidor de Clonación por Unicast En la siguiente figura C.16 se muestra el proceso de un servidor de clonación que utiliza el protocolo unicast. Figura C.16: Manual de usuario: función Servidor de Clonación por Unicast 123

138 A continuación se van a detallar las opciones indicadas en la figura C.16: Dispositivo Origen: Elegimos qué dispositivo local va a ser el origen de la clonación. Borrar pagefile.sys y hiberfil.sys: Si el dispositivo local contiene un sistema Windows, podemos borrar estos ficheros para disminuir el tamaño de la clonación, y así conseguir un proceso más efectivo. Algoritmo de compresión: En este caso solo se presentan dos opciones: utilizar el algoritmo gzip o no usar compresión. Utilizaremos la clonación sin compresión cuando el ancho de banda de la red desde el servidor hasta el cliente sea por lo menos gigabit, así conseguimos una clonación muy rápida. En los demás casos, cuando la red sea una Ethernet a 100 Mb/s, utilizaremos la compresión gzip. Se descarta el uso del algoritmo lzma porque requiere mucho trabajo del procesador, resultando una tasa de transferencia muy baja. Dirección IP del servidor: Se muestra la dirección IP del servidor, para que la utilicemos en el proceso del cliente de clonación por unicast. EMPEZAMOS: Cuando pulsamos en este botón, el servidor publica los parámetros básicos de la clonación (dispositivo, tamaño del dispositivo, sistema de ficheros, algoritmo de compresión, etc) y se queda esperando a que el cliente establezca contacto para iniciar el proceso de clonación. Cuando el cliente acepta el proceso de clonación, el servidor mandará por la red, utilizando el protocolo unicast, la clonación del dispositivo elegido, como se puede apreciar el la siguiente figura C.17. Figura C.17: Manual de usuario: proceso de envío de clonación unicast con partclone Una vez concluido el proceso el sistema muestra una ventana con un mensaje de Proceso Terminado. 124

139 Servidor de Clonación por Multicast En la siguiente figura C.18 se muestra el proceso de un servidor de clonación a través de un protocolo multicast. Figura C.18: Manual de usuario: función Servidor de Clonación por Multicast Como se puede apreciar en la figura C.18, es un proceso similar a la clonación por unicast, por lo que solo se van a detallar aquellos elementos que difieran de este último: Grupo Multicast: para poder utilizar este protocolo requiere una dirección IP especial, que se conoce como grupo multicast. De acuerdo al RFC 3171[4] las direcciones desde la a la están destinadas para ser direcciones de multicast. Y es una dirección comprendida en este rango la que tenemos que utilizar para el grupo multicast. EMPEZAMOS: En este caso el procedimiento es inverso, es decir, cuando todos los clientes estén preparados se quedan esperando a que el servidor inicie el proceso, y es en este instante cuando podemos pulsar el botón de EMPEZAMOS. Servidor de Clonación por P2P El proceso de clonación utilizando el protocolo P2P es un tanto especial, ya que no es un sistema de clonación por red puro, debido a que no se puede generar un fichero.torrent que incluya multitud de ficheros. Dado que las clonaciones suelen hacerse de sistemas operativos con multitud de ficheros, queda descartado este procedimiento. Para solucionar este problema se ha optado por un sistema híbrido, en el que primero se genera una imagen de clonación y se guarda en una partición local, y luego, con esta imagen se genera un fichero.torrent. Una vez que tenemos el.torrent ya podemos utilizar el protocolo P2P para distribuir la imagen de clonación. 125

140 A continuación se detallan las opciones más significativas del proceso del servidor de clonación por P2P, que viene representado en la figura C.19: Partición caché: En primer lugar elegimos qué partición vamos a utilizar de caché, en la que guardaremos la imagen de clonación del dispositivo elegido. Posteriormente se generará el fichero.torrent a partir de la imagen guardada en la caché. Algoritmo de compresión: En este caso queda descartado no utilizar ningún algoritmo de compresión, ya que se podría colapsar la red en la distribución de la imagen. Por ello, utilizaremos el algoritmo gzip si la red es lo suficientemente buena, o si no hay problemas de espacio en la partición caché. En cualquier otro caso, utilizaremos el algoritmo lzma, indicado para redes lentas y para cuando el espacio libre en la caché sea un problema. Figura C.19: Manual de usuario: función Servidor de Clonación por P2P Para iniciar el proceso pulsamos el botón Siguiente, entonces se crea una imagen de clonación, del mismo modo que se ha comentado en el apartado: Guardar imagen de clonación, figura C.5. A continuación, se genera el fichero.torrent. Se pone a disposición de los clientes la información de la imagen de clonación, y se chequea el fichero.torrent, como se ilustra en la figura C

141 Figura C.20: Manual de usuario: El servidor P2P comprueba el fichero.torrent Una vez que se ha chequeado el fichero, el servidor ya puede iniciar el proceso de transmisión por P2P. Es conveniente esperar a que todos los clientes hayan obtenido su copia de la imagen, para dar por finalizado el proceso en el servidor. Para ello pulsamos el botón FIN que se indica en la C.21. Figura C.21: Manual de usuario: El servidor P2P termina el proceso de envío por P2P C.6. Cliente de Clonación Al elegir esta opción, establecemos que el equipo donde se esta ejecutando ClonUCA va a recibir por red la clonación de un dispositivo distribuido por un servidor. Es el proceso complementario al servidor de clonación, y por tanto en ambos procesos hay que utilizar el mismo protocolo de red. Como se puede apreciar en la figura C.22, las opciones son las mismas que en la función del servidor, por lo que se omite su explicación. 127

142 Figura C.22: Manual de usuario: función Cliente de Clonación Cliente de Clonación por Unicast Una vez establecido el equipo como un cliente de clonación por medio de unicast, tenemos que indicarle al sistema la información necesaria para realizar la función, siendo esta la siguiente: Dispositivo Destino: Primero debemos elegir qué dispositivo vamos a clonar. Hay que indicar, que el dispositivo origen del servidor y el dispositivo destino tienen que ser compatibles para realizar la clonación, es decir, si el origen es un disco duro completo, el destino también, si el origen es una partición, el destino también. Y por supuesto, el dispositivo destino no puede ser menor que el dispositivo origen. Dirección IP del Servidor: También debemos conocer el nombre o la dirección IP del servidor, para poder obtener información referente a la clonación: tipo de dispositivo, tamaño del dispositivo, sistema de ficheros, tabla de particiones, etc... Estos elementos los podemos contemplar en la figura C.23. Una vez que lanzamos el proceso, al pulsar el botón Siguiente, el cliente compara la información del dispositivo origen obtenido del servidor con la información de su dispositivo destino, y evalúa si la clonación es posible. En el caso negativo, el cliente aborta el proceso y manda una señal de error al servidor para que también aborte la clonación. En el caso afirmativo, el cliente realiza dos operaciones: 1 o ) manda una señal al servidor para que inicie el proceso de clonación y 2 o ) se queda esperando a que el servidor envíe la clonación, tal y como podemos apreciar en el figura C

143 Figura C.23: Manual de usuario: función Cliente de Clonación por Unicast Figura C.24: Manual de usuario: proceso de recibir clonación por unicast con partclone 129

144 Cliente de Clonación por Multicast Como se puede comprobar las figuras C.25 y C.23 son idénticas, es decir, tenemos que indicarle al sistema la misma información para realizar la clonación. Lo único que cambia es que cuando pulsamos el botón Siguiente, el cliente se queda a la espera de que el servidor empiece a mandar la clonación del dispositivo origen. Figura C.25: Manual de usuario: función Cliente de Clonación por Multicast Cliente de Clonación por P2P Para que la función cliente de clonación por P2P funcione correctamente, tendremos que indicarle los siguientes valores: Dirección IP del Traker: El cliente tiene que conocer donde se encuentra la información para realizar la clonación, es decir, qué características tiene el disco duro origen (tamaño, sistema de ficheros, algoritmo de compresión, etc...) y cual es el fichero.torrent que va a utilizar para para descargarse por Peer To Peer la imagen de clonación. Toda esta información se encuentra publicada en el servidor, y por ello el cliente tiene que conocer su dirección IP para poder obtenerla. Disco duro destino: Después hay que elegir qué disco duro local es el que vamos a restaurar con la imagen de clonación del servidor. El sistema muestra los discos duros disponibles y hay que elegir uno. Después de realizar la elección, el sistema comprueba la viabilidad del proceso de clonación, confrontando la información obtenida del servidor con la información recabada del disco duro local. 130

145 En la figura C.26, se representan las opciones comentadas anteriormente. Figura C.26: Manual de usuario: función Cliente de Clonación por P2P Si el proceso de clonación es viable, el cliente realiza los siguientes pasos: 1. El cliente crea una nueva tabla de particiones en el disco local, con la tabla de particiones obtenida del servidor. 2. Establece la partición caché y la formatea según la información del servidor. 3. Lanza el cliente Bittorrent para descargarse en la caché la imagen de clonación del servidor. Este proceso lo podemos apreciar en la figura C Cuando se ha terminado de descargar la imagen de clonación, el sistema se queda como se aprecia en la figura C.28. Ahora es conveniente esperar a que todos los clientes hayan terminado antes de continuar el proceso, ya que el proceso de descarga se realizará más rápido. Esto es debido a la característica del protocolo Peer To Peer de compartir todo aquello que hemos descargado, así los clientes que todavía no hayan terminado, podrán descargar lo que falta desde un mayor número de ubicaciones y por tanto terminarán antes. 5. Cuando todos los clientes hayan terminado de descargar la imagen, pulsamos el botón SIGUIENTE, y es ahora cuando se restaura el disco duro elegido con la imagen de clonación de la caché. Este es el mismo proceso de Restauración de imágenes descrito con anterioridad, reflejado en la figura C

146 Figura C.27: Manual de usuario: El cliente esta descargando con Bittorrent la imagen de clonación Figura C.28: Manual de usuario: El cliente ha terminado de descargar la imagen de clonación C.7. Clonación Local La Clonación Local nos va a permitir realizar clonaciones entre dispositivos locales, ya sea, entre discos duros o entre particiones. Las opciones de este proceso se pueden ver la figura C.29 y se detallan a continuación: Dispositivo Origen: El sistema nos muestra todos los dispositivos disponibles en el equipo, tanto discos duros como particiones, y hay que elegir uno de ellos. Dispositivo Destino: En función del dispositivo origen elegido, el sistema nos muestra los posibles dispositivos destino, es decir, si el dispositivo origen es un disco duro el sistema nos mostrará los discos duros disponibles para que sea dispositivo destino. 132

147 Borrar pagefile.sys e hiberfil.sys: Si estamos clonando dispositivos con sistemas operativos Windows, podemos realizar la clonación más rápido si omitimos los ficheros pagefile.sys e hiberfil.sys en la clonación. Para ello marcaremos esta opción. Figura C.29: Manual de usuario: función de Clonación Local Hay que indicar que en este proceso no se utiliza ningún algoritmo de compresión, ya que resulta mucho más rápido realizar la clonación directa. Esto es debido a las altas velocidades de transferencias entre discos duros locales. C.8. Sistema de Backup El sistema de Backup nos va a permitir realizar copias de seguridad, tanto normales como incrementales, y restauración de las copias de seguridad. Esta utilidad es complementaria a los procesos de guardar y restaurar imágenes de clonación, ya que está dirigida a trabajar con directorios concretos ("Mis Documentos", Escritorio, /home/usuario", etc...) en vez de con discos duros o particiones. De esto se deduce que el proceso es muy similar a los procesos de guardar y restaurar imágenes de clonación. Las opciones que nos aparecen en la ventana principal del Sistema de Backup las podemos ver en la figura C.30. A continuación detallamos cada una de las opciones: Backup/Restore: Lo primero que tenemos que elegir es qué operación deseamos realizar. Si queremos crear una copia de seguridad de una carpeta elegimos la opción Backup, pero si queremos restaurar una copia de seguridad elegiremos la opción Restore. 133

148 Almacén local: Elegiremos esta opción si la copia de seguridad que queremos crear o restaurar ha sido o va a ser almacenada en dispositivo local, ya sea una partición, una memoria USB o un disco duro externo. Almacén de red en NFS: En este caso, como en los siguientes, la copia de seguridad va a estar almacenada en un recurso de red. Concretamente utilizaremos una recurso NFS proporcionado por un servidor Linux. Almacén de red en SSH: Aquí el recurso lo proporciona un servidor SSH de un entorno Linux, que requiere autentificación para ser utilizado. Almacén de red en SAMBA: Si el recurso lo proporciona un servidor Windows, utilizaremos esta opción. Figura C.30: Manual de usuario: función de Sistema de Backup Backup en Almacén Local Los pasos a seguir para realizar un Backup en un dispositivo local vienen representados en la figura C.31, y se detallan a continuación: Dispositivo Almacén: En primer lugar, el sistema nos nuestra los dispositivos disponibles. Y tendremos que elegir cuál de ellos vamos a utilizar para almacenar la copia de seguridad. Una vez montado el dispositivo en almacen, el sistema nos muestra los directorios existentes en almacen (ver figura C.4). Si creamos un directorio nuevo, realizaremos una copia de seguridad, pero si elegimos un directorio existente que contenga una copia de seguridad, entonces realizaremos una copia de seguridad incremental. 134

149 Dispositivo Origen: Una vez establecido dónde vamos a guardar la copia de seguridad, hay que elegir en qué dispositivo se encuentra la carpeta de la que queremos tener una copia de seguridad. Para ello el sistema nos muestra los dispositivos disponibles. Carpeta de Backup: A continuación hay que elegir la carpeta origen de la copia de seguridad. Para iniciar el proceso en sí, hay que pulsar el botón EMPEZAMOS. Figura C.31: Manual de usuario: función de Backup en Almacén Local Backup en Recurso de Red: NFS, SSH o SAMBA El proceso para realizar una copia de seguridad y guardarla en un recurso de red, se divide en dos pasos: El primero consiste en montar el recurso de red en almacen, según el protocolo elegido. Como se puede apreciar en las figuras, el proceso es casi idéntico a los detallados anteriormente: NFS: Montamos el almacen en un recurso de red NFS, figura C.32. SSH: Montamos el almacen en un recurso de red SSH, figura C.33. SAMBA: Y por último, montamos el almacen en un recurso de red SAMBA, figura C.34. Y el segundo paso, una vez montado el recurso de red en almacen, es el de realizar la copia de seguridad en sí, tal y como se ha detallado en el caso de un almacén local, como podemos comprobar en la figura C

150 Figura C.32: Manual de usuario: función de Backup en Almacén NFS Figura C.33: Manual de usuario: función de Backup en Almacén SSH 136

151 Figura C.34: Manual de usuario: función de Backup en Almacén SAMBA Figura C.35: Manual de usuario: función de Backup en Almacén de Red 137

152 Restore desde Almacén Local El proceso de restauración de una copia de seguridad, es el proceso inverso al de creación de una copia de seguridad, y por tanto tienen muchos elementos en común. A continuación se va a detallar cómo se restaura una copia de seguridad que se encuentra almacenada en un dispositivo local, figura C.36: Dispositivo Local: En primer lugar tendremos que elegir en qué dispositivo local hemos guardado la copia de seguridad. El sistema montará dicho dispositivo en almacen. Fichero Backup: Después, tendremos que buscar en almacen el fichero de copia de seguridad que queremos restaurar, tal y como se aprecia en la figura C.37. Dispositivo Destino: A continuación, debemos elegir el dispositivo donde se encuentra el directorio que queremos restaurar. Directorio a Restaurar: Y por último, elegimos el directorio objeto de la restauración. Para iniciar el proceso en sí, hay que pulsar el botón EMPEZAMOS. Figura C.36: Manual de usuario: función de Restore desde Almacén Local 138

153 Figura C.37: Manual de usuario: función para elegir el fichero de Backup para su restauración Restore desde Recurso de Red: NFS, SSH o SAMBA Al igual que el proceso de creación de una copia de seguridad, la restauración desde un recurso de red se divide en dos pasos: El primero consiste en montar el recurso de red en almacen según el protocolo elegido, tal y como se ha explicado anteriormente (ver figuras C.32, C.33 y C.34). Y el segundo paso, una vez que tenemos montando el almacen, se procede del mismo modo que en una restauración desde un almacén local, como se aprecia en la figura C.38. Figura C.38: Manual de usuario: función de Restore desde Almacén de Red 139