67 lines
3.3 KiB
Markdown
67 lines
3.3 KiB
Markdown
# Setup Steps
|
|
|
|
The first configuration of the server needs some configuration of its mutable state:
|
|
|
|
Setup also heavily relies on the secrets configured, make sure you [understand agenix](./SECRETS.md) good enough.
|
|
|
|
# Root Password
|
|
|
|
The `root` password is `tuxcord` by default on all system configurations. For security, it's important to remember to change it as soon as an installation is done.
|
|
|
|
The root account is intended to be kept active in case there ever is the need to perform a TTY login. But this will be rare so do keep a security complex password saved somewhere and don't share it beyond the necessary amount.
|
|
|
|
# SSH Keys
|
|
|
|
Most agenix secrets have to be decrypted by the machine nixos is being installed to. For this, agenix uses the ssh host keys.
|
|
|
|
This also means that no secrets will be accessible on the host right after a base installation, with the default fresh ssh keys.
|
|
|
|
Will will need to either migrate ssh keys from another host, if you are doing a migration, or take the public keys of the new host out to encrypt agenix secrets against them. These keys, both public and private are present in `/etc/ssh/ssh_host_*`, we have a strong preference in favor of elliptic curve cryptography.
|
|
|
|
Also note that ssh keys are persistent and will be saved across machine boots and virtual machine rebuilds, so you don't need to repeat this process every time.
|
|
|
|
# DNS SOA Record
|
|
|
|
If the DNS server is enabled for the host (`dns.enable`), the host will have a DNS server for itself that can take updates with `nsupdate`.
|
|
|
|
This section assumes surface-level knowledge of DNS records, as well as a IPv4-only server.
|
|
|
|
First of all, make sure that the secrets for `nsudpate` ([DNS TSIG Keys](./SECRETS.md)) are in place, otherwise the server won't be able to take updates and will remain on an empty useless state.
|
|
|
|
You need to tell it it has authority over itself (`SOA` -> `Start Of Authority`) for it to take updates and serve changes properly, as well as configure the base `A` records.
|
|
|
|
`/var/dns/${fqdn}.zone`:
|
|
|
|
```zone
|
|
$ORIGIN ${fqdn}.
|
|
$TTL 14400 ; 4 hours
|
|
@ IN SOA ${fqdn}. ${adminEmail} (
|
|
2026050301 ; serial
|
|
3600 ; refresh (1 hour)
|
|
1800 ; retry (30 minutes)
|
|
604800 ; expire (1 week)
|
|
86400 ; minimum (1 day)
|
|
)
|
|
|
|
@ A ${ip}
|
|
|
|
ns1 A ${ip}
|
|
@ NS ns1
|
|
ns2 A ${ip}
|
|
@ NS ns2
|
|
|
|
* CNAME ${fqdn}.
|
|
```
|
|
|
|
Note the template variables:
|
|
|
|
- You need to place your FQDN in `${fqdn}` (there are shorter ways, but this guarantees functionality even if the hostname and domain don't match).
|
|
- Also an IPv4 address at `${ip}`.
|
|
- And lastly, `${adminEmail}` the SOA record has a `RNAME` field that takes the administrator's email address with dot notation (`test@example.com` would be written as `test.example.com.`).
|
|
- The values related to serial number and lifetimes can and should be tweaked depending on the use-case. Especially `serial`, note that it resembles a date.
|
|
|
|
Then restart bind with `systemctl restart bind`. Make sure that the file is owned by `named:named`.
|
|
|
|
> [!NOTE]
|
|
> This file is **mutable**, bind can and **will** change it with `nsupdate`s, it also tends to format and compact this template into a certain layout.
|