Shared-image stateless nodes¶

Locally executing networked nodes use a centrally maintained system image while durable system or user data resides outside each replaceable node.

Version: v1 · 2026-10-17 · History
Domain-specific #: 14295
Domain group: Applied Sciences & Engineering
Origin domain: Computer Science & Software Engineering
Subdomains: Networked Systems, Diskless Provisioning → Computer Science & Software Engineering
Aliases: Diskless shared-image nodes

Core Idea¶

Shared-image stateless nodes are computers that execute locally using a centrally maintained operating-system or root base. Durable system or user data lives on shared or server storage, so the executing node is replaceable without carrying that unique data. ATIX's diskless shared-root cluster and LTSP's diskless desktops have different purposes, but both supply a common base to local computers and keep relevant durable state off the node.[^{ref-04a7ba39ba4a][}ref-5641d83402a9][^ref-19d4bd0f26e5]

“Stateless” does not mean no RAM state, local configuration or temporary writes. LTSP uses a temporary writable overlay; Warewulf documents node-specific overlays on a common OS image. Warewulf supports that variation, but these documents alone do not establish that all its workload data stays off-node.[^{ref-5641d83402a9][}ref-03889934ec0b][^ref-4b51919831af]

Scope of Application¶

Use this term in networked computer provisioning when several locally executing machines receive a centrally maintained system base and keep state needed after replacement on external storage. The base can be accessed as a shared root or delivered as a client image. A particular NFS, PXE or failover design is not required. Red Hat's diskless guide shows another NFS-root implementation, but does not describe ATIX's particular cluster.[^{ref-04a7ba39ba4a][}ref-5641d83402a9][^ref-33f34edd4562]

Clarity¶

Ask four questions: Where is the system base maintained? Where does code execute? How is the base supplied? Where is durable data kept? An ordinary thin terminal that only displays software running on a server fails the local-execution check. Identical local installations fail the centrally supplied-base check if each OS is then maintained independently. A temporary overlay or per-node hostname does not fail the test.[^{ref-5641d83402a9][}ref-19d4bd0f26e5][^ref-4b51919831af]

Manages Complexity¶

A common base can reduce the number of independent OS installations an operator maintains. The node, image service, per-node configuration and external data store still need management. This arrangement does not by itself guarantee faster boot, better performance or high availability.[^{ref-04a7ba39ba4a][}ref-5641d83402a9][^ref-4b51919831af]

Abstract Reasoning¶

Map the common base, executing node, delivery path and durable state separately. If the shared base cannot be supplied when a node acquires its executing environment, that node cannot operate in this arrangement.[^{ref-04a7ba39ba4a][}ref-5641d83402a9] Installing an independent local OS would change the arrangement's identity. After an image resides in memory, continuing network service is not a universal requirement; Warewulf's in-memory provisioning illustrates that boundary.[^ref-03889934ec0b] This directed reliance on the central base is an internal Dependency relation.

Knowledge Transfer¶

Compare unlike networked systems by their roles instead of assuming they use one boot protocol. ATIX's cluster servers and LTSP's desktops satisfy the same central-base, local-execution and external-state roles through different implementations.[^{ref-04a7ba39ba4a][}ref-5641d83402a9][^ref-19d4bd0f26e5] The broader relation of a shared base plus external state remains a separate possible Prime question; this entry is specifically about computer provisioning.

Example¶

ATIX's “Diskless Shared Root Cluster” diagram shows cluster nodes without local disks accessing a shared root and centralized system/data partitions. LTSP separately starts from a server template, serves a client root over the network, runs on each desktop's CPU and RAM, and keeps user home directories on the server. The first is a compute cluster; the second is a desktop fleet. Neither case requires a universal two-node NFS server or identical configuration on every node.[^{ref-04a7ba39ba4a][}ref-5641d83402a9][^ref-19d4bd0f26e5]

Relationships to Other Abstractions¶

Current abstraction Shared-image stateless nodes Domain-specific

Parents (1) — more general patterns this builds on

Shared-image stateless nodes is part of Dependency Prime

A node's directed reliance on the centrally supplied system base is an identity-bearing part of this architecture.

Hierarchy path (1) — routes to 1 parentless root

Shared-image stateless nodes → Dependency

Neighborhood in Abstraction Space¶

Shared-image stateless nodes sits in a sparse region of the domain-specific corpus (100^th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Unclustered & Miscellaneous (2721 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-17

Not to Be Confused With¶

A server-executed terminal is not a locally executing node. A common software version installed on separate local disks is not necessarily a centrally supplied root. Node-specific configuration is allowed, as Warewulf's overlays illustrate.[^ref-4b51919831af] Standardization is related to the common base, but its full process of independent parties converging on a norm is not required here. Dependency names the node's directed reliance on the central base as part of this architecture, not as its whole-system genus.

References¶

[^ref-04a7ba39ba4a]: Thomas Merz, “Samba as Active/Active HA-Service,” ATIX presentation, 26 April 2006, Slide 19/PDF p.19, “Diskless Shared Root Cluster.” Full original inspected at https://sambaxp.org/archive-data-samba/sxp00-unsorted/09_-thomas_merz-atix-_samba_as_ha_service.pdf . [^ref-5641d83402a9]: LTSP Developers, “Linux Terminal Server Project,” official About and system overview, https://ltsp.org/ , especially the template image, network root, temporary overlay and server-hosted home description. [^ref-19d4bd0f26e5]: LTSP Developers, “Preparation,” official deployment guide, https://ltsp.org/docs/preparation/ , especially the statement that clients run the distribution using their own CPU and RAM while using network disk. [^ref-03889934ec0b]: Warewulf Project, “Stateless Provisioning,” official Warewulf v4.5 User Guide, https://warewulf.org/docs/v4.5.x/contents/stateless.html , especially identical stateless OS images and in-memory provisioning. [^ref-4b51919831af]: Warewulf Project, “Warewulf Overlays,” official Warewulf v4.5 User Guide, https://warewulf.org/docs/v4.5.x/contents/overlays.html , especially node-specific system and runtime overlays. [^ref-33f34edd4562]: Red Hat, “Installing Red Hat Enterprise Linux for Real Time Using Diskless Boot,” RHEL for Real Time 7 Installation Guide, §2.2, https://docs.redhat.com/en/documentation/red_hat_enterprise_linux_for_real_time/7/html/installation_guide/installing_real_time_using_diskless_boot .