ogDocumentation/i18n-docu/docs/en/index.md

Introduction to OpenGnsys v3.0

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 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, full source code of different versions, several discussion and support forums, programming API documentation, and more.

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 under 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 between all components via REST API
• New web console: symfony-angularjs
• Image synchronization with GIT
• Logging and monitoring service

Features of OpenGnSys

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 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 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 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.

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.

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 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 course documentation is available under a Creative Commons Attribution-NonCommercial-ShareAlike license.

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 adds greater flexibility to the solution, covering any scenario.

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 classroom labs and self-study environments.
2. Maintenance of personal computer fleets of an institution’s members.
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.

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 complex tasks and environment customization.
• Administration layer: consisting of the web interface and management database.

Modules

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 different components of the OpenGnsys Project are described below:

OpenGnsys Web Administration

This service consists of three components that centralize solution organization:

• 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 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, 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 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 -

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.

Order execution agent on the client, integrating the following features:

• 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 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 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

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.

Diagram

Organization Model

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) 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 at any level, from the Organizational Unit (or Administrative Unit) down to a specific client.

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.

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 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 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 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.

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).

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.

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, 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

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 (via DHCP) and its default boot process (using PXE) from OpenGnsys.

Boot Process

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 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. 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

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

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

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 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 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.

The Web Interface

OpenGnsys Web Administrator is a management console that allows handling clients of an organizational unit, performing both predefined and custom operations on them.

Overview

The web console is divided into several main areas:

1. Top bar with configuration and status buttons.
2. Left pane with the module tree to operate on.
3. Right pane with operation forms and results.

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 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 main operation types:

• 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.

Other Important Elements

Advanced NetBoot

This feature is integrated into the “ogBoot” module, which now has an API for interaction and administration.

Tool that allows selecting the boot type for all or part of a classroom’s clients, choosing among different boot methods.

By default, OpenGnsys defines 5 boot methods:

Local boot from the first disk (default):

• 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 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 machines.

Netboot allows extending boot options to a second or third disk.

Menus

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
List of items generated from defined procedures.

Custom Menu
Web page created in modified HTML that may include URLs with commands or scripts executed on the client.

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 user’s password.

Task Scheduling

Scheduling tasks allows easy management of task launches within their execution scopes at specific times.

A schedule can include various chronological elements to trigger tasks as needed, specifying days and even hours marked on a calendar.

References

OpenGnsys Project Website

Citation

To cite this source, you can 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.