peter/haccfiles
1
0
Fork 0
forked from hacc/haccfiles
Code Issues Pull requests Projects Releases Wiki Activity
Nixfiles, for hacc.
619 commits 40 branches 0 tags 20 MiB
Nix 86.3%
SCSS 8.1%
HTML 5.6%
Find a file
stuebinm 5fe7a12b74 forgejo: unbundle, use from nixos-unstable-small 
this is almost a revert of 147fe172d9,
but we now use the forgejo package of nixos-unstable-small instead of
that from stable nixos.

we were never noticably faster than forgejo maintainance upstream (turns
out that unlike mattermost, some services actually get updated in time);
no update was ever more than just copying the latest upstream package
recipe.

As a side-effect, this also updates forgejo to 7.0.5, which is a
security release:
  https://codeberg.org/forgejo/forgejo/src/branch/forgejo/RELEASE-NOTES.md#7-0-5
2024-07-05 13:24:13 +02:00
common common: add sqlite-interactive to systemPackages 2024-05-15 22:42:18 +02:00
docs meta: new structure 2024-01-11 23:49:26 +01:00
modules monitoring: warn if no deploy for 10 days 2024-05-02 22:33:47 +02:00
parsons nextcloud: longer startup timeout 2024-07-02 15:11:38 +02:00
pkgs forgejo: unbundle, use from nixos-unstable-small 2024-07-05 13:24:13 +02:00
websites docs: do not rebuild on each change 2024-04-06 23:16:43 +02:00
.gitignore add deploy-rs gc roots to .gitignore 2022-11-19 15:18:32 +01:00
.rgignore add a .rgignore 2024-01-11 21:30:22 +01:00
.sops.yaml rotate octycs's ssh key 2023-05-04 00:40:44 +02:00
flake.lock update nixpkgs-unstable-small 2024-07-01 14:47:37 +02:00
flake.nix update nixpkgs-unstable-small 2024-07-01 14:47:37 +02:00
LICENSE add a LICENSE-file 2022-10-06 19:31:59 +02:00
README.md meta: new structure 2024-01-11 23:49:26 +01:00
secrets.yaml mattermost: switch to postgresql 2024-05-19 23:26:53 +02:00

README.md

hacc nixfiles

Welcome to the hacc nixfiles (haccfiles). This is how we configure (most of) our infrastructure.

General layout

  • flake.nix: Entrypoint & dependencies
  • modules/: home-grown modules for hacc-specific services
  • pkgs/: packages we need which aren't in nixpkgs
  • websites/: static websites hosted by us
  • common/: meta-level config, reusable across machines
  • parsons/: our sole server, its config & the services it runs

Right now, we only have a single host. We might add more again in the future.

Working with this repo

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.

Deploying remotely

It's recommended to use deploy_rs:

deploy .#parsons -k [--dry-activate]

Alternatively, using just nixos-rebuild:

nixos-rebuild --flake .#parsons --target-host parsons \
  --use-remote-sudo --use-substitutes [test|switch|dry-activate]

Re-deploying on parsons itself

Simply do:

nixos-rebuild --flake .#parsons [test|switch|dry-activate]

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.

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:

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