Describe the machine

The first step changes nothing on the target. It asks a few questions and writes the answers into the host repo, which every later step reads.

Run this on the live system:

setup host

Answer the prompts

Each prompt is pre-filled with its default, which you can edit in place or accept with Enter.

== Describe this machine ==
Machine: x86_64 PC, UEFI
? Hostname: archlinux

The name you will type into ssh for the rest of the machine’s life, so something short and memorable beats something descriptive. setup writes it straight into the target’s /etc/hostname rather than using hostnamectl, which inside a chroot talks to the live system’s systemd and would rename the stick instead.

? Install to which disk?
  1) /dev/disk/by-id/nvme-XP1000F256G_2213E5A1B2C3       238.5G  nvme  XP1000F256G  (nvme0n1)
  2) /dev/disk/by-id/ata-Samsung_SSD_870_S5Y1NG0R        931.5G  sata  Samsung SSD 870  (sda)
  (/dev/sdb, the BOOMSTICK you booted from, is not offered)
? Number (1):

The disk is recorded by its /dev/disk/by-id/ name, which belongs to that physical drive, rather than /dev/nvme0n1, which belongs to whatever order the kernel found the drives in this time. The stick you booted from is never offered: setup finds it by its BOOMSTICK partition label and leaves it off the list, and refuses it later even if you write it into the host file by hand.

? Encrypt the root filesystem with LUKS? (yes/no): no

Full-disk encryption protects the data on a machine that is stolen, resold, or returned under warranty. It does nothing for a machine that is already running and unlocked: the threat it addresses is physical possession of the disk.

The cost is a passphrase at every boot, which is a real cost on a headless machine in another room. A laptop is an obvious yes; a home server that must come back up unattended after a power cut is an obvious no.

On a Raspberry Pi, setup warns before asking. The Pi has no bootloader that can prompt for a passphrase, so the prompt comes from the initramfs on the console and serial line – of no use on a Pi with neither attached. Unlocking a headless Pi over the network needs an initramfs with networking and SSH, which this book does not set up. If the Pi is headless, leave encryption off.

? Swap file size, or 0 for none: 8g

Swap is worth having even with plenty of memory: it gives the kernel somewhere to put pages that genuinely are not being used, freeing real memory for the page cache, and it turns “the machine froze solid” into “the machine got slow” when something runs away with allocations. Matching your RAM is only strictly necessary for hibernation, which this book does not set up.

? Time zone: America/Denver
? Locale: en_US.UTF-8
? Console keymap: us

The time zone defaults to the live system’s (UTC unless you changed it); ls /usr/share/zoneinfo lists them. The locale is checked against /etc/locale.gen. Pick a UTF-8 one: a non-UTF-8 default is why box-drawing characters in programs like lsblk degrade into |-, and it causes stranger problems than that in anything handling text. The keymap is for the text console only, which on a machine you reach over SSH you may never see – until a rescue prompt.

? Passwordless sudo for admin? (yes/no): yes
? Extra packages to install (blank for none): just tmux

setup always creates two accounts:

Account	UID	Groups	What it is for
`admin`	1000	`admin`, `wheel`	Administration, and SSH login
`user`	1001	`user`	Everything else. No special privileges.

The split is the point. Day-to-day work – editing, browsing, building, running other people’s code – happens as user, an account that cannot reconfigure the system even by accident. When you intend to administer the machine, you log in as admin.

Whether admin needs a password for sudo is the question. Saying yes means anything that gets a shell as admin has root, which is a real reduction in depth. The reasoning for it here: SSH is key-only, root cannot log in, and a sudo password mostly protects against someone who already has an admin shell – at which point they can wait and capture it. It is the same trade cloud images make. Say no and admin gets ordinary, password-prompting sudo through wheel.

What it wrote

The answers land in one small file of shell variables:

Edit this file: /root/arch/host.env

HOSTNAME=myhost
DISK=/dev/disk/by-id/nvme-XP1000F256G_2213E5A1B2C3
ENCRYPT=no
SWAP_SIZE=8g
TIMEZONE=America/Denver
LOCALE=en_US.UTF-8
KEYMAP=us
ADMIN_NOPASSWD=yes

Edit it with vim /root/arch/host.env, or run setup host again, which re-asks every question with your current answers as the defaults.

/root/arch is a git repository, and setup host seeds the rest of it too:

File	Holds
`host.env`	The answers above
`packages.txt`	Packages beyond the base set, which `setup` picks from the hardware
`units.txt`	systemd units to enable: `systemd-networkd`, `systemd-resolved`, `iwd`, `sshd`, `snapper-cleanup.timer`
`etc/systemd/network/*.network`	DHCP on any wired (`en`) and wireless (`wl`) interface
`etc/ssh/sshd_config.d/10-hardening.conf`	Keys only, no root login
`etc/sudoers.d/10-admin`	Passwordless sudo for `admin`, if you said yes
`etc/snapper/configs/root`, `etc/conf.d/snapper`	Snapshots of `/`, kept to the newest ten
`bin/admin`	The `admin` command, installed to `/usr/local/bin`
`aconfmgr/`	aconfmgr’s view of all of the above, plus what to ignore
`authorized_keys`	The SSH public keys `admin` will accept, copied from the stick

Once seeded, these files are yours: setup never overwrites them, except for the sudoers drop-in, which follows your answer about passwordless sudo, and aconfmgr/10-base.sh, which setup install rewrites from the hardware. The maintenance chapter explains admin and aconfmgr/; until the machine is running you can ignore both.

Change anything before installing

Everything setup install puts on the machine beyond the base system comes from those files, so this is where you deviate from the book. Add packages to packages.txt. Add files under etc/ and they are installed at the same path under /etc. Add or remove units in units.txt.

For example, to use NetworkManager instead of systemd-networkd and iwd – a perfectly good choice if you want its roaming and GUI integration – add networkmanager to packages.txt, replace the first three lines of units.txt with NetworkManager, and delete the two .network files. The aconfmgr configuration is worked out from these files, so it follows without being edited. Commit when you are done:

Run this on the live system:

git -C /root/arch commit -am "Use NetworkManager"

Reinstalling a machine you already have

If the machine has been installed this way before, its host repo already exists – inside the old installation at ~admin/arch, and anywhere you pushed it. Point setup at it instead of answering the questions again:

Run this on the live system:

setup host --from git@git.example.com:you/arch-myhost.git

The live system has no private key of its own, so cloning a private repo over SSH uses yours: connect with ssh -A boomstick to forward your agent.

--from also takes a path to a host.env file, or a name, which is looked up as boomstick/hosts/<name>.env on the stick’s config partition – handy when the machine has no route to your git server.

The only answer it re-checks is the disk. A by-id name belongs to one physical drive, so a reinstall onto a new drive – the usual reason for reinstalling – has to pick again.

No secrets in the host repo

The host repo is meant to be pushed to a git remote, so it holds no secrets. Passwords are asked for during setup install and written nowhere else. WiFi passphrases are copied from the live system into the target, never into the repo. The SSH keys it does hold are public keys. Even so, make any remote you push it to private: it describes your machine in detail.