Compare commits

...

2 Commits

38 changed files with 682 additions and 36 deletions

Binary file not shown.

After

Width:  |  Height:  |  Size: 169 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 83 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 109 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 70 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 64 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 137 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 175 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 133 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 90 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 125 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 128 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 109 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 63 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 166 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 107 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 98 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 144 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 116 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 116 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 108 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 100 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 94 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 112 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 106 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 128 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 119 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 103 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 104 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 112 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 138 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 132 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 95 KiB

View File

@ -0,0 +1,357 @@
# OgGit - Gestión de imágenes Git
## Introducción a OgGit
El componente OgGit está diseñado para gestionar un tipo de imagen de sistema: las imágenes Git. A diferencia de las imágenes monolíticas gestionadas por ogRepository, las imágenes Git permiten capturar el contenido completo de una partición y versionarlo dentro de un repositorio Git, proporcionando una solución robusta y eficiente para el control de cambios, auditoría y reversión de estados en entornos de laboratorio y aula.
Las imágenes Git se crean a partir de una partición del sistema (por ejemplo, un sistema operativo Windows o Linux previamente instalado), y una vez generadas, son almacenadas en un servidor Forgejo, una instancia de Git autoalojada y adaptada para la gestión de múltiples repositorios desde el entorno web. Estas imágenes permiten no solo capturar el estado del sistema en un momento dado, sino también realizar commits incrementales, clonar configuraciones, recuperar archivos individuales y comparar versiones, entre otras operaciones avanzadas.
El flujo de trabajo de OgGit se apoya en varias capas:
- Captura del contenido del sistema: se extraen todos los archivos y carpetas de una partición del cliente.
- Inicialización y mantenimiento de repositorios Git: cada imagen Git se guarda como un repositorio individual en Forgejo, que permite operaciones estándar de Git como commits, ramas, merges o clonado.
- Visualización y gestión desde el interfaz web: gracias a la integración con Forgejo, los administradores pueden consultar el historial de cambios, explorar el contenido del sistema capturado y verificar auditorías desde una interfaz visual.
## ¿Por qué usar imágenes Git?
Las imágenes Git representan una evolución en la gestión de sistemas, especialmente útil en entornos educativos, de desarrollo o pruebas, donde los equipos pueden cambiar constantemente. Sus ventajas incluyen:
- **Versionado completo** del sistema.
- **Acceso a contenido granular** (ver archivos modificados).
- **Restauraciones más rápidas** y específicas.
## Acceso a la gestión de imágenes Git
1. En el menú lateral izquierdo, haz clic en `Repositorios`.
2. Localiza el repositorio deseado.
3. Haz clic en el botón de gestión Git para acceder a la gestión de commits del repositorio seleccionado.
![Acceso a imágenes Git](../assets/images/screenshots/oggui-ogrepository-oggui-menu-access.png)
---
## Lista de commits
Una vez dentro del menú de gestión Git del repositorio, se muestra una tabla con todos los commits disponibles en la rama seleccionada.
- Puedes cambiar de repositorio y rama desde los desplegables superiores.
- También puedes buscar commits por mensaje.
- La tabla muestra información básica como el ID del commit, el mensaje, la fecha, el tamaño, el número de archivos modificados y los tags asignados.
![Lista de commits Git](../assets/images/screenshots/oggui-ogrepository-oggui-menu.png)
### Acciones disponibles por commit
En la columna de acciones (última columna), se pueden realizar las siguientes operaciones:
- Ver archivos modificados (si los hay).
- Ver detalles del commit.
- Asignar etiquetas (tags).
- Restaurar el sistema al estado de ese commit.
---
## Ver detalles del commit
Al pulsar el botón de detalles, se abre un cuadro modal con los datos completos del commit seleccionado:
- Commit ID
- Mensaje
- Fecha
- Tamaño
- Número de archivos modificados
- Líneas añadidas y eliminadas
- Tags asignados
![Detalles del commit](../assets/images/screenshots/oggui-ogrepository-oggui-commit-details.png)
---
## Ver información del repositorio
En la esquina superior derecha de la ventana de commits se encuentra el botón `Ver información`. Al pulsarlo, se muestra un resumen con los metadatos del repositorio Git:
- Nombre del repositorio
- UUID
- Rama seleccionada
- Total de repositorios Git disponibles
- Total de ramas
- Total de commits
![Información del repositorio](../assets/images/screenshots/oggui-ogrepository-oggui-repository-details.png)
---
## Notas
- Estas imágenes Git se generan automáticamente desde la partición del sistema del cliente, y son útiles para mantener una trazabilidad de los cambios realizados.
- Puedes utilizar esta sección para auditar el historial de cambios, clonar imágenes entre clientes o realizar restauraciones específicas desde un commit.
- Los repositorios Git están gestionados internamente por el componente `OgGit`, y pueden consultarse a través de la API REST o desde la interfaz web oggui.
## Crear imagen Git
### Requisitos Previos y Consideraciones Críticas
Antes de iniciar el proceso, verifique que se cumplen las siguientes condiciones en el cliente. Ignorarlos puede resultar en una imagen corrupta, incompleta o en fallos durante la captura.
### Requisitos previos para crear una imagen Git
1. **Sistema estable e íntegro**
- El sistema operativo del cliente debe estar libre de errores de archivos, configuraciones corruptas y fallos de hardware.
- _Recomendación:_ Ejecute comprobaciones de integridad del disco (por ejemplo, `chkdsk /f` en Windows o `fsck` en Linux) y asegúrese de que el sistema arranca sin errores.
2. **Deshabilitar compresión de sistema**
- Los directorios del sistema no deben estar comprimidos mediante herramientas como compresOS o la compresión nativa de Windows NTFS.
- _Cómo comprobarlo:_
- **Windows:** Ejecuta `fsutil fsinfo volumeinfo C:` y verifica que `Supports File-based Compression` esté deshabilitado.
- **Linux:** Comprueba que no se utilicen sistemas de archivos comprimidos (por ejemplo, revisa las opciones de montaje en `/etc/fstab`).
3. **Espacio suficiente en la partición de caché**
- El cliente debe disponer de una partición de caché con espacio libre suficiente para almacenar temporalmente todos los datos extraídos.
- _Regla general:_ El espacio libre debe ser al menos 1.5 veces el tamaño de los datos utilizados en la partición de origen. La falta de espacio provocará el aborto inmediato del proceso.
Asegúrate de cumplir estos requisitos antes de continuar con los pasos detallados a continuación para garantizar una imagen Git fiable y utilizable.
El proceso de creación de una imagen Git se puede dividir en varias fases:
1. **Selección del cliente modelo** encendido en Oglive.
2. **Elección del repositorio Git** (o creación de uno nuevo en caso de que sea la primera vez que se crea una imagen Git para ese cliente).
3. **Selección de la partición del disco** concretamente la que contiene el sistema operativo a capturar.
4. **Ejecución del comando** y seguimiento desde la traza de ejecución.
### Paso 1: Acceder a la acción "Crear imagen"
Desde el panel de administración web:
- Ir a la pestaña **Grupos**.
- Seleccionar la **Unidad Organizativa** deseada.
- Localizar el cliente encendido que actuará como equipo modelo.
- Pulsar el icono de acciones del cliente.
- Elegir **Crear imagen**.
### Paso 2: Seleccionar tipo de imagen "Git"
En el formulario de creación de imagen, se muestra por defecto la opción **Monolítica**. Para trabajar con OgGit:
- Desplegar el selector de **Tipo de imagen**.
- Seleccionar la opción **Git**.
Esto activará nuevas secciones específicas para la configuración Git.
![Información del repositorio](../assets/images/screenshots/oggui-ogrepository-oggui-create-image-new-repository.png)
### Paso 3: Crear un nuevo repositorio
Si es la primera vez que se crea una imagen Git para ese cliente, es necesario crear un nuevo repositorio asociado. Para ello:
- Pulsar el botón **Crear nuevo repositorio / SO**.
- Introducir un nombre identificativo, por ejemplo: `windows11-documentation`.
- Pulsar **Guardar**.
Una vez creado el repositorio, quedará vinculado al cliente y aparecerá en el selector desplegable para futuras operaciones.
![Información del repositorio](../assets/images/screenshots/oggui-ogrepository-oggui-create-image-new-repository-add-name.png)
> **Un solo repositorio por cliente:**
> Cada cliente solo puede tener asociado un único repositorio Git. Si ya existe uno, no podrá crearse un segundo.
### Paso 4: Seleccionar partición del disco
A continuación se presenta una tabla con las particiones detectadas en el cliente:
- Disco y número de partición
- Tamaño en MB
- Tipo de partición (EFI, WINDOWS, CACHE, etc.)
- Sistema de ficheros (NTFS, EXT4, etc.)
- Sistema operativo detectado
Seleccionar aquella partición que contenga el sistema operativo que se desea capturar, por ejemplo:
> Disco 1, Partición 3: NTFS, Windows 11 Home 64 bits.
![Información del repositorio](../assets/images/screenshots/oggui-ogrepository-oggui-create-image-new-repository-select-partition.png)
### Paso 5: Ejecutar la acción y seguimiento
Una vez configurado el repositorio y seleccionada la partición:
- Pulsar el botón **Ejecutar**.
- Se iniciará el proceso de captura y aparecerá una nueva entrada en el panel de **Trazas de ejecución**.
![Información del repositorio](../assets/images/screenshots/oggui-ogrepository-oggui-create-image-new-repository-traza.png)
El cliente arrancado con ogLive mostrará en su pantalla local los comandos en ejecución. Se puede observar, por ejemplo, el montaje del repositorio Git remoto en `/mnt/sda3` y la ejecución del script `crearImagenGit`.
![Información del repositorio](../assets/images/screenshots/oggui-ogrepository-oggui-create-image-new-repository-traza-client.png)
#### Duración y rendimiento
La duración del proceso depende de:
- Tamaño de la partición.
- Número de ficheros y cambios detectados.
- Velocidad de lectura/escritura en disco.
- Conectividad con el servidor del repositorio.
En sistemas con gran volumen de datos (como Windows 11 con varias particiones) el proceso puede extenderse varios minutos.
---
## Visualizar el repositorio en Forgejo
Una vez creada la imagen Git, esta puede consultarse desde la interfaz Forgejo:
1. Entrar en la dirección web del servidor de Git (Forgejo).
2. Navegar al repositorio del cliente, por ejemplo `oggit/windows11-lgromero`.
Se pueden explorar:
- Archivos y directorios del sistema capturado.
- Historial de commits.
- Diferencias entre versiones.
- Cambios en binarios y textos.
Esto permite una inspección avanzada del contenido exacto capturado, ideal para diagnóstico y auditoría.
## Restauración de una Imagen Git
### Introducción
El proceso de restauración de una imagen Git permite desplegar una versión específica de un sistema capturado previamente en uno o más clientes. A diferencia de las imágenes monolíticas, las imágenes Git permiten seleccionar puntos concretos de restauración (commit, rama, tag) gracias al control de versiones.
### Requisitos Previos
- Tener al menos una imagen Git creada y almacenada en un repositorio Forgejo/Gitea.
- El cliente destino debe tener asignado un repositorio en su configuración.
- El cliente debe estar particionado previamente con el tamaño adecuado y el sistema de archivos correcto.
- El cliente debe tener partición CACHE.
- El cliente en estado ogLive para realizar la operación.
### Procedimiento de Restauración
#### Paso 1. Acceder a la Herramienta de Despliegue
Desde el panel de administración web:
- Ir a la pestaña **Grupos**.
- Seleccionar la **Unidad Organizativa** deseada.
- Localizar el cliente encendido que actuará como equipo modelo.
- Pulsar el icono de acciones del cliente.
- Elegir **Desplegar imagen**.
### Paso 2: Seleccionar tipo de imagen "Git"
En el formulario de creación de imagen, se muestra por defecto la opción **Monolítica**. Para trabajar con OgGit:
- Desplegar el selector de **Tipo de imagen**.
- Seleccionar la opción **Git**.
Esto activará nuevas secciones específicas para la configuración Git.
![Información del repositorio](../assets/images/screenshots/oggui-ogrepository-oggui-restore-image-repository.png)
#### 3. Especificar la Versión de la Imagen
| Parámetro | Ejemplo | Descripción |
|-------------------------|----------------------------------------------|--------------------------------------------------|
| Tipo de imagen | Git | Seleccione "Git" como tipo de imagen |
| Seleccionar Repositorio | windows11-documentation | Elija el repositorio que contiene la imagen |
| Seleccionar Rama | main | Seleccione la rama del repositorio |
| Commit ID | a7915357bc7b337cf49c59bee6d4242e578ab44 | Identificador hash del commit específico |
| Mensaje | creating git image | Mensaje descriptivo para la operación |
| Fecha | 11/09/2025 10:02:08 | Fecha y hora de la versión a restaurar |
| Tags | opcional | Etiquetas para categorizar la operación |
#### 4. Selección de Partición de Destino
Seleccione la partición donde desea restaurar la imagen:
![Información del repositorio](../assets/images/screenshots/oggui-ogrepository-oggui-restore-image-repository-select-partition.png)
#### 5. Opciones de Ejecución
- **Ejecutar:** Inicia la restauración inmediatamente.
- **Generar instrucciones:** Crea un script para ejecutar la restauración manualmente.
- **Opciones de programación:** Permite programar la restauración para una fecha futura.
---
### Consideraciones Importantes
- **Restauración Incremental:** La restauración de imágenes Git solo transfiere los cambios respecto a la versión actual, optimizando tiempo y ancho de banda.
- **Conectividad:** Asegúrese de que el cliente tenga conexión de red estable con el servidor Forgejo/Gitea durante el proceso.
- **Compatibilidad:** Verifique que la imagen Git sea compatible con el hardware del cliente destino.
- **Espacio en Disco:** Confirme que la partición de destino tenga espacio suficiente para la imagen restaurada.
## Ejemplo práctico:
### Ejemplo práctico: Organización de ramas y tags en OgGit
Supongamos que partimos de un repositorio con la siguiente estructura inicial:
```
main (rama principal)
├── v1.0-estable (tag)
└── desarrollo (rama)
└── experimentos varios
```
El objetivo es evolucionar el repositorio siguiendo buenas prácticas para llegar a:
```
main (rama principal)
├── v1.0-estable (tag)
├── v1.1-autocad (tag)
├── profesor-autocad (rama)
│ ├── commit: instalación base
│ └── commit: configuración AutoCAD
└── desarrollo (rama)
└── experimentos varios
```
#### Pasos recomendados
1. **Crear una rama específica para el profesor**
- Desde la interfaz de OgGit, selecciona el commit base en `main` y crea una nueva rama llamada `profesor-autocad`.
- Esto permite trabajar en configuraciones específicas sin afectar la rama principal.
![Información del repositorio](../assets/images/screenshots/oggui-ogrepository-oggui-example-create-branch.png)
2. **Realizar commits temáticos**
- En la rama `profesor-autocad`, realiza un commit tras instalar la base del sistema.
- Realiza un segundo commit tras instalar y configurar AutoCAD.
- Añade mensajes descriptivos para cada commit, por ejemplo:
- `instalación base`
- `configuración AutoCAD`
![Información del repositorio](../assets/images/screenshots/oggui-ogrepository-oggui-example-create-image-professor.png)
3. **Etiquetar versiones estables**
- Una vez verificado el funcionamiento, asigna un tag a la rama principal (`main`) tras fusionar los cambios relevantes, por ejemplo:
- `v1.1-autocad`
![Información del repositorio](../assets/images/screenshots/oggui-ogrepository-oggui-example-branch-professor-create-tag-autocad.png)
4. **Mantener ramas de desarrollo separadas**
- Continúa usando la rama `desarrollo` para pruebas y experimentos, evitando mezclar cambios no validados en `main` o `profesor-autocad`.
#### Buenas prácticas
- Utiliza ramas para separar configuraciones o perfiles de usuario (por ejemplo, profesor, alumno, laboratorio).
- Realiza commits frecuentes y descriptivos para facilitar auditoría y restauración.
- Usa tags para marcar versiones estables y facilitar despliegues.
- Fusiona cambios a `main` solo tras validar que funcionan correctamente.
#### Resultado final
El repositorio mostrará una estructura clara y organizada, facilitando restauraciones específicas, auditoría y gestión eficiente de versiones.

View File

@ -0,0 +1,118 @@
# ogLive
**ogLive** es el sistema operativo ligero que se ejecuta temporalmente en los clientes gestionados por OpenGnsys. Se encarga de ejecutar las órdenes enviadas desde la consola web, como la creación de imágenes, el despliegue de sistemas operativos o la ejecución de comandos remotos.
ogLive está basado en Linux y se distribuye en formato ISO. Su gestión completa (descarga, instalación, selección por defecto, cacheado, etc.) se realiza desde el componente **ogboot**, por lo que en esta sección nos centraremos únicamente en el comportamiento de ogLive una vez que ha arrancado en el cliente.
---
## ¿Qué ocurre al arrancar ogLive?
Cuando un cliente se inicia en modo PXE, se le envía:
- El núcleo (`ogvmlinuz`) con los parámetros de arranque necesarios obtenidos desde la plantilla PXE asignada
- El initrd (`oginitrd.img`)
Estos archivos son montados en memoria, iniciando un entorno de Linux desde el que se puede interactuar con la consola web de OpenGnsys.
> **Nota:**
> La máquina cliente debe tener al menos 1.5 GB de RAM para que ogLive funcione correctamente.
Una vez operativo, el cliente carga y renderiza automáticamente una interfaz gráfica accesible por web (**ogBrowser**), que permite visualizar el estado del sistema, ver las particiones detectadas y recibir comandos directamente desde el servidor central.
---
## Interfaz del cliente ogLive
La interfaz gráfica que se presenta tras el arranque muestra las particiones del sistema, indicando:
- **Número de disco y partición**
- **Tamaño de la partición**
- **Tipo de sistema de archivos** (FAT32, NTFS, EXT4, CACHE, etc.)
- **Sistema operativo detectado**, si lo hay
- **Acciones disponibles**, como arrancar un sistema instalado
Además, ofrece botones para reiniciar o apagar el cliente, así como un terminal inferior (modo técnico) para interacción directa.
---
## Asignación del menú ogLive
El contenido de la interfaz web que se muestra al arrancar ogLive puede personalizarse desde la consola web de OpenGnsys. Para ello:
1. Accede a la sección **Clientes** y edita el cliente deseado.
2. En el formulario de edición, localiza el campo **Menú**.
3. Selecciona uno de los menús disponibles.
4. Guarda los cambios.
Este menú determina qué archivos HTML o interfaces se cargan en el navegador del cliente cuando se ejecuta ogLive.
---
## Arquitectura y dependencias
El correcto funcionamiento de ogLive requiere:
- Haber configurado previamente un ogLive válido desde **ogboot**
- Que el cliente tenga acceso a los archivos de arranque por **TFTP/HTTP**
- Que el navegador embebido (**ogBrowser**) se comunique correctamente con el servidor web de OpenGnsys
El sistema utiliza **Qt6** sobre **Sway** como entorno gráfico, y se ejecuta en memoria para evitar alteraciones en el disco del cliente.
---
## Notas adicionales
- Se recomienda que el ogLive cargado por defecto esté cacheado en el cliente si se van a realizar operaciones intensivas, para reducir tráfico de red.
- El arranque de ogLive puede automatizarse mediante plantillas PXE personalizadas.
- Si el menú seleccionado en el cliente apunta a una URL no válida o inaccesible, la interfaz gráfica no se mostrará correctamente.
---
## Gestión de menús de inicio personalizados
OpenGnsys permite definir menús personalizados que serán renderizados en el cliente al arrancar mediante el navegador embebido ogbrowser. Estos menús se utilizan como interfaz de instalación para el usuario, ofreciendo opciones como "Instalar Windows", "Instalar GNU/Linux" o "Apagar el equipo". La personalización de estos menús permite adaptar la experiencia de arranque a distintos grupos de ordenadores, aulas, o necesidades específicas de despliegue.
Cada menú creado dispone de una URL pública única, la cual será asignada a los clientes desde la interfaz de administración. Esta URL es accedida automáticamente por ogbrowser tras el arranque del sistema ogLive.
### Crear un nuevo menú
Para dar de alta un nuevo menú personalizado, accede al módulo lateral **Menús** y pulsa sobre el botón **Añadir menú** situado en la parte superior derecha. Se abrirá un formulario como se muestra en la imagen:
![oggui-oglive-menu-add.png](oggui-oglive-menu-add.png)
**Los campos requeridos son:**
- **Nombre del menú:** identificador único que se usará tanto en la lista de menús como en la URL pública.
- **Resolución:** resolución base del menú para su diseño. Debe coincidir con la resolución del cliente o de la mayoría de los equipos destino (por ejemplo, 1920x1080).
- **Comentarios (opcional):** anotaciones internas sobre el propósito del menú.
- **Menú por defecto:** si se marca esta casilla, el menú quedará asignado como predeterminado para todos los clientes que no tengan uno asignado explícitamente.
Una vez completado el formulario, pulsa en **Guardar**. El menú quedará registrado y aparecerá en la tabla principal de menús.
---
### Consultar y editar un menú existente
En la tabla de menús creados, puedes ver información relevante de cada menú:
- **Nombre del menú**
- **URL pública:** dirección web completa a la que apuntará ogbrowser al arrancar (por ejemplo, `https://127.0.0.1:8443/menu/main`)
- **Estado por defecto:** si es el menú predeterminado
- **Resolución**
- **Fecha de creación**
- **Acciones disponibles:** editar o eliminar
Al pulsar sobre el botón de edición, se accede a un panel que muestra una vista previa en tiempo real del menú renderizado. Este renderizado es el que se presentará en el cliente a través del navegador ogbrowser.
![oggui-oglive-menu.png](oggui-oglive-menu.png)
En esta vista puedes:
- Modificar el nombre, resolución y comentarios del menú.
- Visualizar en tiempo real el resultado HTML del menú.
- Marcarlo como predeterminado.
- Guardar los cambios realizados.
![oggui-oglive-menu-edit.png](oggui-oglive-menu-edit.png)

