The FAI workstation: SSOT, Wake-on-LAN and the mount¶
Two modules: home/net/fai-workstation.nix (the host's SSOT plus wake-workstation) and
home/services/fai-workstation-mount.nix (the rclone SFTP mount).
The SSOT¶
The IP and user were literals repeated in 3 consumers (ssh.nix, the rclone mount, and the wake
script). Now they come from one option. All the consumers are in home/, so the option lives in
home/ too: rule 11 says it lives at the LOWEST level that needs it. Contrast with my.monitors,
which had to move up because a system service needed it.
Wake-on-LAN, and why three paths¶
A magic packet is 6x 0xFF plus 16x the MAC. It is sent from PYTHON and not nixpkgs'
wakeonlan, which is Perl and drags Perl-Critic and Perl-Tidy into the build. It is also the SAME
code that runs on the relay, where I cannot install anything.
SO_BROADCAST is mandatory: without it the kernel refuses to send to a broadcast address. Ports 9
AND 7, because an old NIC sometimes only listens on 7.
wake-workstation tries three paths, in this order:
- A relay through the fai-vm. The only path that wakes a machine that has been off FOR A
WHILE, because it broadcasts on the L2 segment; the other two depend on a warm ARP/CAM cache.
The script goes through the remote
python3's STDIN, so there is nothing to install on the other side. - Unicast through the tunnel, which works while the router's ARP is still warm.
- A directed broadcast to the /25, which a router usually drops (RFC 2644).
It checks for a ppp link first, because with no tunnel there is no route to FAI, and failing
there with the right cause avoids chasing ghosts. Then it waits up to 120 s for a ping.
The mount¶
~/FAI-workstation is the workstation's whole root over rclone SFTP with a VFS cache, so it shows
up in Dolphin as a normal folder and rereads from disk instead of the network.
"/" and not just the home: the user sees what they have permission to read, and the rest shows up
but stays inaccessible, which is normal for a non-root.
It is VPN-gated, not boot-mounted. autoMount = false; vpn connect fai starts the mount and
a disconnect takes it down. The host 200.136.209.229 only exists through the VPN, so a boot-time
mount would be a ghost/stale mount. SSHFS would FREEZE Dolphin in that scenario; rclone fails clean
and reconnects.
SFTP through key_file, the SSH key that already exists, so there are ZERO secrets in Nix. The
rclone.conf is generated by the module; only paths and the host are declared here.
The VPN comes up asynchronously, taking ~10 s until the tunnel and routes exist, so
StartLimitIntervalSec is cleared: without it systemd would give up after 5 quick failures before
the host became reachable. It retries every 10 s until it connects, and since vpn connect fai
gives the start and disconnect gives the stop, there is exactly one owner.
The cache options are the same shape as ~/Drive (see restic.md):
vfs-cache-mode = "writes" means READS go straight through, streaming, without piling up on disk,
and only what you write is cached until it uploads. Switch it to "full" for maximum speed
reopening files, at the cost of filling the cache. dir-cache-time = 5m makes browsing FAST, with
F5 to reload; timeout/contimeout keep it from hanging forever when the VPN drops.
The other direction, one file at a time, does not go through the mount: clipboard-push scp's
what is in the clipboard into a drop on the workstation and hands the remote path back, which is how
an image reaches a TUI over ssh. See
desktop-plumbing.md.
The receiving side is NOT declarable from here¶
The workstation is somebody else's Ubuntu 26.04 (superintendencia-server), out of these dotfiles'
reach, and sudo over there asks for a password. To arm WoL, run ON THE WORKSTATION, once:
sudo ethtool enp7s0 | grep -i wake # "Supports Wake-on: ...g" means it can be used
sudo ethtool -s enp7s0 wol g # arms it now (it does NOT survive a reboot)
To persist it: that machine uses NETPLAN plus systemd-networkd, NOT NetworkManager, so there is no
nmcli. In /etc/netplan/00-installer-config.yaml, under ethernets: enp7s0:, add
wakeonlan: true and run sudo netplan apply. It usually also requires "Wake on LAN/PCIe" TURNED
ON in the BIOS/UEFI.
The measured state (jul/2026): /sys/class/net/enp7s0/device/power/wakeup = disabled, so it is
almost certainly NOT armed. There is no confirming it from here: ethtool's Wake-on fields require
root, and without it the read gives "netlink error: Operation not permitted".