Changes between Version 4 and Version 5 of variosRepoUO


Ignore:
Timestamp:
Mar 21, 2016, 1:15:29 PM (8 years ago)
Author:
irina
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • variosRepoUO

    v4 v5  
    11[[TOC(heading=Índice)]]
    22
    3 {{{
    4 #!div style="width:50%; background: #ffd; font: bold italic large sans-serif">
    5 Propuesta  para debatir en el grupo de desarrollo.
    6 }}}
    73
    84= Cliente de Opengnsys con varios repositorios y unidades organizativas en directorios separados =
    95Son 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.
    106
     7Se han desarrollado el los ticket:
     8 * #678         Unidades organizativas con directorio de imágenes separado.
     9 * #679         Varios repositorios para un mismo cliente.
     10
    1111== Cliente de Opengnsys con varios repositorios ==
    1212
    13 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.
     13El 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.
    1414
    15 El cliente al arrancar monta el recurso ogimages del repositorio por defecto.
     15El cliente al arrancar monta el recurso ogimages del repositorio inicial definido en las propiedades del equipo.
     16
    1617
    1718Los comandos de gestión de imágenes admiten además de REPO, CACHE y el valor de la ip del repositorio que queremos cambiar.
    … …  
    1920 * Si el valor es REPO, se consultará la ip del repositorio por defecto y se cambiará al mismo si es necesario.
    2021
    21 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.
    22 
    23 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.
    24 
    25 El cambio se ha basado en la funcion '''ogChangeRepo''', que añadimos al principio de los script deployImages y updateCache.
     22Desde 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.
    2623
    2724=== ogChangeRepo ===
    28 La función cambia el recurso remoto de /opt/opengnsys/images, es decir muestra las imágenes del repositorio que digamos.  Toma como argumento:
    29  * 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)
    30  * Unidad organizativa: Abreviatura unidad organizativa del repositorio, para la otra funcionalidad.
    3125
    32 El montaje si el cliente esta en modo admin es de lectura y escritura y si está en modo user sólo de lectura.
     26Este 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.
     27
     28El montaje es de lectura y escritura si el cliente esta en modo administración y de sólo lectura si está en modo usuario.
     29
     30Sintaxis y argumentos:
    3331
    3432{{{
    … …  
    3937}}}
    4038
    41 Falta hacer control de errores, si no se puede montar el recurso remoto que deje el repositorio por defecto y salga dando error.
    4239
    43 === Cambios en los script ===
     40 * 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)
     41 * Unidad organizativa: Abreviatura unidad organizativa del repositorio, para la otra funcionalidad.
    4442
    45 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.
     43
     44Si hubiera un error en el cambio del repositorio se volverá a montar el repositorio inicial y mostrará un mensaje informativo.
     45
     46=== Cambios en los script y el intarfaz de la consola ===
    4647
    4748Se añade al principio antes de cualquier consulta que necesite el punto de montaje de samba:
    4849
    4950{{{
    50 # Valor por defecto para el repositorio.
    51 #[ "$REPO" == "$(ogGetRepoIp)" ] && REPO="REPO" -> lo hace  ogChangeRepo
     51# Unidad organizativa
     52[ "$ogunit" != "" ] && OGUNIT="$ogunit/"
     53
     54# Si es una ip y es igual a la del equipo restaura desde cache
    5255[ "$REPO" == "$(ogGetIpAddress)" ] && REPO="CACHE"
    53 # Si es una ip distinta cambiamos de REPO.
    54 if ogCheckIpAddress $REPO >/dev/null ; then
     56# Si es una ip y es distinta a la del recurso samba cambiamos de REPO.
     57ogCheckIpAddress $REPO
     58if [ $? == 0 -o $REPO == "REPO" ] ; then
    5559        # Si falla el cambio -> salimos con error repositorio no valido
    56         ogChangeRepo $REPO || exit $(ogRaiseError $OG_ERR_NOTFOUND '$REPO'; echo $?)
     60        ogChangeRepo $REPO ${OGUNIT%/} || exit $(ogRaiseError $OG_ERR_NOTFOUND '$REPO $OGUNIT'; echo $?)
    5761        REPO="REPO"
    5862fi
    5963}}}
    60 Nota: La tercera línea sólo en deployImage, ya que updateCache no admite CACHE como valor.
    61 
    62 === Pruebas realizadas ===
    63 Como hemos dicho anteriormente se ha probado con éxito los comandos deployImage y updateCache con varios repositorios en todos los protocolos. Pruebas realizadas.
    64 
    65 {{{
    66 ogChangeRepo REPO
    67 ogChangeRepo 10.1.14.8
    68 ogChangeRepo 10.1.14.6
    69 ogChangeRepo en modo admin -> rw
    70 ogChangeRepo en modo user -> ro
    71 
    72 updateCache 10.1.14.8 Ubuntu12.img UNICAST
    73 updateCache 10.1.14.8 Ubuntu12.img MULTICAST 9000:full-duplex:239.194.17.2:70M:20:300
    74 updateCache 10.1.14.8 Ubuntu12.img TORRENT seeder:1000
    75 
    76 deployImage 10.1.14.8 Ubuntu12 1 6 UNICAST-DIRECT
    77 deployImage 10.1.14.8 Ubuntu12 1 6 UNICAST
    78 deployImage 10.1.14.6 Ubuntu12BIEN 1 6 UNICAST
    79 deployImage 10.1.14.8 Ubuntu12 1 6 MULTICAST-DIRECT 9000:full-duplex:239.194.17.2:150M:20:20
    80 deployImage 10.1.14.8 Ubuntu12 1 6 MULTICAST 9000:full-duplex:239.194.17.2:150M:20:20
    81 deployImage 10.1.14.8 Ubuntu12 1 6 TORRENT seeder:1000
    82 }}}
    83 
    8464
    8565== Unidades organizativas en directorios separados ==
    … …  
    8767Cuando 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.
    8868
    89 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.
     69Cada 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.
    9070
    91 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"
     71El 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"
    9272
    9373Nota: 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.
    … …  
    9979Cuando 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:
    10080
    101 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:
     811) 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:
    10282
    10383{{{
    … …  
    126106=== Cambios en los script ===
    127107
    128 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:
     108Cuando 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:
    129109{{{
    130110[ "$ogunit" != "" -a "$3" == "REPO" ] && IMGNAME="$ogunit/$2" || IMGNAME="$2"
    … …  
    133113}}}
    134114
    135 Las funciones no deben verse afectadas ya que están pensadas para que las imágenes pueda estar en subdirectorios. Hay que repasarlas todas.
     115Las funciones no deben verse afectadas ya que están pensadas para que las imágenes pueda estar en subdirectorios.
    136116
    137117El 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:
    … …  
    146126=== Pasamos al cliente el parámetro de la unidad organizativa por PXE ===
    147127
     128El 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.
     129
    148130Al 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:
    149131{{{
    … …  
    155137}}}
    156138
    157 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.
    158 
    159 La consulta para obtener la unidad organizativa de un equipo será:
    160 {{{
    161 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';
    162 +-------------+----------+-------------+
    163 | idordenador | idcentro | abreviatura |
    164 +-------------+----------+-------------+
    165 |           1 |        1 | cdc         |
    166 +-------------+----------+-------------+
    167 }}}
    168 
    169139=== Problema con el protocolo torrent ===
    170140La 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.
    171141
    172 === Pruebas realizadas ===
    173 Se ha comprobado el montaje del recurso ogimages con o sin la variable $OGUNIT.
     142== Compatibilidad varios repositorios y varias unidades organizativas ==
    174143
    175 Otras pruebas que han ido bien:
    176 
    177 {{{
    178 updateCache REPO Ubuntu12 MULTICAST 9000:full:239.194.17.2:70M:20:120
    179 restoreImage REPO Ubuntu12 UNICAST
    180 restoreImage REPO Ubuntu12 MULTICAST 9000:full:239.194.17.2:70M:20:120
    181 }}}
    182 
    183 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.
    184 
    185 == Compatibilidad varios repositorios y varias unidades organizativas ==
    186144En 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.
    187145
    188 Una posibilidad sería incluirla en el argumento del repo separada por dos puntos:
    189 
    190 {{{
    191 $REPO=$IPREPO|REPO[:$OGUNIT]
    192 }}}
    193 Por ejemplo:
    194 {{{
    195 restoreImage 10.1.15.2:cdc Ubuntu12 1 2
    196 }}}
     146En 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.
    197147
    198148== Unificar el montaje de ogimages en un único paso ==