TELEICU/Path B: NixOS - Revision history

Admin: Fix Mermaid diagrams: remove

 wrapping so parser functions execute (via update-page on MediaWiki MCP Server)

2026-07-06T03:18:26Z

Fix Mermaid diagrams: remove <pre> wrapping so parser functions execute (via update-page on MediaWiki MCP Server)

← Older revision		Revision as of 08:48, 6 July 2026
Line 12:		Line 12:
	Every hospital PC runs NixOS with identical, pinned system configuration. A flake repository defines the full OS state — packages, services, users, firewall, K3s agent — and nodes converge to the declared state via <code>comin</code> (pull-based, primary) or <code>deploy-rs</code> (push-based, backup).		Every hospital PC runs NixOS with identical, pinned system configuration. A flake repository defines the full OS state — packages, services, users, firewall, K3s agent — and nodes converge to the declared state via <code>comin</code> (pull-based, primary) or <code>deploy-rs</code> (push-based, backup).

	<pre>
	{{#mermaid:flowchart TB		{{#mermaid:flowchart TB
	subgraph Repo["Flake Repository"]		subgraph Repo["Flake Repository"]
Line 36:		Line 35:
	DEPLOY --> N2		DEPLOY --> N2
	}}		}}
	</pre>

	== Provisioning (zero-touch) ==		== Provisioning (zero-touch) ==
Line 97:		Line 95:
	== Repository structure ==		== Repository structure ==

	<pre>
	{{#mermaid:flowchart LR		{{#mermaid:flowchart LR
	subgraph Flake["teleicu-nixos/"]		subgraph Flake["teleicu-nixos/"]
Line 109:		Line 106:
	end		end
	}}		}}
	</pre>

	== Flake structure ==		== Flake structure ==

Admin: Automated edit (via update-page on MediaWiki MCP Server)

2026-07-06T03:09:57Z

Automated edit (via update-page on MediaWiki MCP Server)

← Older revision		Revision as of 08:39, 6 July 2026
Line 119:		Line 119:
	- <code>packages</code> for the bootstrap ISO		- <code>packages</code> for the bootstrap ISO
	- <code>devShells</code> for development tooling		- <code>devShells</code> for development tooling

			{{Navbox TELEICU}}

	{{Related}}		{{Related}}

Admin: Replace ASCII art with Mermaid diagrams (via update-page on MediaWiki MCP Server)

2026-07-06T02:55:18Z

Replace ASCII art with Mermaid diagrams (via update-page on MediaWiki MCP Server)

@@ Line 12: / Line 12: @@
 Every hospital PC runs NixOS with identical, pinned system configuration. A flake repository defines the full OS state — packages, services, users, firewall, K3s agent — and nodes converge to the declared state via <code>comin</code> (pull-based, primary) or <code>deploy-rs</code> (push-based, backup).
-           ├── comin (pull) ──── primary path
+        COMIN["comin (pull)<br/>each node polls<br/>for new generation"]
-                 └─ triggered from CI for urgent deploys
+        DEPLOY["deploy-rs (push)<br/>triggered from CI<br/>for urgent deploys"]
 == Provisioning (zero-touch) ==
@@ Line 85: / Line 97: @@
 == Repository structure ==
-├── flake.lock
+        FLAKE_NIX["flake.nix<br/>flake.lock"]
 == Flake structure ==

Admin: Create TELEICU Path B: NixOS guide (via create-page on MediaWiki MCP Server)

2026-07-06T02:53:24Z

Create TELEICU Path B: NixOS guide (via create-page on MediaWiki MCP Server)

New page

{{Doc header
|type=guide
|domain=teleicu
|title=Path B: NixOS
|order=8
}}

Full architecture and workflow for the NixOS migration path.

== Architecture ==

Every hospital PC runs NixOS with identical, pinned system configuration. A flake repository defines the full OS state — packages, services, users, firewall, K3s agent — and nodes converge to the declared state via <code>comin</code> (pull-based, primary) or <code>deploy-rs</code> (push-based, backup).

