History

Kiara Grouwstra 6a1db9750d bash-based deployment deduplicate flake inputs make re-exports explicit again Revert "deduplicate flake inputs" This reverts commit `95769084ce`. switch launch shell to root flake's nixpkgs, see #279 use flake-sourced nixos-anywhere in tf, to reproduce modules for nix properly pass repo dir for prod, be it with hard-coded TF init move tf init out of python over read-only nix env skip tf lock in views.py over read-only nix env specify XDG_CACHE_HOME, workaround to error writing to /var/empty/.cache update document updating TF module get TF in prod to the same 'installable ... does not correspond to a Nix language value' for non-flakes seemingly gets further when a similar command is tried from terminal. as per https://github.com/NixOS/nix/issues/8752#issuecomment-1694714693, this may have to do with aligning the current working directory. rm launch flake, as i seem to have reached similar progress without it update nixos-anywhere to fix error 'installable ... does not correspond to a Nix language value' rm comment untrack TF generated provider/module stuff - local dev now requires following launch/README.md for now gitignore .auto.tfvars.json used to track TF module of nixos-anywhere in case we want that file for something else, we can move this (and its ignore) to something separate. use a mutable HOME in TF for nixos-anywhere to make a `.ssh` dir in - will this not backfire? change ssh user to root allow accessing test vms from fedi201's machine ssh key, closes #286 allow accessing test vms from fedi201's machine ssh key, closes #286 update nixpkgs to unstable - resolves manual deploy error on bootloader already on newer version switch to bash deployment tmp		2025-04-05 13:55:10 +02:00
..
common	Add pub key Lois	2025-03-12 12:01:50 +01:00
machines	bash-based deployment	2025-04-05 13:55:10 +02:00
test-machines	A bunch more test machines	2025-04-02 15:06:17 +02:00
architecture.pdf	Move the Proxmox architecture document to `infra/`	2024-11-27 12:20:33 +01:00
flake-part.nix	allow accessing test vms from fedi201's machine ssh key, closes #286	2025-04-05 13:54:51 +02:00
machines.md	Generate list of machines from config	2025-02-27 16:45:11 +01:00
machines.md.sh	Make ShellCheck happy	2025-02-27 16:45:11 +01:00
makeInstallerIso.nix	`makeInstaller` -> `makeInstallerIso`	2025-02-21 20:24:40 +01:00
old-deployment-readme.md	Get rid of the `deployment/` directory	2025-02-25 11:57:20 +01:00
proxmox-provision.sh	Support specifying disk size	2025-02-27 16:45:11 +01:00
proxmox-remove.sh	Report errors in subprocesses	2025-02-27 11:35:55 +01:00
README.md	Document regenerating the list of machines	2025-02-27 16:45:11 +01:00

README.md

Infra

This directory contains the definition of the VMs that host our infrastructure.

Provisioning VMs with an initial configuration

NOTE[Niols]: This is very manual and clunky. Two things will happen. In the near future, I will improve the provisioning script to make this a bit less clunky. In the far future, NixOps4 will be able to communicate with Proxmox directly and everything will become much cleaner.

Choose names for your VMs. It is recommended to choose fediXXX, with XXX above 100. For instance, fedi117.
Add a basic configuration for the machine. These typically go in infra/machines/<name>/default.nix. You can look at other fediXXX VMs to find inspiration. You probably do not need a nixos.module option at this point.
Add a file for each of those VM's public keys, eg.
```
touch keys/systems/fedi117.pub
```
Those files need to exist during provisioning, but their content matters only when updating the machines' configuration.

FIXME: Remove this step by making the provisioning script not fail with the public key does not exist yet.
Run the provisioning script:
```
sh infra/proxmox-provision.sh fedi117
```
The script can take several ids at the same time. It requires some authentication options and provides several more. See --help.
(Optional) Add a DNS entry for the machine; for instance fedi117.abundos.eu A 95.215.187.117.
Grab the public host keys for the machines in question, and add it to the repository. For instance:
```
ssh fedi117.abundos.eu 'sudo cat /etc/ssh/ssh_host_ed25519_key.pub' > keys/systems/fedi117.pub
```
FIXME: Make the provisioning script do that for us.
Regenerate the list of machines:
```
sh infra/machines.md.sh
```
Commit it with the machine's configuration, public key, etc.
At this point, the machine contains a very basic configuration that contains just enough for it to boot and be reachable. Go on to the next section to update the machine and put an actual configuration.

FIXME: Figure out why the full configuration isn't on the machine at this point and fix it.

Updating existing VM configurations

Their configuration can be updated via NixOps4. Run

nixops4 deployments list

to see the available deployments. This should be done from the root of the repository, otherwise NixOps4 will fail with something like:

    nixops4 error: evaluation: error:
           … while calling the 'getFlake' builtin

           error: path '/nix/store/05nn7krhvi8wkcyl6bsysznlv60g5rrf-source/flake.nix' does not exist, evaluation: error:
           … while calling the 'getFlake' builtin

           error: path '/nix/store/05nn7krhvi8wkcyl6bsysznlv60g5rrf-source/flake.nix' does not exist

Then, given a deployment (eg. fedi200), run

nixops4 apply <deployment>

Alternatively, to run the default deployment, which contains all the VMs, run

nixops4 apply

Removing an existing VM

See infra/proxmox-remove.sh --help.