controlcenter

Central management point for a fleet of Yuneta nodes. Nodes dial in to the control center (the agents are the clients); operators then reach any connected node through the control center. C_CONTROLCENTER is a server — it never dials out.

How a node connects to a control center¶

A node connects only when it has an owner. The primary yuneta_agent declares an outbound client service named controlcenter (gclass C_IEVENT_CLI, chain C_IEVENT_CLI → C_IOGATE → C_CHANNEL → C_PROT_TCP4H → C_TCP, TLS). That service is autostart:false and is started only when node_owner ≠ "none"; an empty owner is forced to "none", so by default a node does not dial out.

To enrol a node, set its node_owner (and, if not using the default control center, its __output_url__).

How the remote URL is built¶

The agent assembles the control-center URL from config variables:

tcps://(^^__sys_machine__^^).(^^__node_owner__^^).(^^__output_url__^^)

i.e. tcps://<machine>.<node_owner>.<output_url> where:

→ tcps://x86_64.artgins.yunetacontrol.com:1994 (TLS, default port 1994).

The secondary yuneta_agent22 dials its own endpoint, default yunetacontrol.ovh:1995 (port 1995), and additionally exposes remote PTY consoles that the control center drives with write-tty.

Reaching nodes through the control center (ycommand)¶

The control center exposes two gates (defined in its realm config, not in the binary): __input_side__ where agents connect, and __top_side__ where operators (web / ycommand) connect. In production it listens on port 1997.

1 — point ycommand at the control center (role and service are both controlcenter):

ycommand --url=wss://<cc-host>:1997 --yuno-role=controlcenter --yuno-service=controlcenter -c 'list-agents'

or, through an agent that already holds the control-center connection, with the passthrough form shipped in the controlcenter README:

ycommand -c 'command-yuno id=<cc> service=controlcenter command=list-agents'

2 — list the connected nodes with list-agents (UUID, hostname, status). Connected nodes are discovered live: the control center scans __input_side__ for C_IEVENT_SRV children in state ST_SESSION and reads each one’s identity_card — a node is addressed by its UUID (identity_card.id) or its hostname.

3 — forward a command to one node with command-agent (a SDF_WILD_CMD):

ycommand -c 'command-yuno id=<cc> service=controlcenter command=command-agent agent_id=<host-or-uuid> cmd2agent="list-yunos"'

Parameters: agent_id (UUID or hostname), agent_service, and cmd2agent (the command to run on the node — this is the exact key the handler reads). The control center routes the command to the one matching connected agent (gobj_command, first match only). The node’s agent then executes it, and can itself target a specific yuno via its own command-yuno (command=… service=…).

Inventory (TreeDB)¶

Beyond the live-connection scan, the control center keeps a declared inventory in treedb_controlcenter with topics: systems, users, nodes, services, lists, viewer_engines. The nodes topic (pkey id) records description, provider, provider_url, properties, ip and links to services / systems. This inventory is separate from the set of currently connected agents.

Configuration¶

The yuno composes authz (C_AUTHZ) + controlcenter (C_CONTROLCENTER, default service); Authz.max_sessions_per_user defaults to 4. Key attributes:

The listen URLs/ports live in the realm config (__top_side__ / __input_side__), not in the binary.

Commands¶

Ports¶

Debugging¶