UNIVERSIDAD DE CASTILLA-LA MANCHA ... - Grupo ARCO
UNIVERSIDAD DE CASTILLA-LA MANCHA ... - Grupo ARCO UNIVERSIDAD DE CASTILLA-LA MANCHA ... - Grupo ARCO
82 CAPÍTULO 6. HYDRA 6.2.2. Agente de Base de Datos Para interactuar con la base de datos, se incorporó al Manager un agente que se encarga de hacer que dichas operaciones sean transparentes. Es decir, el Manager no ejecuta sentencias SQL, si no que invoca operaciones para almacenar Despliegues, obtener Imágenes, etc. Si en un futuro cambiase el modelo de la base de datos, o se utilizara otra forma de almacenamiento de la información, tan sólo el agente se vería afectado. Sólo habría que programar un nuevo agente que fuera capaz de manejar el nuevo modelo de persistencia. 6.2.3. Preparación de imágenes Una de las tareas más importantes que realiza el Manager es la preparación de las Imágenes para su distribución. La herramienta utilizada para el despliegue de las Imágenes es IcePatch2, que es un servicio del middleware Ice. IcePatch2 permite ahorrar ancho de banda de dos maneras: en primer lugar, no transmite los ficheros tal cual los encuentra, sino que los comprime antes con bzip. Por otra parte, una vez comprimido cada fichero, calcula el código MD5 [Riv92] correspondiente a cada uno, y almacena esta información en un fichero de texto, llamado IcePatch2.sum. Ambas operaciones las realiza el comando icepatch2calc. Una vez hecho esto, se utiliza icepatch2server para crear un servidor al que conectarse para descargar los ficheros. Cuando un cliente se conecta al servidor (mediante icepatch2client), descarga los ficheros comprimidos y el fichero .sum, que le servirá en primera instancia para detectar errores en la transmisión. Si todo ha ido bien, descomprimirá los ficheros y borrará los comprimidos. El fichero .sum tiene una segunda finalidad, y es que permite detectar cambios. Cuando alguien actualice la Imagen almacenada en el servidor, es de suponer que dicha actualización no afectará a todos los ficheros (aunque podría ser así, no es lo habitual). El uso del fichero .sum permite saber qué ficheros han cambiado o han sido añadidos o eliminados, y transmitir únicamente dichos cambios.
6.2. MANAGER 83 La idea, por tanto, es realizar la preparación con icepatch2calc en la Imagen y dejarla lista para su distribución. Sin embargo, el empleo de IcePatch2 tiene algunos inconvenientes que hubo que resolver. El primero de ellos se debe a los enlaces simbólicos. icepatch2calc no trata los enlaces como ficheros normales, sino que los sigue, accediendo al fichero al que apuntan en lugar de al propio enlace. Esto hace que no los añada a la lista de ficheros a transmitir, lo que deja muchos enlaces importantes (como por ejemplo, los que indican qué núcleo debe arrancarse) sin distribuir, haciendo que el sistema quede inutilizable. También nos tropezamos con los enlaces a ficheros especiales y ficheros de dispositivo, lo que hacía por ejemplo que icepatch2calc intentara añadir el contenido de un CD o de los dispositivos stdin, stdout y stderr, entre otros. Para evitar esto, es necesario añadir un paso previo en el que todos los enlaces simbólicos se almacenan en un fichero comprimido y después se borran. El fichero comprimido será el que se distribuya hacia los ordenadores clientes y luego será el instalador quien se ocupe de restaurarlos en el lugar que les corresponda. El segundo inconveniente implica a los permisos y los propietarios de los ficheros. Al descomprimir los ficheros, todos pertenecen al usuario que esté ejecutando el proceso icepatch2client, ya que es el que los está creando en ese momento. Esto es grave, porque impide por ejemplo que los usuarios puedan acceder a sus propios ficheros, incluidos los usuarios del sistema 2 . Además, algunos permisos como el bit sticky, el bit SUID y el bit SGID han de ser restaurados de forma especial. Por ello, fue necesario utilizar una aplicación auxiliar llamada metastore que almacenara la información sobre los permisos, el propietario y el grupo de cada archivo en un fichero. Este fichero, llamado permissions.hydra, se almacena junto al fichero IcePatch2.sum y se distribuye con la Imagen. El instalador, explicado en la sección 6.5, será el que invoque durante la instalación a la función complementaria de metastore 3 , que se encargará de restaurar los permisos originales de cada fichero. Una vez hecho esto, ya se puede llamar a icepatch2calc de forma que prepare el sistema para su despliegue. El proceso completo puede observarse en la figura 6.1. 2 Usuarios que representan servicios del sistema 3 http://david.hardeman.nu/software.php
- Page 53 and 54: 3.8. HERRAMIENTAS PARA DESPLIEGUE 3
- Page 55 and 56: 3.9. GESTIÓN DE RED 33 3.9. Gesti
- Page 57: 3.10. CONCLUSIONES 35 Tampoco hay u
- Page 60 and 61: 38 CAPÍTULO 4. MÉTODO DE TRABAJO
- Page 62 and 63: 40 CAPÍTULO 4. MÉTODO DE TRABAJO
- Page 65 and 66: 5 Desarrollo En este capítulo... C
- Page 67 and 68: 5.1. ESPECIFICACIÓN DE REQUISITOS
- Page 69 and 70: 5.2. CASOS DE USO 47 Figura 5.1: Di
- Page 71 and 72: 5.2. CASOS DE USO 49 Figura 5.2: Di
- Page 73 and 74: 5.4. ENTORNO DE DESARROLLO Y PRUEBA
- Page 75 and 76: 5.4. ENTORNO DE DESARROLLO Y PRUEBA
- Page 77 and 78: 5.4. ENTORNO DE DESARROLLO Y PRUEBA
- Page 79 and 80: 5.4. ENTORNO DE DESARROLLO Y PRUEBA
- Page 81 and 82: 5.4. ENTORNO DE DESARROLLO Y PRUEBA
- Page 83 and 84: 5.4. ENTORNO DE DESARROLLO Y PRUEBA
- Page 85 and 86: 5.5. INCREMENTOS 63 Memoria: Memori
- Page 87 and 88: 5.5. INCREMENTOS 65 /∗ −∗−
- Page 89 and 90: 5.5. INCREMENTOS 67 5.5.4. Incremen
- Page 91 and 92: 5.5. INCREMENTOS 69 Monday Ampl
- Page 93 and 94: 5.5. INCREMENTOS 71 # ifndef M A N
- Page 95 and 96: 5.5. INCREMENTOS 73 Implementación
- Page 97 and 98: 5.6. BRIDGE ETHERNET Y SERVIDOR DHC
- Page 99: 5.7. TAMAÑO DEL PROYECTO 77 Módul
- Page 102 and 103: 80 CAPÍTULO 6. HYDRA Figura 6.1: P
- Page 106 and 107: 84 CAPÍTULO 6. HYDRA 1. Los usuari
- Page 108 and 109: 86 CAPÍTULO 6. HYDRA Figura 6.3: D
- Page 110 and 111: 88 CAPÍTULO 6. HYDRA Figura 6.4: S
- Page 113 and 114: 7 Caso de Estudio: ESI En este cap
- Page 115 and 116: 7.1. SITUACIÓN ACTUAL 93 Es el cas
- Page 117 and 118: 7.2. IMPLANTACIÓN DE HYDRA 95 5. E
- Page 119: 7.2. IMPLANTACIÓN DE HYDRA 97 2. S
- Page 122 and 123: 100 CAPÍTULO 8. CONCLUSIONES Y TRA
- Page 125 and 126: A Manual de Usuario En este capítu
- Page 127 and 128: A.2. GESTIÓN DE DESPLIEGUES 105 El
- Page 129 and 130: A.3. GESTIÓN DE EQUIPOS 107 Modifi
- Page 131: B Terminología Imagen - Contenedor
- Page 134 and 135: 112 APÉNDICE C. ACRÓNIMOS Y SIGLA
- Page 136 and 137: 114 APÉNDICE C. ACRÓNIMOS Y SIGLA
- Page 138 and 139: 116 APÉNDICE D. GNU FREE DOCUMENTA
- Page 140 and 141: 118 APÉNDICE D. GNU FREE DOCUMENTA
- Page 142 and 143: 120 APÉNDICE D. GNU FREE DOCUMENTA
- Page 144 and 145: 122 BIBLIOGRAFÍA [GLV + 06] Y. Geo
6.2. MANAGER 83<br />
La idea, por tanto, es realizar la preparación con icepatch2calc en la Imagen y<br />
dejarla lista para su distribución. Sin embargo, el empleo de IcePatch2 tiene algunos<br />
inconvenientes que hubo que resolver.<br />
El primero de ellos se debe a los enlaces simbólicos. icepatch2calc no trata los enlaces<br />
como ficheros normales, sino que los sigue, accediendo al fichero al que apuntan en lugar<br />
de al propio enlace. Esto hace que no los añada a la lista de ficheros a transmitir, lo<br />
que deja muchos enlaces importantes (como por ejemplo, los que indican qué núcleo<br />
debe arrancarse) sin distribuir, haciendo que el sistema quede inutilizable. También<br />
nos tropezamos con los enlaces a ficheros especiales y ficheros de dispositivo, lo que<br />
hacía por ejemplo que icepatch2calc intentara añadir el contenido de un CD o de los<br />
dispositivos stdin, stdout y stderr, entre otros.<br />
Para evitar esto, es necesario añadir un paso previo en el que todos los enlaces<br />
simbólicos se almacenan en un fichero comprimido y después se borran. El fichero<br />
comprimido será el que se distribuya hacia los ordenadores clientes y luego será el<br />
instalador quien se ocupe de restaurarlos en el lugar que les corresponda.<br />
El segundo inconveniente implica a los permisos y los propietarios de los ficheros. Al<br />
descomprimir los ficheros, todos pertenecen al usuario que esté ejecutando el proceso<br />
icepatch2client, ya que es el que los está creando en ese momento. Esto es grave, porque<br />
impide por ejemplo que los usuarios puedan acceder a sus propios ficheros, incluidos<br />
los usuarios del sistema 2 . Además, algunos permisos como el bit sticky, el bit SUID y<br />
el bit SGID han de ser restaurados de forma especial.<br />
Por ello, fue necesario utilizar una aplicación auxiliar llamada metastore que almacenara<br />
la información sobre los permisos, el propietario y el grupo de cada archivo<br />
en un fichero. Este fichero, llamado permissions.hydra, se almacena junto al fichero<br />
IcePatch2.sum y se distribuye con la Imagen. El instalador, explicado en la sección 6.5,<br />
será el que invoque durante la instalación a la función complementaria de metastore 3 ,<br />
que se encargará de restaurar los permisos originales de cada fichero.<br />
Una vez hecho esto, ya se puede llamar a icepatch2calc de forma que prepare el<br />
sistema para su despliegue. El proceso completo puede observarse en la figura 6.1.<br />
2 Usuarios que representan servicios del sistema<br />
3 http://david.hardeman.nu/software.php
Change language