users: `--class human|server` is named for who lives there, but what it decides is the root SSH door #77

New issue

Closed

opened 2026-07-19 23:54:27 +00:00 by dan-claude-bot · 0 comments

dan-claude-bot commented

2026-07-19 23:54:27 +00:00

(Migrated from github.com)

Split out of #76, which suffixes fleet machine roles with -server and immediately trips over this: dev-server is class=human.

The mismatch

class reads as a statement about occupancy — who lives on this box. What it actually decides is one thing: does root SSH stay open as the control plane automation door, or does rig users close-root shut it once named operators exist.

Those are not the same question, and the roles show it. dev is an unattended VM-host appliance — nobody lives there, operators visit it to mint boxes and leave. By occupancy it is a server. It is class=human anyway, and correctly so, because operators enter it as themselves and its root door must close. The trait is right; its name describes the wrong axis.

That misnaming is cheap until a second thing wants the word "server". After #76, -server marks the machine family, so dev-server carries a suffix saying server and a trait saying human, and a reader cannot tell that one is about family and the other about doors.

What to do

Rename the trait to what it controls. Strawman — the naming is the substance of this issue, not settled:

--class human|server   ->   --root-door closed|open

human -> closed (named operators enter as themselves; close-root shuts the door)
server -> open (nobody lives here; the control plane automates in)

Then dev-server --root-door closed says exactly what is true, and -server means one thing everywhere.

Why this is not a rename like #76 was

Role names are informational — nothing reads them back. class= is not. It is written into /etc/rig/role and read back by:

rig users apply — root-door policy after the users phase
rig users close-root — refuses outright unless the marker says class=human

So markers on machines already in the field say class=human, and a bootstrap that stops writing it turns close-root into a no-op refusal on exactly the boxes whose root doors most need shutting. Any change here needs a compat read of the old field, and a plan for markers that never get rewritten.

That is why it is not folded into #76: the taxonomy rename is a CLI surface, this one reaches live state that guards root SSH.

Acceptance

the trait is named for the door policy, not for occupancy
old markers carrying class= still resolve, and close-root still refuses correctly on them
dev-server no longer carries a suffix and a trait that appear to contradict

Split out of #76, which suffixes fleet machine roles with `-server` and immediately trips over this: `dev-server` is `class=human`. ## The mismatch `class` reads as a statement about occupancy — who lives on this box. What it actually decides is one thing: **does root SSH stay open as the control plane automation door, or does `rig users close-root` shut it once named operators exist.** Those are not the same question, and the roles show it. `dev` is an unattended VM-host appliance — nobody lives there, operators visit it to mint boxes and leave. By occupancy it is a server. It is `class=human` anyway, and correctly so, because operators enter it *as themselves* and its root door must close. The trait is right; its name describes the wrong axis. That misnaming is cheap until a second thing wants the word "server". After #76, `-server` marks the machine family, so `dev-server` carries a suffix saying server and a trait saying human, and a reader cannot tell that one is about family and the other about doors. ## What to do Rename the trait to what it controls. Strawman — the naming is the substance of this issue, not settled: --class human|server -> --root-door closed|open `human` -> `closed` (named operators enter as themselves; `close-root` shuts the door) `server` -> `open` (nobody lives here; the control plane automates in) Then `dev-server --root-door closed` says exactly what is true, and `-server` means one thing everywhere. ## Why this is not a rename like #76 was Role names are informational — nothing reads them back. `class=` is not. It is written into `/etc/rig/role` and read back by: - `rig users apply` — root-door policy after the users phase - `rig users close-root` — refuses outright unless the marker says `class=human` So markers on machines already in the field say `class=human`, and a bootstrap that stops writing it turns `close-root` into a no-op refusal on exactly the boxes whose root doors most need shutting. Any change here needs a compat read of the old field, and a plan for markers that never get rewritten. That is why it is not folded into #76: the taxonomy rename is a CLI surface, this one reaches live state that guards root SSH. ## Acceptance - [ ] the trait is named for the door policy, not for occupancy - [ ] old markers carrying `class=` still resolve, and `close-root` still refuses correctly on them - [ ] `dev-server` no longer carries a suffix and a trait that appear to contradict

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: heavy-duty/rig#77

No description provided.

users: --class human|server is named for who lives there, but what it decides is the root SSH door #77

The mismatch

What to do

Why this is not a rename like #76 was

Acceptance

users: `--class human|server` is named for who lives there, but what it decides is the root SSH door #77