docs: sectarian purge of non-historical references to nixops4

README.md

@@ -1,8 +1,7 @@
 # The Fediversity project
 
 This repository contains all the code and code-related files having to do with
-[the Fediversity project](https://fediversity.eu/), with the notable exception
+[the Fediversity project](https://fediversity.eu/).
-of [NixOps4 that is hosted on GitHub](https://github.com/nixops4/nixops4).
 
 ## Goals
 
@@ -81,28 +80,12 @@ Not everyone has the expertise and time to run their own server.
   The software includes technical configuration that links software components.
   Most user-facing configuration remains untouched by the deployment process.
 
-  > Example: NixOps4 is used to deploy [Pixelfed](https://pixelfed.org).
+  > Example: OpenTofu is used to deploy [Pixelfed](https://pixelfed.org).
 
 - Migrate
 
   Move service configurations and user data to a different hosting provider.
 
-- [NixOps4](https://github.com/nixops4/nixops4)
-
-  A tool for deploying and managing resources through the Nix language.
-  NixOps4 development is supported by the Fediversity project
-
-- Resource
-
-  A [resource for NixOps4](https://nixops.dev/manual/development/concept/resource.html) is any external entity that can be declared with NixOps4 expressions and manipulated with NixOps4, such as a virtual machine, an active NixOS configuration, a DNS entry, or customer database.
-
-- Resource provider
-
-  A resource provider for NixOps4 is an executable that communicates between a resource and NixOps4 using a standardised protocol, allowing [CRUD operations](https://en.wikipedia.org/wiki/Create,_read,_update_and_delete) on the resources to be performed by NixOps4.
-  Refer to the [NixOps4 manual](https://nixops.dev/manual/development/resource-provider/index.html) for details.
-
-  > Example: We need a resource provider for obtaining deployment secrets from a database.
-
 ## Development
 
 All the code made for this project is freely licenced under [EUPL](https://en.m.wikipedia.org/wiki/European_Union_Public_Licence).

infra/README.md

@@ -5,10 +5,7 @@ infrastructure.
 
 ## Provisioning VMs with an initial configuration
 
-NOTE[Niols]: This is very manual and clunky. Two things will happen. In the near
+NOTE[Niols]: This is very manual and clunky.
-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.
 
 1. Choose names for your VMs. It is recommended to choose `fediXXX`, with `XXX`
    above 100. For instance, `fedi117`.
@@ -61,38 +58,27 @@ everything will become much cleaner.
 
 ## Updating existing VM configurations
 
-Their configuration can be updated via NixOps4. Run
+Their configuration can be updated:
 
 ```sh
-nixops4 deployments list
+tofu apply
-```
-
-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
-
-```sh
-nixops4 apply <deployment>
-```
-
-Alternatively, to run the `default` deployment, which contains all the VMs, run
-
-```sh
-nixops4 apply
 ```
 
 ## Removing an existing VM
 
 See `infra/proxmox-remove.sh --help`.
+
+# TODO
+
+- does it know the key?
+- can it access the key?
+- place in credentials, maybe like nixops
+- secrets
+- test deployed application
+- ssh keys
+- other infra (incl import)
+- TF for users
+- deploy deployment (#76)
+- handle infra state (#169)
+- handle user state (#169)
+- provision VMs (#116)

keys/README.md

@@ -14,7 +14,7 @@ overwrite a secret without knowing its contents.)
 In infra management, the systems' keys are used for security reasons; they
 identify the machine that we are talking to. The contributor keys are used to
 give access to the `root` user on these machines, which allows, among other
-things, to deploy their configurations with NixOps4.
+things, to deploy their configurations.
 
 ## Adding a contributor
 

secrets/README.md

@@ -22,7 +22,7 @@ As an example, let us add a secret in a file “cheeses” whose content should
    extension); this will open your `$EDITOR` ; enter “best ones come
    unpasteurised”, save and close.
 
-3. If you are doing something flake-related such as NixOps4, remember to commit
+3. If you are doing something flake-related, remember to commit
    or at least stage the secret.
 
 4. In the machine's configuration, load our `ageSecrets` NixOS module, declare the machine's host key and start using your secrets, eg.: