1.- Se modifica mkdocs para que permita
1.1.- Enumerar automáticamente las secciones de toda la web. 1.2.- Concatenar documentos en secciones, para prevenir documentos muy largos, ejemplo al final de oggui.md 2.- Se adecúan a este paradigma de enumeracion, index.md, inde_release.md 3.- Se instalan más dependencias de python y se actualiza el fichero requirements.txt 4.- Se crea la carpeta administration/sections en ambos idiomas para añadir las secciones de ogguimain
parent
6c86cd86d3
commit
2f458c16d2
|
|
@ -0,0 +1,30 @@
|
|||
import os
|
||||
import sys
|
||||
|
||||
# Directorio base desde donde se ejecuta mkdocs
|
||||
base_dir = os.getcwd()
|
||||
print(f"Directorio base: {base_dir}\n")
|
||||
|
||||
# Rutas a comprobar
|
||||
snippet_paths = [
|
||||
"sections/oggui-grupos.md",
|
||||
"sections/oggui-acciones.md",
|
||||
"sections/oggui-cierre.md"
|
||||
]
|
||||
|
||||
# Posibles directorios base para los snippets
|
||||
base_paths = [
|
||||
base_dir,
|
||||
os.path.join(base_dir, "docs"),
|
||||
os.path.join(base_dir, "docs/es/administration"),
|
||||
os.path.join(base_dir, "docs/en/administration"),
|
||||
# Añade más rutas si es necesario
|
||||
]
|
||||
|
||||
print("Comprobando rutas de snippets:")
|
||||
for base_path in base_paths:
|
||||
print(f"\nDesde base: {base_path}")
|
||||
for snippet in snippet_paths:
|
||||
full_path = os.path.join(base_path, snippet)
|
||||
exists = os.path.exists(full_path)
|
||||
print(f" - {full_path} {'EXISTE' if exists else 'NO EXISTE'}")
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 56 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 241 KiB After Width: | Height: | Size: 161 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 16 KiB |
|
|
@ -1,112 +1,123 @@
|
|||
# Administration Interface
|
||||
# ogGui - OpenGnsys Administration Interface
|
||||
|
||||
The Web console represents the greatest advancement of OpenGnsys in this new version, with the main features of:
|
||||
## Introduction
|
||||
|
||||
- Developed with a modern and up-to-date language, Angular 18
|
||||
- Responsive Web, working on both PC and mobile environments
|
||||
- Multilingual, with English translation
|
||||
Welcome to the new OpenGnsys administration interface. This manual will guide you through your first steps in setting up and efficiently using the platform. The new web console represents a qualitative leap with the following main features
|
||||
|
||||
|
||||
!!! info
|
||||
- Developed with Angular 18, a modern and up-to-date framework
|
||||
- Responsive web design that works both on PC environments and mobile devices
|
||||
- Multilingual support with English translation
|
||||
|
||||
## Configuration
|
||||
## System Access
|
||||
|
||||
The new OpenGnsys administration interface has the following features for its Configuration
|
||||
To start using OpenGnsys
|
||||
|
||||
{ align=center width=20% }
|
||||
1. Open your preferred web browser
|
||||
2. Enter the URL of the OpenGnsys server
|
||||
3. On the login screen, enter your credentials (username and password)
|
||||
|
||||
### Users
|
||||
Click on "Log In"
|
||||
|
||||
Allows creating, editing and deleting Users
|
||||
|
||||
|
||||
{ align=center }
|
||||
## Main Interface
|
||||
|
||||
#### Add User
|
||||
Once inside, you will find:
|
||||
|
||||
{ align=right width=40% } You will need to define the *username*, *password*, *role*, *organizational unit*, and *view*.
|
||||
- **Side navigation panel**: Access to all modules and functionalities
|
||||
- **Top bar**: User information, notifications, and quick access to settings
|
||||
- **Central workspace**: Where the selected information is displayed and managed
|
||||
|
||||
- **Username**: this will be used for login
|
||||
|
||||
|
||||
- **Password**: the password is defined here by an administrator. The user will not be able to change the password unless they have access to the user administration panel.
|
||||
## Initial Configuration
|
||||
|
||||
- **Role**: allows assigning one or more roles to the user. Roles provide greater granularity when managing the permissions each user will have to administer the platform.
|
||||
### User Management
|
||||
|
||||
- **Organizational Unit**: allows defining which group of classrooms or machines the user will be able to administer. This field allows choosing one or more groups that the user can interact with.
|
||||
User management allows you to control who has access to the system and what they can do.
|
||||
|
||||
<div style="clear: both;"></div>
|
||||
|
||||
|
||||
#### Edit User
|
||||
#### Viewing Existing Users
|
||||
|
||||
This window allows editing all the fields that were defined during its creation.
|
||||
Go to **Administration > Users** to view the list of current system users.
|
||||
|
||||
#### Delete User
|
||||
|
||||
|
||||
Allows deleting a user.
|
||||
#### Adding a New User
|
||||
|
||||
### Roles
|
||||
1. On the Users page, click the "Add Users" button
|
||||
2. Complete the form with the following data:
|
||||
|
||||
Roles allow managing the access permissions that users have to administer the platform. Currently there are 4 administrative levels according to the roles:
|
||||
|
||||
|
||||
- Super Admin: allows total control of the platform, without restrictions.
|
||||
- Organizational Unit Admin: allows the user to perform all existing activities on the organizational unit.
|
||||
- Organizational Unit Operator:
|
||||
- User
|
||||
- **Username**: Unique identifier for logging in
|
||||
- **Password**: Access key (note: only administrators can change passwords)
|
||||
- **Role**: Select one or more roles that will define the user's permissions
|
||||
- **Organizational Unit**: Defines which groups of classrooms or machines the user will be able to administer
|
||||
|
||||
3. Click "Save" to create the new user
|
||||
|
||||
#### Editing an Existing User
|
||||
|
||||
1. In the user list, locate the user you want to edit
|
||||
2. Click the edit icon (pencil)
|
||||
3. Update the necessary fields
|
||||
4. Save the changes
|
||||
|
||||
#### Deleting a User
|
||||
|
||||
1. In the user list, locate the user you want to delete
|
||||
2. Click the delete icon (trash can)
|
||||
3. Confirm the action when prompted
|
||||
|
||||
### Role Configuration
|
||||
|
||||
Roles define the permissions of users on the platform. OpenGnsys includes four predefined levels:
|
||||
|
||||
- **Super Admin**: Full control of the platform, without restrictions
|
||||
- **Organizational Unit Admin**: Full control over the assigned organizational unit
|
||||
- **Organizational Unit Operator**: Limited permissions to operate machines in the assigned unit
|
||||
- **User**: Basic access to the platform
|
||||
|
||||
### Environment Variables
|
||||
|
||||
In this menu, the IPs and ports of the APIs for the different components are mainly defined
|
||||
Environment variables define the connection configuration with the different components:
|
||||
|
||||
- OG_CORE_IP
|
||||
- OG_DHCP_API_URL
|
||||
- OG_BOOT_API_URL
|
||||
- OG_LOG_IP
|
||||
- REMOTEPC_AUTH_LOGIN
|
||||
- REMOTEPC_AUTH_USERNAME
|
||||
- REMOTEPC_AUTH_PASSWORD
|
||||
- REMOTEPC_URL
|
||||
1. Go to **Administration > Environment Variables**
|
||||
2. Configure the following variables according to your infrastructure:
|
||||
|
||||
- **OG_CORE_IP**: IP address of the main server
|
||||
- **OG_DHCP_API_URL**: URL of the DHCP service API
|
||||
- **OG_BOOT_API_URL**: URL of the boot server API
|
||||
- **OG_LOG_IP**: IP address of the log server
|
||||
- **REMOTEPC_AUTH_LOGIN**: Authentication URL for RemotePC
|
||||
- **REMOTEPC_AUTH_USERNAME**: Username for RemotePC
|
||||
- **REMOTEPC_AUTH_PASSWORD**: Password for RemotePC
|
||||
- **REMOTEPC_URL**: Base URL of the RemotePC service
|
||||
- **SSL_ENABLED**: true or false.
|
||||
|
||||
|
||||
|
||||
!!! note "Note"
|
||||
The UDS_ variables will appear as REMOTEPC_ in your installation
|
||||
|
||||
## Navigating the Menus
|
||||
|
||||
In the left panel, we have the menus that give us access to the OpenGnsys features that we currently have active and running.
|
||||
!!! note "Note"
|
||||
It is possible that OpenGnsys does not include some modules, because they are served by external infrastructures, the most classic example is DHCP. In this case, when accessing that menu you will see a warning that this module is not enabled.
|
||||
The left side panel contains all available menus according to your role and the active modules:
|
||||
|
||||
## Manage Groups
|
||||
- **Groups**: Management of groups
|
||||
- **Actions**: The management module for Actions, Commands, and Tasks.
|
||||
- **Subnets**: The management module for the DHCP service.
|
||||
- **Boot**: The management module for the ogLive and PXE boot services.
|
||||
- **Calendars**: Module for managing machine availability in the RemotePC service
|
||||
- **Repositories**: Module for managing repositories and the images associated with each.
|
||||
- **Menus**: Allows managing the menus that will be displayed when starting ogLive on a client machine.
|
||||
|
||||
{align=right width=50%}The main characteristics of groups are:
|
||||
!!! note "Note"
|
||||
Some modules may not be available if they depend on external services that are not configured. For example, if the DHCP service is managed externally, accessing that menu will display a notice indicating that the module is not enabled.
|
||||
|
||||
- Inheritance
|
||||
- Network and DHCP service
|
||||
- Boot Server
|
||||
- ogLive version
|
||||
- PXE template
|
||||
- NTP Server
|
||||
- Image Repository
|
||||
- Configuration of P2P values (mode, time)
|
||||
- Configuration of Multicast values (speed, port, mode)
|
||||
- Menu
|
||||
- Hardware Profile
|
||||
|
||||
Element groups are a hierarchical system that allows grouping of elements. The most common are Campus, Centers, Classrooms and Clients.
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
subgraph c1 [" Campus"]
|
||||
subgraph c2 [" Centro"]
|
||||
subgraph c3 [" Aula"]
|
||||
c4[" Cliente"]
|
||||
end
|
||||
end
|
||||
end
|
||||
|
||||
classDef campusStyle fill:#f9d5e5,stroke:#333,stroke-width:3px
|
||||
classDef centroStyle fill:#eeeeee,stroke:#333,stroke-width:2px
|
||||
classDef aulaStyle fill:#b5ead7,stroke:#333,stroke-width:1px
|
||||
classDef clienteStyle fill:#c7ceea,stroke:#333,stroke-width:1px
|
||||
|
||||
class c1 campusStyle
|
||||
class c2 centroStyle
|
||||
class c3 aulaStyle
|
||||
class c4 clienteStyle
|
||||
```
|
||||
|
||||
<div style="clear: both;"></div>
|
||||
--8<-- "sections/oggui-grupos.md"
|
||||
--8<-- "sections/oggui-acciones.md"
|
||||
--8<-- "sections/oggui-cierre.md"
|
||||
|
|
|
|||
|
|
@ -1,18 +1,16 @@
|
|||
# Introduction to OpenGnsys v3.0
|
||||
|
||||
## 1. Introduction
|
||||
|
||||
The OpenGnsys project (pronounced OpenGenesis) brings together the joint effort of several Spanish public universities to build an application that enables easy centralized management of workstations and servers. It allows distribution, installation, and deployment of different operating systems.
|
||||
The OpenGnsys project (pronounced OpenGénesis) brings together the combined effort of several Spanish public universities to build an application that allows easy centralized management of computers and servers. It enables the distribution, installation, and deployment of different operating systems.
|
||||
|
||||
|
||||
|
||||
OpenGnsys was born out of the need to have a set of free and open tools forming a complete, versatile, and intuitive system for managing and cloning machines, which can be used both in computer labs and for reinstalling workstations and servers.
|
||||
OpenGnsys was born out of the need for a set of free and open tools that make up a complete, versatile, and intuitive equipment management and cloning system, usable both for managing computer classrooms and for reinstalling computers and servers.
|
||||
|
||||
The OpenGnsys website (www.opengnsys.es) provides all project manuals, the full source code of various versions, discussion and support forums, API documentation, and more.
|
||||
The OpenGnsys website (www.opengnsys.es) provides all project manuals, full source code of different versions, several discussion and support forums, programming API documentation, and more.
|
||||
|
||||
### 1.1. Background, Present, and Future
|
||||
## Background, Present, and Future
|
||||
|
||||
OpenGnsys originated in May 2009 after the RedIRIS Working Groups held in Málaga, as an effort to integrate several projects in development:
|
||||
OpenGnsys originated in May 2009 after the RedIRIS Working Groups held in Málaga, as an effort to integrate several projects under development:
|
||||
|
||||
- Brutalix, University of Zaragoza
|
||||
- Advanced Cloning Environment (EAC), University of Málaga
|
||||
|
|
@ -20,278 +18,279 @@ OpenGnsys originated in May 2009 after the RedIRIS Working Groups held in Málag
|
|||
|
||||
Currently, several universities collaborate on the project.
|
||||
|
||||
This version addresses the following improvements:
|
||||
This version addresses the following improvements
|
||||
- Python as the main programming language
|
||||
- Communication among all components via REST API
|
||||
- Communication between all components via REST API
|
||||
- New web console: symfony-angularjs
|
||||
- Image synchronization with GIT
|
||||
- Logging and monitoring service
|
||||
|
||||
## 2. Features of OpenGnsys
|
||||
## Features of OpenGnSys
|
||||
|
||||
The main management of OpenGnsys is based on a simple web interface that allows common tasks for managing software distribution on various clients. However, OpenGnsys’s structure is versatile enough to adapt to the needs of different network architectures in companies and institutions.
|
||||
The main management interface of OpenGnsys is based on a simple web interface that allows you to perform common tasks for managing software distribution on various clients. However, OpenGnsys’s structure is versatile enough to adapt to the needs of different computer network architectures in businesses and institutions.
|
||||
|
||||
For an administrator with advanced knowledge, OpenGnsys allows adding new functionalities via the cloning engine’s function API and defines how to integrate them into the console easily, as well as how to define startup menus for different clients.
|
||||
For an administrator with advanced knowledge, OpenGnsys allows new functionalities to be added via the cloning engine API and defines how to integrate them into the console simply, as well as defining boot menus for different clients.
|
||||
|
||||
The usual workflow starts from a model machine where one or more operating systems are installed with the necessary programs and data, creating images of its file systems, and then replicating them to all machines in an organization or to a specific group.
|
||||
The usual workflow is to start from a model machine where you have one or more operating systems installed with the necessary programs and data, create images of its file systems, and then replicate them to all computers in an organization or to a group of them.
|
||||
|
||||
|
||||
|
||||
Specific configuration and data modification tasks on each client can be performed directly from OpenGnsys once the image dump process is finished, without needing to boot the target operating system, by accessing the data on the disks. This provides a significant advantage over other similar products, even commercial ones.
|
||||
Specific configuration and data modification tasks on each client can be carried out directly from OpenGnsys once the image dump process is complete, without needing to boot the corresponding operating system, by accessing the information stored on the disks. This offers a significant advantage over other similar, even commercial, products.
|
||||
|
||||
Image and file distribution can be done flexibly, so different communication protocols have been implemented, such as Unicast, Multicast, and P2P; and data can also be available offline (without the need for server communication) by accessing each client’s local data cache or an external storage device.
|
||||
The distribution of images and files can be done flexibly, so different communication protocols have been implemented, such as Unicast, Multicast, and P2P; the information can even be made available offline (without server communication) by accessing each client’s local data cache or an external storage device.
|
||||
|
||||
File system-level restoration allows restoring to disk partitions smaller than the original size, down to the minimum occupied by the data.
|
||||
System restoration is performed at the file system level and allows restoring to disk partitions smaller than the original size, down to the minimum occupied by the data.
|
||||
|
||||
Restoring the original operating system not only makes an exact copy of the model: it can also perform destination machine configuration tasks such as changing the machine name, detecting hardware and installed software inventory, copying or deleting files and directories, modifying the Windows registry, joining a domain, etc.
|
||||
Restoring the original operating system is not only about making an exact copy of the model: configuration tasks on the target machine can also be performed, such as changing the machine name, detecting hardware inventory and installed software, copying or deleting files and directories, modifying the Windows registry, joining a domain, etc.
|
||||
|
||||
By definition, OpenGnsys is a Free Software project. As such, all code is licensed under GPLv3 or later, while the course documentation is available under the Creative Commons Attribution-NonCommercial-ShareAlike license.
|
||||
By definition, OpenGnsys is a Free Software project. As such, all code is licensed under GPLv3 or later, while course documentation is available under a Creative Commons Attribution-NonCommercial-ShareAlike license.
|
||||
|
||||
## 3. Architecture
|
||||
## Architecture
|
||||
|
||||
In this version of OpenGnsys, emphasis has been placed on solution modularity, allowing deployment of different components on a single monolithic server or on separate machines. This provides greater flexibility to cover any scenario.
|
||||
In this version of OpenGnsys, emphasis has been placed on solution modularity, allowing deployment of different components on a single monolithic server or on separate machines. This adds greater flexibility to the solution, covering any scenario.
|
||||
|
||||
OpenGnsys’s architecture is flexible enough to adapt to the needs of different computer network models in companies and institutions, and can be used in various scenarios:
|
||||
The OpenGnsys architecture is flexible enough to adapt to the needs of different computer network models in companies and institutions, usable in various types of scenarios:
|
||||
|
||||
1. Centralized management of ICT Support Units for Teaching and Research, both for in-person teaching labs and self-learning.
|
||||
1. Centralized management of ICT Support Units for Teaching and Research, both for classroom labs and self-study environments.
|
||||
2. Maintenance of personal computer fleets of an institution’s members.
|
||||
3. Deployment and maintenance of servers in a particular Data Center.
|
||||
4. Administration of machine cloning repositories for helpdesk services or institutional information points.
|
||||
3. Deployment and maintenance of a specific Data Center’s servers.
|
||||
4. Administration of equipment cloning repositories for helpdesk services or an institution’s information points.
|
||||
|
||||
### 3.1. Service Layers
|
||||
### Service Layers
|
||||
|
||||
OpenGnsys consists of a set of modules separated into different service layers:
|
||||
|
||||
- **Lower layer**: responsible for direct access to client devices and cloning engine functions.
|
||||
- **Intermediate layer**: made up of tools for performing complex tasks and environment customization.
|
||||
- **Administration layer**: comprising the web interface and management database.
|
||||
- **Intermediate layer**: made up of tools for complex tasks and environment customization.
|
||||
- **Administration layer**: consisting of the web interface and management database.
|
||||
|
||||
### 3.2. Modules
|
||||
### Modules
|
||||
|
||||
The OpenGnsys Project is a modular system integrating interrelated components that can be adapted to a variety of work scenarios. These components include standard services (file servers, web, database, DHCP, PXE, etc.) and custom tools developed for the project, which together offer all system features.
|
||||
The OpenGnsys Project is a modular system integrating interrelated components, adaptable to a variety of work scenarios. These components include standard services (file servers, web, database, DHCP, PXE, ...) and custom tools developed for the project, which together provide all system capabilities.
|
||||
|
||||
The following describes the different components of the OpenGnsys Project:
|
||||
The different components of the OpenGnsys Project are described below:
|
||||
|
||||
**OpenGnsys Web Administration**
|
||||
|
||||
This service consists of three components that centralize the solution’s organization:
|
||||
This service consists of three components that centralize solution organization:
|
||||
|
||||
- **ogCore**: the API interface that interconnects all components and manages the solution from the web interface.
|
||||
- **ogGUI**: the web interface that allows complete solution administration without using the console.
|
||||
- **ogDB**: the OpenGnsys database that centralizes all information and, in this version, has been architecturally redesigned to handle the new solution paradigm.
|
||||
- **ogCore**: the API interface that interconnects all components and allows solution administration from the web interface.
|
||||
- **ogGUI**: the web interface, enabling full solution administration without using the console.
|
||||
- **ogDB**: the OpenGnsys database, centralizing all information and redesigned in this version to support the new solution paradigm.
|
||||
|
||||
**OpenGnsys DHCP**
|
||||
|
||||
The DHCP service has been updated to be deployed optionally and modularly, with an API for its administration. The current OpenGnsys version uses KEA DHCP.
|
||||
The DHCP service has been updated to be optionally and modularly deployable, with an API for its administration. In the current version of OpenGnsys, KEA DHCP is used.
|
||||
|
||||
**OpenGnsys Boot**
|
||||
|
||||
The OpenGnsys boot system, formerly integrated into "OpenGnsys Server," has become a module with an administration API, allowing its installation as an "optional" component (though essential for OpenGnsys operation). This module manages ogLive assignments, as well as templates and their assignments.
|
||||
The OpenGnsys boot system, previously integrated into "OpenGnsys Server," has become a module with an administration API, allowing optional installation (though its functionality is essential for OpenGnsys). This module manages ogLive assignments, as well as templates and their assignment.
|
||||
|
||||
**OpenGnsys Repository**
|
||||
|
||||
Manages the image repository for each administrative unit defined in the OpenGnsys Repository module and provides complementary file services (currently using SAMBA as the file server). One or more modules can exist, depending on the organization model.
|
||||
In this version, "synchronized images" via "git images" functionality have been integrated, allowing image creation by this method and increasing solution flexibility.
|
||||
Manages the repository of images for each administrative unit defined in the OpenGnsys Repository module and a complementary file service (currently using SAMBA as the file server). One or more modules can exist, depending on the defined organization model. This version integrates “synchronized images” via the “git images” functionality, allowing image creation by this method and providing greater solution flexibility.
|
||||
|
||||
**OpenGnsys Live Client –ogLive–**
|
||||
**OpenGnsys live Client - ogLive -**
|
||||
|
||||
In this version, the ogLive kernel (version 6.8) and internal components such as ogBrowser have been updated to fix certain shortcomings and add new features.
|
||||
In this version, the ogLive kernel has been updated (version 6.8), along with its internal components like ogBrowser to address certain shortcomings and adopt new functionalities.
|
||||
|
||||
This client-side execution agent integrates the following functionalities:
|
||||
Order execution agent on the client, integrating the following features:
|
||||
|
||||
- Graphical interface for selecting admin-defined options.
|
||||
- Graphic interface for selecting administrator-defined options.
|
||||
- Interactive execution of cloning engine functions in administrator mode.
|
||||
- Execution of tasks sent from the OpenGnsys Administrator module.
|
||||
|
||||
It consists of two stages: the first load stage (tftboot) and the second load stage (ogLive via NFS/SAMBA). Later topics will cover more about ogLive.
|
||||
It consists of two elements: the first load stage (tftpboot) and the second load stage (ogLive via NFS/SAMBA). Later topics will cover more about ogLive.
|
||||
|
||||
**OpenGnsys Cloning Engine**
|
||||
|
||||
Function libraries of the cloning engine, installation, and OS boot on the client. In this version, functions have been migrated to Python for code standardization and certain features refined.
|
||||
Function libraries for the cloning engine, operating system installation, and boot on the client. In this version, functions have been migrated to Python to standardize the code and some functionalities have been refined.
|
||||
|
||||
**OpenGnsys Installer**
|
||||
|
||||
Installation, update, and uninstallation programs including configuration generator, client boot generator, component package generator, etc.
|
||||
In version 3.0, there are four installation methods:
|
||||
- “Graphical” installation via script.
|
||||
Programs for system installation, update, and uninstallation, including configuration generators, client boot generators, component package generators, etc.
|
||||
In this 3.0 version, there are 4 installation methods
|
||||
- “Graphical” installation via Script.
|
||||
- Installation via Debian packages.
|
||||
- Installation and deployment via Docker containers.
|
||||
- Installation and deployment via preconfigured OVAs ready for distribution.
|
||||
- Installation and deployment via preconfigured OVAs, ready for distribution.
|
||||
|
||||
#### 3.2.1. Diagram
|
||||
### Diagram
|
||||
|
||||
|
||||
|
||||
### 3.3. Organization Model
|
||||
### Organization Model
|
||||
|
||||
In version 3.0, information organization has been made more flexible by creating a more organic hierarchy. An Organizational Unit can be one of four types:
|
||||
In this 3.0 version, information organization has been made more flexible by creating a more organic hierarchy. An Organizational Unit can be one of 4 types:
|
||||
|
||||
- Center
|
||||
- Classroom Group
|
||||
- Classroom
|
||||
- Client Group
|
||||
|
||||
From an organization’s (university’s) perspective, OpenGnsys consists of a central management console divided into independent Administrative Units, each of which can have one or more data repositories serving one or more computer classroom groups.
|
||||
From an organization’s (University) perspective, OpenGnsys consists of a central management console divided into a set of independent Administrative Units, each of which can have one or more data repositories serving one or more computer classroom groups.
|
||||
|
||||
This distribution allows operations to be applied to any scope from the Organizational Unit (or Administrative Unit) down to a specific client.
|
||||
This distribution allows operations to be applied at any level, from the Organizational Unit (or Administrative Unit) down to a specific client.
|
||||
|
||||
Additionally, a filtering and view system has been created to operate on groups of machines based on criteria such as Operating System, State (on/off), etc.
|
||||
Additionally, a filtering and views system has been created, allowing operations on equipment groups based on criteria such as Operating System, Status (on/off), etc.
|
||||
|
||||
|
||||
|
||||
## 4. Communication Protocols
|
||||
## Communication Protocols
|
||||
|
||||
Cloning a file system across many computers involves transferring large volumes of data and thus significant deployment time. OpenGnsys mitigates these impacts by implementing several data transfer methods using three different communication protocols.
|
||||
Cloning a file system across many computers involves transferring a large volume of data, thus a significant deployment time. OpenGnsys mitigates these impacts by providing several data transfer methods using three different communication protocols.
|
||||
|
||||
The protocols available for cloning operations are:
|
||||
|
||||
- **Unicast**: all data is transmitted independently to each affected client. The volume sent equals the image size multiplied by the number of clients. This is the simplest and most basic method but the least efficient. It is used as a fallback when any other method’s transmission fails.
|
||||
- **Unicast**: all data are sent independently to each affected client. The volume sent equals the image size multiplied by the number of clients. This is the simplest and most basic method, but the least efficient. It is used as a fallback protocol in case of transmission failures in other methods.
|
||||
|
||||
- **Multicast**: data is sent simultaneously to all session clients, so the image is sent only once. This method is very efficient but incompatible with some network hardware. Session-specific parameters must be specified, such as multicast IP address, port, and transmission rate.
|
||||
- **Multicast**: data are sent simultaneously to all clients in the session, so the image is sent only once. This method is very efficient but is incompatible with some network hardware. Specific session parameters must be set, such as multicast IP address, connection port, and transmission speed.
|
||||
|
||||
- **Bittorrent (P2P)**: the repository sends random image chunks to each client in the swarm. When a client receives a complete chunk, it retransmits it to the rest until all have completed the transfer. This protocol is very efficient, though it consumes much network bandwidth, requires data to be pre-stored in each client’s local cache, and needs parameters such as maximum clients, whether they will participate in distribution, and how long they will continue transmitting after receiving all data. P2P protocols may also be filtered on some networks.
|
||||
- **Bittorrent (P2P)**: the repository transmits random pieces of the image to each client in the swarm. When a client receives a complete piece, it also retransmits it to the other machines until all complete the transfer. This protocol is very efficient, although it consumes much network bandwidth, requires data to be pre-stored in each client’s local cache, and needs parameters like maximum clients, participation in the swarm, and seeding time after full data reception. P2P protocols may also be filtered on some networks.
|
||||
|
||||
Image generation from the model and its sending to the repository always use Unicast, since communication involves only one sender (the model client) and one receiver (the image repository).
|
||||
The process of generating a model image and sending it to its repository always uses the Unicast protocol, since the communication involves only a sender (the model client) and a receiver (the image repository).
|
||||
|
||||
It is recommended that the student evaluate the different restoration protocols in their operational environment to verify compatibility with their data network and identify the most efficient option in each case.
|
||||
Students are advised to evaluate the different restoration protocols in their operational environment to determine which are compatible with their network and which may be most efficient in each case.
|
||||
|
||||
|
||||
|
||||
## 5. Basic Operation Concepts
|
||||
## Basic Operation Concepts
|
||||
|
||||
Working with OpenGnsys requires administrators to understand some basic operation concepts.
|
||||
Working with OpenGnsys requires administrators to know some basic operational concepts.
|
||||
|
||||
**Adding New Computers**
|
||||
|
||||
Process to register new machines in the system by first including their data in the DHCP configuration and then copying this information into the web administration console. Note that OpenGnsys uses only static DHCP data.
|
||||
Process to register new machines in the system, first adding their data to the DHCP service configuration and then copying this information into the web administration console. Note that OpenGnsys only uses static DHCP data.
|
||||
|
||||
**Boot Sequence**
|
||||
|
||||
Preferred execution order after a computer is powered on. An OpenGnsys client must be configured to boot first from the network interface. For security and control, disabling direct boot from local devices may be advisable.
|
||||
Order of preference for execution after powering on a computer. An OpenGnsys client must be configured to boot first from the network interface. For security and control reasons, direct boot from local devices may be disabled.
|
||||
|
||||
**OpenGnsys Client**
|
||||
|
||||
A machine registered in the system that, when powered on, receives its connection data from OpenGnsys (via DHCP) and its default boot process (using PXE).
|
||||
A machine registered in the system that, when powered on, receives its connection data (via DHCP) and its default boot process (using PXE) from OpenGnsys.
|
||||
|
||||
**Boot Process**
|
||||
|
||||
Execution sequence that loads the computer’s operating system. OpenGnsys offers choosing between an OS already installed on the machine or a small GNU/Linux system used for cloning operations. The standard OpenGnsys client boot process ends by running the OpenGnsys Browser.
|
||||
Execution sequence that loads the computer’s operating system. OpenGnsys offers the choice between an already installed OS or a small proprietary GNU/Linux system used to manage cloning operations. The standard OpenGnsys client boot process ends by running the OpenGnsys Browser.
|
||||
|
||||
**OpenGnsys Browser**
|
||||
|
||||
Web browser that shows the user the operation selection menu for a given client. It has two modes: user (menu and status bar only) and administrator (also includes an address bar, an output message console, and a command execution terminal).
|
||||
Web browser displaying the user menu of operations for a given client, with two modes: user (menu and status bar only) and administration (which also includes an address bar, an output message console, and a command execution terminal).
|
||||
|
||||
**Menu**
|
||||
|
||||
Set of options the administrator offers the user, displayed by the Browser. You can define a normal startup menu (usually including OS boot, file system restoration, and shutdown) and an optional administration menu (which can include predefined management operations like image creation).
|
||||
Set of options the administrator offers the user, displayed by the Browser. A normal boot menu can be defined (typically including OS boot, file system restoration, and system shutdown) and an optional administration menu (which additionally may include preconfigured management operations, such as image creation).
|
||||
|
||||
**Model Client**
|
||||
|
||||
A machine with all software installed and correctly configured that must be cloned. To avoid post-configuration issues, it should have hardware similar to target machines. However, it need not have the same partition layout or size as others, though it is recommended.
|
||||
Computer that must have all software installed and properly configured for cloning and that, to avoid post-configuration issues, should have a hardware setup similar to target machines. However, it need not maintain the same partition layout and sizes, though this is recommended.
|
||||
|
||||
**Computer Group**
|
||||
|
||||
A set of clients that share the same hardware profile or are located in the same room, and that share the same installation distribution and post-configuration data.
|
||||
Set of clients that are usually identical (share the same hardware profile) or located in the same room, sharing the same installation distribution and post-configuration data.
|
||||
|
||||
**File System Image**
|
||||
|
||||
A file containing an exact copy of one of the model client’s file systems. OpenGnsys can maintain several associated files, such as checksums and Bittorrent transmission data.
|
||||
File containing an exact copy of one of the model client’s file systems. OpenGnsys can maintain several files associated with an image, such as checksums and transmission data for the Bittorrent protocol.
|
||||
|
||||
**Post-Configuration**
|
||||
|
||||
Sequence of commands for individual client customization, executed after a file system clone, which may include creating, deleting, or editing files.
|
||||
Sequence of commands allowing independent customization for each client, executed after file system cloning, and which may include file creation, deletion, or editing operations.
|
||||
|
||||
**Local Cache**
|
||||
|
||||
Client’s local data repository that speeds up cloning by avoiding connection to the remote repository, storing image data, post-configuration data, and optionally client boot files. The local cache is a file system usually formatted as Ext4 and often on the disk 1’s fourth partition.
|
||||
Client’s local data repository that speeds up the cloning process by avoiding remote repository connections, storing the client’s own images, post-configuration data, and optionally client boot files. The local cache is a file system typically formatted as Ext4 and usually resides on the 4th partition of disk 1.
|
||||
|
||||
## 6. The Web Interface
|
||||
## The Web Interface
|
||||
|
||||
OpenGnsys Web Administrator is a management console that handles clients in an organizational unit, performing both system-predefined and operator-customized operations.
|
||||
OpenGnsys Web Administrator is a management console that allows handling clients of an organizational unit, performing both predefined and custom operations on them.
|
||||
|
||||
### 6.1. Overview
|
||||
### Overview
|
||||
|
||||
The web console is divided into main areas:
|
||||
The web console is divided into several main areas:
|
||||
|
||||
1. Top bar with configuration and status buttons.
|
||||
2. Left area with the module tree for operations.
|
||||
3. Right area with operation forms and results.
|
||||
2. Left pane with the module tree to operate on.
|
||||
3. Right pane with operation forms and results.
|
||||
|
||||
|
||||
|
||||
The main objects accessible via menu bar tools are:
|
||||
The primary objects accessible via the menu bar tools are:
|
||||
|
||||
- **Groups**: hierarchical distribution of the organizational unit based on classroom groups, classrooms, computer groups, and individual computers.
|
||||
- **Actions**: list of basic commands and grouping of administrator-defined procedures and tasks. Actions run on classroom tree objects.
|
||||
- **Subnets**: DHCP service administration module (ogDHCP).
|
||||
- **Boot**: equipment boot service administration module (ogBoot).
|
||||
- **Calendars**: manages access availability per defined calendars for RemotePC classroom machines.
|
||||
- **Software**: manages different software profiles for client machines.
|
||||
- **Repositories**: administers the ogRepository component, integrating monolithic images, synchronized images (git), and their management via the new API.
|
||||
- **Menus**: list of startup menus assignable to classroom tree objects.
|
||||
- **Groups**: hierarchical distribution of the organizational unit based on classroom groups, classrooms, computer groups, and computers.
|
||||
- **Actions**: list of basic commands and grouping of procedures and tasks defined by the administrator. Actions are executed on elements of the classroom tree.
|
||||
- **Subnets**: module for DHCP service administration (ogDHCP).
|
||||
- **Boot**: module for equipment boot service administration (ogBoot).
|
||||
- **Calendars**: functionality to manage access availability for classroom machines according to defined schedules for RemotePC.
|
||||
- **Software**: manage different software profiles for client machines.
|
||||
- **Repositories**: module to administer the ogRepository component, integrating monolithic images, synchronized (git) images, and their management through the new API.
|
||||
- **Menus**: list of boot menus assignable to elements of the classroom tree.
|
||||
|
||||
These menus include, among others, the following primary operation types:
|
||||
These menus include, among others, the following main operation types:
|
||||
|
||||
- **Commands**: submenu of predefined basic actions executed on classroom tree elements.
|
||||
- **Wizards**: submenu of complex commands allowing customization during execution.
|
||||
- **Procedures**: ordered sequences of commands with custom parameters.
|
||||
- **Tasks**: commands executed on a specific scope and schedulable for execution at set times.
|
||||
- **Action Queues**: lists of pending actions in a specific scope.
|
||||
- **Commands**: submenu of basic predefined actions executed on classroom tree elements.
|
||||
- **Wizards**: submenu of complex commands allowing some execution-time customization.
|
||||
- **Procedures**: ordered sequences of commands with customized parameters.
|
||||
- **Tasks**: commands executed on a particular scope that can be scheduled for specific times.
|
||||
- **Action Queues**: lists of pending actions in a given scope.
|
||||
|
||||
### 6.2. Other Important Elements
|
||||
## Other Important Elements
|
||||
|
||||
#### 6.2.1. Advanced NetBoot
|
||||
### Advanced NetBoot
|
||||
|
||||
Integrated into the “ogBoot” module, which now has an interaction and administration API.
|
||||
This feature is integrated into the “ogBoot” module, which now has an API for interaction and administration.
|
||||
|
||||
Tool to select the boot type for all or part of the clients in a classroom, choosing among different startup methods.
|
||||
Tool that allows selecting the boot type for all or part of a classroom’s clients, choosing among different boot methods.
|
||||
|
||||
OpenGnsys defines five default boot methods:
|
||||
By default, OpenGnsys defines 5 boot methods:
|
||||
|
||||
**Local boot from the first disk (default):**
|
||||
- Local boot from the 1st partition.
|
||||
- Local boot from the 2nd partition.
|
||||
- Local boot from the 3rd partition.
|
||||
- Local boot from the 1st partition of the disk.
|
||||
- Local boot from the 2nd partition of the disk.
|
||||
- Local boot from the 3rd partition of the disk.
|
||||
|
||||
**Boot of an OS –ogLive– for machine cloning:**
|
||||
**Boot of an operating system – ogLive – for equipment cloning:**
|
||||
- Network boot with Browser in user mode (ogLive).
|
||||
- Network boot with Browser in administrator mode (ogLiveAdmin).
|
||||
|
||||
NetBoot supports both legacy BIOS and UEFI-based systems and allows adding boot options for a second or third disk.
|
||||
Netboot supports both legacy BIOS and UEFI-based machines.
|
||||
|
||||
#### 6.2.2. Menus
|
||||
Netboot allows extending boot options to a second or third disk.
|
||||
|
||||
A menu is a modified web page or a list of items presented to the client’s Browser as the home page. It typically includes options for booting installed operating systems, manipulating local data, or executing predefined actions on the client.
|
||||
### Menus
|
||||
|
||||
Menus defined in the web administration console can be classified by generation method:
|
||||
A menu is a modified web page or a list of items presented to the client’s Browser as a start page. It usually contains options for booting installed operating systems, manipulating local data, or executing predefined actions on that client.
|
||||
|
||||
Menus definable in the web administration console can be classified by generation method:
|
||||
|
||||
**Automatic Menu**
|
||||
Item list generated from defined procedures.
|
||||
List of items generated from defined procedures.
|
||||
|
||||
**Custom Menu**
|
||||
Modified HTML web page that can include URLs with commands or scripts executed on the client.
|
||||
Web page created in modified HTML that may include URLs with commands or scripts executed on the client.
|
||||
|
||||
Menus can also be classified by required access type:
|
||||
Menus can also be classified by access type:
|
||||
|
||||
**Public Menu**
|
||||
Page and item list executable by any user.
|
||||
|
||||
**Private Menu**
|
||||
Page or item list executable only after entering the administrator password.
|
||||
Page or item list executable only after entering the administrator user’s password.
|
||||
|
||||
#### 6.2.3. Task Scheduling
|
||||
### Task Scheduling
|
||||
|
||||
Scheduling task execution allows easy management of launching tasks in their execution scopes at specified times.
|
||||
Scheduling tasks allows easy management of task launches within their execution scopes at specific times.
|
||||
|
||||
A schedule can comprise various chronological elements, enabling task launches according to timing needs, specifying days and even hours marked on a calendar.
|
||||
A schedule can include various chronological elements to trigger tasks as needed, specifying days and even hours marked on a calendar.
|
||||
|
||||
## 7. References
|
||||
## References
|
||||
|
||||
[OpenGnsys project website](http://www.opengnsys.es)
|
||||
[OpenGnsys Project Website](http://www.opengnsys.es)
|
||||
|
||||
## 8. How to Cite Us
|
||||
## Citation
|
||||
|
||||
To include a citation of this source, copy and paste the following text:
|
||||
To cite this source, you can copy and paste the following text:
|
||||
|
||||
- You must include the following CC license in your work:
|
||||
<a rel="license" href="http://creativecommons.org/licenses/by-nc-sa/4.0/"><img alt="Creative Commons License" style="border-width:0" src="https://i.creativecommons.org/l/by-nc-sa/4.0/88x31.png" /></a><br />This work is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-nc-sa/4.0/">Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International license</a>.
|
||||
<a rel="license" href="http://creativecommons.org/licenses/by-nc-sa/4.0/"><img alt="Creative Commons License" style="border-width:0" src="https://i.creativecommons.org/l/by-nc-sa/4.0/88x31.png" /></a><br />This work is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-nc-sa/4.0/">Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License</a>.
|
||||
|
|
|
|||
|
|
@ -1,144 +1,160 @@
|
|||
# OpenGnsys - Changelog v3.0.0 (May 19, 2025)
|
||||
# OpenGnsys - Changelog v3.0.0 (19 May 2025)
|
||||
|
||||
## Version Summary
|
||||
|
||||
This major release introduces significant improvements across all OpenGnsys components, including a new boot system, an updated cloning engine, Git integration, a revamped administration interface, and a new universal installer.
|
||||
This major release introduces significant improvements across all OpenGnsys components, including a new boot system, updated cloning engine, Git integration, revamped administration interface, and a new universal installer.
|
||||
|
||||
---
|
||||
|
||||
## Core Components
|
||||
## OpenGnsys DHCP (ogDHCP v0.7.0)
|
||||
|
||||
### OpenGnsys DHCP (ogDHCP v0.7.0)
|
||||
- DHCP installation and configuration via API.
|
||||
- Management and assignment of networks to console objects
|
||||
|
||||
- Installation and configuration of DHCP via API.
|
||||
- Management and assignment of networks to console objects.
|
||||
## OpenGnsys Boot (ogBoot v0.7.1)
|
||||
|
||||
### OpenGnsys Boot (ogBoot) v0.7.1
|
||||
- Optimized PXE-related services
|
||||
- Introduced a new, lighter and faster ogLive with updated drivers
|
||||
- Added ogLive generation tool with support for Engine, Browser, and Agent dependencies
|
||||
|
||||
#### Boot System
|
||||
- Optimized services associated with PXE.
|
||||
- Implemented a new, lighter and faster ogLive with updated drivers.
|
||||
- Added an ogLive generation tool with support for Engine, Browser, and Agent dependencies.
|
||||
## ogLive v3.3.0
|
||||
|
||||
### ogLive v3.3.0
|
||||
- Incorporated new OpenGnsys Browser with kiosk mode
|
||||
- Added full support for HTML5/CSS/JavaScript (ogBrowser)
|
||||
|
||||
#### Interface and Browser
|
||||
- Incorporated the new OpenGnsys Browser with kiosk mode.
|
||||
- Added full support for HTML5/CSS/JavaScript (ogBrowser).
|
||||
## Cloning Engine (ogCloningEngine v0.10.0)
|
||||
|
||||
#### Cloning Engine v0.10.0
|
||||
- Restructured the OpenGnsys Cloning Engine and partially migrated it to Python.
|
||||
- Ensured exclusive use of open source components.
|
||||
- Restructured the OpenGnsys Cloning Engine and partially migrated to Python
|
||||
- Ensured exclusive use of open source components
|
||||
|
||||
#### OpenGnsys Agent v5.3.0
|
||||
- Implemented ogAgent for Windows, Linux, Mac, and ogLive developed in Python.
|
||||
## OpenGnsys Agent (ogAgent v5.3.0)
|
||||
|
||||
#### General Features
|
||||
- Implemented calendar management for remote equipment usage.
|
||||
- Implemented ogAgent for Windows, Linux, Mac, and ogLive developed in Python
|
||||
|
||||
## General RemotePC Features
|
||||
|
||||
- Calendar management implemented for remote equipment use
|
||||
|
||||
---
|
||||
|
||||
## OpenGnsys Repository v0.8.1
|
||||
## OpenGnsys Repository (ogRepository v0.8.1)
|
||||
|
||||
#### Repository Improvements
|
||||
- Expanded the functionality of the OpenGnsys Repository.
|
||||
### Repository Improvements
|
||||
|
||||
- Expanded OpenGnsys Repository functionalities
|
||||
- Integrated with other system modules via REST API.
|
||||
|
||||
#### Transfers
|
||||
- Optimized transfer methods: Unicast, Multicast, and P2P.
|
||||
- Updated image transfer protocols.
|
||||
### Transfers
|
||||
|
||||
#### API and Security
|
||||
- Expanded features through REST API.
|
||||
- TLS encryption for all APIs.
|
||||
- Optimized transfer methods: Unicast, Multicast, and P2P
|
||||
- Updated image transfer protocols
|
||||
|
||||
#### Git Management
|
||||
- Added features for images synchronized with Git.
|
||||
- Integrated Forgejo for advanced repository management via web interface.
|
||||
- Added functions to create and select Git repositories.
|
||||
### API and Security
|
||||
|
||||
#### Git Integration v0.51
|
||||
- Improved functions in Git.lib for cloning and restoration.
|
||||
- Implemented a Python function library.
|
||||
- Added automatic creation of Git repositories during installation.
|
||||
- Incorporated synchronization between Git repositories and partitions.
|
||||
- Expanded features via REST API
|
||||
- TLS encryption for all APIs
|
||||
|
||||
### Git Management
|
||||
|
||||
- Implemented features for Git-synchronized images
|
||||
- Integrated Forgejo for advanced repository management via web interface
|
||||
- Added functions to create and select Git repositories
|
||||
|
||||
### Git Integration (ogGit v0.51)
|
||||
|
||||
- Improved functions in Git.lib for cloning and restoration
|
||||
- Implemented Python function library
|
||||
- Added automatic Git repository creation during installation
|
||||
- Incorporated synchronization between Git repositories and partitions
|
||||
---
|
||||
|
||||
## Administration Web (GUI) v0.13.0
|
||||
## Web Administration (ogGUI v0.13.0)
|
||||
|
||||
#### Interface
|
||||
- Completely redesigned web interface with responsive design.
|
||||
- Maintained all previous functionalities.
|
||||
- Improved visual experience and usability.
|
||||
### Interface
|
||||
|
||||
#### Modularity
|
||||
- Implemented modular system management.
|
||||
- Incorporated an advanced roles and permissions system.
|
||||
- Added tag-based search.
|
||||
- Completely redesigned web interface with responsive layout
|
||||
- Retained all previous functionalities
|
||||
- Improved visual experience and usability
|
||||
|
||||
#### Centralized Management (ogCore v0.13.0)
|
||||
- Unified administration of all components from the web.
|
||||
- Eliminated the need for command-line tasks in routine operations.
|
||||
### Modularity
|
||||
|
||||
#### Actions
|
||||
- Implemented a new action management system by agent type.
|
||||
- Added grouping into composite actions.
|
||||
- Incorporated a complete action history.
|
||||
- Implemented pending "required" actions.
|
||||
- Added a wizard for predefined actions and advanced mode.
|
||||
- Implemented modular system management
|
||||
- Incorporated advanced roles and permissions system
|
||||
- Added tag-based search
|
||||
|
||||
#### Clients
|
||||
- Developed a new hierarchical structure for groups.
|
||||
- Simplified group membership management.
|
||||
- Added support for heterogeneous groups.
|
||||
- Implemented configuration inheritance for deployment.
|
||||
- Incorporated grid view visualization.
|
||||
- Added the concept of a dynamic "view" based on criteria.
|
||||
### Centralized Management (ogCore v0.13.0)
|
||||
|
||||
#### Repositories and Images
|
||||
- Reorganized into group structures.
|
||||
- Implemented distinction between image types.
|
||||
- Improved information display for clients.
|
||||
- Added support for multiple simultaneous repositories.
|
||||
- Incorporated granular permissions and recycle bin.
|
||||
- Implemented advanced searches and migration between repositories.
|
||||
- Unified administration of all components via the web
|
||||
- Removed the need for the command line for routine tasks
|
||||
|
||||
#### Profiles
|
||||
- Added searches by advanced criteria.
|
||||
- Implemented referential naming for profiles.
|
||||
- Incorporated relationships between profiles for comparison.
|
||||
### Actions
|
||||
|
||||
#### Monitoring
|
||||
- Developed a notification system.
|
||||
- Added configurable statistics.
|
||||
- Implemented contextual help.
|
||||
- Unified communication via OpenGnsys Core.
|
||||
- Implemented new action management system by agent type
|
||||
- Added grouping in composite actions
|
||||
- Incorporated full action history
|
||||
- Implemented pending "required" actions
|
||||
- Added wizard for predefined actions and advanced mode
|
||||
|
||||
### Clients
|
||||
|
||||
- Developed new hierarchical structure for groups
|
||||
- Simplified group membership management
|
||||
- Added support for heterogeneous groups
|
||||
- Implemented configuration inheritance for deployment
|
||||
- Incorporated grid view
|
||||
- Added concept of dynamic "view" based on criteria
|
||||
|
||||
### Repositories and Images
|
||||
|
||||
- Reorganized into group structure
|
||||
- Implemented distinction between image types
|
||||
- Improved information display for clients
|
||||
- Added support for multiple simultaneous repositories
|
||||
- Incorporated granular permissions and recycle bin
|
||||
- Implemented advanced searches and repository migration
|
||||
|
||||
### Profiles
|
||||
|
||||
- Added searches by advanced criteria
|
||||
- Implemented referential profile naming
|
||||
- Incorporated profile comparison relationships
|
||||
|
||||
### Monitoring
|
||||
|
||||
- Developed notification system
|
||||
- Added configurable statistics
|
||||
- Implemented contextual help
|
||||
- Unified communication via OpenGnsys Core
|
||||
|
||||
---
|
||||
|
||||
## OpenGnsys Log Service
|
||||
|
||||
#### Logging System
|
||||
- Implemented REST API for full integration.
|
||||
- Centralized log storage and management.
|
||||
- Incorporated collection agents.
|
||||
- Added database processing (OpenSearch).
|
||||
### Logging System
|
||||
|
||||
#### Visualization
|
||||
- Developed an adaptive interface.
|
||||
- Implemented advanced filtering options.
|
||||
- Added result export.
|
||||
- Implemented REST API for full integration
|
||||
- Centralized log storage and management
|
||||
- Incorporated collection agents
|
||||
- Added database processing (OpenSearch)
|
||||
|
||||
### Visualization
|
||||
|
||||
- Developed adaptable interface
|
||||
- Implemented advanced filtering options
|
||||
- Added results export
|
||||
|
||||
---
|
||||
|
||||
## Universal Installer
|
||||
|
||||
#### Scripts
|
||||
- Updated existing scripts with version availability display.
|
||||
- Added compatibility verification.
|
||||
### Scripts
|
||||
|
||||
#### Installers
|
||||
- Developed a unified graphical installer with a progress bar.
|
||||
- Implemented full management options (install, update, remove).
|
||||
- Added database import/export.
|
||||
- Created a Debian/Ubuntu package repository.
|
||||
- Updated existing scripts with available versions display
|
||||
- Added compatibility checking
|
||||
|
||||
### Installers
|
||||
|
||||
- Developed unified graphical installer with progress bar
|
||||
- Implemented full management options (installation, upgrade, removal)
|
||||
- Added database import/export
|
||||
- Created Debian/Ubuntu package repository
|
||||
|
|
|
|||
|
|
@ -2,24 +2,26 @@
|
|||
|
||||
## Introducción
|
||||
|
||||
Bienvenido a la nueva interfaz de administración de OpenGnsys. Este manual te guiará en tus primeros pasos para configurar y utilizar eficientemente la plataforma. La nueva consola web representa un salto cualitativo con las siguientes características principales:
|
||||
Bienvenido a la nueva interfaz de administración de OpenGnsys. Este manual te guiará en tus primeros pasos para configurar y utilizar eficientemente la plataforma. La nueva consola web representa un salto cualitativo con las siguientes características principales
|
||||
|
||||
- Desarrollada con Angular 18, un framework moderno y actual
|
||||
- Diseño web responsivo que funciona tanto en entornos de PC como en dispositivos móviles
|
||||
- Soporte multilingüe con traducción al inglés
|
||||
!!! info
|
||||
- Desarrollada con Angular 18, un framework moderno y actual
|
||||
- Diseño web responsivo que funciona tanto en entornos de PC como en dispositivos móviles
|
||||
- Soporte multilingüe con traducción al inglés
|
||||
|
||||
|
||||
## Acceso al Sistema
|
||||
|
||||
## 1. Acceso al Sistema
|
||||
|
||||
Para comenzar a utilizar OpenGnsys:
|
||||
Para comenzar a utilizar OpenGnsys
|
||||
|
||||
1. Abre tu navegador web preferido
|
||||
2. Introduce la dirección URL del servidor OpenGnsys
|
||||
3. En la pantalla de inicio de sesión, introduce tus credenciales (nombre de usuario y contraseña)
|
||||
4. Haz clic en "Iniciar sesión"
|
||||
|
||||
## 2. Interfaz Principal
|
||||
Haz clic en "Iniciar sesión"
|
||||
|
||||
|
||||
|
||||
## Interfaz Principal
|
||||
|
||||
Una vez dentro, encontrarás:
|
||||
|
||||
|
|
@ -27,21 +29,23 @@ Una vez dentro, encontrarás:
|
|||
- **Barra superior**: Información del usuario, notificaciones y acceso rápido a configuraciones
|
||||
- **Área de trabajo central**: Donde se visualiza y gestiona la información seleccionada
|
||||
|
||||
## 3. Configuración Inicial
|
||||
|
||||
|
||||
### 3.1 Gestión de Usuarios
|
||||
## Configuración Inicial
|
||||
|
||||
### Gestión de Usuarios
|
||||
|
||||
La gestión de usuarios te permite controlar quién tiene acceso al sistema y qué puede hacer.
|
||||
|
||||
|
||||
|
||||
#### 3.1.1 Visualizar Usuarios Existentes
|
||||
#### Visualizar Usuarios Existentes
|
||||
|
||||
Accede al menú **Administración > Usuarios** para ver la lista de usuarios actuales del sistema.
|
||||
|
||||
|
||||
|
||||
#### 3.1.2 Añadir un Nuevo Usuario
|
||||
#### Añadir un Nuevo Usuario
|
||||
|
||||
1. En la pantalla de usuarios, haz clic en el botón "Añadir Usuarios"
|
||||
2. Completa el formulario con los siguientes datos:
|
||||
|
|
@ -55,20 +59,20 @@ Accede al menú **Administración > Usuarios** para ver la lista de usuarios act
|
|||
|
||||
3. Haz clic en "Guardar" para crear el nuevo usuario
|
||||
|
||||
#### 3.1.3 Editar un Usuario Existente
|
||||
#### Editar un Usuario Existente
|
||||
|
||||
1. En la lista de usuarios, localiza el usuario que deseas modificar
|
||||
2. Haz clic en el icono de edición (lápiz)
|
||||
3. Actualiza los campos necesarios
|
||||
4. Guarda los cambios
|
||||
|
||||
#### 3.1.4 Eliminar un Usuario
|
||||
#### Eliminar un Usuario
|
||||
|
||||
1. En la lista de usuarios, localiza el usuario que deseas eliminar
|
||||
2. Haz clic en el icono de eliminación (papelera)
|
||||
3. Confirma la acción cuando se te solicite
|
||||
|
||||
### 3.2 Configuración de Roles
|
||||
### Configuración de Roles
|
||||
|
||||
Los roles definen los permisos de los usuarios en la plataforma. OpenGnsys incluye cuatro niveles predefinidos:
|
||||
|
||||
|
|
@ -77,16 +81,11 @@ Los roles definen los permisos de los usuarios en la plataforma. OpenGnsys inclu
|
|||
- **Operador de Unidad Organizativa**: Permisos limitados para operar equipos en la unidad asignada
|
||||
- **Usuario**: Acceso básico a la plataforma
|
||||
|
||||
Para configurar roles:
|
||||
### Variables de Entorno
|
||||
|
||||
1. Accede a **Configuración > Roles**
|
||||
2. Desde aquí podrás ver, editar o crear nuevos roles según necesites
|
||||
Las variables de entorno definen la configuración de conexión con los diferentes componentes:
|
||||
|
||||
### 3.3 Variables de Entorno
|
||||
|
||||
Las variables de entorno definen la configuración básica de conexión con los diferentes componentes:
|
||||
|
||||
1. Accede a **Configuración > Variables de Entorno**
|
||||
1. Accede a **Administración > Variables de Entorno**
|
||||
2. Configura las siguientes variables según tu infraestructura:
|
||||
|
||||
- **OG_CORE_IP**: Dirección IP del servidor principal
|
||||
|
|
@ -97,42 +96,14 @@ Las variables de entorno definen la configuración básica de conexión con los
|
|||
- **REMOTEPC_AUTH_USERNAME**: Usuario para RemotePC
|
||||
- **REMOTEPC_AUTH_PASSWORD**: Contraseña para RemotePC
|
||||
- **REMOTEPC_URL**: URL base del servicio RemotePC
|
||||
- **SSL_ENABLED**: verdadero o falso.
|
||||
|
||||
## 4. Estructura Jerárquica
|
||||
|
||||
|
||||
OpenGnsys organiza los equipos en una estructura jerárquica que facilita su administración. Aunque en esta versión trasciende los conceptos de OU->Aula->Cliente y todos son grupos que se pueden anidar en una estructura jerárquica, para el caso de uso más habitual, el docente, seguiría esta estructura:
|
||||
```
|
||||
Campus > Centro > Aula > Cliente
|
||||
```
|
||||
!!! note "Nota"
|
||||
Las variables UDS_ aparecerán como REMOTEPC_ en tu instalación
|
||||
|
||||
|
||||
|
||||
### 4.1 Creación de Grupos
|
||||
|
||||
Para crear un nuevo grupo:
|
||||
|
||||
1. Accede al menú de **Grupos**
|
||||
2. Selecciona "Nueva Unidad Organizativa"
|
||||
3. Define el tipo de grupo (Centro, Grupo de Aulas, Aula, Grupo de ClientesCentro, Grupo de Aulas, Aula, Grupo de Clientes)
|
||||
4. Completa la información requerida
|
||||
5. Guarda los cambios
|
||||
|
||||
### 4.2 Características de los Grupos
|
||||
|
||||
Los grupos permiten la herencia de configuración, lo que significa que los ajustes aplicados a un grupo superior se heredan automáticamente en los grupos inferiores. Esto incluye:
|
||||
|
||||
- Red y servicio DHCP
|
||||
- Configuración del Boot Server
|
||||
- Versión de ogLive
|
||||
- Plantilla PXE
|
||||
- Servidor NTP
|
||||
- Repositorio de imágenes
|
||||
- Configuración P2P (modo, tiempo)
|
||||
- Configuración Multicast (velocidad, puerto, modo)
|
||||
- Menú de arranque
|
||||
- Perfil de hardware
|
||||
|
||||
## 5. Navegación por los Menús
|
||||
## Navegación por los Menús
|
||||
|
||||
El panel lateral izquierdo contiene todos los menús disponibles según tu rol y los módulos activos:
|
||||
|
||||
|
|
@ -147,56 +118,6 @@ El panel lateral izquierdo contiene todos los menús disponibles según tu rol y
|
|||
!!! note "Nota"
|
||||
Es posible que algunos módulos no estén disponibles si dependen de servicios externos no configurados. Por ejemplo, si el servicio DHCP se gestiona externamente, al acceder a dicho menú se mostrará un aviso indicando que el módulo no está habilitado.
|
||||
|
||||
## 6. Operaciones Básicas
|
||||
|
||||
### 6.1 Gestión de Grupos
|
||||
|
||||
Para administrar equipos:
|
||||
|
||||
1. Accede al menú **Equipos**
|
||||
2. Utiliza los filtros para localizar equipos específicos
|
||||
3. Selecciona uno o varios equipos para realizar acciones como:
|
||||
- Encender/Apagar
|
||||
- Restaurar imagen
|
||||
- Clonar disco
|
||||
- Realizar mantenimiento
|
||||
|
||||
### 6.2 Gestión de Acciones
|
||||
|
||||
Para trabajar con Acciones:
|
||||
|
||||
1. Accede al menú **Acciones**
|
||||
2. Desde aquí podrás:
|
||||
|
||||
- Adminisrar los Comandos
|
||||
- Ejecutar Grupos de Comandos
|
||||
- Ejecutar Tareas
|
||||
|
||||
## 7. Solución de Problemas Comunes
|
||||
|
||||
### 7.1 Problemas de Acceso
|
||||
|
||||
Si no puedes acceder al sistema:
|
||||
|
||||
- Verifica que las credenciales sean correctas
|
||||
- Comprueba la conectividad con el servidor
|
||||
- Contacta con el administrador para verificar tus permisos
|
||||
|
||||
### 7.2 Módulos No Disponibles
|
||||
|
||||
Si un módulo aparece como no disponible:
|
||||
|
||||
- Verifica que el servicio correspondiente esté activo
|
||||
- Comprueba las variables de entorno relacionadas
|
||||
- Consulta los logs del sistema para identificar posibles errores
|
||||
|
||||
## 8. Recursos Adicionales
|
||||
|
||||
[Foro de la Comunidad][foro-url]{target=\_blank}
|
||||
[foro-url]: https://foro.opengnsys.es
|
||||
[Repositorio Git de Desarrollo][git-url]{target=\_blank}
|
||||
[git-url]: https://dev.opengnsys.es/gitea
|
||||
---
|
||||
|
||||
Este manual te ha proporcionado los conocimientos básicos para comenzar a utilizar la interfaz de administración de OpenGnsys. Para información más detallada sobre funcionalidades específicas, consulta la documentación completa o contacta con el soporte técnico.
|
||||
|
||||
--8<-- "sections/oggui-grupos.md"
|
||||
--8<-- "sections/oggui-acciones.md"
|
||||
--8<-- "sections/oggui-cierre.md"
|
||||
|
|
|
|||
|
|
@ -0,0 +1,10 @@
|
|||
## Gestión de Acciones
|
||||
|
||||
Para trabajar con Acciones:
|
||||
|
||||
1. Accede al menú **Acciones**
|
||||
2. Desde aquí podrás:
|
||||
|
||||
- Adminisrar los Comandos
|
||||
- Ejecutar Grupos de Comandos
|
||||
- Ejecutar Tareas
|
||||
|
|
@ -0,0 +1,27 @@
|
|||
## Solución de Problemas Comunes
|
||||
|
||||
### Problemas de Acceso
|
||||
|
||||
Si no puedes acceder al sistema:
|
||||
|
||||
- Verifica que las credenciales sean correctas
|
||||
- Comprueba la conectividad con el servidor
|
||||
- Contacta con el administrador para verificar tus permisos
|
||||
|
||||
### Módulos No Disponibles
|
||||
|
||||
Si un módulo aparece como no disponible:
|
||||
|
||||
- Verifica que el servicio correspondiente esté activo
|
||||
- Comprueba las variables de entorno relacionadas
|
||||
- Consulta los logs del sistema para identificar posibles errores
|
||||
|
||||
## Recursos Adicionales
|
||||
|
||||
[Foro de la Comunidad][foro-url]{target=\_blank}
|
||||
[foro-url]: https://foro.opengnsys.es
|
||||
[Repositorio Git de Desarrollo][git-url]{target=\_blank}
|
||||
[git-url]: https://dev.opengnsys.es/gitea
|
||||
---
|
||||
|
||||
Este manual te ha proporcionado los conocimientos básicos para comenzar a utilizar la interfaz de administración de OpenGnsys. Para información más detallada sobre funcionalidades específicas, consulta la documentación completa o contacta con el soporte técnico.
|
||||
|
|
@ -0,0 +1,46 @@
|
|||
## Grupos: Estructura Jerárquica
|
||||
|
||||
OpenGnsys organiza los equipos jerárquicamente para facilitar su administración. Esta versión trasciende el esquema tradicional OU->Aula->Cliente, permitiendo grupos anidables a múltiples niveles. Para el caso de uso entornos docentes, se puede seguir estructurando del mismo modo, pero ya no es imprescindible.
|
||||
|
||||
```mermaid
|
||||
Campus > Centro > Aula > Cliente
|
||||
```
|
||||
|
||||
{ align=center }
|
||||
|
||||
### Características de los Grupos
|
||||
|
||||
Los grupos permiten la herencia de configuración, lo que significa que los ajustes aplicados a un grupo superior se heredan automáticamente en los grupos inferiores. Esto incluye:
|
||||
|
||||
- Red y servicio DHCP
|
||||
- Configuración del Boot Server
|
||||
- Versión de ogLive
|
||||
- Plantilla PXE
|
||||
- Servidor NTP
|
||||
- Repositorio de imágenes
|
||||
- Configuración P2P (modo, tiempo)
|
||||
- Configuración Multicast (velocidad, puerto, modo)
|
||||
- Menú de arranque
|
||||
- Perfil de hardware
|
||||
|
||||
### Creación de Grupos
|
||||
|
||||
Para crear un nuevo grupo:
|
||||
|
||||
1. Accede al menú de **Grupos**
|
||||
2. Selecciona "Nueva Unidad Organizativa"
|
||||
3. Define el tipo de grupo (Centro, Grupo de Aulas, Aula, Grupo de ClientesCentro, Grupo de Aulas, Aula, Grupo de Clientes)
|
||||
4. Completa la información requerida
|
||||
5. Guarda los cambios
|
||||
|
||||
### Gestión de Clientes
|
||||
|
||||
Para administrar clientes:
|
||||
|
||||
1. Accede al menú **Equipos**
|
||||
2. Utiliza los filtros para localizar equipos específicos
|
||||
3. Selecciona uno o varios equipos para realizar acciones como:
|
||||
- Encender/Apagar
|
||||
- Restaurar imagen
|
||||
- Clonar disco
|
||||
- Realizar mantenimiento
|
||||
|
|
@ -1,7 +1,5 @@
|
|||
# Introducción a OpenGnsys v3.0
|
||||
|
||||
## 1. Introducción
|
||||
|
||||
El proyecto OpenGnsys (léase OpenGénesis) reúne el esfuerzo conjunto de varias Universidades Públicas españolas para construir una aplicación que permita una fácil gestión centralizada de ordenadores y servidores. Con ella se permite la distribución, instalación y despliegue de distintos sistemas operativos.
|
||||
|
||||
|
||||
|
|
@ -10,7 +8,7 @@ OpenGnsys nace debido a la necesidad de disponer de un conjunto de herramientas
|
|||
|
||||
La página web de OpenGnsys (www.opengnsys.es) dispone de todos los manuales del proyecto, el código completo de las distintas versiones, varios foros de discusión y ayuda, documentación de la API de programación, etc.
|
||||
|
||||
### 1.1. Antecedentes, presente y futuro
|
||||
## Antecedentes, presente y futuro
|
||||
|
||||
OpenGnsys nace en mayo de 2009 tras los Grupos de Trabajo de RedIRIS celebrados en Málaga, como un esfuerzo de integrar varios proyectos en desarrollo:
|
||||
|
||||
|
|
@ -27,7 +25,7 @@ Esta versión, aborda las siguientes mejoras
|
|||
- Sincronización de imágenes con GIT
|
||||
- Servicio de logs y monitoreo
|
||||
|
||||
## 2. Características de OpenGnSys
|
||||
## Características de OpenGnSys
|
||||
|
||||
La gestión principal de OpenGnsys está basada en una sencilla interfaz web que permite realizar las tareas comunes para gestionar la distribución de software en los distintos clientes. Sin embargo, la estructura de OpenGnsys es lo suficientemente versátil como para adaptarse a las necesidades de las diferentes arquitecturas de redes de ordenadores disponibles en empresas e instituciones.
|
||||
|
||||
|
|
@ -47,7 +45,7 @@ La restauración del sistema operativo original no sólo supone hacer una copia
|
|||
|
||||
Por definición, OpenGnsys es un proyecto de Software Libre. Como tal, todo el código está licenciado bajo GPLv3 o superior, mientras que la documentación de los cursos está disponible bajo licencia Creative Commons Reconocimiento-NoComercial-CompartirIgual.
|
||||
|
||||
## 3. Arquitectura
|
||||
## Arquitectura
|
||||
|
||||
En esta versión de OpenGnsys, se ha puesto énfasis en la modularidad de la solución, permitiendo desplegar los diferentes componentes en un sólo servidor monolítico, o bien en máquinas separadas. Esto dota de mayor flexibilidad a la solución, que permite cubrir cualquier escenario.
|
||||
|
||||
|
|
@ -58,7 +56,7 @@ La arquitectura de OpenGnsys es suficientemente flexible como para adaptarse a l
|
|||
3. Despliegue y mantenimiento de los servidores de un Centro de Datos en particular.
|
||||
4. Administración de repositorios de clonación de equipos para los servicios de soporte (helpdesk) o los puntos de información de una Institución.
|
||||
|
||||
### 3.1. Capas de servicios
|
||||
### Capas de servicios
|
||||
|
||||
OpenGnsys está constituido por un conjunto de módulos separados en distintas capas de servicios:
|
||||
|
||||
|
|
@ -66,7 +64,7 @@ OpenGnsys está constituido por un conjunto de módulos separados en distintas c
|
|||
- **Capa intermedia**: constituida por un conjunto de herramientas para realizar tareas complejas y personalización del entorno.
|
||||
- **Capa de administración**: que consta de la interfaz web y la base de datos de gestión.
|
||||
|
||||
### 3.2. Módulos
|
||||
### Módulos
|
||||
|
||||
El Proyecto OpenGnsys es un sistema modular que integra un conjunto de componentes interrelacionados entre sí, que puede ser adaptado a una diversidad de escenarios de trabajo posibles. Estos componentes están formados por servicios estándar (servidores de archivos, web, base de datos, DHCP, PXE, ...) y por herramientas desarrolladas a medida para el proyecto, que en combinación ofrecen todas las prestaciones del sistema.
|
||||
|
||||
|
|
@ -119,11 +117,11 @@ En esta versión 3.0, se cuenta con 4 métodos de instalación
|
|||
- Instalación y despliegue mediante OVAs preconfiguradas, listas para su distribución.
|
||||
|
||||
|
||||
#### 3.2.1. Esquema
|
||||
### Esquema
|
||||
|
||||
|
||||
|
||||
### 3.3. Modelo de organización
|
||||
### Modelo de organización
|
||||
|
||||
En esta versión 3.0, la organización de la información se ha flexibilizado creando una jerarquía más orgánica. Una Unidad Organizativa puede ser de 4 tipos:
|
||||
|
||||
|
|
@ -140,7 +138,7 @@ Así mismo, se ha creado un sistema de filtrado y vistas, que permite operar con
|
|||
|
||||
|
||||
|
||||
## 4. Protocolos de comunicaciones
|
||||
## Protocolos de comunicaciones
|
||||
|
||||
El proceso de clonación de un sistema de archivos en un número amplio de ordenadores supone un gran volumen de datos transferidos y, por lo tanto, un tiempo importante en el despliegue de dichos datos. OpenGnsys intenta mitigar estos impactos implantando varios métodos para realizar las transferencias de datos, utilizando 3 protocolos de comunicaciones diferentes.
|
||||
|
||||
|
|
@ -158,7 +156,7 @@ Se recomienda que el alumno evalúe los distintos protocolos de restauración en
|
|||
|
||||
|
||||
|
||||
## 5. Conceptos básicos de operación
|
||||
## Conceptos básicos de operación
|
||||
|
||||
El modo de trabajo con el sistema OpenGnsys requiere que los administradores del sistema tengan un conocimiento de algunos conceptos básicos de operación.
|
||||
|
||||
|
|
@ -206,11 +204,11 @@ Secuencia de órdenes que permite la personalización independiente para cada cl
|
|||
|
||||
Repositorio de datos local del cliente que acelera el proceso de clonación evitando la necesidad de conexión con el repositorio remoto y que almacena los datos de las imágenes propias, sus datos de post-configuración y, opcionalmente, los ficheros del proceso de arranque del cliente. La caché local es un sistema de archivos que normalmente está formateado como Ext4 y que suele estar alojado en la 4ª partición del disco 1.
|
||||
|
||||
## 6. La interfaz web
|
||||
## La interfaz web
|
||||
|
||||
OpenGnsys Web Administrator es una consola de gestión que permite manejar los clientes de una unidad organizativa, realizando un conjunto de operaciones sobre los mismos, tanto las predefinidas por el sistema como aquellas personalizadas por los operadores.
|
||||
|
||||
### 6.1. Descripción general
|
||||
### Descripción general
|
||||
|
||||
La consola web se divide en una serie de espacios principales:
|
||||
|
||||
|
|
@ -239,9 +237,9 @@ En este tipo de menús se encuentran, entre otros, los siguientes tipos de opera
|
|||
- **Tareas**: comandos que se ejecutan sobre un determinado ámbito en particular y que pueden ser programados para ejecutarse en momentos determinados.
|
||||
- **Colas de acciones**: listas de acciones que están pendientes de ejecución en un ámbito determinado.
|
||||
|
||||
### 6.2. Otros elementos importantes
|
||||
## Otros elementos importantes
|
||||
|
||||
#### 6.2.1. NetBoot Avanzado
|
||||
### NetBoot Avanzado
|
||||
|
||||
Esta funcionalidad, se ha integrado en el módulo "ogBoot" que ahora cuenta con una API para interacción y administración.
|
||||
|
||||
|
|
@ -262,7 +260,7 @@ El netboot soporta el arranque de equipos con BIOS legacy y de tipo UEFI.
|
|||
|
||||
El netboot permite ampliar las opciones de arranque para un segundo o tercer disco.
|
||||
|
||||
#### 6.2.2. Menús
|
||||
### Menús
|
||||
|
||||
Un menú es una página web modificada o una lista de ítems que se le presenta al Browser del cliente como página de inicio. Suele contar con una serie de opciones para el arranque de sistemas operativos instalados, la manipulación de datos locales o la ejecución de acciones predefinidas sobre dicho cliente.
|
||||
|
||||
|
|
@ -282,17 +280,17 @@ Página y lista de elementos que pueden ser ejecutados por cualquier usuario.
|
|||
**Menú privado**
|
||||
Página o lista de ítems que solo pueden ser ejecutados tras introducir la clave del usuario administrador.
|
||||
|
||||
#### 6.2.3. Programación de tareas
|
||||
### Programación de tareas
|
||||
|
||||
La programación de ejecución de tareas permite gestionar fácilmente el lanzamiento de dichas tareas sobre sus ámbitos de ejecución en determinados momentos.
|
||||
|
||||
Una programación puede constar por varios elementos cronológicos distintos, que permiten lanzar la tarea según las necesidades temporales, pudiendo indicar los días e incluso las horas, marcándolas sobre un calendario.
|
||||
|
||||
## 7. Referencias bibliográficas
|
||||
## Referencias bibliográficas
|
||||
|
||||
[Sitio web del proyecto OpenGnsys](http://www.opengnsys.es)
|
||||
|
||||
## 8. Para citarnos
|
||||
## Para citarnos
|
||||
|
||||
Para incluir la cita de esta fuente puede copiar y pegar el siguiente texto:
|
||||
|
||||
|
|
|
|||
|
|
@ -6,88 +6,85 @@ Esta versión principal introduce importantes mejoras en todos los componentes d
|
|||
|
||||
---
|
||||
|
||||
## Core Components
|
||||
|
||||
### OpenGnsys DHCP (ogDHCP v0.7.0)
|
||||
## OpenGnsys DHCP (ogDHCP v0.7.0)
|
||||
|
||||
- Instalación y configuración de DHCP mediante API.
|
||||
- Gestión y asignación de redes a los objetos de la consola
|
||||
|
||||
### OpenGnsys Boot (ogBoot) v0.7.1
|
||||
## OpenGnsys Boot (ogBoot v0.7.1)
|
||||
|
||||
#### Sistema de Arranque
|
||||
- Optimizados los servicios asociados a PXE
|
||||
- Implementado nuevo ogLive más ligero y rápido con drivers actualizados
|
||||
- Añadida herramienta de generación de ogLive con soporte para dependencias de Engine, Browser y Agent
|
||||
|
||||
### ogLive v3.3.0
|
||||
## ogLive v3.3.0
|
||||
|
||||
#### Interfaz y Browser
|
||||
- Incorporado nuevo OpenGnsys Browser con modo kiosko
|
||||
- Añadido soporte completo para HTML5/CSS/JavaScript (ogBrowser)
|
||||
|
||||
#### Motor de Clonación v0.10.0
|
||||
## Motor de Clonación (ogCloningEngine v0.10.0)
|
||||
- Reestructurado el OpenGnsys Cloning Engine y migrado parcialmente a Python
|
||||
- Garantizada la utilización exclusiva de componentes open source
|
||||
|
||||
#### OpenGnsys Agent v5.3.0
|
||||
## OpenGnsys Agent (ogAgent v5.3.0)
|
||||
|
||||
- Implementado ogAgent para Windows, Linux, Mac y ogLive desarrollado en Python
|
||||
|
||||
#### Funcionalidades Generales
|
||||
## Funcionalidades Generales RemotePC
|
||||
- Implementada gestión de calendarios para uso remoto de equipos
|
||||
|
||||
---
|
||||
|
||||
## OpenGnsys Repositoriy v0.8.1
|
||||
## OpenGnsys Repositoriy (ogRepository v0.8.1)
|
||||
|
||||
#### Mejoras del Repositorio
|
||||
### Mejoras del Repositorio
|
||||
- Ampliadas las funcionalidades del OpenGnsys Repository
|
||||
- Integrado con otros módulos del sistema mediante API REST.
|
||||
|
||||
#### Transferencias
|
||||
### Transferencias
|
||||
- Optimizados los métodos de transferencia: Unicast, Multicast y P2P
|
||||
- Actualizados los protocolos de transferencia de imágenes
|
||||
|
||||
#### API y Seguridad
|
||||
### API y Seguridad
|
||||
- Ampliadas las funcionalidades mediante API REST
|
||||
- Cifrado mediante TLS para todas las API
|
||||
|
||||
#### Gestión Git
|
||||
### Gestión Git
|
||||
- Implementadas funcionalidades para imágenes sincronizadas con Git
|
||||
- Integrado Forgejo para gestión avanzada de repositorios mediante interfaz web
|
||||
- Añadidas funciones para crear y seleccionar repositorios Git
|
||||
|
||||
#### Integración con Git v0.51
|
||||
### Integración con Git (ogGit v0.51)
|
||||
- Mejoradas las funciones en Git.lib para clonación y restauración
|
||||
- Implementada biblioteca de funciones en Python
|
||||
- Añadida creación automática de repositorios Git durante la instalación
|
||||
- Incorporada sincronización entre repositorios Git y particiones
|
||||
---
|
||||
|
||||
## Web de Administración (GUI) v0.13.0
|
||||
## Web de Administración (ogGUI v0.13.0)
|
||||
|
||||
#### Interfaz
|
||||
### Interfaz
|
||||
- Rediseñada completamente la interfaz web con diseño responsive
|
||||
- Mantenidas todas las funcionalidades previas
|
||||
- Mejorada la experiencia visual y usabilidad
|
||||
|
||||
#### Modularidad
|
||||
### Modularidad
|
||||
- Implementada gestión modular del sistema
|
||||
- Incorporado sistema avanzado de roles y permisos
|
||||
- Añadida búsqueda por etiquetas
|
||||
|
||||
#### Gestión Centralizada (ogCore v0.13.0)
|
||||
### Gestión Centralizada (ogCore v0.13.0)
|
||||
- Unificada la administración de todos los componentes desde la web
|
||||
- Eliminada la necesidad de línea de comandos para tareas habituales
|
||||
|
||||
#### Acciones
|
||||
### Acciones
|
||||
- Implementado nuevo sistema de gestión de acciones por tipo de agente
|
||||
- Añadida agrupación en acciones compuestas
|
||||
- Incorporado historial completo de acciones
|
||||
- Implementadas acciones "requeridas" pendientes
|
||||
- Añadido asistente para acciones predefinidas y modo avanzado
|
||||
|
||||
#### Clientes
|
||||
### Clientes
|
||||
- Desarrollada nueva estructura jerárquica para grupos
|
||||
- Simplificada la gestión de pertenencia a grupos
|
||||
- Añadido soporte para grupos heterogéneos
|
||||
|
|
@ -95,7 +92,7 @@ Esta versión principal introduce importantes mejoras en todos los componentes d
|
|||
- Incorporada visualización en cuadrícula
|
||||
- Añadido concepto de "vista" dinámica basada en criterios
|
||||
|
||||
#### Repositorios e Imágenes
|
||||
### Repositorios e Imágenes
|
||||
- Reorganizados en estructura de grupos
|
||||
- Implementada distinción entre tipos de imágenes
|
||||
- Mejorada la visualización de información para clientes
|
||||
|
|
@ -103,12 +100,12 @@ Esta versión principal introduce importantes mejoras en todos los componentes d
|
|||
- Incorporados permisos granulares y papelera de recuperación
|
||||
- Implementadas búsquedas avanzadas y migración entre repositorios
|
||||
|
||||
#### Perfiles
|
||||
### Perfiles
|
||||
- Añadidas búsquedas por criterios avanzados
|
||||
- Implementada nomenclatura referencial de perfiles
|
||||
- Incorporada relación entre perfiles para comparación
|
||||
|
||||
#### Monitorización
|
||||
### Monitorización
|
||||
- Desarrollado sistema de notificaciones
|
||||
- Añadidas estadísticas configurables
|
||||
- Implementada ayuda contextual
|
||||
|
|
@ -118,13 +115,13 @@ Esta versión principal introduce importantes mejoras en todos los componentes d
|
|||
|
||||
## OpenGnsys Log Service
|
||||
|
||||
#### Sistema de Logging
|
||||
### Sistema de Logging
|
||||
- Implementada API REST para integración completa
|
||||
- Centralizado el almacenamiento y gestión de logs
|
||||
- Incorporados agentes de recolección
|
||||
- Añadido procesamiento en base de datos (OpenSearch)
|
||||
|
||||
#### Visualización
|
||||
### Visualización
|
||||
- Desarrollada interfaz adaptable
|
||||
- Implementadas opciones de filtrado avanzadas
|
||||
- Añadida exportación de resultados
|
||||
|
|
@ -133,11 +130,11 @@ Esta versión principal introduce importantes mejoras en todos los componentes d
|
|||
|
||||
## Instalador Universal
|
||||
|
||||
#### Scripts
|
||||
### Scripts
|
||||
- Actualizados scripts existentes con visualización de versiones disponibles
|
||||
- Añadida verificación de compatibilidad
|
||||
|
||||
#### Instaladores
|
||||
### Instaladores
|
||||
- Desarrollado instalador gráfico unificado con barra de progreso
|
||||
- Implementadas opciones completas de gestión (instalación, actualización, eliminación)
|
||||
- Añadida importación/exportación de base de datos
|
||||
|
|
|
|||
|
|
@ -86,8 +86,11 @@ markdown_extensions:
|
|||
- pymdownx.tilde # Añadido: subíndice y tachado
|
||||
- pymdownx.smartsymbols # Añadido: símbolos como (c), ->, !=, etc.
|
||||
- abbr # Añadido: abreviaturas
|
||||
- pymdownx.snippets # Añadido: incluir fragmentos desde archivos
|
||||
|
||||
- pymdownx.snippets: # Añadido: incluir fragmentos desde archivos
|
||||
# Múltiples rutas base para permitir que los snippets funcionen en estructuras multilingües
|
||||
# sin tener que cambiar las referencias en los archivos .md
|
||||
base_path: [".", "docs", "docs/es/administration", "docs/en/administration"]
|
||||
check_paths: true
|
||||
extra:
|
||||
alternate:
|
||||
- name: Español
|
||||
|
|
@ -129,8 +132,30 @@ nav:
|
|||
- Logs y Monitorización: developer/oglog.md
|
||||
|
||||
plugins:
|
||||
- enumerate-headings:
|
||||
toc_depth: 3
|
||||
strict: true
|
||||
increment_across_pages: true # Si quieres numeración continua en múltiples páginas
|
||||
- search
|
||||
# - awesome-pages
|
||||
- include-markdown
|
||||
- glightbox:
|
||||
touchNavigation: true
|
||||
loop: false
|
||||
effect: zoom
|
||||
slide_effect: slide
|
||||
width: 100%
|
||||
height: auto
|
||||
zoomable: true
|
||||
draggable: true
|
||||
skip_classes:
|
||||
- custom-skip-class-name
|
||||
auto_themed: false
|
||||
auto_caption: false
|
||||
caption_position: bottom
|
||||
background: white
|
||||
shadow: true
|
||||
manual: false
|
||||
- i18n:
|
||||
reconfigure_material: true
|
||||
docs_structure: folder
|
||||
|
|
@ -174,7 +199,7 @@ plugins:
|
|||
cover_title: TITLE TEXT
|
||||
cover_subtitle: SUBTITLE TEXT
|
||||
custom_template_path: TEMPLATES PATH
|
||||
toc: false
|
||||
toc: true
|
||||
toc_level: 3
|
||||
toc_title: TOC TITLE TEXT
|
||||
toc_numbering: true
|
||||
|
|
|
|||
|
|
@ -7,6 +7,7 @@ cairocffi==1.7.1
|
|||
CairoSVG==2.8.2
|
||||
certifi==2025.4.26
|
||||
cffi==1.17.1
|
||||
chardet==5.2.0
|
||||
charset-normalizer==3.4.2
|
||||
click==8.2.0
|
||||
colorama==0.4.6
|
||||
|
|
@ -25,8 +26,10 @@ MarkupSafe==3.0.2
|
|||
mergedeep==1.3.4
|
||||
mkdocs==1.6.1
|
||||
mkdocs-awesome-pages-plugin==2.10.1
|
||||
mkdocs-enumerate-headings-plugin==0.6.2
|
||||
mkdocs-get-deps==0.2.0
|
||||
mkdocs-glightbox==0.4.0
|
||||
mkdocs-include-markdown-plugin==7.1.5
|
||||
mkdocs-material==9.6.14
|
||||
mkdocs-material-extensions==1.3.1
|
||||
mkdocs-minify-plugin==0.8.0
|
||||
|
|
@ -50,6 +53,7 @@ pyphen==0.17.2
|
|||
python-dateutil==2.9.0.post0
|
||||
PyYAML==6.0.2
|
||||
pyyaml_env_tag==1.1
|
||||
reportlab==4.4.1
|
||||
requests==2.32.3
|
||||
simple-file-checksum==1.3.1
|
||||
six==1.17.0
|
||||
|
|
|
|||
Loading…
Reference in New Issue