fix: the overlay screen when joining two nodes #23

Merged

marcos-mendez merged 4 commits from fix/overlay-screen-joining-nodes into master

2026-10-03 09:30:48 -03:00

marcos-mendez commented

2026-10-03 09:27:10 -03:00

(Migrated from github.com)

Three bugs the maintainer hit on 2026-10-03 while joining keel-web-1 and keel-web-2 over the WireGuard overlay.

keelmenu._overlay showed Overlay network under Instance > Advanced until the spec had an overlay, and after that in the Instance menu itself, so Advanced disappeared.

Choice: the entry's place now depends only on the installation mode, and is fixed for the life of the node:

simple installation (Keel Web/Core): always Instance > Advanced, configured or not;
cloud_simple / cloud_advanced: in the Instance menu itself, as before.

I think this is the least surprising option. The first time you look for the screen is to configure it, so that is where you learn its place, and it never moves after that. Moving it to the top level once configured would mean one of two things: an Advanced that has disappeared, or two places for one screen. In the cloud modes nothing else is behind Advanced, so no empty Advanced is shown. uses_overlay had no other reader and is removed. Tests cover both states (unconfigured and configured, enabled or with an address) in simple and cloud modes, at the rule level and in the loaded Instance menu.

2. A node could add itself as a peer

Add peer now:

refuses this node's own public key (the one at the top of the same screen);
refuses a peer mesh address that equals one of this node's (address or ipv4_address, with or without a prefix);
asks yes/no when the peer is outside this node's prefix (e.g. node fdbc:cc61:347f::1/64, peer fd11:a58a:88ef::2). This still works because the peer is routed as a /128.

After a refusal, or a No, you are back in the form with what you typed. wgscreen.ACTIONS now receive the node's key. keelfirstboot passes it too, and its test fakes now take it, so a caller left on the old signature fails.

keel did not refuse a peer key equal to the node's own. That fix is in Keel-Linux/keel#71: it reads the key from private_key.file the way keel network wireguard key does, so it only runs when secret files are checked. The screen validates with --no-secret-files, so it does its own check first.

3. The confirmation window ran out unnoticed

After apply, while the change still waits (the operator answered No, or keel refused the confirmation), a box now gives the exact deadline in UTC, e.g. reverts at 14:32:05 UTC (90 s from now), and the command keel network confirm. The deadline comes from keel's own marker (keel.network.marker): changed_at plus window on the same clock keel dates the change with. The window timer is armed right when the interface comes up. If keel cannot date the change, the box says "as its window ends" rather than inventing a time.
Back on the screen while a change waits, the first line says so, with the deadline, and Confirm now is the first, highlighted choice. It runs keel network confirm and shows keel's verdict. If the change still waits after that, the deadline box follows.
What the screen can and cannot do: keel decides who may confirm (keel.network.session and confirm), from the process tree:
- accepted: the machine's console, or a process attached from a container's host (pct enter, lxc-attach);
- accepted: an SSH session started after the change and arriving over the new configuration (for the overlay, over the overlay or the uplink);
- refused: an SSH session that was open before the change, an ssh from the machine to itself, or tmux/screen.
The screen does not judge the session itself. Confirm now therefore works from the console, or from confconsole started in a new SSH session. In the confconsole that ran the apply over SSH it is refused, and the box then says how to confirm and by when.
CONFIRM_QUESTION default: dialog's yesno has no --defaultno here, so Enter already answers Yes. The trap was the text, which told an SSH operator to answer No, and No led nowhere. The question now says Yes is safe to try (keel refuses without changing anything) and that the next screen gives the deadline. The default stays Yes.
Not changed, noted: confirming over the overlay with ssh -J failed because the nodes' sshd hardening sets AllowTcpForwarding no. A plain ssh to the node's overlay address from a shell on the other node works.

Every new text is held by tests to 72 columns and to the rows of an 80x24 console, including the first screen with a waiting change, four choices and three peers. Coverage stays at 100 %. The changelog has a new entry, 2.2.3+keel15, on top.

