Hand a dev VM an inference key from the hypervisor in one line #92

New issue

Open

opened 2026-10-09 23:09:31 +01:00 by vnprc-agent · 0 comments

vnprc-agent commented

2026-10-09 23:09:31 +01:00

Primary goals:

One host-side line — a command on the hypervisor that reads a key file and runs pi-key <provider> on a named VM over the existing admin SSH, so the key never appears on a command line or in history; today this is the unwrapped ssh <vm> pi-key nullsink < ~/<key file>, which works because pi-key reads the key from stdin when stdin is not a terminal.
Named in the start-here page — the attendee path says where the key file goes and the one line to run, and the deck's install section says the same.
The managed path stays the durable one — pi-provider add on the host, commit, re-lock, rebuild-vm, which leaves the VM holding no key file, remains the demo of "only keys are precious"; this flow is the fast first contact, as pi-key already is inside the VM.

Current state and specifics

pi-key (allod/archetypes modules/pi-key.sh) takes the provider as an argument, skips the model prompt when stdin is not a terminal, reads the key from stdin, writes it at mode 0600 and records the provider; proven from a host with a fake key piped through ssh. Nothing wraps that line, nothing documents it, and the workshop plan decided the key for workshop VMs goes in this way, saved as a file in the laptop's home (plan of record, 2026-10-09).

Scope

In: the host-side wrapper in allod/nexus (or a documented one-liner if a wrapper adds nothing), its shell test, and the start-here text. Out: pi-key itself; the managed provider path; any key purchase or funding step.

Part of allod/strategy#65

A deployment's operator hands a dev VM an inference key from the hypervisor in one step, without typing it into the VM, so a room full of fresh installs can each get a prefunded key from a file the operator placed. Primary goals: - **One host-side line** — a command on the hypervisor that reads a key file and runs `pi-key <provider>` on a named VM over the existing admin SSH, so the key never appears on a command line or in history; today this is the unwrapped `ssh <vm> pi-key nullsink < ~/<key file>`, which works because `pi-key` reads the key from stdin when stdin is not a terminal. - **Named in the start-here page** — the attendee path says where the key file goes and the one line to run, and the deck's install section says the same. - **The managed path stays the durable one** — `pi-provider add` on the host, commit, re-lock, `rebuild-vm`, which leaves the VM holding no key file, remains the demo of "only keys are precious"; this flow is the fast first contact, as `pi-key` already is inside the VM. ### Current state and specifics `pi-key` (`allod/archetypes` `modules/pi-key.sh`) takes the provider as an argument, skips the model prompt when stdin is not a terminal, reads the key from stdin, writes it at mode 0600 and records the provider; proven from a host with a fake key piped through `ssh`. Nothing wraps that line, nothing documents it, and the workshop plan decided the key for workshop VMs goes in this way, saved as a file in the laptop's home (plan of record, 2026-10-09). ### Scope In: the host-side wrapper in `allod/nexus` (or a documented one-liner if a wrapper adds nothing), its shell test, and the start-here text. Out: `pi-key` itself; the managed provider path; any key purchase or funding step. Part of allod/strategy#65

vnprc-agent referenced this issue from allod/strategy

2026-10-09 23:10:21 +01:00

A Forgejo VM on the hypervisor: PRs and issues for a forge-less deployment #65