mikronova/draupnir

draupnir's own BMC — a Rust Redfish server fronting KVM

Feature redfish-server (OFF by default) · src/redfish_server.rs · shared vocabulary in src/redfish/wire.rs · anchored by tests/redfish_server_conformance.rs against tests/fixtures/dmtf/ · live loop in tests/redfish_kvm_loop_proof.rs Declared 2026-08-15.

What it is

A pure-Rust Redfish service that answers the endpoints draupnir's Redfish client drives, and translates them onto a QEMU/KVM guest through draupnir's own Boot/Lifecycle seam. It turns any Linux box with /dev/kvm into a Redfish-controllable machine.

src/redfish.rs was already the client end — it drives a real iDRAC / iLO / OpenBMC. This is the other end of the same protocol, in the same crate, sharing the same wire vocabulary.

Why it exists

Two reasons, and the second is the durable one.

1. A Redfish burn needs a BMC, and a developer box has none. The iso-metal matrix row can never go green here, because a human with a USB stick is not a matrix row. This gives the wire half of that proof a service to run against — recorded as iso-redfish-sim, on its own row.
2. It is a real capability. A lab, a CI fleet or a nested-virt pool becomes addressable with the same out-of-band vocabulary as the metal it stands in for. That is squarely draupnir's charter: kvm and container, low level.

It is Rust rather than OpenStack's Python sushy-emulator because putting the metal-path proof on a Python service would put it outside the pure-Rust charter — and because draupnir already owned both ends, so the server is the hinge between them rather than a new dependency.

THE TRAP, and what is done about it

draupnir's client talking to draupnir's server is a MIRROR. Both ends can be wrong in the same way and every test still passes. That is the identity-value failure: a test sitting on 1.0 cannot tell a working transform from a dead one. A loopback green proves self-consistency, not Redfish.

Two answers, neither optional:

• The shapes are anchored OUTSIDE this repo. tests/redfish_server_conformance.rs reads DMTF's published JSON Schema, the Base.1.19.0 message registry and the public-rackmount1 mockup — vendored under tests/fixtures/dmtf/, provenance and digests in PROVENANCE.md, re-hashed at run time so a fixture edited to make a test pass is itself a red. See "What the anchor checks" below.
• The form is iso-redfish-sim, never iso-metal. An emulator proves the wire, never the hardware. iso-metal stays Absent, visibly, on its own row.

The translation — no new machinery

BootOrder::from_redfish_target is the inverse of the client's BootOrder::redfish_target, and it lives next to it in src/lib.rs — two mappings in two modules would be two mappings, and the one that mattered would be the one nobody tested.

Each order then selects the constructor that already expresses it:

• Medium → BootSpec::iso_boot — the inserted media is the whole payload.
• Disk → BootSpec::kvm_boot_installed_disk, which by construction carries no medium at all (validate() refuses Disk + a medium). That is what makes an Hdd override applied rather than merely acknowledged.
• Auto → the node's own order: the medium if a tray is loaded, else the local disk.

A target this node cannot honour (Pxe, BiosSetup) is refused by name, never coerced into one it can.

REUSE, not a twin — src/redfish/wire.rs

The paths, property names, action names, enum tokens, the Basic-auth encoder/decoder and the action-body builders/readers are written down once, in redfish::wire, and both ends read them:

• the client composes host + wire::system_path(id);
• the server's routing table is built from the same wire::* calls;
• the client's insert_media_body and the server's read_insert_media_body sit in the same file, with a round-trip test between them, so a field renamed on one side fails to compile-or-test rather than silently disagreeing at runtime.

The conformance suite then checks those paths against the @odata.id strings in DMTF's own mockup — so "the two ends agree" and "the two ends are right" are separate, separately proven claims.

TLS — why the server needed a certificate at all

draupnir's client pins the BMC certificate (RedfishBoot::pin_cert_pem; verification stays ON with that cert as the sole trusted root). A pinned client needs a real cert to pin, so the server mints a genuine self-signed X.509 with SANs per run and holds the key in memory only — nothing is written to disk, so there is no .key/.pem/.der that could be committed. cert_pem() hands out the public half.

The crate is rcgen 0.13 with default-features = false, features = ["pem","ring"] — the same crate, features and call shape as Skidbladnir's src/pki.rs, which is the constellation's TLS-identity story and is already proven to load into a real rustls::ServerConfig. korp-installer's SigningIdentity (RSA + x509-cert) was read and deliberately not reused: it mints an Authenticode code-signing identity, not a TLS server identity with SANs. Skidbladnir's code cannot simply be called from here either — Skidbladnir path-deps this crate (Skidbladnir/Cargo.toml:87), so a dep back onto its pki module would be a cycle. Same crate, same pattern: one cert story, not two.

Threading

The accept loop runs on a gatling::background::Job — the constellation's sanctioned home for a raw thread (ROOT-LAW #0), the same seam src/exe.rs:246 already uses. No bare std::thread::spawn, no rayon, no async runtime.

The endpoints

Everything below the service root needs HTTP Basic auth (401 + WWW-Authenticate otherwise). A wrong method answers 405 with Allow.

What the anchor checks

1. No invented property — every key emitted must be one DMTF's schema declares, or a well-formed Redfish annotation (the patternProperties grammar is matched by hand, so ResetType@Redfish.AllowedValues still dies).
2. Nothing required missing — every name in the schema's required array.
3. The @odata.type is real — #Ns.vX_Y_Z.Type must be a definition the DMTF schema file for that exact version declares.
4. Advertised values are DMTF's — ResetType@Redfish.AllowableValues ⊆ Resource.json#/definitions/ResetType; BootSourceOverrideTarget… ⊆ ComputerSystem.json#/definitions/BootSource.
5. The mockup's URIs are our paths — DMTF's own @odata.id strings and the Reset action's target, compared to wire::*.
6. The errors are the registry's — every message compared field-for-field with the Base.1.19.0 entry of the same Id, and each live error payload against redfish-error.v1_0_2 + Message.v1_1_2.

The RED controls

Named limitations — read before trusting interop

• No real BMC was ever contacted. Conformance to DMTF's published shapes makes interop with an iDRAC/iLO plausible. It is not measured. iso-metal stays Absent.
• This BMC does not fetch remote media. A real BMC pulls the image over http(s)/NFS/CIFS; this one resolves a file:// URI or an absolute path and refuses a remote scheme by name. The client side is unchanged — it still sends whatever URI real metal would be given — but the server side is an emulator difference, and it is loud rather than silent.
• Session authentication is not implemented. HTTP Basic only. The required ServiceRoot.Links.Sessions pointer resolves to an empty, read-only SessionCollection, and POST there answers 405 with Allow: GET rather than handing out a plausible-looking token.
• The $metadata / odata service documents are not served. Nothing draupnir's client asks for; a generic Redfish explorer would notice.
• HTTP/1.1 with Content-Length bodies only — no chunked request bodies. Redfish clients do not chunk action bodies, and a service that guessed would be guessing.
• One request per connection, Connection: close, no keep-alive. Keep-alive was tried first and produced a measured flake: 3 ECONNRESET failures in 28 full conformance runs (2026-08-15), the classic idle-close race against the client's connection pool on a deliberately serial accept loop. 0 in 40 after the change. A TLS handshake per request is the price; a proof that lies one run in ten is not.
• The accept loop is serial. One request at a time. A BMC control plane makes single-digit numbers of calls per boot; concurrency here would buy nothing and cost a lock story.