wiki:InitrdClienteSecondFileSystem

Version 24 (modified by adv, 14 years ago) (diff)

Actualizando información

TOC(heading=Índice)?

Cliente OpenGnsys

Objetivo

  1. Ser capaz de inicializarse desde:
    • cualquier dispositivo removible (usb, cd, dvd),
    • una partición cache, o un espacio no particionado (¿¿¿???)
    • y por supuesto por red, utilizando cualquier protocolo.
  2. Ofrecer la posibilidad de añadir o actualizar software usando los gestores de paquetes estándar.
  3. Que el software instalado en el cliente, no afecte a su arranque (especialmente en el modo PXE)

Descripción

  1. El "cliente" se compone en su primera etapa de un kernel y un initrd.
  2. 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).
  3. 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.

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.

sobre la primera etapa kernel, initrd

Sobre la segunda etapa ogclient.img

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.

Para ello

 source ogFSHlnk-generatorV2.sh; ogFSHCreate [jaunty,karmic] 

Añadir software al og2ndFS

En el caso de que después de su creación queramos añadirle mas software procedemos como sigue.

  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".
  2. Exportamos el proxy si fuese necesario.
  3. Instalamos con apt los paquetes que necesitemos.
  4. Escapamos con exit
  5. Desmontamos con ogFSHUnmount.

A testear

Todo esto está probado, solo falta testear:

  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.
  2. Ofrecer servicios de red desde el propio "cliente".

¿Como puedo testear el og2ndFS desde mi opengnsys?

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).

Ya tengo el og2ndFS y el initrd, ¿como consigo hacer dispositivos (cd,usb y cache) arrancables?:

source ogFSHlnk-generatorV2.sh; CrearISO

Nos creará una iso, con los tres archivos comentados: kernel, initrd y og2ndfs.

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.

DEV=`blkid -t LABEL=ogClient`

og1ndFS - Primer sistema de Archivos Unico para multi-arranque (cd-dvd/usb/cache/nfs)

og2ndFS - Segundo Sistema de Archivos Único para multi- arranque.

FAQ

¿Por qué no utilizar unionfs y squasfs?:

Pues sí, pero si esto es simple y funciona mejor. Aunque se deja funciones para utilizar unionfs.

¿Está completamente testeado?:

Aun falta testearlo a fondo.

¿Cual es mi propuesta?:

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.

¿Por que no hace el load2ndfs.sh un chroot?:

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.???

Gestor de arranque remoto

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).

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.

Gestor de Arranque Remoto.

Gestor de startpages

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.

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).

Gestor de Páginas de Inicio o starpages.

Estado Actual

  • branch ogFSHlnk: (tarea) Proporcionar API al cliente para ampliar su sofware al instante.
    • (ok) Capacidad similar squashfs-unionfs para el 1er FileSystem (initrd).
      • Herramientas busybox
      • Requisito hardware del cliente: 50 MB de RAM.
  • (ok) Generación del 2º FileSystem con debootstrap, incluyendo la compilación de las herramientas en ToolsGNU.c del engine
    • pendiente opción debootstrap desde cd instalación ububu
  • Modificación del oginit para que utilice este 2º FileSystem
    • (ok) en remoto
    • pendiente en local.
  • 2º FileSystem disponible en local o en remoto.
    • (ok) en remoto
    • Pendiente en local (partición CACHE, usb, cdrom) con imágenes virtuales.
  • (ok) Ampliación del 2º FileSystem con apt-get para el administrador.