2021-01-11 00:22:37 +00:00
|
|
|
# hacc nixfiles
|
|
|
|
|
|
|
|
welcome to hacc nixfiles (haccfiles). this is the code describing our nix-based infrastructure.
|
|
|
|
|
|
|
|
## structure
|
|
|
|
|
2022-11-14 17:38:43 +00:00
|
|
|
- `flake.nix`: Entrypoint & dependencies
|
2021-01-11 00:22:37 +00:00
|
|
|
- `common/`: configuration common to all hosts
|
|
|
|
- `modules/`: home-grown modules for hacc-specific services
|
|
|
|
- `pkgs/`: packages we built and don't want to upstream
|
2022-11-14 17:38:43 +00:00
|
|
|
- `hosts/`: configuration.nix per host (currently there's only one of those)
|
2022-01-07 17:15:18 +00:00
|
|
|
- `services/`: all services we run; imported in appropriate host config
|
2022-11-14 17:38:43 +00:00
|
|
|
- `websites/`: static websites we deploy somewhere
|
2021-01-11 00:22:37 +00:00
|
|
|
|
|
|
|
## working with the haccfiles
|
|
|
|
|
2022-11-14 17:38:43 +00:00
|
|
|
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]
|
|
|
|
~~~
|
2021-01-11 00:22:37 +00:00
|
|
|
|
2022-11-14 17:38:43 +00:00
|
|
|
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)
|
2021-01-20 18:45:21 +00:00
|
|
|
|
2023-05-03 21:04:13 +00:00
|
|
|
## 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.
|
|
|
|
|
2023-02-24 16:33:48 +00:00
|
|
|
## 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.
|
|
|
|
|
2022-01-07 17:15:18 +00:00
|
|
|
## 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]"...`)
|
|
|
|
|
2021-01-20 18:45:21 +00:00
|
|
|
## committing to haccfiles
|
2022-11-14 17:38:43 +00:00
|
|
|
- Things on `main` should always reflect the config that's actually deployed on
|
|
|
|
parsons, except during testing / debugging sessions
|
2021-01-20 18:45:21 +00:00
|
|
|
- split up commits, every commit is one atomic change
|
2022-11-14 17:38:43 +00:00
|
|
|
- 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)
|
2021-01-20 18:45:21 +00:00
|
|
|
- Exception: autogenerated messages (merge commits, reverts, etc)
|
2022-11-14 17:38:43 +00:00
|
|
|
- don't overuse merge commits, try to rebase things if possible with reasonable
|
|
|
|
effort
|