wsl1

WSL Ubuntu on dev-workstation (wsl1) — Local Dev Worker Node

⚠️ SUPERSEDED (2026-08-11). This doc’s self-polling/native-process/outbound-poll architecture was found to conflict with ADR-005’s Docker + CF-Tunnel-inbound design for this same host, caught by the /review-plan pass on #6085. Owner decision: ADR-005’s Docker design is the one to build. Do not implement this doc’s self-polling job-claiming design (docs/designs/6094-self-polling-queue-worker.md) as scoped. This doc’s hardware spec (6 cores, 31GB RAM, below) is still accurate and should be reused for ADR-005 §5b’s sizing. The wsl1-worker SSH key was removed from vps-h1 (PROTECTED host) per owner decision; it remains on the other 5 hosts pending the Docker build.

Environment ID: wsl1 Type: local-dev Status: superseded by ADR-005 (architecture); hardware spec still current

Purpose

WSL2 Ubuntu instance running on the primary Windows dev workstation (dev-workstation, see docs/environments/dev-workstation.md), provisioned as a supplementary Linux worker node alongside lap1. Provides additional queue worker capacity without a dedicated VPS. Follows the same scoping decision as lap1 — never given bms-4-equivalent production access (no role-*.env.sops decrypt, no MongoDB rs0 admin, no GH App token). This is a deliberate choice, not an oversight: see docs/playbooks/lap1-worker-credentials.md for why role-*.env.sops recipients were narrowed to developer + CI only (plan #4556 Phase 3) — putting full production credentials on the least-controlled, least-monitored class of host (a live interactive dev machine) would reopen exactly the hole that hardening closed.

Not a replacement for bms-4. Use only for P1–P2 jobs; never P0 (incident response, sys-admin operations requiring guaranteed availability) — same rule as lap1.

Hardware

Field	Value
Label	wsl1
Host OS	Windows 10 Home 10.0.19045 (dev-workstation)
Guest OS	Ubuntu 26.04 LTS (WSL2, systemd enabled)
CPU	6 cores
RAM	31 GB (WSL2 allocation)
Disk	954 GB free (/, /dev/sde)
IP	CF Tunnel: wsl1-ssh.zintegrowana.online (no direct inbound; host has an unstable/dynamic IP)

Connectivity

Direction	Protocol	Destination	Notes
Outbound	SSH	vps-i1, vps-h1, bms-1, bms-2, bms-3, bms-4	Dedicated key /root/.ssh/wsl1-worker (ed25519, comment wsl1-worker-2026-08-11), added to each server’s /root/.ssh/authorized_keys. Verified end-to-end 2026-08-11.
Outbound	HTTPS	mwkqmgadqnkkihjdeqsi.supabase.co	Queue polling (que-type worker)
Outbound	HTTPS	p24-meta-dispatcher.radieu.workers.dev	Worker queue API
Inbound	CF Tunnel	wsl1-ssh.zintegrowana.online	cloudflared systemd service on WSL, tunnel id ece80c39-a244-464d-86db-0892658f37c0. Connector verified registered (4x QUIC connections to CF edge). Client-side proxy issue resolved 2026-08-11 by the single-level hostname rename — see Resolved Issues.

Running Workers

Worker ID	Type	Description
wsl1-que-w1	Queue worker	Polls Supabase p24_worker_queue — outbound HTTPS only, P1-P2

Setup Done (2026-08-11)

• WSL2 Ubuntu 26.04, systemd enabled (/etc/wsl.conf: [boot] systemd=true)
• openssh-server installed, ssh.socket/ssh.service enabled + active (listens 0.0.0.0:22, [::]:22)
• cloudflared 2026.7.3 installed (apt .deb), cloudflared.exe on the Windows host upgraded to match (was stale at 2025.8.1 — a version mismatch was one of the debugging dead-ends, see Known Issues)
• Cloudflare Tunnel wsl1-ssh created via API (account acc5b2c956dd488265003364e2c7f84a), remotely-managed config (config_src: cloudflare), ingress originally wsl1-ssh.tunnel.zintegrowana.online → ssh://localhost:22, catch-all 404 — renamed 2026-08-11 to the single-level wsl1-ssh.zintegrowana.online, see Resolved Issues
• DNS CNAME wsl1-ssh.zintegrowana.online → <tunnel-id>.cfargotunnel.com (proxied)
• cloudflared installed as a systemd service on WSL via connector token (cloudflared service install <token>)
• Cloudflare Access application wsl1-ssh (type ssh) + policy wsl1-ssh-owner-only (allow radieu@gmail.com) created — did not resolve the client-side proxy issue, see Known Issues
• Admin pubkey (radieu-root-2026-06-27, the dev-workstation’s main key) added to WSL’s own /root/.ssh/authorized_keys
• Dedicated wsl1-worker ed25519 keypair generated on WSL for outbound connections; its pubkey added to /root/.ssh/authorized_keys on vps-i1, vps-h1, bms-1, bms-2, bms-3, bms-4 — verified end-to-end from WSL to all 6
• Windows Scheduled Task P24-WSL-Autostart (trigger: at logon) runs wsl.exe -d Ubuntu -u root -- /bin/true so the distro (and its systemd services) come up automatically after a reboot
• C:\Users\konar\.wslconfig — vmIdleTimeout=-1 set to prevent the WSL2 VM auto-terminating after the last foreground process exits (requires wsl --shutdown + restart to take effect — not yet cycled as of this write-up, to avoid dropping the live tunnel connection mid-setup)
• CF_TUNNEL_WSL1_TOKEN stored in secrets/administration.env.sops (connector run-token, same pattern as CF_TUNNEL_LAP1_TOKEN)

Resolved Issues

CF Tunnel SSH client-side proxy connection reset — RESOLVED 2026-08-11, root cause: two-level hostname outside Universal SSL coverage

Original symptom: ssh -o ProxyCommand="cloudflared access ssh --hostname wsl1-ssh.tunnel.zintegrowana.online" root@wsl1 (and the --url-based local-listener variant) failed with kex_exchange_identification: read: Connection reset. The WSL-side cloudflared connector logged failed to connect to origin error=EOF originURL=https://wsl1-ssh.tunnel.zintegrowana.online for the requests that did reach it. Same symptom class was independently hit on lap1 (lap1-ssh.tunnel.zintegrowana.online, “TLS-layer reset, 3 methods tested”).

Ruled out along the way: cloudflared.exe version mismatch (upgraded 2025.8.1 → 2026.7.3, no change), missing Access application/policy (created, no change), a dead/unregistered tunnel connector (confirmed healthy — 4x QUIC connections to CF edge fra17/fra18/txl01).

Root cause, found 2026-08-11: the zone’s free Universal SSL wildcard (*.zintegrowana.online) covers exactly one subdomain level. Both wsl1-ssh.tunnel.zintegrowana.online and lap1-ssh.tunnel.zintegrowana.online are two levels deep — Cloudflare’s edge resets the TLS handshake before cloudflared access ssh can complete it, producing exactly this symptom.

Fix: both tunnels renamed to single-level hostnames — wsl1-ssh.zintegrowana.online and lap1-ssh.zintegrowana.online — as part of the fleet-wide CF Tunnel backup-SSH rollout that same day. See docs/playbooks/fleet-backup-ssh-cf-tunnel.md for the full hostname map and the “never add a two-level hostname in this zone” rule going forward. windows-dev’s CF Tunnel (provisioned later, #6186) used the single-level form from the start, informed by this diagnosis.

Does not block worker functionality — wsl1-que-w1 polls Supabase outbound over HTTPS and does not need inbound reachability, same as lap1-que-w1/w2. The tunnel remains useful groundwork (DNS + ingress + connector are all correctly provisioned) for whichever fix resolves this, and could still serve non-SSH ingress (e.g. an HTTPS metrics endpoint) in the meantime.

Secrets Access

Same scoping as lap1 — see docs/playbooks/lap1-worker-credentials.md. wsl1 has no access to role-*.env.sops files (recipients are developer + CI only, plan #4556 Phase 3). It does not hold the repo’s primary SOPS age key; it is not a Class A session.

Naming Convention

Follows {server-label}-{worker-type}-{index} — see docs/playbooks/adding-new-worker.md.

Worker	Segments	Meaning
wsl1-que-w1	wsl1 + que + w1	WSL node 1, queue worker, slot 1

Pane execution layer — abandoned pilot (historical, #6132)

wsl1 was briefly considered as a target host for the Pane (runpane.com) execution pilot — a scoped alternative to ADR-005 §5b’s Docker design for this host and lap1, using parallel job execution via a self-hosted local daemon. The pilot was abandoned the same day it was proposed (2026-08-11) after Pane’s headless daemon setup hit an unresolved, architectural hang (confirmed via 4 independently ruled-out theories — display availability, network/DNS, WSL2 connectivity, virtual framebuffer; root cause per Pane’s own docs is that its “remote daemon” has no genuine headless code path). See #6132’s final comment for the full writeup. ADR-005’s Docker design (#6110) is the confirmed design of record for this host; see the status banner at the top of this file and windows-dev.md for the current build.

Related Docs

• docs/playbooks/adding-new-worker.md — worker registration playbook (Registered Workers table)
• docs/environments/lap1.md — the precedent this setup follows
• docs/environments/dev-workstation.md — the Windows host WSL runs on
• docs/playbooks/p24-network-admin.md — CF Tunnel operations
• docs/playbooks/lap1-worker-credentials.md — why role credentials are intentionally withheld