haccfiles/README.md
stuebinm 003f2f7e44 move all on-disk secrets into sops
this only concerns secrets which are in a raw file. Some of our
services (e.g. nextclouds) keeps secrets in its database; these remain
untouched.

Not yet deployed because of shitty train internet.
2023-05-03 23:04:13 +02:00

94 lines
3.5 KiB
Markdown

# hacc nixfiles
welcome to hacc nixfiles (haccfiles). this is the code describing our nix-based infrastructure.
## structure
- `flake.nix`: Entrypoint & dependencies
- `common/`: configuration common to all hosts
- `modules/`: home-grown modules for hacc-specific services
- `pkgs/`: packages we built and don't want to upstream
- `hosts/`: configuration.nix per host (currently there's only one of those)
- `services/`: all services we run; imported in appropriate host config
- `websites/`: static websites we deploy somewhere
## working with the haccfiles
You will need a flake-enabled nix installation, and have your ssh config set up
so that `ssh parsons` will connect to `parsons.hacc.space`.
It's recommended to use [deploy_rs](https://github.com/serokell/deploy-rs):
~~~shell
deploy .#parsons -k [--dry-activate]
~~~
Alternatively, using just `nixos-rebuild`:
~~~shell
nixos-rebuild --flake .#parsons --target-host parsons \
--use-remote-sudo --use-substitutes [test|switch|dry-activate]
~~~
If for some reason you have `nix` but not `nixos-rebuild`, you can still build the
system closure using:
~~~shell
nix build .#nixosConfigurations.parsons.config.system.build.toplevel
~~~
(but you might have trouble deploying it)
## Secret management
We use [sops-nix](https://github.com/Mic92/sops-nix) to manage secrets which we'd
like to have in Git but don't want to be public. Entires in `secrets.yaml` are
encrypted for each of the age keys listed in `.sops.yaml`, which are themselves
derived from ssh keys.
For the initial set up, please take a look at the sops-nix Readme file.
To edit the secrets file, just use `sops secrets.yaml`, which will decrypt the
file & open it in your $EDITOR, then re-encrypt it when you're done.
To add a new key, use `ssh-to-age` to convert your ssh key to age, and add it to
`sops.yaml`. Then do `sops updatekeys secrets.yaml` to re-encrypt the file for
the new set of keys.
## Working on websites
Websites are exposed as flake outputs: if you're working on a website & want to
check it in a browser, do e.g.
~~~shell
nix run .#\"muc.hacc.earth\"
~~~
to start a local http server (note that some of our websites need a directory
to be built in; these use `/tmp/hacc-website`).
To add a new website, add a new subdirectory to `websites`; nix will generate a
vhost config based on that directory's name. Add a `default.nix` in your directory
describing how to build the website, and give its derivation a `watch` attribute
to make the `nix run` setup work.
## I don't want to build this long dependency / want a cached version!
If it's still available on parsons from a previous deploy, do:
```shell
nix copy --from ssh://parsons /nix/store/...
```
Note: don't just copy the .drv file (which Nix complains about if it can't
build something), that's just the description of how to build it! If you
don't know the actual outpath, look in the .drv file (should start with
`Derive([("out","[the path you want]"...`)
## committing to haccfiles
- Things on `main` should always reflect the config that's actually deployed on
parsons, except during testing / debugging sessions
- split up commits, every commit is one atomic change
- follow the commit format: "place: $change"
- place: e.g. `modules/$module`, `services/$service` ...
- change: describe your change. Please wrap your lines sensibly (or configure
your editor to do this for you)
- Exception: autogenerated messages (merge commits, reverts, etc)
- don't overuse merge commits, try to rebase things if possible with reasonable
effort