Skip to content

Developer Laptop Setup

The same setup script bootstraps both physical dev laptops and Terraform-provisioned Windows dev VMs, so there's exactly one script to keep working rather than two diverging ones.

Setup.ps1

Located on the NAS share (\\<nas>\share\...\devsetup\Setup.ps1), run in two phases:

  1. Phase 1 (default, no flags) — enables Windows features needed for WSL2/Hyper-V, schedules a reboot, and registers RunOnce keys so it resumes automatically after that reboot.
  2. Phase 2 (-PostReboot) — waits for the post-reboot environment to settle, creates the WSL user, and runs make install-ubuntu (renamed from install-wsl — the same target now also covers Ubuntu VMs and Docker image builds, not just WSL) to pull in the actual devhome toolchain inside WSL.

For a Terraform-provisioned Windows VM, both phases run automatically as remote-exec provisioners over WinRM (see terraform/vsphere/compute/win11.tf) — the first phase's reboot deliberately drops the WinRM connection mid-provision, which is expected (on_failure = continue); the second phase retries WinRM with a long timeout until the VM is back and finishes the setup non-interactively.

For a physical laptop, run Setup.ps1 directly (no -PostReboot flag needed the first time — the RunOnce key handles resuming after reboot the same way).

Repo access

Clone devhome (this repo's parent) into WSL. Secrets are never checked out with it — they come from Vault at runtime (see Vault Overview) and from a mounted NAS share for anything that has to be a real file (SSH keys, the .vault_env sourcing file).

Canonical NFS mount mapping

Every WSL/VM setup gets exactly two fixed NFS mounts, regardless of which machine it is — this consistency is what lets scripts, aliases, and kubeconfig paths behave identically everywhere:

Remote export Local mount point Contains
truenas-dr.devhome.cloud:/mnt/virutal_machine/backup/config /mnt/backup/config This repo (devhome), Vault env file, kubeconfigs, certs
truenas.devhome.cloud:/mnt/share /mnt/truenas The devsetup repo, ISOs, general file share

configure-personal.sh sets DEVHOME_REPO (default /mnt/backup/config/devhome) and VAULT_ENV_FILE (default $DEVHOME_REPO/config/secrets/.vault_env) from this mapping, plus a devhome shell alias (make -C "$DEVHOME_REPO") — the reason devhome <target> works as a shorthand from anywhere once the shell profile is set up.

NFS export ACLs must match the current subnet — see TrueNAS Services for what happens (and how to check) when a VM lands on a different subnet than an export's allowed-network list expects.

Mount mode: lan vs lab

make configure-personal MOUNT_MODE=lan|lab controls which hostname variant the mount step targets (useful for machines that reach TrueNAS over a different path depending on network context). The self-hosted ADO agent container always defaults to MOUNT_MODE=lab (set via the Dockerfile ENV, overridable at runtime) since it always runs inside the lab network itself.

.vault_env

Sourced before running any script or Terraform command that needs VAULT_ADDR/ VAULT_TOKEN:

source /mnt/backup/config/secrets/.vault_env

(or the Windows UNC equivalent, \\<nas>\backup\config\secrets\.vault_env, if working from outside a WSL/Linux shell). Nothing in this repo should ever hardcode a Vault token.