update readme
parent
83da47cdd1
commit
c18a87ebe5
@ -1,12 +1,36 @@
|
||||
usage:
|
||||
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):
|
||||
```sh
|
||||
./setup.sh <server> <fqdn>
|
||||
# (!) wipes the start sectors of all disks (!)
|
||||
# (!) review before executing (!)
|
||||
./reset.sh
|
||||
reboot
|
||||
|
||||
|
||||
./setup.sh <template> <fqdn>
|
||||
|
||||
# example:
|
||||
./setup.sh ovh token.lubi.link
|
||||
./setup.sh ovh_rise-1 server321.example.com
|
||||
|
||||
|
||||
# Unlock the disk after booting the server from disk:
|
||||
# Dropbear is configured on 222
|
||||
ssh -p 222 <fqdn> /bin/cryptroot-unlock
|
||||
```
|
||||
|
||||
after connecting to dropbear:
|
||||
```sh
|
||||
/bin/cryptroot-unlock && exit
|
||||
```
|
||||
`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`
|
Loading…
Reference in New Issue