# 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.
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.
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.
### 1.1. 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:
- Brutalix, University of Zaragoza
- Advanced Cloning Environment (EAC), University of Málaga
- Hidra Web Interface, University of Seville
Currently, several universities collaborate on the project.
This version addresses the following improvements:
- Python as the main programming language
- Communication among all components via REST API
- New web console: symfony-angularjs
- Image synchronization with GIT
- Logging and monitoring service
## 2. 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.
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.
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.
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.
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.
File system-level restoration 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.
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.
## 3. 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.
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:
1. Centralized management of ICT Support Units for Teaching and Research, both for in-person teaching labs and self-learning.
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.1. 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.
### 3.2. 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 following describes the different components of the OpenGnsys Project:
**OpenGnsys Web Administration**
This service consists of three components that centralize the solution’s 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.
**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.
**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.
**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.
**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.
This client-side execution agent integrates the following functionalities:
- Graphical interface for selecting admin-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.
**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.
**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.
- Installation via Debian packages.
- Installation and deployment via Docker containers.
- Installation and deployment via preconfigured OVAs ready for distribution.
#### 3.2.1. Diagram
### 3.3. 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:
- 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.
This distribution allows operations to be applied to any scope 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.
## 4. 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.
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.
- **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.
- **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.
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).
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.
## 5. Basic Operation Concepts
Working with OpenGnsys requires administrators to understand some basic operation 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.
**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.
**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).
**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.
**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).
**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).
**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 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.
**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.
**Post-Configuration**
Sequence of commands for individual client customization, executed after a file system clone, which may include creating, deleting, or editing files.
**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.
## 6. 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.
### 6.1. Overview
The web console is divided into 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.
The main objects accessible via 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.
These menus include, among others, the following primary 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.
### 6.2. Other Important Elements
#### 6.2.1. Advanced NetBoot
Integrated into the “ogBoot” module, which now has an interaction and administration API.
Tool to select the boot type for all or part of the clients in a classroom, choosing among different startup methods.
OpenGnsys defines five default 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.
**Boot of an OS –ogLive– for machine 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.
#### 6.2.2. Menus
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 defined in the web administration console can be classified by generation method:
**Automatic Menu**
Item list generated from defined procedures.
**Custom Menu**
Modified HTML web page that can include URLs with commands or scripts executed on the client.
Menus can also be classified by required 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.
#### 6.2.3. Task Scheduling
Scheduling task execution allows easy management of launching tasks in their execution scopes at specified times.
A schedule can comprise various chronological elements, enabling task launches according to timing needs, specifying days and even hours marked on a calendar.
## 7. References
[OpenGnsys project website](http://www.opengnsys.es)
## 8. How to Cite Us
To include a citation of this source, copy and paste the following text:
- You must include the following CC license in your work:
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International license.