Changes between Version 2 and Version 3 of Version1.0.1-PRE


Ignore:
Timestamp:
May 25, 2011, 2:39:27 PM (14 years ago)
Author:
adv
Comment:

Info para la version 1.0.1

Legend:

Unmodified
Added
Removed
Modified

  • Version1.0.1-PRE

    v2 v3  
    12121) Integración, en el comando Restaurar, del uso de transferencias con protocolos multicast y torrent.
    1313
     14
    14152) Integración, en el asistente Deploy, la opción de sólo updateCache (almacenar las imágenes en cache, para una posterior restauración)
    1516
    16 3) Mejoras en la gestión distribuida desde la interfaz WEB.
    17 Determinados clientes, denominados MASTER, pueden realizar ciertas tareas del Repositorio.   Dependiendo de que tipo de tareas, los clientes serán MASTER-REPOSITORIOS o MASTER.
    18 El MASTER-REPOSITORIO. Pude crear imágenes en su cache, restaurar directamente por unicast|multicast las particiones de los demás clientes con  una imagen almacenada en su cache, o en el repositorio(realizando multicast en una subred distinta a la del repositorio), y/o clonar el contenido de su propia partición. Requiere ser dado de alta como repositorio, sólo a efectos de poder controlar que imágenes contiene en su cache.
    19 El MASTER, es cualquier cliente que queramos usar el contenido de su partición para clonarla directamente en los demás clientes, o realizar una transferencia multicast en otra subred, de una archivo-imagen almacenado en el repositorio.
    2017
    21 4) Mejoras en la restauración de windows (testeado en XP y 7).
    22 Se permite restaurar/arrancar/iniciar un windows, en una partición distinta a la que se generó.
    23 Se permite tener varios windows totalmente independientes.
     183) Mejoras en el engine de clonación. Detección de tamaño de repositorios (global o local).
     19* En el caso de un deploy o updateCache, si no hay cache o espacio insufiente realiza un restoreImage desde el REPO (repositorio global) directamente a la partición del cliente por UNICAST.
     20
     21
     22
     234) Mejoras en la gestión distribuida desde la interfaz WEB.
     24* Determinados clientes, denominados MASTER, pueden realizar ciertas tareas del Repositorio.   
     25* Dependiendo de que tipo de tareas, los clientes serán MASTER-REPOSITORIOS o MASTER.
     26 * El MASTER-REPOSITORIO.
     27    * Pude crear imágenes en su cache
     28    * Enviar(unicast|multicast) un fichero-imagen almacenado en su cache directamente a la particion destino de los demás cliente. Restauración.
     29    * Inicio sesión multicast en subredes distinta al servidor repositorio opengnsys. Permite enviar una imagen por multicast en su subred distinta al REPO OG. El Master establece conxión unicast con el REPO OG, y realiza un multicast en los clientes de su subred.
     30    * Envía directamente por unicast|multicast una partición suya (sin tener fichero-imagen creada) a las particiones de los demás clientes. Clonación directa.
     31    * Requiere ser dado de alta como repositorio, sólo a efectos de poder controlar que imágenes contiene en su cache.
     32 * El MASTER, es cualquier cliente, que podrá realizar cualquier operacion indicada del Master-repositirio, a excepción de crear una imagen en su cache. El envio de ficheros-imagenes desde su cache, requiere un previo deploy o updateCache.
     33
     345) Mejoras en la restauración de windows (testeado en XP y 7).
     35* Se permite restaurar/arrancar/iniciar un windows, en una partición distinta a la que se generó.
     36* Se permite tener varios windows totalmente independientes.
     37
     386) Mejoras en el engine de acceso al registro.
     39* Genera una estrucutra con todos los ficheros "hive" que componen el registro de windows, incluyendo todos los usuarios que tengan en su perfil el .DAT.
    2440
    25415) Mejoras en el arranque del cliente OpenGnsys PXE  (ogclient).
    26 Los ficheros básicos de arranque por pxe, pueden ser almacenados en la cache del cliente.
    27 De esta manera el tiempo de arranque de un cliente OG, es siempre el mismo. Independientemente si se arranca un aula completa o hay transferencias torrent/multicast en la red.
     42* Los ficheros básicos de arranque por pxe, pueden ser almacenados en la cache del cliente.
     43* De esta manera el tiempo de arranque de un cliente OG, es siempre el mismo.
     44 * Independientemente si se arranca un aula completa o hay transferencias torrent/multicast en la red.
     45* Se permite modificar fácilmente dicho comportamiento.
     46
    2847
    29486) Seguimiento del comando inicio de sesión de los sistemas operativos.
    30 El proceso de iniciar sesión de la consola web, o localmente con el "browser", con determinados hardware en los clientes no funciona.
    31 La alternativa es realizar un reinicio completo, pero con seguimiento.  Este seguimiento, permitirá dos reinicios consecutivos al sistema operativo indicado (considerando la comprobación del sistema de archivos). En el próximo reinicio arranca el ogclient (opengnsys pxe), que podrá detectar si el inicio al sistema fue correcto.
     49* El proceso de iniciar sesión de la consola web, o localmente con el "browser", con determinados hardware en los clientes no funciona.
     50* La alternativa es realizar un reinicio completo, pero con seguimiento. 
     51 * Este seguimiento, permitirá dos reinicios consecutivos al sistema operativo indicado (considerando la comprobación del sistema de archivos).
     52 * En el próximo reinicio arranca el ogclient (opengnsys pxe), que podrá detectar si el inicio al sistema fue correcto.
     53
     54
    3255
    3356