Changes between Initial Version and Version 1 of variosRepoUO

Timestamp:

Apr 10, 2015, 1:51:12 PM (9 years ago)

Author:

irina

Comment:

--

variosRepoUO

@@ +1 @@
+[[TOC(heading=Índice)]]
+
+{{{
+#!div style="width:50%; background: #ffd; font: bold italic large sans-serif"> 
+Propuesta de API REST para debatir en el grupo de desarrollo.
+}}}
+
+= Cliente de Opengnsys con varios repositorios y unidades organizativas en directorios separados =
+Son dos funcionalidades distintas pero ambas afectan al montaje del recurso ogimages en el cliente de opengnsys, por ello la solución ha de ser conjunta.
+
+== Cliente de Opengnsys con varios repositorios ==
+
+El cliente de opengnsys tendrá un repositorio por defecto, pero podrá restaurar y crear imágenes de otros diferente. La condición es que '''todos los repositorios tengan la misma clave ''' de samba para el usuario de opengnsys.
+
+El cliente al arrancar monta el recurso ogimages del repositorio por defecto.
+
+Los comandos de gestión de imágenes admiten además de REPO, CACHE y el valor de la ip del repositorio que queremos cambiar. 
+ * En caso de ser una ip el primer paso será comprobar si el valor que nos han dado es repositorio que está y lo cambie si es necesario.
+ * Si el valor es REPO, se consultará la ip del repositorio por defecto y se cambiará al mismo si es necesario.
+
+Desde el lado del cliente la información del repositorio se optiene a partir del recurso remoto que está montado en /opt/opengnsys/images. Por ejemplo, la ip del servidor se obtiene revisando la ip del recurso remoto ogimages, el tamaño de las imágenes se calcula haciendo referencia a la ruta "local" en el cliente, el espacio libre en el repositorio según el espacio que quede en el sistema de ficheros montado en /opt/opengnsys/images, etc. Por este motivo las funciones del motor de clonación van a necesitar pocos cambio, en las pruebas realizadas hasta ahora no ha habido que modificar ninguna.
+
+Hasta ahora se ha conseguido utilizar deployImages y updateCache con varios repositorios en todos los protocolos. Lo demás no se ha mirado, posiblemente sae igual de fácil.
+
+El cambio se ha basado en la funcion '''ogChangeRepo''', que añadimos al principio de los script deployImages y updateCache.
+
+=== ogChangeRepo ===
+La función cambia el recurso remoto de /opt/opengnsys/images, es decir muestra las imágenes del repositorio que digamos.  Toma como argumento:
+ * IPREPO|REPO: la ip del repositorio, si le pasamos la cadena "REPO" busca el valor de la ip del repositorio por defecto (parámetro PXE)
+ * Unidad organizativa: Abreviatura unidad organizativa del repositorio, para la otra funcionalidad.
+
+El montaje si el cliente esta en modo admin es de lectura y escritura y si está en modo user sólo de lectura.
+
+{{{
+ogChangeRepo IPREPO|REPO [ OgUnit ]
+    ej: ogChangeRepo 10.1.120.3
+    ej: ogChangeRepo REPO
+    ej: ogChangeRepo 10.1.120.3 cdc
+}}}
+
+Falta hacer control de errores, si no se puede montar el recurso remoto que deje el repositorio por defecto y salga dando error.
+
+=== Cambios en los script ===
+
+El script deployImage sí admitía como valor del repositorio la ip, podía ser la del repositorio o la del cliente que cambiaba respectivamente por las cadenas REPO o CACHE, updateCache no lo tenía en cuenta. 
+
+Se añade al principio antes de cualquier consulta que necesite el punto de montaje de samba:
+
+{{{
+# Valor por defecto para el repositorio.
+#[ "$REPO" == "$(ogGetRepoIp)" ] && REPO="REPO" -> lo hace  ogChangeRepo
+[ "$REPO" == "$(ogGetIpAddress)" ] && REPO="CACHE"
+# Si es una ip distinta cambiamos de REPO.
+if ogCheckIpAddress $REPO >/dev/null ; then
+        # Si falla el cambio -> salimos con error repositorio no valido
+        ogChangeRepo $REPO || exit $(ogRaiseError $OG_ERR_NOTFOUND '$REPO'; echo $?)
+        REPO="REPO"
+fi
+}}}
+Nota: La tercera línea sólo en deployImage, ya que updateCache no admite CACHE como valor.
+
+=== Pruebas realizadas ===
+Como hemos dicho anteriormente se ha probado con éxito los comandos deployImage y updateCache con varios repositorios en todos los protocolos. Pruebas realizadas.
+
+{{{
+ogChangeRepo REPO
+ogChangeRepo 10.1.14.8
+ogChangeRepo 10.1.14.6
+ogChangeRepo en modo admin -> rw
+ogChangeRepo en modo user -> ro
+
+updateCache 10.1.14.8 Ubuntu12.img UNICAST
+updateCache 10.1.14.8 Ubuntu12.img MULTICAST 9000:full-duplex:239.194.17.2:70M:20:300
+updateCache 10.1.14.8 Ubuntu12.img TORRENT seeder:1000
+
+deployImage 10.1.14.8 Ubuntu12 1 6 UNICAST-DIRECT
+deployImage 10.1.14.8 Ubuntu12 1 6 UNICAST
+deployImage 10.1.14.6 Ubuntu12BIEN 1 6 UNICAST
+deployImage 10.1.14.8 Ubuntu12 1 6 MULTICAST-DIRECT 9000:full-duplex:239.194.17.2:150M:20:20
+deployImage 10.1.14.8 Ubuntu12 1 6 MULTICAST 9000:full-duplex:239.194.17.2:150M:20:20
+deployImage 10.1.14.8 Ubuntu12 1 6 TORRENT seeder:1000
+}}}
+
+
+== Unidades organizativas en directorios separados ==
+
+Cuando un repositorio tiene dos unidades organizativas sus imágenes se sitúan en el mismo directorio pudiendo tener problemas, por ejemplo si coinciden los nombres o se llena el espacio.
+
+Cada unidad organizativa tendrá sus imágenes en un subdirectorio de /opt/opengnsys/images, el nombre del subdirectorio será una abreviatura de la unidad organizativa. Está abreviatura será una propiedad más del aula en la consola y se le enviará al cliente por PXE en la variable ogunit.
+
+El cliente montará en /opt/opengnsys/images el recurso ogimages/ogunit, de forma que el cambio es transparente del lado del cliente. Cuando un comando le pida una imagen al servidor sí necesita la especificar a qué unidad organizativa se refiere, como los comandos aceptan que la imagen este en subdirectorios bastaría enviarle al servidor como nombre de la imagen "$OGUNIT/$IMAGENAME"
+
+En la cache no establecemos distinción entre las unidades organizativas ni creamos subdirectorios.
+
+=== Cambios en el montaje del ogimages ===
+
+Cuando montamos el recurso ogimages consultamos si existe el valor de ogunit y lo añadimos al path del recurso remoto. El montaje se realiza en dos pasos:
+
+1) En el initrd tenemos la función ogExportVarEnvironment donde se definen los recursos remotos del cliente opengnsys (ogimages, oglog,...). Solo cambian las líneas:
+
+{{{
+diff ogfunctions ogfunctions.orig
+< [ "$ogunit" != "" ] && OGUNIT="/$ogunit"
+
+<    export SRCOGIMAGES="/opt/opengnsys/images$OGUNIT" && echo "SRCOGIMAGES=$SRCOGIMAGES" >> $CFGINITRD 
+>    export SRCOGIMAGES="/opt/opengnsys/images" && echo "SRCOGIMAGES=$SRCOGIMAGES" >> $CFGINITRD        
+
+<    export SRCOGIMAGES="ogimages$OGUNIT" && echo "SRCOGIMAGES=$SRCOGIMAGES" >> $CFGINITRD
+>    export SRCOGIMAGES="ogimages" && echo "SRCOGIMAGES=$SRCOGIMAGES" >> $CFGINITRD
+}}}
+
+2) Cuando se está terminando de arrancar el script /etc/preinit/mountrepo.sh si el cliente de OpenGnSys está en modo de administración monta el recurso ogimages en modo lectura-escritura. Los cambios son:
+{{{
+< [ "$ogunit" != "" ] && OGUNIT="/$ogunit"
+
+<    nfs)       mount.nfs ${ROOTREPO}:$OGIMG$OGUNIT $OGIMG -o rw,nolock ;;
+>    nfs)       mount.nfs ${ROOTREPO}:$OGIMG $OGIMG -o rw,nolock ;;
+
+<    mount.cifs //${ROOTREPO}/ogimages$OGUNIT $OGIMG -o rw,serverino,acl,username=opengnsys,password=$PASS
+>    mount.cifs //${ROOTREPO}/ogimages $OGIMG -o rw,serverino,acl,username=opengnsys,password=$PASS
+}}}
+
+
+=== Cambios en los script ===
+
+En todos los pasos se crea la variable del nombre de la imagen construida poniendo delante del mismo subdirectorio de la unidad organizativa y sustituyendo esta variable donde se usaba el argumento de entrada de comando. Ejemplo:
+{{{
+[ "$ogunit" != "" -a "$3" == "REPO" ] && IMGNAME="$ogunit/$2" || IMGNAME="$2"
+
+ogExecAndLog command ogRestoreImage "$REPO" "$IMGNAME" "$DISK" "$PART"
+}}}
+
+Las funciones no deben verse afectadas ya que están pensadas para que las imágenes pueda estar en subdirectorios. Hay que repasarlas todas.
+
+El script de servidor bin/torrent-creator, que genera las sumas de comprobación de las imágenes y los ficheros torrent, hay que modificarlo para que revise los subdirectorios de primer nivel del /opt/opengnsys/images. El cambio sería:
+
+{{{
+diff torrent-creator  torrent-creator.orig
+< for IMG in *.{img,pgz,diff} */*.{img,pgz,diff}; do
+> for IMG in *.{img,pgz,diff}; do
+}}}
+ 
+
+=== Pasamos al cliente el parámetro de la unidad organizativa por PXE ===
+
+Al cliente de opengnsys se le debe pasar como parámetro del kernel la abreviatura de la unidad organizativa. Inicialmente la incorporamos en las plantillas de PXE: Ejemplo:
+{{{
+title OpenGnSys-NET
+keeppxe
+kernel (pd)/ogclient/ogvmlinuz  ro boot=oginit vga=788 irqpoll acpi=on og2nd=sqfs ogprotocol=smb ogactiveadmin=true ogdebug=true ogupdateinitrd=true ogunit=cdc INFOHOST
+initrd (pd)/ogclient/oginitrd.img
+boot
+}}}
+
+Como solución definitiva de debe estar en la base de datos como el campo "abreviatura" en la tabla centros. Cuando se cree el fichero PXE a partir de la plantilla también habrá que consultar este dato.
+
+La consulta para obtener la unidad organizativa de un equipo será:
+{{{
+select ordenadores.idordenador, aulas.idcentro, centros.abreviatura from ordenadores inner join aulas inner join centros where ordenadores.idaula=aulas.idaula and aulas.idcentro=centros.idcentro and ordenadores.ip='$IP';
++-------------+----------+-------------+
+| idordenador | idcentro | abreviatura |
++-------------+----------+-------------+
+|           1 |        1 | cdc         |
++-------------+----------+-------------+
+}}}
+
+=== Problema con el protocolo torrent ===
+La transferencia del protocolo torrent se basa en dos procesos del servidor, btlaunchmany.bittornado y bttrack, el semillero y el tracker respectivamente. Uno de ellos no ve los subdirectorios. Habría que ver qué solución tiene.
+
+== Compatibilidad varios repositorios y varias unidades organizativas ==
+En caso de querer incluir las dos funcionalidades hay que decidir cómo pasar los parámetros a los comandos, ya que tendríamos que pasar  la ip del repositorio y la unidad organizativa. 
+
+Una posibilidad sería incluirla en el argumento del repo separada por dos puntos: 
+
+{{{
+$REPO=$IPREPO|REPO[:$OGUNIT]
+}}}
+Por ejemplo:
+{{{
+restoreImage 10.1.15.2:cdc Ubuntu12 1 2
+}}}
+
+== Unificar el montaje de ogimages en un único paso ==
+
+Esto es independiente de las nuevas funcionalidades.
+
+El montaje se realiza en dos pasos pero podría hacerse en uno sólo, me parece que no existe ninguna comprobación intermedia que aporte algo. 
+
+En el segundo paso el script mountrepo consulta el parámetro PXE "ogactiveadmin" para decidir si monta el repositorio en modo escritura.
+
+En el primer paso el script oginit del initrd llama a la función ogConnect con el parámetro "ro", bastaría comprobar el parámetro PXE ogactiveadmin y montar el recurso ogimages con los permisos correctos para cada caso. El cambio sería el siguiente:
+
+{{{
+diff oginit oginit.orig
+<[ "$ogactiveadmin" == "true" ] &&  RWOPT=',rw' || RWOPT=',ro'
+<        ogConnect $OGSERVERIMAGES $OGPROTOCOL $SRCOGIMAGES $DSTOGIMAGES $RWOPT
+>        ogConnect $OGSERVERIMAGES $OGPROTOCOL $SRCOGIMAGES $DSTOGIMAGES ,ro