close
Warning:
Failed to sync with repository "ogBrowser-Git": (1366, "Incorrect string value: '\\xF0\\x9F\\x93\\xA6 I...' for column 'message' at row 1"); repository information may be out of date. Look in the Trac log for more information including mitigation strategies.
- Timestamp:
-
May 4, 2010, 1:18:36 PM (15 years ago)
- Author:
-
adv
- Comment:
-
info propuesta cliente basado en dos etapas independientes
Legend:
- Unmodified
- Added
- Removed
- Modified
-
v2
|
v3
|
|
7 | 7 | dispositivo removible (usb, cd, dvd), una partición cache, o un espacio no |
8 | 8 | particionado (¿¿¿???), y por supuesto por red. |
| 9 | |
9 | 10 | El "cliente" se compone en su primera etapa de un kernel ubuntu |
10 | 11 | (personalmente prefiero versión server), y un initrd. (actualmente basado |
11 | 12 | en el instalador de ubuntu). |
| 13 | |
12 | 14 | Estos elementos se cargan mediante un gestor de arranque, en el caso de |
13 | 15 | cd-dvd (isonlinux), en el caso de partición-cache (offline-grub,grub2-, |
14 | | online-pxe-). El inicializador de opengnsys (ubicado en el 1ndFS-initrd-), |
| 16 | online-pxe-). |
| 17 | |
| 18 | El inicializador de opengnsys (ubicado en el 1ndFS-initrd-), |
15 | 19 | detectará donde se ubica el fichero que contiene el 2ndFS y ejecutará el |
16 | 20 | load2ndFS, que ampliará la capacidad del 1ndFS. |
17 | | Resumiendo tres ficheros: kernel, initrd(1ndFS), y el og2ndFS. Estos tres |
18 | | ficheros, nos proporciona la capacidad de ser enviados o distribuidos a la |
19 | | cache de los clientes por torrent, o multicast. Asi, cualquier dispositivo |
20 | | (usb,cd-dvd,particion rescate) tendrá estos tres elementos más un |
| 21 | |
| 22 | |
| 23 | Resumiendo tres ficheros: kernel, initrd(1ndFS), y el og2ndFS. |
| 24 | |
| 25 | Estos tres ficheros, nos proporciona la capacidad de ser enviados o distribuidos a la |
| 26 | cache de los clientes por torrent, o multicast. |
| 27 | |
| 28 | Asi, cualquier dispositivo (usb,cd-dvd,particion rescate) tendrá estos tres elementos más un |
21 | 29 | directorio con las imagenes que se quisiera tener. |
22 | | Todo esto está probado, solo falta testear la conectividad con los |
23 | | servicios opengnsys, y el browser (desde mi última actualización tengo |
24 | | algún problema de comunicación) así como ofrecer servicios de red desde el |
25 | | propio "cliente" |
26 | 30 | |
27 | | ¿Que és el og2ndFS?, es un Sistema Operativo generado por debootstrat |
28 | | almacenado en un fichero linux. Puede estar basado en el mismo kernel que |
| 31 | |
| 32 | Todo esto está probado, solo falta testear: |
| 33 | * la conectividad con los servicios opengnsys, y el browser (detectado algún fallo leve cuando el ogADM envia un /bin/sh) |
| 34 | * así como ofrecer servicios de red desde el propio "cliente" |
| 35 | |
| 36 | ¿Que és el og2ndFS?: |
| 37 | Es un Sistema Operativo generado por debootstrat almacenado en un fichero linux. Puede estar basado en el mismo kernel que |
29 | 38 | el initrd(basado en instalador ubuntu), o en el kernel de nuestro equipo. |
30 | | Para ello source ogFSHlnk-generatorV2.sh; ogFSHCreate [jaunty,karmic]. Si |
31 | | después de su creación queremos añadirle más software llamamos a la |
32 | | función ogFSHMount (chroot hacia el file-loop) nos pedirá el login del |
33 | | cliente, que por defecto es "og", exportamos el proxy si fuese necesario e |
34 | | instalmos con apt. exit y desmontamos con ogFSHUnmount. |
35 | | ¿Como puedo testear el og2ndFS desde mi opengnsys?. una vez que tienes |
36 | | generado el og2ndFS, debes copiar el load2ndfs.sh al etc/init del cliente. |
37 | | Así cuando un cliente, desde la pestaña shell del browser ejecuta |
38 | | load2ndfs.sh en un 1-3 segundos dispondrá de toda la capacidad del og2ndFS |
39 | | (alterará el $PATH, y usará el /lib /usr del og2ndFS). |
40 | 39 | |
41 | | ¿Por que no hace el load2ndfs.sh un chroot? Inicialmente load2ndfs esta |
42 | | concebido para añadir capacidad al actual cliente-browser. Quizás si se |
43 | | cambia la filosofía e iniciamos el browser dentro del og2ndFS.??? |
| 40 | Para ello |
| 41 | {{{ |
| 42 | source ogFSHlnk-generatorV2.sh; ogFSHCreate [jaunty,karmic] |
| 43 | }}} |
| 44 | Si después de su creación queremos añadirle más software llamamos a la función ogFSHMount (chroot hacia el file-loop) nos pedirá el login del cliente, que por defecto es "og", exportamos el proxy si fuese necesario e instalmos con apt. exit y desmontamos con ogFSHUnmount. |
44 | 45 | |
45 | | Ya tengo el og2ndFS y el initrd, ¿como consigo hacer dispositivos |
46 | | (cd,usb,cache) arrancables? |
| 46 | ¿Como puedo testear el og2ndFS desde mi opengnsys?: |
| 47 | una vez que tienes generado el og2ndFS, debes copiar el load2ndfs.sh al etc/init del cliente. |
| 48 | 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). |
| 49 | |
| 50 | |
| 51 | |
| 52 | Ya tengo el og2ndFS y el initrd, ¿como consigo hacer dispositivos (cd,usb,cache) arrancables?: |
| 53 | {{{ |
47 | 54 | source ogFSHlnk-generatorV2.sh; CrearISO |
48 | | Nos creará una iso, con los tres archivos comentados: kernel, initrd y |
49 | | og2ndfs. NOTA: el actual initrd |
50 | | (branches/offline/client/boot/initrd-generator), no incluye la detecctión |
51 | | y utilización del 2ndfs, pero si en el |
52 | | branches/ogFSHlnk/initramfs-tools-OG. Aunque el procedimiento es bien |
53 | | sencillo DEV=`blkid -t LABEL=ogClient`. |
| 55 | }}} |
| 56 | Nos creará una iso, con los tres archivos comentados: kernel, initrd y og2ndfs. |
| 57 | NOTA: el actual initrd (branches/offline/client/boot/initrd-generator), no incluye la detecctión y utilización del 2ndfs, pero si en el |
| 58 | branches/ogFSHlnk/initramfs-tools-OG. Aunque el procedimiento es bien sencillo DEV=`blkid -t LABEL=ogClient`. |
54 | 59 | |
55 | | ¿Por qué no utilizar unionfs y squasfs?. Pues sí, pero si esto es simple y |
56 | | funciona mejor. |
57 | | ¿Está completamente testeado? Aun falta testearlo a fondo. |
58 | | ¿Cual es mi propuesta?. tener los tres archivos en cache, y utilizar esta |
59 | | no sólo para las imagenes sino también para el SO "cliente" y desde la |
60 | | web, (gestor de arranque remoto), indicar que arranque desde la cache, en |
61 | | el caso de que no tenga que realice un arranque por pxe. Por supuesto, el |
62 | | cliente detectará si tiene que actualizarse, y si el caso, que proceda por |
63 | | torrent, o multicast. |
| 60 | ¿Por qué no utilizar unionfs y squasfs?: |
| 61 | Pues sí, pero si esto es simple y funciona mejor. Aunque se deja funciones para utilizar unionfs. |
64 | 62 | |
| 63 | ¿Está completamente testeado?: |
| 64 | Aun falta testearlo a fondo. |
| 65 | |
| 66 | ¿Cual es mi propuesta?: |
| 67 | tener los tres archivos en cache, y utilizar esta no sólo para las imagenes 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. |
| 68 | |
| 69 | ¿Por que no hace el load2ndfs.sh un chroot?: |
| 70 | 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.??? |
65 | 71 | |
66 | 72 | 2) Gestor de arranque remoto. |