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

=== Pruebas realizadas ===
Se ha comprobado el montaje del recurso ogimages con o sin la variable $OGUNIT.

Otras pruebas que han ido bien:

{{{
updateCache REPO Ubuntu12 MULTICAST 9000:full:239.194.17.2:70M:20:120 
restoreImage REPO Ubuntu12 UNICAST 
restoreImage REPO Ubuntu12 MULTICAST 9000:full:239.194.17.2:70M:20:120
}}}

Con las imágenes sincronizadas tipo archivo hay problemas, ya que para poder restaurarla hay que montar la imagen y está definido el punto de montaje en /opt/opengnsys/images/mount/$IMAGENAME que está por encima del recurso remoto que ve el cliente de opengnsys. Habría que modificar las funciones que montan las imágenes y posiblemente alguna más.

== 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