Go to file
lub 92df129cfa add reminder to post-debootstrap to use passwd
fixes the awkward docker privilege escalation workaround
authorized_keys change ssh keys of lub
authorized_keys_dropbear only use rsa keys for dropbear
config move /etc/resolv.conf to the end
hardware remove ip address
README.md only use rsa keys for dropbear
post-debootstrap-installer.sh add rsync
reset.sh remove -e from reset.sh
setup.sh add reminder to post-debootstrap to use passwd

README.md

These scripts setup a blank hardware server according to our requirements including partitions, raids, debootstrap, package installation and various other configuration. The goal is to create a server ready to join into the swarm.

Usage (from a live system):

# (!) wipes the start sectors of all disks (!)
# (!) review before executing (!)
./reset.sh
reboot


./setup.sh <template> <fqdn>

# example:
./setup.sh ovh_rise-1 server321.example.com


# Unlock the disk after booting the server from disk:
# Dropbear is configured on 222 and only allows the user root
ssh -p 222 root@<fqdn>
cryptroot-unlock

setup.sh executes the hardware specific template files, debootstraps and invokes the actual installer inside the fresh environment.
As much as possible should be done in the chroot, as only there we have control over the software (the live system is normally provided by the hardware provider).

Templates (hardware/*) consist of three files:

  • esp - a symlink to the desired ESP partition
  • parted.sh - script to prepare the partitions. Should create ESP (/boot/efi), md0 (/) and md1 (/boot)
  • network.sh - creates the neccessary configs in /etc/systemd/network

config/* gets copied to the chroot and contains static config files

authorized_keys/* is used to create the users and populate their respective ~/.ssh/authorized_keys authorized_keys_dropbear/* is allowed to login for fde unlocking. No ed25519 keys supported.`