Technical architecture¶

InfraMedia is assembled as an image and is not modified on the machine. The root filesystem is composed of layers, each layer a squashfs image packed at build time. Everything the machine writes lives on separate partitions.

Firmware layers¶

The application layer is an increment over the base one: only the difference from the base layer goes into it. Libraries already present below are not carried up again.

Disk partitions¶

The installer lays the disk out in three partitions.

• FIRMWARE — the EFI boot partition: the boot files of the installed versions, the layer images, the loader menu.
• SETTINGS — the machine's settings: the configurator's store and the /etc overlay.
• VAR — mutable data: logs, the database directory, the application's working files.

The root stays read-only throughout. The home directory of root is a tmpfs and lives until the next reboot; whatever has to survive one belongs on the mutable data partition.

Boot¶

The machine boots through systemd-boot. The kernel, the initrd, the command line and the manifest of the firmware contents are glued into a single boot file. This is done for one property: choosing a boot entry chooses the kernel, the initrd and the list of layers together, and they cannot fall out of sync. Two firmware versions on the disk are two menu entries, and a rollback returns the whole set.

The boot goes like this.

1. UEFI hands control to the loader, which starts the boot file of the version selected in the menu.
2. The initrd reads the manifest, finds the layer images on the boot partition and verifies their sha256 against the manifest.
3. The layers are attached and assembled into the root; the /etc overlay from the settings partition is attached on top.
4. Control passes to systemd, which brings up the management daemon and the application.

The initrd is a busybox script: it does not depend on the application and is built once per architecture.

The configurator¶

The configurator is the machine's management daemon. It listens on HTTP port 8090 and exposes the API: machine overview, network interfaces, machine name and time servers, firmware, reboot and power off. It also serves the web interface — there is no separate port for it.

It acts on the system by calling the standard programs and writing configuration files — ip, networkctl, resolvectl, hostnamectl, timedatectl, systemctl and the files under /etc/systemd/.

The settings store¶

The single source of truth about how the machine is configured is the configurator's settings store. The systemd files are rendered from it and are never read back.

Two practical rules follow.

• Editing the generated files by hand is pointless: the next render restores the stored value.
• The stored value and the actual state are different things. The stored value comes from the store, the actual state the configurator takes from the running system through the machine-readable output of the system utilities, and the two can differ.

The change session¶

Network changes are applied in a confirm-or-revert mode. A change opens a session, and while it is open the store is frozen as a whole. If the confirmation does not arrive in time, the store returns to the saved copy and the settings to the previous ones. There is never more than one open session.

The point of the mechanism is practical: a mistake in an interface setting no longer means losing access to the machine.

Limited mode¶

If the store cannot be read — the file is damaged or its version is newer than the daemon itself — the configurator falls into limited mode: read operations work, changes are rejected, nothing is rendered. The machine keeps running on what has already been rendered.

The hardware profile¶

The hardware profile describes the machines the firmware of this architecture runs on: the kernel configuration with their drivers and the rules that bring physical interfaces to canonical names by device path. The drivers of every supported machine are built into one kernel, and the same image boots on any of them.

Canonical names are assigned by the role of the interface — manage for management, streaming for streaming, with an ordinal number. Only an interface that has a canonical name can be configured through the API; a physical interface without one is visible but not configurable.

The web interface¶

The web interface ships in the base layer and is served by the daemon itself — it has to work on a machine where the application is absent or has not come up. It has five sections: Overview, Interfaces, System, Updates, Power.

The screens are built apart from the shell: they carry no theme, no router and no authentication, and they do not know where the API lives. That gives them two entrances — the application on the configurator's port, and a section inside the console of the application, which loads the screens from the machine itself. The operator configures the chassis where they already work with the media server.

Two versions¶

The operating system and the server firmware carry different numbers. The firmware is InfraMedia of one version plus the application of another; both are recorded in the manifest of the boot file. The application is built on the published parts of the operating system rather than rebuilding it.