View File

@ -1,55 +1,225 @@
# ogrepository
El componente OgRepository de OpenGnsys es el encargado de almacenar, organizar y distribuir las imágenes de sistema que serán desplegadas en los equipos cliente. Estas imágenes representan un estado completo del sistema operativo, las configuraciones y las aplicaciones instaladas en un equipo de referencia, y permiten clonar ese entorno a múltiples máquinas de forma automatizada y controlada.
OgRepository actúa como un repositorio central o distribuido, permitiendo a los administradores mantener una colección organizada de imágenes y controlar su disponibilidad, distribución y verificación.
El módulo ogrepository ofrece una interfaz web dentro de OpenGnsys para realizar las siguientes acciones:
- Crear imágenes monolíticas de un sistema operativo a partir de un cliente previamente arrancado con ogLive.
- Consultar el listado de imágenes disponibles en un repositorio.
- Eliminar imágenes no utilizadas.
- Descargar o importar imágenes desde otros servidores o dispositivos.
- Asignar imágenes a un determinado cliente o grupo de clientes.
## Introducción a ogRepository
El sistema permite dos tipos de imágenes, cada una con sus propias características y casos de uso.
## Tipos de imágenes
El componente **ogRepository** se encarga de almacenar, gestionar y distribuir las imágenes del sistema operativo utilizadas para clonar equipos en entornos de laboratorio o aula.
1. Imágenes monolíticas
Las imágenes monolíticas almacenan el contenido completo del sistema de archivos del cliente en un único fichero comprimido. Estas imágenes se crean a partir de un cliente configurado previamente y se restauran íntegramente sobre otro equipo, sobrescribiendo su contenido.
Funciona en conjunción con el `ogServer` y los clientes, proporcionando una interfaz web centralizada para realizar todas las operaciones de gestión: visualización, importación, exportación, verificación de integridad y eliminación de imágenes.
El fichero resultante suele tener extensión .img y se almacena en el repositorio asignado al cliente.
### Arquitectura y Flujo de Trabajo
1. **Creación:** Las imágenes se crean desde un cliente arrancado via `ogLive`.
2. **Almacenamiento:** Se almacenan en el directorio del `ogRepository` asignado a ese cliente.
3. **Consulta:** El `ogServer` consulta al repositorio para obtener la lista de imágenes disponibles.
4. **Restauración:** Durante una operación de clonación, la máquina cliente descarga la imagen desde el repositorio (vía Unicast, Multicast o P2P/BitTorrent).
No es posible restaurar parcialmente una imagen monolítica: siempre se transfiere el contenido completo, incluso si sólo han cambiado unos pocos ficheros.
## Tipos de Imágenes Gestionadas
Su uso es recomendado cuando se desea una imagen "maestra" estable y uniforme para ser desplegada en múltiples equipos de un aula o laboratorio.
ogRepository es compatible con dos tipos de imágenes, cada una diseñada para diferentes casos de uso:
2. Imágenes Git
Las imágenes Git permiten almacenar los cambios realizados en el sistema de archivos en un repositorio Git. A diferencia del enfoque monolítico, esta modalidad permite controlar versiones, gestionar ramas y realizar operaciones como sincronización o copia incremental.
| Tipo | Descripción | Formato | Caso de Uso Ideal |
| :--- | :--- | :--- | :--- |
| **Imágenes Monolíticas** | Captura completa y comprimida de una partición. Es una réplica exacta del sistema de archivos en el momento de la captura. | Archivo `*.img.zst` (compresión Zstandard) | Entornos estables, imágenes base inmutables, restauraciones rápidas y sencillas. |
| **Imágenes Git** | Imágenes versionadas que almacenan cambios incrementales. Gestionadas por el componente `OgGit`. | Repositorio Git (normalmente en Forgejo/Gitea) | Entornos con cambios frecuentes, needing auditoría de cambios, reversión de estados y optimización de espacio y ancho de banda. |
Cada imagen se guarda en un repositorio .git bajo el directorio /opt/opengnsys/images/.
### Archivos Asociados a Imágenes Monolíticas
Es posible restaurar únicamente los cambios realizados desde una versión anterior.
Cada imagen monolítica genera una serie de archivos auxiliares esenciales para su gestión e integridad:
Esta funcionalidad es gestionada por el componente complementario oggit, y se trata más adelante en este manual.
| Archivo | Propósito |
| :--- | :--- |
| **`<nombre>.img.zst`** | La imagen comprimida en sí misma (formato Zstandard). |
| **`<nombre>.sum`** | Suma de verificación SHA256 para validar la integridad del archivo de imagen. |
| **`<nombre>.size`** | Contiene el tamaño de la imagen comprimida, usado para cálculos de progreso. |
| **`<nombre>.info.checked`** | Metadatos de la imagen (cliente origen, partición, tipo de compresor, tamaño real, etc.). |
| **`<nombre>.torrent`** | Metadatos para habilitar la distribución eficiente de la imagen via protocolo BitTorrent (P2P). |
Nota: Aunque ambas imágenes se almacenan en el mismo servidor, utilizan formatos distintos y no son intercambiables.
### Acciones disponibles en la interfaz web
- Consultar el listado de imágenes disponibles en el repositorio.
- Ver los detalles técnicos de cada imagen: nombre, tamaño, cliente origen, partición, tipo de clonador, etc.
- Comprobar su integridad mediante sumas de verificación.
- Importar imágenes externas previamente generadas.
- Exportar imágenes para su traslado o respaldo en otros entornos.
- Eliminar imágenes individualmente o en bloque.
### Consideraciones
## Consideraciones
- Cada cliente debe tener asignado un repositorio de imágenes en su configuración. Las imágenes creadas se almacenarán en dicho repositorio.
- Las imágenes deben ser creadas a partir de clientes previamente arrancados mediante ogLive, y correctamente preparados (sin usuarios conectados, sin procesos en ejecución críticos, etc.).
- Las imágenes deben ser creadas a partir de clientes previamente arrancados mediante ogLive y correctamente preparados (sin usuarios conectados, sin procesos en ejecución críticos, etc.).
- Se recomienda mantener una nomenclatura clara y estandarizada para facilitar la identificación de las imágenes.
- El espacio del servidor debe ser suficiente para albergar las imágenes generadas, especialmente en el caso de restauraciones o sincronizaciones masivas.
---
## Alta de un repositorio en la GUI
1. Entra en la interfaz web de OpenGnsys con un usuario administrador.
2. En el menú lateral, pulsa **Repositorios**.
![oggui-ogrepository-main.png](../assets/images/screenshots/oggui-ogrepository-main.png)
3. Pulsa **Añadir repositorio**.
![oggui-ogrepository-repository-options.png](../assets/images/screenshots/oggui-ogrepository-repository-options.png)
4. Rellena el formulario:
- **Nombre del repositorio:** Un identificador legible (p. ej. `repository-test`).
- **IP:** La IP del servidor ogRepository (p. ej. `192.168.3.3`).
- **Puerto SSH:** Valor que utilizará el sistema para algunas acciones como transferir imágenes (p. ej. `22`).
- **Usuario:** Usuario de sistema con el que ogCore se conectará al repositorio (p. ej. `opengnsys`).
- **Comentarios:** Información adicional (Opcional).
5. Pulsa **Guardar**.
---
### Comprobación rápida
- Tras guardar, el nuevo registro debe aparecer en la tabla de **Administrar repositorios**.
- Usa el botón **Imágenes monolíticas** del repositorio para abrir el inventario de imágenes. Si todo está correcto, verás la lista y podrás pulsar **Ver información** para inspeccionar el JSON.
![oggui-ogrepository-repository-info.png](../assets/images/screenshots/oggui-ogrepository-repository-info.png)
> **Nota:**
> Los inventarios que se muestran provienen de `repoinfo.json` / `trashinfo.json` en el servidor ogRepository.
> Si el repositorio es nuevo, estos ficheros estarán vacíos hasta que se cree la primera imagen desde un cliente.
---
## Asignar un repositorio a un cliente
1. Ve a **Grupos** (o al listado donde gestionas los clientes).
2. En la tarjeta del cliente, abre el menú ⋮ y pulsa **Editar**.
3. En el formulario, localiza el campo **Repositorios** y selecciona el repositorio que acabas de crear (p. ej. `repository-test`).
4. Revisa el resto de campos (OgLive, interfaz, MAC, IP, plantilla PXE, etc.) y pulsa **Guardar**.
![oggui-ogrepository-asign-repository-client.png](../assets/images/screenshots/oggui-ogrepository-asign-repository-client.png)
Esta asignación tiene las siguientes implicaciones:
- Ese cliente tendrá acceso a las imágenes almacenadas en el repositorio asignado, pudiendo restaurar cualquiera de ellas según sea necesario.
- Las imágenes creadas desde ese cliente se guardarán automáticamente en el repositorio seleccionado.
- Si tienes varios repositorios, puedes asignar repos diferentes a distintos clientes o aulas, optimizando el tráfico de red.
---
## Verificación
- Desde **Repositorios → Imágenes monolíticas** del repo asignado, confirma que la imagen objetivo existe.
- En el cliente (cuando arranque ogLive), podrás lanzar operaciones que consumirán este repositorio.
---
## Añadir manualmente una imagen al repositorio
En algunos casos, puede ser necesario importar manualmente una imagen monolítica ya existente en el sistema de archivos del servidor ogRepository. Este proceso es útil cuando una imagen `.img` ha sido generada previamente o transferida desde otro servidor, y no ha sido registrada aún en la base de datos del componente.
Para añadir una imagen manualmente, sigue estos pasos:
### 1. Renombrar la imagen
El archivo `.img` debe tener un nombre válido, sin espacios ni caracteres especiales, y sin la extensión al ser registrado en la interfaz. Por ejemplo, si la imagen representa un sistema Ubuntu BIOS, se puede renombrar de la siguiente manera:
```bash
mv imagen.img /opt/opengnsys/ogrepository/images/ubuntu-imagen-bios-documentation.img
```
> **Importante:**
> Asegúrate de que el nombre no contenga la extensión `.img` al registrarlo en la interfaz (solo el nombre base será introducido).
### 2. Mover la imagen al directorio de imágenes
La imagen debe ubicarse en el directorio gestionado por ogRepository:
Ejemplo:
```bash
mv ubuntu-imagen-bios-documentation.img /opt/opengnsys/ogrepository/images/
```
### 3. Ajustar los permisos
Es necesario que el archivo `.img` tenga como propietario el usuario `opengnsys` para que el backend pueda manipularlo correctamente:
```bash
chown opengnsys:opengnsys /opt/opengnsys/ogrepository/images/ubuntu-imagen-bios-documentation.img
chmod 744 /opt/opengnsys/ogrepository/images/ubuntu-imagen-bios-documentation.img
```
### 4. Importar la imagen desde la interfaz web
Una vez el archivo esté correctamente ubicado y con los permisos apropiados, se debe registrar en el sistema desde la interfaz web:
- Accede al apartado **Repositorio** de la interfaz de OpenGnsys.
- Haz clic en el botón **Importar imagen**.
- Se abrirá una ventana emergente solicitando el nombre de la imagen.
- Introduce el nombre sin la extensión:
```
ubuntu-imagen-bios-documentation
```
- Haz clic en **Continuar**.
![Añadir imagen](oggui-ogrepository-repository-add-image.png)
---
## Acciones disponibles sobre una imagen
Desde la interfaz de ogRepository, es posible gestionar las imágenes monolíticas mediante un menú contextual que aparece junto al icono de opciones (⋮). Este menú permite ejecutar distintas acciones sobre una imagen ya registrada en el repositorio.
![Opciones de imagen](oggui-ogrepository-repository-options.png)
A continuación se describen todas las acciones disponibles:
### Obtener ficheros auxiliares
Esta opción genera los archivos auxiliares necesarios para que la imagen pueda ser desplegada correctamente en los clientes. Los archivos generados incluyen:
- `.torrent`: archivo para transmisiones P2P.
- `.sum`: hash de verificación de integridad (SHA256).
- `.info.checked`: metadatos de validación (tamaño, hash, tipo de sistema de archivos, etc.).
- `.size`: tamaño en bloques de la imagen, usado en el cálculo de progreso de restauración.
- `.meta`: archivo opcional con metainformación adicional.
**Nota:** Esta acción debe ejecutarse siempre tras importar manualmente una imagen al repositorio.
### Eliminar permanentemente
Elimina completamente la imagen del repositorio, tanto en la base de datos como en el sistema de archivos del servidor. Esta acción es irreversible.
**Nota:** Si la imagen fue eliminada previamente, pero aún está en papelera, esta opción la elimina definitivamente.
### Recuperar imagen de la papelera
Permite restaurar una imagen previamente eliminada, que ha sido enviada a la papelera lógica del sistema. La imagen volverá a estar disponible para uso inmediato.
**Nota:** Esta opción solo está activa si la imagen se encuentra en estado "eliminado".
### Transferir imagen
Permite transferir la imagen desde el servidor actual a otro servidor ogRepository de la red. Se debe especificar la IP, puerto SSH y usuario del servidor destino. La transferencia se realiza mediante SCP y requiere que el usuario tenga permisos de escritura en el directorio de imágenes del servidor destino.
![Transferir imagen](oggui-ogrepository-repository-transferir-image.png)
**Nota:** Esta función es útil para clonar imágenes entre servidores sin necesidad de exportarlas manualmente.
### Transferir imagen globalmente
Similar a la opción anterior, pero la imagen se marca como "global" una vez completada la transferencia. Las imágenes globales están disponibles para ser vistas y utilizadas por todos los servidores de la red, según la configuración distribuida de OpenGnsys.
**Nota:** Requiere permisos administrativos y configuración previa de los nodos de red.
### Realizar backup
Genera una copia de seguridad de la imagen actual. El destino del backup puede ser configurado, ya sea en otro disco local o en un servidor remoto (NFS, SSH, etc.).
La copia puede incluir solo el archivo `.img` o todos los archivos asociados a la imagen.
### Checkear estado imagen
Verifica la integridad de la imagen comprobando que:
- El archivo `.img` existe y es accesible.
- El archivo `.sum` coincide con el hash actual del `.img`.
- Los archivos auxiliares están presentes y no están corruptos.
Esta opción es útil para diagnosticar errores antes de realizar una restauración.
### Renombrar imagen
Permite modificar el nombre lógico de la imagen dentro del sistema, actualizando su referencia en la base de datos.
**Nota:** Esta acción no renombra el archivo físico en el sistema de archivos. Solo afecta al nombre mostrado y registrado en la base de datos.

View File

@ -40,7 +40,7 @@ Antes de definir una tabla de particiones se recomienda tener en cuenta:
| FREEBSD, SOLARIS, … | Sistemas nativos correspondientes | Para sistemas alternativos (no habituales) |
!!! note "Nota"
El sistema identifica partición CACHE como tal, pero internamente utiliza un sistema de archivos EXT4 con configuración específica.
El sistema identifica partición CACHE como tal, pero internamente utiliza un sistema de archivos EXT4 con configuración específica. Sin embargo es importante marcar el tipo CACHE para que OpenGnsys la gestione correctamente.
## La partición CACHE

View File

@ -120,6 +120,7 @@ nav:
- Motor de Clonación: administration/ogcloneengine.md
- Gestión de discos y particiones: administration/particionador.md
- Gestión de Repositorios: administration/ogrepository.md
- Gestión de Imágenes Git: administration/oggit.md
- ogAgent: administration/ogagent.md
- Logs y Monitorización: administration/oglog.md
- Desarrolladores: