wiki:variosRepoUO

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.

Se han desarrollado el los ticket:

  • #678 Unidades organizativas con directorio de imágenes separado.
  • #679 Varios repositorios para un mismo cliente.

Cliente de Opengnsys con varios repositorios

El cliente de opengnsys tendrá un repositorio inicial, 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 inicial definido en las propiedades del equipo.

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 obtiene 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 no necesitan cambios y podemos seguir restaurando con todos los protocolos sin encontrar diferencia alguna.

ogChangeRepo

Este comportamiento se basa en la funcion ogChangeRepo que cambia el recurso remoto de ogimages (/opt/opengnsys/images) tomando como origen el repositorio que le indiquemos, es decir el cliente ve las imágenes del repositorio que digamos.

El montaje es de lectura y escritura si el cliente esta en modo administración y de sólo lectura si está en modo usuario.

Sintaxis y argumentos:

ogChangeRepo IPREPO|REPO [ OgUnit ]
    ej: ogChangeRepo 10.1.120.3
    ej: ogChangeRepo REPO
    ej: ogChangeRepo 10.1.120.3 cdc
  • IPREPO|REPO: la ip del repositorio, si le pasamos la cadena "REPO" tomará el valor del repositorio actual.
  • Unidad organizativa: Abreviatura unidad organizativa del repositorio, para la otra funcionalidad.

Si hubiera un error en el cambio del repositorio se volverá a montar el repositorio inicial y mostrará un mensaje informativo.

Cambios en los script y el intarfaz de la consola

Se añade al principio antes de cualquier consulta que necesite el punto de montaje de samba:

# Unidad organizativa
[ "$ogunit" != "" ] && OGUNIT="$ogunit/"

# Si es una ip y es igual a la del equipo restaura desde cache
[ "$REPO" == "$(ogGetIpAddress)" ] && REPO="CACHE"
# Si es una ip y es distinta a la del recurso samba cambiamos de REPO.
ogCheckIpAddress $REPO
if [ $? == 0 -o $REPO == "REPO" ] ; then
        # Si falla el cambio -> salimos con error repositorio no valido
        ogChangeRepo $REPO ${OGUNIT%/} || exit $(ogRaiseError $OG_ERR_NOTFOUND '$REPO $OGUNIT'; echo $?)
        REPO="REPO"
fi

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 se definirá en la consola en las propiedades de la unidad organizativa 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 esté en subdirectorios bastaría enviarle al servidor como nombre de la imagen "$OGUNIT/$IMAGENAME"

Nota: El servidor sabe a qué unidad organizativa pertenece cada cliente, pero cuando llega un comando al servidor no sabe qué equipo se lo ha mandado. Por ello preferimos mandar la UO como parte de información de la imagen.

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 /script/ogfunctions dentro del 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

Cuando se crea la variable del nombre de la imagen ponemos delante del mismo el subdirectorio de la unidad organizativa, de forma que cuando se utilice en el resto del script solicitará al repositorio en archivo de la imagen con su path correcto. 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.

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

El valor del directorio de la unidad organizativa se guarda en la base de datos y se consulta cuando se cree el fichero PXE a partir de la plantilla.

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

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.

En una de las reuniones se ha decidido que por simplicidad no se pasará a los script el valor de la unidad organizativa, teniendo siempre el valor que se la pase por PXE. Esto implica que el equipo podrá cambiar entre los repositorios de la unidad organizativa pero no acceder a las imágenes de una unidad organizativa distinta.

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
Last modified 6 weeks ago Last modified on Jul 14, 2017, 1:07:08 PM