Changes between Version 26 and Version 27 of InitrdClienteSecondFileSystem
- Timestamp:
- Mar 30, 2011, 10:02:48 AM (13 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
InitrdClienteSecondFileSystem
v26 v27 11 11 1. Ofrecer la posibilidad de añadir o actualizar software usando los gestores de paquetes estándar. 12 12 1. Que el software instalado en el cliente, no afecte a su arranque (especialmente en el modo PXE) 13 1. Independizar el tiempo de arranque del cliente, independiente del número de estos que se inician simultánemente. 13 14 14 15 == Descripción == 15 16 16 1. El "cliente" se compone en su primera etapa de un kernel y un initrd. 17 1. Estos elementos se cargan mediante un gestor de arranque, en el caso de cd-dvd (p.e isonlinux), en el caso de partición-cache (p.e. offline-grub, grub2 u online-pxe). 18 1. El inicializador de opengnsys ubicado en el initrd (sistema de archivos de la primera etapa) detectará donde se ubica el sistema de archivos de la segunda etapa, y lo incluirá como tal. 17 1. El "cliente" se compone en: 18 * Primera etapa: un kernel y un initrd. 19 * Segunda etapa: el sistema raíz o root(con todas las aplicaciones necesarias). 20 1. Los elementos de la primera etapa se cargan mediante un gestor de arranque, dependiendo del contendor(cd,dvd,usb,particionCache,red) se usuará el más idóneo (p.e isonlinux, grub, grub4dos, gpxe). 21 1. El inicializador de opengnsys ubicado en el initrd (boot=oginit) detectará donde se ubica el sistema raíz (segunda etapa), y lo incluirá como tal. 19 22 20 Resumiendo, tenemos tres ficheros. El kernel, el initrd (1er FS), y el ogclient.img (2nd FS). Estos tres ficheros, nos proporciona la capacidad de ser enviados o distribuidos a la cache de los clientes por torrent, o multicast. Asi, cualquier dispositivo (usb, cd-dvd o partición rescate) tendrá estos tres elementos más un directorio con las imagenes que se quisiera tener. 23 == Instalación == 24 No realizar el proceso en un sistema en procucción. 25 Se ha testado con éxito en la ubuntu server 32 bits 10.04 y 10.10 21 26 22 == Primera etapa (kernel e initrd) ==23 24 == Segunda etapa (ogclient.img) ==25 Es un Sistema Operativo generado por debootstrap almacenado en un fichero linux. Puede estar basado en el mismo kernel que el initrd basado en instalador ubuntu o en el kernel de nuestro equipo.26 27 Para ello28 27 {{{ 29 source ogFSHlnk-generatorV2.sh; ogFSHCreate [jaunty,karmic] 28 mv /opt/opengnsys/tftpboot/ogclient/ /opt/opengnsys/tftpboot/ogclientTrunk; 29 svn checkout http://www.opengnsys.es/svn/branches/ogClient /tmp/opengnsys_installer/opengnsys/installer/ogClient; 30 svn checkout http://www.opengnsys.es/svn/branches/version1.0/client/shared/ /tmp/opengnsys_installer/opengnsys/client/shared; 31 svn checkout http://www.opengnsys.es/svn/branches/version1.0/client/engine/ /tmp/opengnsys_installer/opengnsys/client/engine; 32 find /tmp/opengnsys_installer/ -name .svn -type d -exec rm -fr {} \; 2>/dev/null; 33 /tmp/opengnsys_installer/opengnsys/installer/ogClient/ogClientGeneratorV2.sh; 30 34 }}} 31 35 32 === Añadir software al og2ndFS ===33 En el caso de que después de su creación queramos añadirle mas software procedemos como sigue.34 1. Llamamos a la función ogFSHMount, este es un chroot hacia el file-loop. Después nos pedirá el login del cliente que por defecto es "og".35 1. Exportamos el proxy si fuese necesario.36 1. Instalamos con apt los paquetes que necesitemos.37 1. Escapamos con exit38 1. Desmontamos con ogFSHUnmount.39 36 40 == A testear == 41 Todo esto está probado, solo falta testear: 42 1. La conectividad con los servicios opengnsys, y el browser. Se ha detectado algún fallo leve cuando el ogADM envía un /bin/sh. 43 1. Ofrecer servicios de red desde el propio "cliente". 37 El proceso que se ha indicado a continuación, genera los elementos del cliente OpenGnsys, basados en la versión de ubuntu que tengamos instalados (mismo kernel y distribución). 44 38 45 === ¿Como puedo testear el og2ndFS desde mi opengnsys? === 46 Una vez que tienes generado el og2ndFS, debes copiar el load2ndfs.sh al etc/init del cliente. Así cuando un cliente, desde la pestaña shell del browser ejecuta load2ndfs.sh en un 1-3 segundos dispondrá de toda la capacidad del og2ndFS (alterará el $PATH, y usará el /lib /usr del og2ndFS). 47 48 Ya tengo el og2ndFS y el initrd, ¿como consigo hacer dispositivos (cd,usb y cache) arrancables?: 49 {{{ 50 source ogFSHlnk-generatorV2.sh; CrearISO 39 /opt/opengnsys/tftpboot/ogclient/ 40 {{{ 41 ./ogvmlinuz (el kernel) 42 ./oginitrd.img (el initrd) 43 ./ogclient.img (el sistema raiz, accesible como disco virtual usando schroot desde el host que lo generó, para ser actualizado) 44 ./ogclient.sqfs (el sistema raiz, comprimido para ser usado por los clientes OpenGnsys) 51 45 }}} 52 46 53 Nos creará una iso, con los tres archivos comentados: kernel, initrd y og2ndfs.54 47 55 '''NOTA''': El actual initrd (branches/offline/client/boot/initrd-generator), no incluye la detección y utilización del 2ndfs, pero si en el branches/ogFSHlnk/initramfs-tools-OG. Aunque el procedimiento es bien sencillo. 48 === Las fases de la instalación === 49 * Fase 1. Instalación en el equipo donde se ejecuta la instalación de software necesario. 50 * Fase 2. Asignación de valores, como la versión del kernel, basados en los datos del S.O que ejecuta el instalador, que serán utilizados para generar el cliente. 51 * Fase 3. Creación del sistema raiz (ogclient.img). Primero se crea un disco duro virtual, y se particiona -ogCleint2nFile()-. En la primera partición se genera un sistema operativo con la herramienta deboobstrap -ogClient2ndFs()-, con parametros basados en la fase2. 52 * Fase 4. Se configura el acceso al sistema raiz (ogclient.img) para ser usado con la herramienta schroot -ogClientSchrootConf()- 53 * Fase 5. Se configura o se incluyen los elementos especiales de opengnsys (engine, QTEmbbedbed, pci.ids, browser, ogAdmClient). -ogClient2ndSVN()- 54 * Fase 6. Ampliación del sistema raiz -- instalación de software con apt, compilación de algunas herramientas, importación de la clave ssh desde el SO que lo generó. 55 * Fase 7. Generación del initrd. 56 * Fase 8. Generación del sistema raiz en sqfs. 57 58 59 60 61 == Modificaciones al cliente == 62 63 Pasos previos: 56 64 {{{ 57 DEV=`blkid -t LABEL=ogClient` 65 svn checkout http://www.opengnsys.es/svn/branches/ogClient /tmp/opengnsys_installer/opengnsys/installer/ogClient; 66 source /tmp/opengnsys_installer/opengnsys/installer/ogClient/ogClientManager.lib 58 67 }}} 59 68 60 og1ndFS - Primer sistema de Archivos Unico para multi-arranque (cd-dvd/usb/cache/nfs)61 * http://www.informatica.us.es:8080/opengnsys/browser/branches/ogFSHlnk/initramfs-tools-OG62 * http://www.informatica.us.es:8080/opengnsys/browser/branches/offline/client/boot/initrd-generator63 69 64 og2ndFS - Segundo Sistema de Archivos Único para multi- arranque. 65 * http://www.informatica.us.es:8080/opengnsys/browser/branches/ogFSHlnk/boot 70 === Generar un nuevo initrd, con nuestras "locales", y almacenarlos en el /opt/opengnsys/tftpboot/ogclient/ === 71 {{{ 72 schroot -C IMgogclient -- /root/ReconfigureLocales.sh 73 ogClientInintrd host 74 }}} 66 75 67 == FAQ ==68 ¿Por qué no utilizar unionfs y squasfs?:69 Unionfs, integrado recientemente.70 76 71 ¿Está completamente testeado?:72 Aun falta testearlo a fondo.73 77 74 ¿Cual es mi propuesta?:75 Tener los tres archivos en cache, y utilizar esta no sólo para las imágenes sino también para el SO "cliente" y desde la web, (gestor de arranque remoto), indicar que arranque desde la cache, en el caso de que no tenga que realice un arranque por pxe. Por supuesto, el cliente detectará si tiene que actualizarse, y si el caso, que proceda por torrent, o multicast.76 78 77 ¿Por que no hace el load2ndfs.sh un chroot?: 78 Inicialmente load2ndfs esta concebido para añadir capacidad al actual cliente-browser. Quizás si se cambia la filosofía e iniciamos el browser dentro del og2ndFS.??? 79 === Copiar nuevos archivos al sistema raiz del cliente (ogclient.img) === 79 80 80 == Gestor de arranque remoto == 81 Nos facilita tener un control previo, definir un determinado arranque por defecto, mostrar un menú. Definir el arranque de multiples clientes (basados en ramfs o nfs). Gestión de menús y sus correspondientes elemetos. Un ejemplo de menú sería arrancar windows, arrancar linux. (solución temporal al hdboot). 81 Cualquier archivo extra, que queramos añadir al sistema raiz del cliente, tenemos el directorio /tmp compartido entre el SO y el ogclient. 82 {{{ 83 schroot -c IMGogclient 84 cp /tmp/ficheroOGSERVER.txt /home/opengnsys/ficheroEnOGclient.txt 85 }}} 82 86 83 En la rama viene los ficheros y la ubicación necesaria para integrarlo en la web. Sería interesante que se testeara y ver las posiblidad que puede ofrecer un gestor de arranque remoto a opengnsys.84 87 85 Gestor de Arranque Remoto.86 * http://www.informatica.us.es:8080/opengnsys/browser/branches/eac-hidra-uma/OGEAC87 88 88 == Gestor de startpages ==89 Definir la realización de operaciones basadas en aulas o grupo de ordenadores. Sería interesante que se testeara y ver las posiblidad que puede ofrecer un asistente.90 89 91 Tanto para el gestor de arranque remoto, y el gestor de starpages, hay que realizar un par de modificaciones sql. (el ficheró esta en la rama indicada). 90 === Generar un nuevo initrd, con un nuevo proceso de inicio de OpenGnsys === 92 91 93 Gestor de Páginas de Inicio o starpages.94 * http://www.informatica.us.es:8080/opengnsys/browser/branches/eac-hidra-uma/OGEAC95 92 96 == Estado Actual ==97 93 98 * branch ogFSHlnk: (tarea) Proporcionar API al cliente para ampliar su sofware al instante. 99 * (ok) Capacidad similar squashfs-unionfs para el 1er !FileSystem (initrd). 100 * Herramientas busybox 101 * Requisito hardware del cliente: 50 MB de RAM. 102 * (ok) Generación del 2º !FileSystem con debootstrap, incluyendo la compilación de las herramientas en ToolsGNU.c del engine 103 * pendiente opción debootstrap desde cd instalación ububu 104 * Modificación del oginit para que utilice este 2º !FileSystem 105 * (ok) en remoto 106 * pendiente en local. 107 * 2º !FileSystem disponible en local o en remoto. 108 * (ok) en remoto 109 * Pendiente en local (partición CACHE, usb, cdrom) con imágenes virtuales. 110 * (ok) Ampliación del 2º !FileSystem con apt-get para el administrador. 94 95 === Instalar nuevas herramientas en el sistema raiz del (ogclient.img) === 96 97 {{{ 98 schroot -c IMGogclient 99 apt-get update python3 100 }}} 101 102 103 104 105 === Generar un nuevo sistema sqfs === 106 107 108 109