syntaxhighlight lang="text"
┌──────────────────────┐
│ Flake repository │
│ (Nix flake, │
│ all node configs) │
└──────────┬───────────┘
│
├── comin (pull) ──── primary path
│ └─ each node polls for new generation
│
└── deploy-rs (push) ── backup path
└─ triggered from CI for urgent deploys
syntaxhighlight

== Provisioning (zero-touch) ==

New sites are provisioned using a custom ISO generated with <code>nixos-generator</code>:

# The ISO boots with a pre-configured Cloudflare Tunnel or Tailscale connection already active
# A bootstrap script on the ISO initiates <code>nixos-anywhere</code> over the tunnel
# <code>nixos-anywhere</code> partitions the disk (ZFS via disko) and installs NixOS
# The node reboots into its NixOS generation and registers as a K3s agent
# <code>comin</code> starts polling for configuration updates

== What NixOS manages ==

* Every system package, kernel parameter, and service
* Tailscale configuration and bringup
* K3s agent installation, config, and auto-join
* Cloudflare tunnel service (cloudflared)
* ZFS dataset layout and mount points
* OpenEBS localPV provisioner for K3s
* Monitoring agent, log shipper, downtime classifier
* Firewall rules (strict — only Tailscale + K3s + tunnel outbound)
* sops-nix secret decryption at build time

== What K3s manages ==

* Middleware container deployments
* Service discovery, ingress, workload scaling
* Identity as a Kubernetes node (identical to Path A at this layer)

== Storage ==

ZFS + OpenEBS localPV:

* Root pool: mirrored (if multiple disks) or single-disk with regular snapshots
* LocalPV datasets for stateful middleware workloads
* ZFS snapshots via sanoid/syncoid for fast backup
* Off-site backup via restic or zfs send to S3

== Rollback ==

* Instant: <code>nixos-rebuild switch --rollback</code> reverts to the previous generation
* At boot: hold Shift/space during systemd-boot to select a previous generation
* Every NixOS generation is an atomic, bootable unit — rollback is always available even if the OS is partially broken

== Update mechanism ==

<code>comin</code> is the primary path (pull-based, suited for unreliable connectivity):

- Each node polls the flake repository on a configurable interval
- When a new generation is available, it builds and activates it atomically
- If the build fails, the node stays on its current generation — no partial state

<code>deploy-rs</code> is the backup path:

- Push-based, triggered from CI for urgent/canary deploys
- Requires the node to be reachable at deploy time
- Used for staging and canary nodes where immediate rollout is needed

== Repository structure ==

syntaxhighlight lang="text"
teleicu-nixos/
├── flake.nix # inputs + outputs
├── flake.lock
├── hosts/
│ ├── cp-1/ # control plane VM 1
│ │ ├── configuration.nix
│ │ └── hardware-configuration.nix
│ ├── cp-2/
│ ├── cp-3/
│ ├── spoke-template/ # template for spoke nodes
│ │ ├── configuration.nix
│ │ └── hardware-configuration.nix
│ └── hub-template/ # template for hub nodes
├── modules/
│ ├── tailscale.nix
│ ├── k3s-agent.nix
│ ├── cloudflared.nix
│ ├── zfs.nix
│ ├── openebs.nix
│ ├── monitoring.nix
│ └── downtime-classifier.nix
├── profiles/
│ ├── base.nix # shared across all nodes
│ ├── spoke.nix # spoke-specific additions
│ └── hub.nix # hub-specific additions
├── secrets/ # encrypted via sops-nix
│ └── …
├── iso/
│ └── bootstrap.nix # nixos-generator config for install ISO
└── comin/
└── configuration.nix # comin poll config
syntaxhighlight

== Flake structure ==

<code>flake.nix</code> exposes:

- <code>nixosConfigurations</code> for each host (CP VMs + spoke/hub templates)
- <code>cominConfigurations</code> for comin-based auto-updates
- <code>packages</code> for the bootstrap ISO
- <code>devShells</code> for development tooling

{{Related}}