TOC(heading=Índice)?

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