ov-foundation/skills/tailscale/SKILL.md
Tailscale mesh VPN (tailscaled service). Installs the tailscale package from upstream, enables tailscaled.service via systemd. Use when adding Tailscale as a standalone systemd service to an image — distinct from the deploy-time Tailscale tunnel/sidecar model.
npx skillsauth add overthinkos/overthink-plugins tailscaleInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
| Property | Value |
|----------|-------|
| Dependencies | none |
| Ports | none (WireGuard uses UDP; no host port mapping) |
| Service | tailscaled.service (systemd, enabled at build time) |
| Install files | tasks: |
rpm:): tailscale from the upstream tailscale-stable repo (https://pkgs.tailscale.com/stable/fedora/tailscale.repo)pac:): tailscale# image.yml -- typical bootc composition
my-bootc-image:
base: "quay.io/fedora/fedora-bootc:43"
bootc: true
distro: ["fedora:43", fedora]
layers:
- bootc-base
- tailscale
- ...
The layer's cmd: task issues systemctl enable tailscaled.service at build time (suffixed with || true because offline bootc assembly can't fully activate a live systemd — same || true pattern used in /ov-foundation:bootc-config for systemctl set-default graphical.target).
The image does not bring up the mesh on first boot — tailscale up --authkey=tskey-… is a runtime concern, not a build-time concern. Options:
sudo tailscale up and copy the login URL./etc/tailscale/authkey (out of scope for this layer).For target: local host deploys (canonical: local.ov-cachyos), pair this layer with /ov-foundation:tailscale-up — the runtime-config sibling that sets --operator=$account so non-root user-systemd quadlets can run tailscale serve (the per-pod tunnel: tailscale mechanism in deploy.yml), and that keeps the tailnet device name in sync with hostname -s across hostname changes. tailscale-up self-gates on systemctl is-active tailscaled so it's a no-op in image-build / pre-auth contexts; bootc consumers don't include it.
/ov-selkies:selkies-desktop-bootc — primary consumer (bootc VM that wants a tailnet identity at boot).Two declarative checks (build-scope):
tailscale-binary — /usr/bin/tailscale and /usr/sbin/tailscaled executables existtailscaled-unit-enabled — systemctl is-enabled tailscaled.service returns enabled/ov-foundation:tailscale) — bakes the daemon into a system image as a first-class systemd service. The image runs its own tailnet node. Use for bootc/VM images./ov-foundation:container-nesting — also installs the tailscale package, but as a tool inside a container-in-container harness (rootless podman with Tailscale-backed outbound). Different use case; don't use both in the same image./ov-advanced:sidecar, /ov-core:deploy) — a separate deployment-time decision that runs tailscale in a sidecar container alongside your app pod, giving the app a tailnet identity without baking the daemon into the app image. This is deploy.yml-only state and is not affected by whether this layer is present.All three can coexist, but for most cases you want exactly one.
/ov-foundation:tailscale-up — runtime-config sibling for target: local host deploys (sets --operator + --hostname). Use both layers together on host targets that need tailscale serve to work without sudo./ov-foundation:container-nesting — the previous home of the tailscale package (bundled with buildah/skopeo/docker for nested podman; separate concern)/ov-selkies:selkies-desktop-bootc — primary consumer/ov-foundation:bootc-config — companion layer for bootc boot wiring (autologin, graphical target, supervisord user service)/ov-advanced:sidecar — deploy-time Tailscale sidecar pattern (alternative, not a replacement)/ov-core:deploy — deploy.yml tunnel/sidecar configuration/ov-build:layer — layer authoring reference/ov-build:eval — declarative testing referenceUse when the user asks about:
tailscaled.service appears in a bootc image's service listdevelopment
Claude Code multi-agent support in Overthink — sub-agents, dynamic workflows, and agent teams, and how each drives the existing `ov eval` disposable beds to test and verify. MUST be invoked before authoring or invoking an ov sub-agent / dynamic workflow / agent team, wiring agent-lifecycle hooks, or asking "which primitive should drive the R10 beds?".
tools
Mounts a virtiofs share tagged `workspace` at /workspace inside a VM guest via a systemd .mount unit. Use when a kind:vm entity shares a host directory into the guest and you need it auto-mounted (and re-mounted at every boot).
development
MUST be invoked before any work involving: the `kind: android` schema kind, a `target: android` deploy, the `apk:` layer package format (installing Android apps declaratively), AndroidDeployTarget, an in-pod emulator OR a remote/physical adb-endpoint device, or nested `pod → android` deployment. The first-class Android device + app surface that sits above `ov eval adb`/`appium`.
tools
Use when committing, branching, pushing, merging, tagging, creating PRs, or approving/merging PRs with gh — the feat/-branch, R10-gated, never-force-push landing workflow across the main repo + the plugins submodule + image/<distro> submodules. Covers sync-to-upstream, branch/worktree pruning, the fork+PR path for contributors without write access, and cross-repo @github landing order.