OpenPXE/docs/NEXT_PHASE.md

Phase 6 — recommendations

The v0.2.0 cut leaves OpenPXE in a state where the entire protocol stack and operator UI are exercised by 66 automated tests, the container is multi-arch buildable, and the image ships at ~97 MB. What's left before this looks and feels like a 1.0 product is mostly real-hardware validation plus a small batch of features that can only sensibly be designed once we've watched real machines image.

This doc is a punch list, ordered by what I'd do first if I had a week.

Tier 1 — must-do before we call anything "stable"

1. Real-hardware validation matrix

We have CI tests for every protocol leg, but no end-to-end PXE on real firmware. Build a small matrix:

client	firmware	OS family	pass criteria
any 10-y-old mini-PC	Legacy BIOS	Ubuntu Server 24.04	gets to GRUB / installer
Intel NUC / similar	UEFI x64	Windows 11	reaches "where do you want to install"
Raspberry Pi 4	UEFI ARM64	Raspberry Pi OS	gets to login prompt
Dell / HP business laptop	UEFI x64	Fedora	one of: kernel boot or wimboot

Add a docs/HARDWARE_VALIDATION.md checklist that records what worked, firmware versions, and any quirks. Anything weird gets a regression test in the relevant crate.

2. Boot menu hotkey + UI accessibility audit

The iPXE menu has number-key + letter hotkeys but no documentation on what they map to. Generate a printable cheat-sheet from crates/http-api/src/ipxe_script.rs so operators don't have to read the source. Run a screen-reader pass over the web UI — most of it should be fine since we're mostly tables + form labels, but the Terminal pane and the SSE log output need explicit aria-live regions.

3. Boot.wim re-patch detection

Bootimus v0.1.62's "fingerprint of patched inputs + Save & Re-patch" pattern is a small but high-value feature: when an operator changes the SMB host override or upgrades wimboot, the existing patched boot.wim is silently stale. We should:

• Hash the inputs (smb_host, smb_share, startnet.cmd content, wimboot binary digest) into the IsoMeta;
• Surface a "needs re-patch" warning on the Storage tab when the hash drifts;
• Add a "Re-patch SMB" button that re-runs the WimPatcher.

Tier 2 — features that round out pre-beta

4. Auto-install file library

iVentoy and Bootimus both support attaching autounattend.xml / preseed.cfg / kickstart.cfg to an image. The mechanics are straightforward: store files under <work_dir>/autoinstall/<distro>/, expose CRUD via /api/autoinstall-files, and modify the WimPatcher

• Linux kernel cmdline to fetch + apply the right file. Placeholders worth supporting (Bootimus pattern): {{MAC}}, {{HOSTNAME}}, {{IP}}, {{SERVER_ADDR}}, {{IMAGE_FILENAME}}, substituted serve-side per request.

5. Wake-on-LAN trigger

A natural pair with per-MAC host bindings: bind a MAC to an image, then click "Wake & Image" to send the magic packet and let OpenPXE do the rest. Implementation is small (udp/9 broadcast, magic packet construction) but it makes the bound-host workflow feel instant.

6. Distro profile manifest

Today, distro detection lives as Rust match arms in introspect.rs and the kernel cmdline templates live in store.rs. Bootimus extracts this into a JSON manifest that ships embedded in the binary AND is overridable by the operator at runtime — so a new distro can be added without rebuilding the container. Worth porting; it'd let community contributions land as PRs to a single JSON file.

7. Syslog receiver

smee ships one. The use case: WinPE / Linux installers can be configured to syslog over the network to the PXE server; if we have an endpoint and a place in the UI to view per-client diagnostics, post-mortem on a failed install gets dramatically easier.

8. UEFI HTTP Boot validation

Option 60 = HTTPClient is wired up in decide() already, but we've never tested it on real firmware. Some Dell + Lenovo UEFIs prefer it over PXE-via-TFTP. A quick check on a real machine (disable TFTP boot in firmware, force HTTP boot) and a regression test would be nice.

Tier 3 — bigger lifts, only if there's demand

9. Pure-Rust SMB server

smbd from Samba is ~80 MB of the runtime image. There are pure-Rust SMB2 server crates (smbd-server, smb-rs) of varying maturity. Replacing the dep would slim the image by ~40% and remove the CAP_SYS_ADMIN requirement for SMB. Worth a spike, not necessarily landable in Phase 6.

10. IPv6 / DHCPv6

PXE-over-IPv6 is real (RFC 5970). Some sites are v6-only. Worth implementing once we know we have one. Until then, IPv4-only is the right default — flipping the bit on v6 without v6 testing is asking for silent breakage.

11. Multi-replica deployment

The current design assumes one OpenPXE per broadcast domain. Two proxies on the same L2 will race; the deployment queue is in-memory, etc. For HA we'd need to:

• Externalize the deployment queue (Redis, etcd) or lean into "the menu is cheap to refetch if a replica dies";
• Ensure DHCP proxy replies are deterministic so a client always gets the same answer regardless of which replica replied;
• Document the L2 collision domain story.

This is a large lift and should only happen if someone's actually asking for it.

12. Pi 4 / SBC quirks

Raspberry Pi netboot uses a specific DHCP option-43 vendor field + TFTP path layout that OpenPXE doesn't currently special-case. There's a spec; the work is small once we have a Pi to test on.

What I'd skip

• A custom DHCP server (not proxy). The proxy mode is the right abstraction; full DHCP would need raw sockets + a lot of corner-case handling for problems no operator wants us to solve.
• A pluggable backend abstraction à la Tinkerbell. Tinkerbell does it because they integrate with k8s CRDs. OpenPXE's "the file system IS the database" model is simpler and good enough for the target audience. Don't add a Backend trait until something asks for it.
• Multiple language UIs. Bootimus added these in v0.1.62 and the translations are LLM-generated. Skip until we have real users asking for non-English.

Quick wins (could land in a single afternoon)

• Add a Grafana dashboard JSON to deploy/grafana/ driven off the new /metrics endpoint.
• A openpxe bench subcommand that runs a 10-second internal load test (synthetic queue joins) so an operator can sanity-check tuning.
• Ship a basic docker-compose.yml for the Unraid path that demos the new themes / progress widget.
• Generate a printable single-page operator runbook from the README
  • architecture.md (e.g. cargo xtask runbook).