Skip to content

Hosts

Every physical and virtual host in the Dashecorp/Invotek infrastructure.

Active Hosts

Every host marked Ålesund is at the operator's parents' house outside Ålesund (Møre og Romsdal) — remote access only, no hands-on physical access (see Physical Locations).

Host Tailscale IP OS Location Role SSH Access
MacBook Air M4 24GB 100.126.195.52 macOS 15 (Darwin 25.1) Las Palmas (with operator) Dev machine, Claude Code (workspaces 3-6) Local
Dell Precision 5520 (dell-stig-1) 100.95.212.93 Ubuntu 24.04 LTS Ålesund k3s cluster (legacy, scaled down) ssh -i ~/.ssh/dell-stig-1 claude@100.95.212.93
VPS srv1099021 (Volt-E) 100.111.142.118 Linux (x86_64) Boston, USA Volt-E (agent-runner, systemd) ssh -i ~/.ssh/vps-srv1099021 root@100.111.142.118
Pi4-02 8GB 100.77.12.75 Linux (ARM64) Ålesund Spare/legacy node — former Review-E host (agent-runner retired; Review-E now runs in the GCP k3s cluster as rig-agent-runtime pods) ssh -i ~/.ssh/rpi-pi4-02 claude@100.77.12.75
Pi4-03 8GB (Pi-E) 100.107.48.17 Linux (ARM64) Ålesund Pi-E agent (agent-runner, systemd) ssh -i ~/.ssh/rpi-claude claude@100.107.48.17
Mac Mini M4 100.92.170.124 macOS (Apple Silicon) Ålesund iBuild-E (agent-runner, LaunchAgent) + iClaw-E (agent-runner, LaunchAgent) — no CI runner (self-hosted macOS runner retired 2026-06-29; ios-sdk CI now runs on GitHub-hosted macos-26) ssh -i ~/.ssh/mac-executor claude@100.92.170.124
DS412+ (NAS) 100.95.36.122 Linux Ålesund Synology NAS (~9TB) — NFS volumes for k3s —
Pi4-01 100.73.159.126 Linux (ARM64) Ålesund Tailscale exit node ssh -i ~/.ssh/rpi-pi4-01 claude@100.73.159.126

Mobile Devices (Tailscale)

Device Tailscale IP OS Notes
Samsung Galaxy A17 100.90.74.87 Android Pushbullet SMS forwarding
iPhone 15 Pro Max 100.110.193.124 iOS Primary phone
iPad (10th gen) 100.75.46.53 iOS —

Retired/Offline Nodes

Node Tailscale IP Last seen Notes
9f71f0bfa6c6 100.93.47.98 131d ago Unknown container
google-cloud-debian-1 100.95.117.82 42d ago GCP instance
kubectl-jumpbox 100.75.171.111 271d ago Retired
win-pw0edb77-1 100.124.218.17 — Private machine (not part of infra)
iPad Pro 12.9 6th Gen 100.74.168.115 20d ago —

VNC Access

Host Protocol Address Port Client When needed
Mac Mini M4 VNC (macOS Screen Sharing) 100.92.170.124 5900 Screens app Maintenance, claude login
Mac Mini M4 noVNC (browser) https://100.92.170.124:6080/vnc.html 6080 Browser (HTTPS required) Fallback if Screens unavailable
Volt-E (VPS) VNC (x11vnc) 100.111.142.118 5900 Screens app claude login for OAuth refresh
Volt-E (VPS) noVNC (websockify) http://100.111.142.118:6080 6080 Browser Fallback
Pi4-02 (spare) VNC (x11vnc) 100.77.12.75 5900 Screens app Former Review-E host — Review-E now in GCP k3s; node is spare
Pi-E (Pi4-03) VNC (x11vnc in Docker) 100.107.48.17 5900 Screens app Normally not needed (token pushed)
Pi-E (Pi4-03) noVNC (Docker) http://100.107.48.17:6080 6080 Browser Fallback

VNC Notes

  • All connections require Tailscale — connect via 100.x.x.x addresses
  • Mac Mini M4 noVNC: Must use HTTPS (self-signed cert) — crypto.subtle requires secure context for ARD auth
  • Mac Mini M4 Screen Recording: If VNC shows black screen, check System Settings → Privacy & Security → Screen Recording is enabled. Disabling Remote Management first may be needed to unlock the toggle (macOS Sequoia requirement).
  • Volt-E: Runs LXDE desktop with x11vnc (systemd service xvfb-vnc.service). Pi4-02 (the former Review-E host) has the same setup but is now a spare; Review-E runs in GCP k3s.
  • Pi-E: VNC runs inside Docker container (ports 5900 + 6080 exposed)
  • Recommended client: Screens app (iOS/macOS) — works with all hosts

