Merge branch 'admin-console'
commit
a93f3ade15
Binary file not shown.
|
After Width: | Height: | Size: 56 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 241 KiB After Width: | Height: | Size: 115 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 212 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 149 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 45 KiB After Width: | Height: | Size: 238 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 to configure and use the platform efficiently. 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 on both desktop 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 OpenGnsys server URL
|
||||
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*.
|
||||
- **Sidebar 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
|
||||
#### View Existing Users
|
||||
|
||||
This window allows editing all the fields that were defined during its creation.
|
||||
Go to **Administration > Users** to see the list of current system users.
|
||||
|
||||
#### Delete User
|
||||
|
||||
|
||||
Allows deleting a user.
|
||||
#### Add 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 classroom groups or machines the user can manage
|
||||
|
||||
3. Click "Save" to create the new user
|
||||
|
||||
#### Edit 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
|
||||
|
||||
#### Delete 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 user permissions on the platform. OpenGnsys includes four predefined levels:
|
||||
|
||||
- **Super Administrator**: Full control of the platform, no restrictions
|
||||
- **Organizational Unit Administrator**: 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 to 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:
|
||||
|
||||
## Navigating the Menus
|
||||
- **OG_CORE_IP**: IP address of the main server
|
||||
- **OG_DHCP_API_URL**: DHCP service API URL
|
||||
- **OG_BOOT_API_URL**: Boot server API URL
|
||||
- **OG_LOG_IP**: Logging server IP address
|
||||
- **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
|
||||
|
||||
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.
|
||||
|
||||
|
||||
## Manage Groups
|
||||
!!! note "Note"
|
||||
UDS_ variables will appear as REMOTEPC_ in your installation
|
||||
|
||||
{align=right width=50%}The main characteristics of groups are:
|
||||
## Menu Navigation
|
||||
|
||||
- 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
|
||||
The left sidebar contains all available menus based on your role and the active modules:
|
||||
|
||||
Element groups are a hierarchical system that allows grouping of elements. The most common are Campus, Centers, Classrooms and Clients.
|
||||
- **Groups**: Group management
|
||||
- **Actions**: Actions, Commands, and Tasks management module
|
||||
- **Subnets**: DHCP service management module
|
||||
- **Boot**: Management module for ogLive and PXE boot services
|
||||
- **Calendars**: Module to manage machine availability in the RemotePC service
|
||||
- **Repositories**: Module to manage repositories and their associated images
|
||||
- **Menus**: Allows managing the menus displayed when launching ogLive on a client machine
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
subgraph c1 [" Campus"]
|
||||
subgraph c2 [" Centro"]
|
||||
subgraph c3 [" Aula"]
|
||||
c4[" Cliente"]
|
||||
end
|
||||
end
|
||||
end
|
||||
!!! 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 message indicating that the module is not enabled.
|
||||
|
||||
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"
|
||||
|
|
|
|||
|
|
@ -0,0 +1,11 @@
|
|||
## Action Management
|
||||
|
||||
To work with Actions:
|
||||
|
||||
1. Go to the **Actions** menu
|
||||
2. From here you can:
|
||||
|
||||
- Manage Commands
|
||||
- Execute Command Groups
|
||||
- Execute Tasks
|
||||
|
||||
|
|
@ -0,0 +1,28 @@
|
|||
## Common Troubleshooting
|
||||
|
||||
### Access Issues
|
||||
|
||||
If you cannot access the system:
|
||||
|
||||
- Verify that the credentials are correct
|
||||
- Check connectivity with the server
|
||||
- Contact the administrator to verify your permissions
|
||||
|
||||
### Modules Unavailable
|
||||
|
||||
If a module appears as unavailable:
|
||||
|
||||
- Ensure the corresponding service is active
|
||||
- Check the related environment variables
|
||||
- Review the system logs to identify potential errors
|
||||
|
||||
## Additional Resources
|
||||
|
||||
[Community Forum][foro-url]{target=\_blank}
|
||||
[foro-url]: https://foro.opengnsys.es
|
||||
[Development Git Repository][git-url]{target=\_blank}
|
||||
[git-url]: https://dev.opengnsys.es/gitea
|
||||
---
|
||||
|
||||
This manual has provided you with the basic knowledge to begin using the OpenGnsys administration interface. For more detailed information on specific features, consult the full documentation or contact technical support.
|
||||
|
||||
|
|
@ -0,0 +1,129 @@
|
|||
## Hierarchical Containment Structure
|
||||
|
||||
The logical schema of OpenGnsys offers elements to organize computer equipment in a simplified hierarchical containment structure, as well as user control to access the schema or part of it.
|
||||
|
||||
The new hierarchical structure has been significantly simplified, now based on two main elements: **Organizational Units (Groups)** and **Clients (Workstations)**.
|
||||
|
||||
- **Organizational Units (Groups):**
|
||||
Groups can be of any type according to organizational needs, allowing a completely flexible and adaptable structure for any organizational context.
|
||||
|
||||
- **Clients (Workstations):**
|
||||
These represent the individual machines that will be managed by OpenGnsys.
|
||||
|
||||
This simplified structure enables greater organizational flexibility, conceptually adapting to any type of situation. For example, isolated workstations in different geographical locations can be efficiently grouped into a specific "client group," facilitating centralized management.
|
||||
|
||||
One of the main elements for organization remains the **organizational unit**. Its primary function is to group objects for administrative purposes and enable delegation of authority.
|
||||
|
||||
Delegation allows for the administration of a large number of centers, departments, or laboratories to be distributed among a group of administrator-type users who are trusted to perform specific administrative tasks.
|
||||
|
||||
### Scope of Application Concept
|
||||
|
||||
Each hierarchical element establishes a **scope of application**, a fundamental concept in infrastructure design. This scope determines the set of machines on which specific tasks can be executed, providing granular and organized control of management operations.
|
||||
|
||||
!!! tip "Infrastructure Design"
|
||||
The scope of application is key to efficiently planning the management of machines in your organization.
|
||||
|
||||
## Decentralized Administration
|
||||
|
||||
The OpenGnsys administration tool allows a single administrator to centrally manage resources. In addition to this centralized administration, a decentralized administration can be defined that leverages the new simplified hierarchical structure.
|
||||
|
||||
### Delegating Authority over an Organizational Unit
|
||||
|
||||
The console administrator or superadministrator can manage the delegation of administrative responsibilities for specific organizational units to other administrators.
|
||||
|
||||
With the new simplified structure, this delegation can be made over any type of group, providing greater flexibility in distributing administrative responsibilities.
|
||||
|
||||
These administrators will manage their organizational unit through the console's web interface, having full control over the elements contained within their scope of responsibility.
|
||||
|
||||
### Delegating Tasks to Users with or without Authority
|
||||
|
||||
An organizational unit administrator can delegate specific tasks within the scopes that belong to their organizational unit, regardless of the type of group they manage.
|
||||
|
||||
These delegated tasks are accessible by the user from the managed computer's own terminal. The delegated tasks are included in a menu that may require authentication – a private menu – or not – a public menu.
|
||||
|
||||
A **public menu** typically includes the task of starting a specific operating system. On the other hand, a **private menu** – which requires authentication – is intended to offer cloning options on the computer itself or on all computers in a specific group.
|
||||
|
||||
The flexibility of the new structure allows these delegations to adapt to various organizational scenarios, from traditional structures to geographically distributed groups.
|
||||
|
||||
## The Predefined OpenGnsys Schema
|
||||
|
||||
During the installation process of OpenGnsys, the schema is automatically configured, offering a basic structure adapted to the new simplified hierarchy. This default configuration implements the four conceptual types of Organizational Units to facilitate organizational management.
|
||||
|
||||
### Default Structure
|
||||
|
||||
The predefined schema establishes the following organizational hierarchy:
|
||||
|
||||
- **Center**: Represents the main organizational level
|
||||
- **Classroom Group**: Allows grouping of multiple classrooms with similar characteristics
|
||||
- **Classroom**: Defines specific physical spaces with computers
|
||||
- **Client Group**: Facilitates the grouping of specific workstations
|
||||
|
||||
This default structure can be fully adapted to the specific needs of each organization, allowing nested groups at multiple levels according to particular requirements.
|
||||
|
||||
### Initial Administrative Configuration
|
||||
|
||||
Access to console administration is initially allowed for a single superadministrator user, who also has administrative rights over all organizational units by default. The name and password for this user are set during the installation process.
|
||||
|
||||
Delegated administration of organizational units is initially undefined, except for the OpenGnsys image repository service, which by default is the machine where the application is installed.
|
||||
|
||||
### Organizational Flexibility
|
||||
|
||||
Although this default structure is based on the traditional educational model (Center→Classroom Group→Classroom→Client Group), the new architecture allows surpassing this scheme, facilitating more complex or different organizations based on the specific needs of each environment.
|
||||
|
||||
This flexibility allows isolated workstations in different locations to be efficiently grouped or for completely different organizational structures from the traditional educational model to be implemented.
|
||||
|
||||
## Group Administration
|
||||
|
||||
To manage groups, access the **Groups** module from the left side menu, where the following screen will be displayed:
|
||||
|
||||
- Filter and Search Menu
|
||||
- Group Tree (Organizational Unit/Classroom)
|
||||
- Clients (corresponding to the selected group in the left panel)
|
||||
|
||||
{ style="display: block; margin: 20px auto; max-width: min(1024px, 100%); height: auto;" }
|
||||
|
||||
## Group Features
|
||||
|
||||
Groups allow configuration inheritance, meaning settings applied to a higher-level group are automatically inherited by lower-level groups unless specified otherwise. This includes:
|
||||
|
||||
- Network and DHCP service
|
||||
- Boot Server Configuration
|
||||
- ogLive version
|
||||
- PXE template
|
||||
- NTP Server
|
||||
- Image Repository
|
||||
- P2P Configuration (mode, time)
|
||||
- Multicast Configuration (speed, port, mode)
|
||||
- Boot Menu
|
||||
- Hardware Profile
|
||||
|
||||
### Creating Groups
|
||||
|
||||
To create a new group:
|
||||
|
||||
1. Go to the **Groups** menu
|
||||
2. Select "New Organizational Unit"
|
||||
3. Define the type of group (Center, Classroom Group, Classroom, Client Group)
|
||||
4. Fill in the required information
|
||||
5. Save the changes
|
||||
|
||||
{ style="display: block; margin: 20px auto; max-width: min(1024px, 100%); height: auto;" }
|
||||
|
||||
### Creating Clients
|
||||
|
||||
To register clients, there are two options:
|
||||
|
||||
- Register a single client
|
||||
- Bulk client registration
|
||||
|
||||
To register a client:
|
||||
|
||||
1. Go to the **Groups** menu
|
||||
2. New Client -> Add Single Client
|
||||
3. Fill in the client information
|
||||
|
||||
{ style="display: block; margin: 20px auto; max-width: min(1024px, 100%); height: auto;" }
|
||||
|
||||
For bulk client registration:
|
||||
|
||||
- A text file must be created (it can be `.txt` or any plain text format) with the following DHCP configuration structure:
|
||||
|
|
@ -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 - ogCloningEngine 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 - ogAgent 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 - ogRepository 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 - ogGit 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 - ogGui 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
|
||||
|
|
|
|||
|
|
@ -1,114 +1,137 @@
|
|||
# Interfaz de Administración
|
||||
# ogGui - Interfaz de Administración OpenGnsys
|
||||
|
||||
La consola Web, supone el mayor avance de OpenGnsys en esta nueva versión, con las caractersíticas principales de:
|
||||
## Introducción
|
||||
|
||||
- Desarrollada con un lenguaje actual y moderno, Angular 18
|
||||
- Web Responsiva, funcionando tanto en entorno de PC como Móvil
|
||||
- Multilingüe, contando con traducción a inglés
|
||||
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
|
||||
|
||||
|
||||
!!! 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
|
||||
|
||||
## Configuración
|
||||
Después de realizar este módulo podrá:
|
||||
|
||||
La nueva interfaz de administración de OpenGnsys, cuenta con las siguientes características para su Configuración
|
||||
**Manejo de la interfaz**
|
||||
|
||||
{ align=center width=20% }
|
||||
- Describir la estructura jerárquica que proporciona OpenGnsys
|
||||
- Gestionar usuarios y permisos
|
||||
- Gestionar roles y autorización
|
||||
- Configurar las variables de entorno
|
||||
|
||||
### Usuarios
|
||||
**Organización de los diferentes elementos**
|
||||
|
||||
Se permite crear, editar y eliminar Usuarios
|
||||
- Gestión de Grupos y Clientes.
|
||||
- Ámbito de aplicación. Acciones.
|
||||
|
||||
{ align=center }
|
||||
## Acceso al Sistema
|
||||
|
||||
#### Añadir Usuario
|
||||
Para comenzar a utilizar OpenGnsys
|
||||
|
||||
{ align=right width=40% } Habrá que definir el *usuario*, *contraseña*, *rol*, *unidad organizativa* y *vista*.
|
||||
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)
|
||||
|
||||
- **Nombre de Usuario**: se usará para le inicio de sesión
|
||||
Haz clic en "Iniciar sesión"
|
||||
|
||||
- **Contraseña**: la contraseña se define aquí por un administrador. El usuario no podrá cambiar la contraseña, si no tiene acceso al panel de administración de usuarios.
|
||||
{ style="display: block; margin: 20px auto; max-width: min(1024px, 100%); height: auto;" }
|
||||
|
||||
- **Rol**: permite asignar uno o varios roles al usuario. Los roles permiten una mayor granularidad a la hora de administrar los permisos que tendrá cada usuario para administrar la plataforma.
|
||||
## Interfaz Principal
|
||||
|
||||
- **Unidad Organizativa**: permite definir sobre qué grupo de aulas o equipos podrá administrar el usuario. Este campo permite elegir uno o varios grupos sobre los que el usuario podrá interactuar.
|
||||
Una vez dentro, encontrarás:
|
||||
|
||||
<div style="clear: both;"></div>
|
||||
- **Panel de navegación lateral**: Acceso a todos los módulos y funcionalidades
|
||||
- **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
|
||||
|
||||
#### Editar usuario
|
||||
{ style="display: block; margin: 20px auto; max-width: min(1024px, 100%); height: auto;" }
|
||||
|
||||
Esta ventana permite editar todos los campos que se han definido en la creación del mismo.
|
||||
## Configuración Inicial
|
||||
|
||||
#### Eliminar Usuario
|
||||
### Gestión de Usuarios
|
||||
|
||||
Permite eliminar un usuario.
|
||||
La gestión de usuarios te permite controlar quién tiene acceso al sistema y qué puede hacer.
|
||||
|
||||
### Roles
|
||||
{ style="display: block; margin: 20px auto; max-width: min(1024px, 100%); height: auto;" }
|
||||
|
||||
Los roles permiten gestionar los permisos de acceso que tienen los usuarios para adminsitrar la plataforma. Actualmente se cuenta con 4 niveles de administración según los roles:
|
||||
#### Visualizar Usuarios Existentes
|
||||
|
||||
- Super Admin: permite control total de la plataforma, sin restricciones.
|
||||
- Admin de Unidad Organizativa: permite al usuario realizar todas las actividades existentes, sobre la unidad organizativa.
|
||||
- Operador de Unidad Organizativa:
|
||||
- Usuario
|
||||
Accede al menú **Administración > Usuarios** para ver la lista de usuarios actuales del sistema.
|
||||
|
||||
{ style="display: block; margin: 20px auto; max-width: min(1024px, 100%); height: auto;" }
|
||||
|
||||
#### 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:
|
||||
|
||||
{ style="display: block; margin: 20px auto; max-width: min(1024px, 100%); height: auto;" }
|
||||
|
||||
- **Nombre de Usuario**: Identificador único para iniciar sesión
|
||||
- **Contraseña**: Clave de acceso (nota: solo los administradores pueden cambiar contraseñas)
|
||||
- **Rol**: Selecciona uno o varios roles que definirán los permisos del usuario
|
||||
- **Unidad Organizativa**: Define sobre qué grupos de aulas o equipos podrá administrar el usuario
|
||||
|
||||
3. Haz clic en "Guardar" para crear el nuevo usuario
|
||||
|
||||
#### 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
|
||||
|
||||
#### 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
|
||||
|
||||
### Configuración de Roles
|
||||
|
||||
Los roles definen los permisos de los usuarios en la plataforma. OpenGnsys incluye cuatro niveles predefinidos:
|
||||
|
||||
- **Super Admin**: Control total de la plataforma, sin restricciones
|
||||
- **Admin de Unidad Organizativa**: Control completo sobre la unidad organizativa asignada
|
||||
- **Operador de Unidad Organizativa**: Permisos limitados para operar equipos en la unidad asignada
|
||||
- **Usuario**: Acceso básico a la plataforma
|
||||
|
||||
### Variables de Entorno
|
||||
|
||||
En este menú se definen, principalmente, las IP y puerto de las API de los diferentes componentes
|
||||
Las variables de entorno definen la configuración de conexión con los diferentes componentes:
|
||||
|
||||
- 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. 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
|
||||
- **OG_DHCP_API_URL**: URL de la API del servicio DHCP
|
||||
- **OG_BOOT_API_URL**: URL de la API del servidor de arranque
|
||||
- **OG_LOG_IP**: Dirección IP del servidor de logs
|
||||
- **REMOTEPC_AUTH_LOGIN**: URL de autenticación para RemotePC
|
||||
- **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.
|
||||
|
||||
{ style="display: block; margin: 20px auto; max-width: min(1024px, 100%); height: auto;" }
|
||||
|
||||
!!! note "Nota"
|
||||
Las variables UDS_ aparecerán como REMOTEPC_ en tu instalación
|
||||
|
||||
## Navegación por los Menús
|
||||
|
||||
En el panel izquierdo, contamos con los menús que nos dan acceso a las características de OpenGnsys que tengamos actualmente activas y funcionando.
|
||||
!!! note "Nota"
|
||||
Es posible que OpenGnsys no cuente con algunos módulos, porque son consumidos de infraestructuras externas, el ejemplo más clásico es DHCP. En este caso, al acceder a dicho menú se nos mostrará una advertenca de que este módulo no está habilitado.
|
||||
El panel lateral izquierdo contiene todos los menús disponibles según tu rol y los módulos activos:
|
||||
|
||||
## Administrar Grupos
|
||||
|
||||
{align=right width=50%}Las características principales de los grupos son:
|
||||
|
||||
- Herencia
|
||||
- Red y servicio DHCP
|
||||
- Boot Server
|
||||
- Versión de ogLive
|
||||
- Plantilla PXE
|
||||
- Servidor NTP
|
||||
- Repositorio de Imágenes
|
||||
- Configuración de los valores de P2P (modo, tiempo)
|
||||
- Configuración de los valores de Multicast (velocidad, puerto, modo)
|
||||
- Menú
|
||||
- Perfil de Hardware
|
||||
|
||||
Los grupos de elementos, son un sistema jerárquico que permite agrupación de elementos. Los más clásicos son Campus, Centros, Aulas y Clientes.
|
||||
|
||||
```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>
|
||||
- **Grupos**: Administración de los grupos
|
||||
- **Acciones**: El módulo de gestión de Acciones, Comandos y Tareas.
|
||||
- **Subredes**: El módulo de gestión del servicio de DHCP.
|
||||
- **Boot**: El módulo de gestión de los servicios de arranque ogLive y PXE.
|
||||
- **Calendarios**: Módulo para la gestión de disponibilidad de equipos en el servicio RemotePC
|
||||
- **Repositorios**: Módulo para la gestión de repositorios y las imágenes asociadas a cada uno.
|
||||
- **Menús**: Permite administrar los menús que se mostarán al iniciar ogLive en un equipo cliente.
|
||||
|
||||
!!! 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.
|
||||
|
||||
--8<-- "sections/oggui-grupos.md"
|
||||
--8<-- "sections/oggui-acciones.md"
|
||||
--8<-- "sections/oggui-cierre.md"
|
||||
|
|
|
|||
|
|
@ -0,0 +1,48 @@
|
|||
## Administración y ejecución de Acciones.
|
||||
|
||||
En esta sección, se describen las principales características del módulo de Acciones para llevar a cabo la ejecución de comandos, procedimientos y tareas, así como su ámbito de aplicación definiendo el contexto.
|
||||
|
||||
- **Acción:**
|
||||
Operación en general que puede ser requerida desde la consola de administración web y que será ejecutada en los clientes
|
||||
- **Comando**
|
||||
Acción predefinida en la consola web de OpenGnsys. En esta nueva consola de Opengnsys se pueden añadir nuevos comandos, utilizando la función de "script" de los procedimientos.
|
||||
- **Procedimiento** (Script)
|
||||
Secuencia de acciones con sus parámetros de ejecución que puede ser lanzada para ejecutarse sobre cualquier cliente o grupo de clientes. Esta característica se articula a través de los "Scripts"
|
||||
- **Tarea**
|
||||
Secuencia de acciones, similar al procedimiento, que se realiza directamente sobre un ámbito de ejecución determinado y que puede ser programada para realizarse en periodos específicos de tiempo.
|
||||
|
||||
Para acceder a estas características tenemos tres opciones que determinan su ámbito de aplicación
|
||||
|
||||
- **Desde el panel lateral**, donde podemos trabajar directamente con los **Comandos** y **Tareas** para **Crear**, **Editar**, **Eliminar**.
|
||||
- **Desde el árbol de grupos** donde tendremos acceso al menú de "Ejecutar Script" que nos permitirá realizar dicha acción sobre los objetos contenidos en este grupo.
|
||||
- **Sobre un cliente determinado**, donde podremos acceder tanto al menú de acciones predefinidas, como al menú de script.
|
||||
|
||||
{ style="display: block; margin: 20px auto; max-width: min(1024px, 100%); height: auto;" }
|
||||
|
||||
!!! warning "Advertencia"
|
||||
La nueva consola permite, a pesar de haber seleccionado un grupo en el árbol de grupos, revisar la selección para hacerla más granular, quitando de la lista de clientes objetivo aquellos sobre los que no se quiera llevar a cabo la actividad. El botón "Ejecución Comandos" se habilita cuando hay al menos un cliente seleccionado.
|
||||
|
||||
{ style="display: block; margin: 20px auto; max-width: min(1024px, 100%); height: auto;" }
|
||||
|
||||
## Acciones predefinidas
|
||||
|
||||
Desde la ventana de clientes, podemos acceder a las acciones disponibles para un cliente determinado, en función de su estado.
|
||||
|
||||
En el ejemplo, observamos que el cliente está encendido por lo tanto las acciones disponibles son:
|
||||
|
||||
{ style="float: right; margin: 0 0 15px 20px; max-width: min(350px, 45%); height: auto;" }
|
||||
|
||||
- **Apagar**: permite apagar un equipo encendido. En este caso concreto, al estar el icono del cliente amarillo, nos indica que se encuentra iniciado en ogLive
|
||||
- **Reiniciar**
|
||||
- **Iniciar Sesión**
|
||||
- **Crear Imagen**: al encontrarse iniciado en ogLive, nos permite crear una imagen a partir de este equipo, si consideramos que es el equipo modelo.
|
||||
- **Clonar/desplegar imagen**: las herramientas de clonación y despliegue de imágenes se encuentran disponibles si nos encontramos con un equipo iniciado en ogLive.
|
||||
- Eliminar Imagen Cache
|
||||
- **Particionar y Formatear**: el motor de clonación se encuentra disponible, por lo que nos permite trabajar con la estructura del disco
|
||||
- Inventario Software
|
||||
- Inventario Hardware
|
||||
- **Ejecutar script**: así mismo, nos permite ejecutar scripts sobre el cliente, que en este caso, se reducen al ámbito de aplicación de ogLive
|
||||
|
||||
<div style="clear: both;"></div>
|
||||
|
||||
|
||||
|
|
@ -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,147 @@
|
|||
## Estructura de contención jerárquica
|
||||
|
||||
El esquema lógico de OpenGnsys proporciona los elementos para organizar los equipos informáticos en una estructura de contención jerárquica simplificada, así como el control de usuarios que tendrán acceso al esquema o a parte de éste.
|
||||
|
||||
La nueva estructura jerárquica se ha simplificado significativamente, basándose ahora en dos elementos principales: **Unidades Organizativas (Grupos)** y **Clientes (Estaciones de Trabajo)**.
|
||||
|
||||
- **Unidades Organizativas (Grupos):**
|
||||
Los grupos pueden ser del tipo que se desee según las necesidades organizacionales, permitiendo una estructura completamente flexible y adaptable a cualquier contexto organizacional.
|
||||
|
||||
- **Clientes (Estaciones de Trabajo):**
|
||||
Representan los equipos individuales que serán gestionados por OpenGnsys.
|
||||
|
||||
Esta estructura simplificada permite una mayor flexibilidad organizacional, pudiendo adaptarse conceptualmente a cualquier tipo de situación. Por ejemplo, estaciones de trabajo aisladas en diferentes localizaciones geográficas pueden agruparse eficientemente en un "grupo de clientes" específico, facilitando su gestión centralizada.
|
||||
|
||||
Uno de los elementos principales para la organización sigue siendo la **unidad organizativa**. Su principal función es agrupar objetos con fines administrativos y permitir la delegación de autoridad.
|
||||
|
||||
La delegación permite distribuir la administración de un gran número de centros, departamentos o laboratorios, entre una serie de usuarios de tipo administrador en quienes se confía para realizar tareas de administración específicas.
|
||||
|
||||
### Concepto de ámbito de aplicación
|
||||
|
||||
Cada elemento jerárquico establece un **ámbito de aplicación**, concepto fundamental en el diseño de la infraestructura. Este ámbito determina sobre qué conjunto de equipos se pueden ejecutar tareas específicas, proporcionando un control granular y organizado de las operaciones de gestión.
|
||||
|
||||
!!! tip "Diseño de infraestructura"
|
||||
El ámbito de aplicación es clave para planificar eficientemente la gestión de equipos en tu organización.
|
||||
|
||||
## Administración descentralizada
|
||||
|
||||
La herramienta de administración de OpenGnsys permite que un único administrador gestione los recursos de forma centralizada. Además de esta administración centralizada, se puede definir una administración descentralizada que aprovecha la nueva estructura jerárquica simplificada.
|
||||
|
||||
### Delegación de autoridad sobre una unidad organizativa
|
||||
|
||||
El administrador de la consola o superadministrador puede gestionar la delegación de responsabilidades administrativas para unidades organizativas específicas en otros administradores.
|
||||
|
||||
Con la nueva estructura simplificada, esta delegación puede realizarse sobre cualquier tipo de grupo, proporcionando mayor flexibilidad en la distribución de responsabilidades administrativas.
|
||||
|
||||
Estos administradores gestionarán su unidad organizativa mediante la interfaz web de la consola, teniendo control total sobre los elementos contenidos en su ámbito de responsabilidad.
|
||||
|
||||
### Delegación de tareas a usuarios con o sin autoridad
|
||||
|
||||
El administrador de una unidad organizativa puede delegar tareas específicas sobre los ámbitos que pertenecen a su unidad organizativa, independientemente del tipo de grupo que administre.
|
||||
|
||||
Estas tareas delegadas son accesibles por el usuario desde el propio terminal del ordenador gestionado. Las tareas delegadas se incluyen en un menú que puede requerir autenticación –menú privado– o no –menú público–.
|
||||
|
||||
Un **menú público** normalmente incluye la tarea de iniciar un determinado sistema operativo. En cambio, un **menú privado** –que requiere autenticación– está destinado a ofrecer opciones de clonación sobre el propio ordenador o sobre todos los ordenadores de un grupo específico.
|
||||
|
||||
La flexibilidad de la nueva estructura permite que estas delegaciones se adapten a diferentes escenarios organizacionales, desde estructuras tradicionales hasta grupos distribuidos geográficamente.
|
||||
|
||||
## El esquema predefinido de OpenGnsys
|
||||
|
||||
Durante el proceso de instalación de OpenGnsys se configura de manera automática el esquema, ofreciendo una estructura básica adaptada a la nueva jerarquía simplificada. Esta configuración predeterminada implementa los cuatro tipos conceptuales de Unidades Organizativas para facilitar la gestión organizacional.
|
||||
|
||||
### Estructura predeterminada
|
||||
|
||||
El esquema predefinido establece la siguiente jerarquía organizacional:
|
||||
|
||||
- **Centro**: Representa el nivel organizacional principal
|
||||
- **Grupo de Aulas**: Permite agrupar múltiples aulas con características similares
|
||||
- **Aula**: Define espacios físicos específicos con equipos informáticos
|
||||
- **Grupo de Clientes**: Facilita la agrupación de estaciones de trabajo específicas
|
||||
|
||||
Esta estructura predeterminada puede adaptarse completamente a las necesidades específicas de cada organización, permitiendo crear grupos anidables a múltiples niveles según los requerimientos particulares.
|
||||
|
||||
### Configuración administrativa inicial
|
||||
|
||||
El acceso a la administración de la consola está permitido inicialmente a un solo usuario de tipo superadministrador, que además tiene los derechos de administración sobre todas las unidades organizativas por defecto. El nombre de este usuario y su contraseña son los indicados durante el proceso de instalación.
|
||||
|
||||
La administración de las unidades organizativas delegadas está inicialmente sin definir, a excepción del servicio repositorio de imágenes OpenGnsys, que por defecto es el equipo donde se ha instalado la aplicación.
|
||||
|
||||
### Flexibilidad organizacional
|
||||
|
||||
Aunque se proporciona esta estructura predeterminada basada en el modelo educativo tradicional (Centro→Grupo de Aulas→Aula→Grupo de Clientes), la nueva arquitectura permite trascender este esquema, facilitando organizaciones más complejas o diferentes según las necesidades específicas de cada entorno.
|
||||
|
||||
Esta flexibilidad permite que estaciones de trabajo aisladas en diferentes localizaciones se puedan agrupar eficientemente, o que se implementen estructuras organizacionales completamente diferentes al modelo educativo tradicional.
|
||||
|
||||
## Administración de los Grupos
|
||||
|
||||
Para administrar los grupos, accedemos al módulo **Grupos** del menú lateral izquierdo, donde se nos presentará la siguiente pantalla
|
||||
|
||||
- Menú de Filtros y Búsqueda
|
||||
- Arbol de Grupos (Unidad Organizativa/Aula)
|
||||
- Clientes (correspondientes al grupo seleccionado en el panel de la izquierda)
|
||||
|
||||
{ style="display: block; margin: 20px auto; max-width: min(1024px, 100%); height: auto;" }
|
||||
|
||||
## 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, si no se indica lo contrario. 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
|
||||
|
||||
{ style="display: block; margin: 20px auto; max-width: min(1024px, 100%); height: auto;" }
|
||||
|
||||
### Creación de Clientes
|
||||
|
||||
Para dar de alta clientes existen dos opciones
|
||||
|
||||
- Alta de un cliente individual
|
||||
- Alta masiva de clientes
|
||||
|
||||
Para dar de alta un cliente:
|
||||
|
||||
1. Accede al menú **Grupos**
|
||||
2. Nuevo Cliente -> Añadir cliente unitario
|
||||
3. Cubrir la información del cliente
|
||||
|
||||
{ style="display: block; margin: 20px auto; max-width: min(1024px, 100%); height: auto;" }
|
||||
|
||||
Para dar de alta varios clientes de forma masiva
|
||||
|
||||
- Se debe elaborar un fichero de texto (puede ser `.txt` o cualquier formato de texto plano) que tenga la siguiente estructura de configuración DHCP:
|
||||
|
||||
```
|
||||
host nombre_host01 {
|
||||
hardware ethernet a0:48:1c:8a:f1:5c;
|
||||
fixed-address 172.17.69.11;
|
||||
}
|
||||
host nombre_host02 {
|
||||
hardware ethernet a0:48:1c:8a:f1:5d;
|
||||
fixed-address 172.17.69.12;
|
||||
}
|
||||
```
|
||||
|
||||
- Se elige a qué **Grupo** van a pertenecer los clientes
|
||||
- Existen dos opciones para cargar los datos:
|
||||
- **Subir fichero**: Se carga el fichero con el formato correspondiente
|
||||
- **Pegar contenido**: Se pega directamente el contenido en la ventana de importación
|
||||
|
||||
{ style="display: block; margin: 20px auto; max-width: min(1024px, 100%); height: auto;" }
|
||||
|
|
@ -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 - ogCloningEngine 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 - ogAgent 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 - ogRepository 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 - ogGit 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 - ogGui 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
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
site_name: OpenGnsys v3.0
|
||||
site_url: https://opengsys.es
|
||||
use_directory_urls: true
|
||||
repo_url: https://dev.opengnsys.es/gitea
|
||||
repo_name: OpenGnsys Gitea
|
||||
|
||||
|
|
@ -86,8 +87,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 +133,29 @@ 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_caption: false
|
||||
caption_position: bottom
|
||||
background: white
|
||||
shadow: true
|
||||
manual: false
|
||||
- i18n:
|
||||
reconfigure_material: true
|
||||
docs_structure: folder
|
||||
|
|
@ -161,8 +186,7 @@ plugins:
|
|||
minify_html: true
|
||||
minify_js: true
|
||||
minify_css: true
|
||||
- tags: # Añadido: soporte para etiquetas
|
||||
tags_file: tags.md # Archivo donde se muestran todas las etiquetas
|
||||
- tags # Añadido: soporte para etiquetas
|
||||
- social # Añadido: imágenes para compartir en redes
|
||||
- pdf-generate:
|
||||
author: "OpenGnsys"
|
||||
|
|
@ -174,7 +198,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,7 +26,11 @@ 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-i18n==0.4.6
|
||||
mkdocs-include-markdown-plugin==7.1.5
|
||||
mkdocs-material==9.6.14
|
||||
mkdocs-material-extensions==1.3.1
|
||||
mkdocs-minify-plugin==0.8.0
|
||||
|
|
@ -49,6 +54,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