flan
bd7f46a260
The install hardcoded one specific forge: bootstrap and the archinstall custom-commands fetched from a private Gitea, and firstboot cloned a private dotfiles repo from it. Anyone else cloning this got an installer that could not work and that pointed at a repo they cannot read. Split the two phases. The base install (LUKS + btrfs + snapper + yay) is now generic and runs from a fresh clone with no configuration. The personal phase (vault unlock, forge key registration, dotfiles, yadm bootstrap) reads a gitignored site.env; with none present firstboot reports what it is skipping and leaves a complete system. One fetch root, ARCH_TURNKEY_BASE, now feeds bootstrap, the archinstall custom-commands (via an @@BASE@@ placeholder) and the ISO autorun, defaulting to the public mirror. iso/build.sh bakes site.env into a custom ISO so an unattended personal install stays one boot.
2.6 KiB
Site config — provisioning your own machines
arch-turnkey installs in two phases:
| Phase | What it does | Needs a site config? |
|---|---|---|
| 1 · Base | archinstall: LUKS + btrfs subvolumes + snapper + yay | no |
| 2 · Personal | unlock vault → register SSH key with your forge → clone dotfiles → yadm bootstrap |
yes |
Phase 1 is generic and works for anyone straight from a clone. Phase 2 is inherently
personal — it needs your forge, your vault, your dotfiles — so none of it is baked
into this repo. Instead it reads a site.env that you supply. With no site.env,
firstboot prints what it's skipping and stops with a complete, clean Arch system.
site.env is gitignored. It should never be committed.
Setting one up
Copy the template and fill it in:
cp configs/site.env.example site.env
$EDITOR site.env
You need, at minimum, DOTFILES_REPO — a yadm repo carrying ~/.config/pkglist/
(common + class-* + per-host). Unset, phase 2 is skipped entirely. The forge variables
exist so the freshly-generated SSH key on the new machine can be registered with your forge
before the dotfiles clone is attempted, and the vault variables collapse the two secrets
phase 2 needs (a forge token, the archive passphrase) behind a single master-password prompt.
Getting it onto the machine
bootstrap.sh installs site.env to /etc/arch-turnkey/site.env (mode 0600) once
archinstall finishes; firstboot.sh sources it on first boot. Three ways to get it there:
Unattended — bake it into an ISO. Put it at iso/site.env and build:
cd iso && ./build.sh
Booting that ISO auto-runs bootstrap, which finds the config at /root/site.env. This is
the near-zero-typing path: boot, answer archinstall's disk/user prompts, enter your vault
master password once, done.
Ad hoc — drop it on the live ISO. Before running bootstrap, write it to /root/site.env.
Anywhere else. Point ARCH_TURNKEY_SITE at it:
ARCH_TURNKEY_SITE=/mnt/usb/site.env bash bootstrap.sh
Not depending on GitHub at install time
bootstrap.sh fetches the rest of the tree from the public GitHub mirror by default, so a
plain curl | bash works for anyone. If you'd rather the install pull from your own forge,
set ARCH_TURNKEY_BASE (in site.env or the environment):
ARCH_TURNKEY_BASE="https://git.example.com/you/arch-turnkey/raw/branch/master"
Everything downstream — the archinstall config's custom-commands, firstboot.sh, the
systemd unit — is fetched relative to that one root, so a single variable re-points the
whole install at a mirror you control.