diff --git a/README.md b/README.md index 877d2e2e..09ecadef 100644 --- a/README.md +++ b/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 -of [NixOps4 that is hosted on GitHub](https://github.com/nixops4/nixops4). +[the Fediversity project](https://fediversity.eu/). ## Goals @@ -81,27 +80,15 @@ 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) +- [OpenTofu](https://opentofu.org/) - 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. + An infrastructure-as-code tool, and open-source (MPL 2.0) fork of Terraform. ## Development @@ -118,9 +105,6 @@ Contact the project team if you have questions or suggestions, or if you're inte Most of the directories in this repository have their own README going into more details as to what they are for. As an overview: -- [`deployment/`](./deployment) contains work to generate a full Fediversity - deployment from a minimal configuration. - - [`infra/`](./infra) contains the configurations for the various VMs that are in production for the project, for instance the Git instances or the Wiki, as well as means to provision and set up new ones. @@ -128,14 +112,8 @@ details as to what they are for. As an overview: - [`keys/`](./keys) contains the public keys of the contributors to this project as well as the systems that we administrate. -- [`matrix/`](./matrix) contains everything having to do with setting up a - fully-featured Matrix server. - - [`secrets/`](./secrets) contains the secrets that need to get injected into machine configurations. - [`services/`](./services) contains our effort to make Fediverse applications work seemlessly together in our specific setting. - -- [`website/`](./website) contains the framework and the content of [the - Fediversity website](https://fediversity.eu/) diff --git a/infra/README.md b/infra/README.md index 133f6a32..5fd01a90 100644 --- a/infra/README.md +++ b/infra/README.md @@ -7,7 +7,7 @@ infrastructure. 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 +In the future, orchestration 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` @@ -15,8 +15,7 @@ everything will become much cleaner. 2. Add a basic configuration for the machine. These typically go in `infra/machines//default.nix`. You can look at other `fediXXX` VMs to - find inspiration. You probably do not need a `nixos.module` option at this - point. + find inspiration. 2. Add a file for each of those VM's public keys, eg. ``` @@ -59,40 +58,6 @@ everything will become much cleaner. 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 - -```sh -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 - -```sh -nixops4 apply -``` - -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`. diff --git a/infra/common/options.nix b/infra/common/options.nix index 230eea5d..d6abafac 100644 --- a/infra/common/options.nix +++ b/infra/common/options.nix @@ -93,7 +93,7 @@ in description = '' The IP address of the machine, version 4. It will be injected as a value in `networking.interfaces.eth0`, but it will also be used to - communicate with the machine via NixOps4. + communicate with the machine. ''; }; @@ -118,7 +118,7 @@ in description = '' The IP address of the machine, version 6. It will be injected as a value in `networking.interfaces.eth0`, but it will also be used to - communicate with the machine via NixOps4. + communicate with the machine. ''; }; @@ -141,7 +141,7 @@ in hostPublicKey = mkOption { description = '' The ed25519 host public key of the machine. It is used to filter Age - secrets and only keep the relevant ones, and to feed to NixOps4. + secrets and only keep the relevant ones, and to feed to TF. ''; }; diff --git a/keys/README.md b/keys/README.md index 0de57810..b562a3ca 100644 --- a/keys/README.md +++ b/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 diff --git a/launch/README.md b/launch/README.md index c0599bc8..e620556a 100644 --- a/launch/README.md +++ b/launch/README.md @@ -22,6 +22,8 @@ then to initialize, or after updating pins or TF providers: setup ``` +then, one can use the `tofu` CLI. + ## implementing proper documentation TODO. diff --git a/launch/garage.nix b/launch/garage.nix index 559ca37f..1f00644b 100644 --- a/launch/garage.nix +++ b/launch/garage.nix @@ -4,7 +4,7 @@ let ## and will end up in the Nix store. We don't care as they are only ever ## used for testing anyway. ## - ## FIXME: Generate and store in NixOps4's state. + ## FIXME: Generate and store in state. mastodonS3KeyConfig = { pkgs, ... }: { diff --git a/launch/mastodon.nix b/launch/mastodon.nix index 26682f50..6533442e 100644 --- a/launch/mastodon.nix +++ b/launch/mastodon.nix @@ -12,6 +12,6 @@ in mastodon = mastodonS3KeyConfig { inherit pkgs; } // { enable = true; }; - temp.cores = 1; # FIXME: should come from NixOps4 eventually + temp.cores = 1; # FIXME: should come from TF eventually }; } diff --git a/launch/peertube.nix b/launch/peertube.nix index 4124568a..5f523942 100644 --- a/launch/peertube.nix +++ b/launch/peertube.nix @@ -13,7 +13,7 @@ in enable = true; ## NOTE: Only ever used for testing anyway. ## - ## FIXME: Generate and store in NixOps4's state. + ## FIXME: Generate and store in state. secretsFile = pkgs.writeText "secret" "574e093907d1157ac0f8e760a6deb1035402003af5763135bae9cbd6abe32b24"; }; }; diff --git a/panel/src/panel/settings.py b/panel/src/panel/settings.py index 6e7f0619..47b8597e 100644 --- a/panel/src/panel/settings.py +++ b/panel/src/panel/settings.py @@ -241,6 +241,6 @@ if user_settings_file is not None: # PATH to expose to launch button bin_path=env['BIN_PATH'] -# path of the root flake to trigger nixops from, see #94. +# path of the root flake to deploy from # to deploy this should be specified, for dev just use a relative path. repo_dir = env["REPO_DIR"] diff --git a/secrets/README.md b/secrets/README.md index 345bd134..65840925 100644 --- a/secrets/README.md +++ b/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.: diff --git a/services/fediversity/default.nix b/services/fediversity/default.nix index 4f793c03..7e20e0c3 100644 --- a/services/fediversity/default.nix +++ b/services/fediversity/default.nix @@ -31,7 +31,7 @@ in type = types.submodule { options = { cores = mkOption { - description = "number of cores; should be obtained from NixOps4"; + description = "number of cores; should be obtained from TF"; type = types.int; }; diff --git a/services/fediversity/peertube/options.nix b/services/fediversity/peertube/options.nix index 21eaa021..3b99dda1 100644 --- a/services/fediversity/peertube/options.nix +++ b/services/fediversity/peertube/options.nix @@ -20,7 +20,7 @@ in description = '' Internal option — change at your own risk - FIXME: should it be provided by NixOps4? + FIXME: should it be provided by TF? or maybe we should just ask for a main secret from which to derive all the others? ''; };