One transport, one login, one way

The task. A managed node on which the Hub writes the configuration, checks it, puts it into effect, reads state and runs commands — today over two transports with two kinds of access, though one would do.

What it is made of:

• /configFile read — fetches what is on the node before overwriting it; the file list comes from /configFile listconfigfiles;
• /configFile commit — writes files without checking or reloading;
• /command — test config, then reload;
• http-api-authorisation — the key all of this travels with.

The parts have different scopes. Node level; the scheme covers everything except installing the engine, which needs a shell. The monitor port must be reachable by the Hub, and the key must be stored where the Hub uses it.

How they interact. The whole scheme is in the order of actions, because writing neither checks nor puts into effect: read, write, check, reload, and on failure restore what was read. The Hub performs exactly this sequence today, only the write goes over SSH — so the scheme is about changing the transport. The trade-off is real: there are fewer access paths, but one key reaches both the configuration and any node command.