Editions: EUZOS Desktop and EUZOS Server

Owner's decision (26-10-2026): two editions from one codebase. The same kernel, the same libraries and the same bootloader; you choose the edition when you build. What an edition does not have does not go into the kernel: the modules are behind #[cfg(feature = ...)] and the libraries that only one edition uses are optional. So it is not "disabled", it is not there.

Shared are: the kernel itself (memory, threads, SMP, ACPI/AML, PCI), the console and the shell, the network (TCP/IP, DHCP, DNS, NTP, TLS, HTTP client), sshd (with the same rules as now), storage and the installer of install, the Linux translation layer (without /dev/snd, /dev/video and the Wayland compositor in the server), fetch, the app store and DriverEnricher.

Building

make image                                     # EUZOS Desktop, test build (as always)
make image EUZOS_EDITION=server                 # EUZOS Server, test build
make image EUZOS_EDITION=server EUZOS_ENV=production
make images                                    # all four, checked and zipped

EUZOS_EDITION=desktop|server (default desktop) can be combined with EUZOS_ENV=test|production. In the kernel these are the cargo features desktop (default) and server; exactly one of the two, otherwise the build stops with an error. cargo build -p euzos-kernel without features therefore remains the desktop.

Where it lives in the code:

• kernel/Cargo.toml: the features and which libraries are optional (desktop: web, http, mail, image, hda, alsa, sdio, iwl, uvc, rtl8712, wayland, devtools, oauth, onedrive, graph, mailapp, browserfeedback, storage; server: bcm).
• kernel/src/main.rs: the desktop modules (screen, desktop, browser, chromium, mail, mailapp, explorer, apps, camera, sound, wifi and volume button, on-screen keyboard, terminal, clipboard, installation with account, Microsoft, Entra, vault, offline, privacy, Server Admin) are behind #[cfg(feature = "desktop")]; workplace, serverinstaller and packages behind server. Also net/{wifi,wifi_pci,iwl,brcmfmac, rtl8712,mbim,web}, usb/{uvc,mbim,rtl8712} and linux/{snd,video,wayland}.
• In a few places the shared code needs a name that only exists in the other edition. There a small module with the same name and no contents stands in: server/screen.rs (no graphical screen: a notice becomes a line on the console, keys go to the text installer), net/no_mobile.rs (net::mbim: never metered), linux/no_media.rs (snd, video, wayland: empty types, so no device) and, in the desktop, usb/without_ehci.rs. If shared code gains a new call into a desktop module, the server build fails: put the call behind #[cfg(feature = "desktop")] or add the name to such a module.
• The server build allows dead_code (main.rs): helper code that only the desktop modules used stays there unused and drops out at link time. Other warnings (unused imports, variables) remain errors; both editions build without warnings.
• The kernel file contains EUZOS-EDITION:desktop or EUZOS-EDITION:server (main.rs, EDITION_MARK); make images uses it to check that every image has the kernel of its edition. The first line of the log names the edition: EUZOS Server kernel v0.4.1, build v236 (...).

Size of the kernels

Measured on desktop v239 and server v3 with the graphical server installer (release, opt-level=s, LTO; the production build differs by a few KiB):

make images writes the size of each kernel to build/editions-<build>.txt and at the end of its output.

Images

make images creates four zips (chmod 600):

The checks on the production images are the same as before (the names of the test files must not be in the image); in addition every image is checked for the kernel of the right edition. The small installation stick (make installer) is for the desktop only: you install EUZOS Server from the full image.

The server installer

Boot EUZOS Server from a USB stick and the graphical installer appears, in the same style as the desktop one: the choice screen (Console or Install, the console after 10 s), the cards, light or dark depending on the hour, mouse and keyboard, and the on-screen keyboard if there is no physical keyboard (installer also starts it by hand; without a framebuffer the text installer, installer text). The screens are in libs/ui/src/installation_server.rs (tested, and as PNG with make ui: build/ui/installatie-server/, also light and in English); the kernel draws them with a small layer of its own (kernel/src/server/screen.rs: framebuffer, fonts, arrow, on-screen keyboard). After the installation the server boots into the console, as always. The steps:

1. Environment (test build only): SBX or PROD; is written to the disk as PROFILE.TXT.
2. Network: the network adapter (by default the one with a link) and DHCP or a static address: IP address, netmask or prefix (/24 or 255.255.255.0), gateway, one or two DNS servers, and optionally the external address (public IP or DNS name if the server is behind NAT). IPv4 only: the network stack does not know IPv6 yet (an IPv6 address gives a clear message). An invalid address or a gateway outside the subnet gives a message at the field. A public address is allowed (the server is then directly on the internet): then the warning "This server is directly reachable from the internet" ("Deze server is direct vanaf internet bereikbaar"); the firewall is closed anyway (see "Firewall"). The address applies immediately (for the Account step) and is written to the disk as NETWORK.TXT.
3. Account: the admin logs in or creates an account (e-mail and password, with the code from the mail; the same step as on the desktop, with sbx:/prod: in a test build), without Microsoft. The PC token is only in the installer's memory.
4. Packages: the list, first Workplace management (on by default), then the Package cache (on by default; it needs Workplace management, PACKAGE-CACHE.md). Each package on or off (click, digit, or arrow keys and space). All packages are available. The File server (files, docs/PACKAGE-FILESERVER.md) can be chosen (off by default; it needs Workplace management). Web server (off by default) writes WEB.TXT; its ports 80 and 443 open when the admin turns it on in Server Admin (docs/PACKAGE-WEBSERVER.md). Backup (docs/PACKAGE-BACKUP.md) is available, off by default. A package that is not finished yet would be shown greyed out as coming soon.
5. Name of the workplace server (if Workplace management is chosen).
6. Disk, 7. Wipe (fast or thorough), 8. Confirm (the last 4 characters of the serial number), 9. Progress, 10. Done (power off, remove the stick, power on).

After a successful installation the installer registers the workplace server with the profile server using the admin's account (POST /api/workplace/v1/register?token=<pc-token>; the old Dutch route /api/werkplek/v1/registreer remains as a legacy alias; admins only, with a limit per network and per account): under that admin's organization, with who installed it, when, and the external address. After that it shows up in Server Admin for that admin (name, account, installation date, external address); workplace-register on the VPS is no longer needed. If the admin has more organizations, or it fails (no internet), the Done screen says so and it can be done later. Then the installer logs out the PC token.

The password never goes to the disk (only the kernel has it, during the request). The server only holds the workplace keys (WPKEY.TXT, WPTLS.TXT, created on the machine itself), WORKPLC.TXT (name), NETWORK.TXT, PROFILE.TXT and in a test build the AUTHKEYS.TXT from the stick (SSH for development).

Network after the installation

NETWORK.TXT (euzos_ip::static_ip, tested): per adapter by MAC address dhcp or statisch <ip>/<prefix> <gateway|-> <dns1> [<dns2>], and extern <address> (the keywords in the file are on-disk format and stay Dutch). The server uses it at every boot and on every link. To change it: network on the console (also on a production server: network management), e.g. network bcm0 statisch 192.0.2.6/24 192.0.2.1 1.1.1.1 or network bcm0 dhcp, or in Server Admin (netwerk and netwerk-zet).

Firewall

Owner's decision: an EUZOS Server is completely closed by default, with or without a public address (euzos_ip::firewall, with tests for the rule order; in the kernel net/firewall.rs, on our own network stack, inbound only). Always allowed through are only replies to what the server opens itself, looked up in the kernel's own state (security check Gen10, GEN-1/GEN-2): TCP only of an existing connection, UDP only from the address and port an open socket sent to (DHCP, DNS, NTP; the profile server and the download server just work that way). lan is the subnet of the adapter a packet comes in on, and a source from the subnet of another adapter is dropped (reverse-path check, GEN-3). Blocked packets are counted and logged per source in net log (rate-limited). Further:

Rules (allow|deny tcp|udp|icmp <port|from-to|-> lan|anywhere|<ip>[/<prefix>]; the Dutch words of version 1, toestaan|weigeren and overal, are still accepted) are applied in order; the first that matches decides, otherwise closed. They are in \EOS\FW\FIREWALL.TXT, signed with the server's key (WPKEY.TXT); a modified file does not count (then the default applies), and every change goes into the workplace server's log. The kernel writes version 2 of the file (EUZOS-firewall-v2, English words, a signed counter that goes up with every change, shown by firewall); a signed version 1 file stays valid until the next change. A list without access to the admin protocol is refused (otherwise the server becomes unmanageable). On the console of a production server you can only view the firewall (firewall); opening and closing is only possible with Server Admin (firewall-open, firewall-sluit, firewall-zet). In a test build the console can do it as well (firewall open|close <rule>).