Troubleshooting: claude CLI hangs on the Mac Mini (keychain wedge)

Symptom: claude (interactive, -p, or --debug) hangs at startup with zero output; the debug log (~/.claude/debug/*.txt) stops at CA certs: Config fallback; security commands — even security list-keychains — hang and pile up /usr/bin/security procs (PPID 1).

Cause: the macOS keychain daemon (securityd) is wedged (observed at ~17-day uptime) and/or a stuck keychain-authorization dialog is sitting unanswered on the headless GUI — a claude CLI version bump re-signs the binary, so macOS re-prompts "allow access to keychain item 'Claude Code'?" and nobody can click it. claude reads its OAuth credential via security find-generic-password -a claude -s "Claude Code", which then blocks. Token/network/trust are fine (the OAuth token returns HTTP 200 via curl), and the hang is identical over Tailscale SSH and LAN SSH — so it is not a network or session-context issue.

Cannot be fixed from SSH: killall secd doesn't clear it, and securityd is SIP-protected — sudo killall securityd is a no-op (same PID), and sudo launchctl kickstart -k system/com.apple.securityd returns 150: Operation not permitted while System Integrity Protection is engaged.

Fix: 1. Preferred (no reboot): VNC to the Mac screen over Tailscale (Screens → 100.92.170.124:5900, or noVNC https://100.92.170.124:6080/vnc.html) and click Always Allow on the keychain dialog (enter the login password). Releases securityd; the ACL update stops future prompts. 2. Fallback: sudo reboot — auto-login (autoLoginUser=claude) unlocks the login keychain on boot, giving a fresh securityd.

Both fixes assume the Mac is powered on and on the network. There is no hands-on access to it (see Physical Locations) — if the box is off or off the network, recovery means phoning the operator's parents; one such outage ran ~20 days before anyone noticed.

Verify: cd /tmp/rtd-demo/cc-demo-repo && claude -p "Reply PONG" --strict-mcp-config returns a reply within seconds (instead of hanging).

SSH to the Mac Mini via the Pi-E LAN jump

Pi-E (LAN 192.168.1.105, also routed onto the 192.168.68.x segment) reaches the Mac Mini's native sshd on its LAN IP 192.168.68.131 (port 22). Useful as an alternate SSH path — note that VNC ports 5900/6080 are filtered on the Mac's LAN IP, so use the Tailscale IP for VNC:

ssh -i ~/.ssh/mac-executor \
  -o ProxyCommand="ssh -i ~/.ssh/rpi-claude -W %h:%p claude@100.107.48.17" \
  claude@192.168.68.131

(This is only an access path; the keychain wedge described above affects this session too.)

Physical Locations

Ålesund (Møre og Romsdal) — operator's parents' house, no hands-on access:
├── Dell Precision 5520 (i7, 32GB, 233GB NVMe) — k3s cluster
├── Mac Mini M4 — iBuild-E + iClaw-E
├── Raspberry Pi 4-01 — exit node
├── Raspberry Pi 4-02 — spare/legacy (former Review-E host; Review-E now in GCP k3s)
├── Raspberry Pi 4-03 — Pi-E
└── Synology DS412+ (~9TB) — NFS for k3s

Las Palmas de Gran Canaria — with the operator:
├── MacBook Air M4 — dev + orchestrator
└── Mobile devices

Boston (Hostinger DC):
└── VPS srv1099021 — Volt-E

Ålesund site notes

  • No hands-on physical access. The hardware is in a third party's home in a different part of the country. Nobody on the team can touch it. Anything needing a power cycle, a cable, or a screen — a box that is off, a wedged console — means phoning the operator's parents. A powered-off Mac Mini went unnoticed for ~20 days this way. Treat "unreachable" as potentially unrecoverable-without-a-phone-call, not as a reboot away.
  • Exit nodes: pi4-01 is the documented exit node (see the host table and networking.md) and pi4-02 also advertises the capability. Measured 2026-08-24: the operator's MacBook is configured to exit via pi4-02. Both sit at this site, so either way the egress is the Ålesund WAN.
  • Measured WAN egress: 83.243.161.154 — ISP "Tafjord Get", the Ålesund-region cable operator. pi4-02, pi4-03 and the Dell each resolved to it independently (2026-08-24).
  • Re-derive the site location from any Linux host there: curl -s --interface $(ip route | awk '/^default/{print $5; exit}') https://ipinfo.io/json. You must bind to the physical interface: a host using a Tailscale exit node reports the exit node's egress, not its own. This bites in both directions — the operator's MacBook exits via pi4-02, which is itself at this site, so an unbound check from Gran Canaria returns the Ålesund WAN and looks correct while telling you nothing.