Introduction
Introduction
KOS is built on top of a custom Linux distribution that allows KOS to be ported across a wide variety of target hardware with a large base of skilled developers and a well-developed support ecosystem. For experienced desktop Linux users, KOS will immediately feel familiar. However, since KOS is designed to run on unattended dispensers rather than general-purpose desktops, it differs from desktop Linux in several key ways.
System Tools
-
systemd - Most Linux systems now use systemd for runlevel and daemon management. KOS is built from scratch with systemd support, and systemd units are the recommended method to integrate custom OS daemons.
-
NetworkManager - Many smart dispensers are placed in complex network environments. KOS relies on NetworkManager for network configuration, ensuring that dispensers can support any network scenario through simple configuration or advanced triggers.
-
X11 - KOS uses the Xorg Xserver to host the GUI interface (usually Chromium). X is run without a display manager. Instead, it is configured to start the GUI application as its only client.
-
Chromium - KOS ships with Google’s Chromium web browser to host the dispenser GUI.
-
SSH - KOS includes an SSH server for development and maintenance. Access can be dynamically adjusted through KOS Studio to ensure security and prevent unauthorized access to production dispensers.
-
Package Manager - Unlike desktop Linux, KOS does not include any type of in-system package manager like APT or DNF. All software packages are assembled at the time a release is created by KOS Studio, and the only supported method to install additional system packages is through KOS Studio builds. See the section on disk layout for more information.
Filesystem
KOS is responsible for maintaining a secure and functional system over years of usage and unattended software updates. To support this requirement, the OS is structured to prevent drift between dispensers' disk contents over time. Software is shipped as a series of immutable filesystem images that are hash-verified and never modified on the dispenser itself. The images are combined in an OverlayFS at runtime and capped with a writable top layer that is wiped on each reboot. This allows software to function as if it is running on a normal writable filesystem, but guarantees a known start-up environment on each boot. A separate disk partition is set aside for runtime data that must persist across reboots.
The disk of a KOS node usually includes three partitions:
-
Boot - This partition is dependent on the target hardware and includes early boot code to launch the initial Linux kernel
-
ImageFS - This partition is the central repository for the immutable system components and the OS manifests that reference them. It is usually kept read-only, but it is briefly made writable when installing software updates.
-
DataFS - This partition is used to store persistent runtime data for the dispenser. It holds KABs that are dynamically downloaded as well as settings, logs, and other dispenser-specific data.
Boot Process
To support verified boot with immutable components, the boot process for KOS differs significantly from standard desktop distributions. Parts of the boot process allow customization but the process is designed to support multi-node configurations, consistent updates across multiple nodes as well as discovery processes that may be needed in the field when hardware is replaced.