Three bugs the maintainer hit on 2026-10-03 while joining keel-web-1 and keel-web-2 over the WireGuard overlay. ## 1. The menu entry moved `keelmenu._overlay` showed **Overlay network** under Instance > Advanced until the spec had an overlay, and after that in the Instance menu itself, so Advanced disappeared. **Choice:** the entry's place now depends only on the installation mode, and is fixed for the life of the node: - simple installation (Keel Web/Core): always Instance > Advanced, configured or not; - `cloud_simple` / `cloud_advanced`: in the Instance menu itself, as before. I think this is the least surprising option. The first time you look for the screen is to configure it, so that is where you learn its place, and it never moves after that. Moving it to the top level once configured would mean one of two things: an Advanced that has disappeared, or two places for one screen. In the cloud modes nothing else is behind Advanced, so no empty Advanced is shown. `uses_overlay` had no other reader and is removed. Tests cover both states (unconfigured and configured, enabled or with an address) in simple and cloud modes, at the rule level and in the loaded Instance menu. ## 2. A node could add itself as a peer Add peer now: - refuses this node's own public key (the one at the top of the same screen); - refuses a peer mesh address that equals one of this node's (`address` or `ipv4_address`, with or without a prefix); - asks yes/no when the peer is outside this node's prefix (e.g. node `fdbc:cc61:347f::1/64`, peer `fd11:a58a:88ef::2`). This still works because the peer is routed as a /128. After a refusal, or a No, you are back in the form with what you typed. `wgscreen.ACTIONS` now receive the node's key. `keelfirstboot` passes it too, and its test fakes now take it, so a caller left on the old signature fails. keel did not refuse a peer key equal to the node's own. That fix is in Keel-Linux/keel#71: it reads the key from `private_key.file` the way `keel network wireguard key` does, so it only runs when secret files are checked. The screen validates with `--no-secret-files`, so it does its own check first. ## 3. The confirmation window ran out unnoticed - **After apply**, while the change still waits (the operator answered No, or keel refused the confirmation), a box now gives the exact deadline in UTC, e.g. `reverts at 14:32:05 UTC (90 s from now)`, and the command `keel network confirm`. The deadline comes from keel's own marker (`keel.network.marker`): `changed_at` plus `window` on the same clock keel dates the change with. The window timer is armed right when the interface comes up. If keel cannot date the change, the box says "as its window ends" rather than inventing a time. - **Back on the screen** while a change waits, the first line says so, with the deadline, and **Confirm now** is the first, highlighted choice. It runs `keel network confirm` and shows keel's verdict. If the change still waits after that, the deadline box follows. - **What the screen can and cannot do:** keel decides who may confirm (`keel.network.session` and `confirm`), from the process tree: - accepted: the machine's console, or a process attached from a container's host (`pct enter`, `lxc-attach`); - accepted: an SSH session started after the change and arriving over the new configuration (for the overlay, over the overlay or the uplink); - refused: an SSH session that was open before the change, an ssh from the machine to itself, or tmux/screen. The screen does not judge the session itself. Confirm now therefore works from the console, or from confconsole started in a new SSH session. In the confconsole that ran the apply over SSH it is refused, and the box then says how to confirm and by when. - **CONFIRM_QUESTION default:** dialog's yesno has no `--defaultno` here, so Enter already answers Yes. The trap was the text, which told an SSH operator to answer No, and No led nowhere. The question now says Yes is safe to try (keel refuses without changing anything) and that the next screen gives the deadline. The default stays Yes. - **Not changed, noted:** confirming over the overlay with `ssh -J` failed because the nodes' sshd hardening sets `AllowTcpForwarding no`. A plain ssh to the node's overlay address from a shell on the other node works. Every new text is held by tests to 72 columns and to the rows of an 80x24 console, including the first screen with a waiting change, four choices and three peers. Coverage stays at 100 %. The changelog has a new entry, 2.2.3+keel15, on top.