During an event¶

What to watch, and how to change things once contestants are working. Every command here leaves connected machines connected unless it says otherwise.

Where the logs are¶

Each program writes to its systemd journal:

$ journalctl -u vnet-conductor -f          # on the conductor
$ journalctl -u vnet-switch -f             # on a switch
$ journalctl -u vnet-agent -n 50           # on a machine

Log messages explains the lines.

Who is connected¶

On the conductor:

$ sudo systemctl kill -s USR1 vnet-conductor     # write the dump now
$ sudo vnet-state /var/vnet-dump.bin /etc/vnet/auth.txt
dump written 2026-11-11 09:14:02

switches (2)
  switch1  192.0.2.11:6000  network=::internet  since 2026-11-11 08:01:13
  switch2  192.0.2.12:6001  network=::internet  since 2026-11-11 08:01:14

agents (3)
  c001  10.0.1.1  on switch1  since 2026-11-11 08:40:55
  c002  10.0.1.2  on switch2  since 2026-11-11 08:41:02
  judge  10.0.0.1  on switch1  since 2026-11-11 08:02:30

expected but not connected (0)

The joining list appears only while joins are in progress.

A machine in expected but not connected is off, has no network, or is refused: see Troubleshooting. A since time much later than the others means the machine rejoined: look at its agent log. (After the conductor restarts, every since is the time the machine reconnected to it.)

What each switch is doing¶

$ sudo systemctl kill -s USR1 vnet-switch
$ journalctl -u vnet-switch -n 20

The statistics line, and one line per machine, are explained in Monitor the network.

Change who may talk to whom¶

Edit the access list on the conductor, then reload:

$ sudoedit /etc/vnet/switch.txt
$ sudo systemctl reload vnet-conductor
$ journalctl -u vnet-conductor -n 5
[Conductor] Config reloaded, fingerprint 4be1c09a7f3d; sent to 2 switch(es)
[Conductor] Switch switch1 applied config 4be1c09a7f3d
[Conductor] Switch switch2 applied config 4be1c09a7f3d

The new rules apply to the next packet on every switch. If you generate the files with vnet-roster, edit the roster, run it again into the same directory (keys are kept), and copy switch.txt and auth.txt to the conductor before reloading.

If the log says Config reload failed; the previous config stays in force, the line before it names the line of the file that is wrong.

Add a machine¶

Add its key to /etc/vnet/auth.txt and its address and rules to /etc/vnet/switch.txt (or add it to the roster and generate again), reload the conductor, install its files and start its agent. No other machine is disturbed.

Remove a machine¶

Remove it from the auth file and reload: it can no longer join. A machine already connected stays until its next join; stop its agent, or restart the switch it is on, to remove it at once. Removing it from the access list instead cuts its traffic at once while leaving it connected.

Let one machine out of lockdown¶

On that machine: sudo systemctl stop vnet-agent. The default route and the firewall are put back as they were; the machine is off the overlay. To open only one address, add a line to its bypass file and run sudo systemctl reload vnet-agent (Lock down contestant machines).

Restart a program¶

Any program can be restarted at any time; Failures and recovery says what the machines see. In short: restarting the conductor is invisible to the contest; restarting a switch moves its machines to the other switches; restarting an agent cuts its machine for a few seconds.

Do not¶

Edit a file and forget to reload: nothing changes until the reload, and the next restart then applies a change you no longer remember.
Give two machines the same name or the same env file: they keep pushing each other off (Failures and recovery).
Run two conductors. Agents and switches would split between them.

vNet

Versions