Server packages: the model

Choice: a package is a role or an app, described in one list (euzos_install::server::PACKAGES). The installer and the command packages show that list automatically; a new package is one more line plus its code.

Why this way:

• Workplace management is a role. It is a network service with its own keys that manages the cache in the apps area and checks the admin protocol; that belongs in the kernel, with the same code as on a PC (app_store).
• No module loader. "Downloading" a role would mean that the kernel loads code: a larger attack surface (see docs/WORKPLACE.md, "Server Admin: the package format"). So a role comes with a new EUZOS Server release (signed manifest, fetch/install), not separately. This stays true with the layered updates of 28-10-2026 (LAYERED-UPDATES.md): downloaded data packages contain no code, and downloaded drivers run as isolated user-space processes with only their own device's resources, never as code inside the kernel.
• Apps like Server Admin. What needs no kernel rights can be a signed package from the catalog: the same chain as Chromium and Server Admin, with a download token, and updatable separately.

Turning on and off with Server Admin (27-10-2026)

After the installation the admin turns a package on or off with Server Admin on an EUZOS PC (the admin protocol, port 8446, with the PC key and an admin proof from the profile server):

serveradmin <server> pakketten                  the Packages screen
serveradmin <server> pakket-aan <id>
serveradmin <server> pakket-uit <id>            shows what will happen
serveradmin <server> pakket-uit <id> bevestig   and does it

(The Server Admin action names pakketten, pakket-aan, pakket-uit and bevestig are signed in the admin protocol and stay Dutch on the wire.)

• Packages shows per package: on, off, not installed, or coming soon (kernel/src/server/packages.rs, packages::text).
• Turning off asks for confirmation (bevestig; the server itself also refuses it without, confirmation_needed) and closes the package's ports in the firewall (Package::ports; Workplace management: the cache port 8445; the Package cache: the same port). A rule that also allows the admin protocol stays and is reported (Rules::close_port). Workplace management off means: no cache (the cache port refuses, nothing is filled), but sign-in and management remain, so it can be turned on again. The state is stored as pakket=uit in WORKPLC.TXT. The Package cache (cache) has its own switch in CACHE.TXT (package=off); the cache only serves when both are on. pakket-aan cache on a server without CACHE.TXT (installed before 27-10-2026) sets it up first (PACKAGE-CACHE.md).
• Turning on does not open the firewall by itself: Server Admin names the rule (firewall-open allow tcp 8445 lan).
• Packages that are coming soon cannot be turned on (pakket_binnenkort).
• Every change goes into the server's log (logboek in Server Admin): who (the account from the admin proof), from which PC, and what happened to the firewall.

Later

• A web server: first as a role (web, WEB.TXT): the strict HTTP server of libs/workplace (euzos_workplace::http) and the TLS server of libs/tls already exist. As an app only once EUZOS's own ABI can start a program as a service, with limited rights and a port of its own.
• App packages on the server: the installer side (PACKAGES.TXT) is done; fetching after the first boot comes with the first app package for the server.

EHCI and the desktop

The EHCI driver (USB 2.0, branch ehci, docs/USB-EHCI.md) and the BCM5720 driver (branch bcm5720) are only in EUZOS Server: they are needed for the HPE MicroServer Gen10 (USB 2.0 ports on the EHCI, Broadcom BCM5720 on board) and have not been tested on hardware yet.

EHCI can later move to the desktop as well, after tests on the VAIO, the HP and the FZ-G1 (older Intel chipsets with EHCI next to or before the xHCI). Then: remove #[cfg(feature = "server")] at pub mod ehci in usb/mod.rs, and remove usb/without_ehci.rs. The calls (usb::ehci::init, poll, halt_for_reboot, the lines of usb) are already in both editions.

Console of a production server

Nobody logs in on EUZOS Server. In a production build the console of the server itself (keyboard and screen, physical access) therefore allows the harmless commands (help, reboot, power off, date, mem) and in addition the server packages and the network: workplace, workplace setup [name], workplace now, packages, installer, ip, dhcp, ping, dns, ps, log [n], pci, usb, disks, network (also changing it: network management) and firewall (view only) (euzos_profile::console::allowed_on_server). Never sshd, profile, stick, run or install. A production server has no SSH: sshd does not start, and the firewall does not know the development rule.