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:
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.
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.
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
Si hubiera un error en el cambio del repositorio se volverá a montar el repositorio inicial y mostrará un mensaje informativo.
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
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 "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.
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:
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
< [ "$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
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
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
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.
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.
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