Skip to main content

Crate hatchery_server

Crate hatchery_server 

Source
Expand description

Host for hatchery subservices. See deploy/README.md.

Re-exports§

pub use config::ServerConfig;
pub use error::ServerError;
pub use subservice::State;
pub use subservice::Status;
pub use subservice::Subservice;
pub use supervisor::Supervisor;

Modules§

config
Server configuration: an optional TOML file (HATCHERY_SERVER_CONFIG) with environment variables taking precedence. Addresses, binary paths and key variable names are never compiled in beyond loopback defaults; secrets are never stored here, only the names of the variables that hold them.
control
Loopback control endpoint (minimal HTTP/1.1, no framework).
drain_consumer
Core drain consumer (A2 / A3): core dials C2, drains one node stream, and answers on the same stream. C2 never dials core and never sees plaintext.
error
harness
Harness + observation host: supervises the hatchery-harness binary (the observation engine and store run inside it). Arguments come from the operator’s configuration; tokens stay in the environment the child inherits (GATE4AGENT_C2_TOKEN, operator token), never in arguments.
hub
P6: the hub behind the server control API: node calls forwarded by C2 and operator (HQ) calls for mail and tasks. All state lives under the data dir; admission is always read from the P2 ledger, never from the request.
m4a
m4a subservice: the node-side messenger key vault (m4a-agent 0.4).
memory
memory4agent subservice (crates.io memory4agent 0.3, binary memory4agent-server). On demand only: the server never starts it by itself. It listens on loopback in 18200-18299, has no authentication, and is never published to WireGuard or outside. The child runs with a scrubbed environment so it never sees vault keys or tokens.
mesh_runtime
Production wiring for NodeOperatorMesh (A2).
messenger
P6: the hatchery messenger. It is the mail4agent mailbox engine (participants, addressing, rooms, delivery, acknowledgement; SQLite store) driven by the P2 provision ledger: a node is a participant exactly while the ledger says it is active and holds the mail grant, and room membership follows the ledger’s rooms. The engine’s rule is kept: a sender is never a field a caller fills in, it is the authenticated node the call arrives for.
node_controller
Core-side node controller (A2): g4a parsing lives here, not on C2.
node_sink
Production node-call sink on core (A2): applies node calls to the Hub.
operator_control
Core operator control (A2): same client wire as the former C2 control socket, but requests go through crate::node_controller::OperatorLink over the drain. C2 never sees this socket and never parses g4a.
provision
P2: provisioning of enrolled nodes on the server side.
subservice
Subservice contract and a supervised-process implementation.
supervisor
Lifecycle: start the autostart subservices, answer health, stop everything.
tasks
P6: minimal task manager. Tasks live in SQLite under the server data dir. An operator creates and assigns them; a node sees (and progresses) only the tasks assigned to it, and a task can be assigned only to a node whose ledger entry holds the tasks grant (trusted by default). The hub enforces that; this module is storage and state rules.

Functions§

build_subservices
Build the subservices enabled by features and configuration.