nixos-test-pixelfed-wip #22

Merged
taeer merged 11 commits from nixos-test-pixelfed-wip into main 2024-09-20 17:47:21 +02:00
7 changed files with 28 additions and 24 deletions
Showing only changes of commit fb02afc6c9 - Show all commits

View file

@ -53,5 +53,9 @@ in {
urlFor = bucket: "http://${bucket}.${rootDomainAndPort}"; urlFor = bucket: "http://${bucket}.${rootDomainAndPort}";
}; };
}; };
pixelfed.domain = "pixelfed.${config.fediversity.domain}";
mastodon.domain = "mastdodon.${config.fediversity.domain}";
peertube.domain = "peertube.${config.fediversity.domain}";
Outdated
Review

there's a style decision here between

  1. defining our own top-level e.g. fediversity.pixelfed.domain, and
  2. referring to e.g. services.pixelfed.domain everywhere.

(1) has the advantage of grouping everything in one place and under one naming scheme, as opposed to needing to know that e.g. mastodon's is under services.mastodon.localDomain instead.
It has the disadvantage of having basically a duplicate option, that really should always be exactly identical to another option. Now if someone sets services.pixelfed.domain somewhere, it won't get propagated to all the other places that use it, because they refer to fediversity.pixelfed.domain. It's also hard to know where to stop with option (1), since you could recategorize all the options under some different scheme at the top level, which might be somewhat more consistent.

I tend to go with option (2), but in a tightly controlled module like we're planning, I don't think it's objectively the right choice, just a style difference as I said.


In the case of the garage options above, we sort of have the same question. But in that case there's information we can't easily get out of the options that are available in services.garage (e.g. just the port itself), so I think it does make sense to define our own options.

Though we should probably discuss with the maintainer of the nixpkgs module if it makes sense to upstream those changes.

there's a style decision here between 1. defining our own top-level e.g. `fediversity.pixelfed.domain`, and 2. referring to e.g. `services.pixelfed.domain` everywhere. (1) has the advantage of grouping everything in one place and under one naming scheme, as opposed to needing to know that e.g. mastodon's is under `services.mastodon.localDomain` instead. It has the disadvantage of having basically a duplicate option, that really should always be exactly identical to another option. Now if someone sets `services.pixelfed.domain` somewhere, it won't get propagated to all the other places that use it, because they refer to `fediversity.pixelfed.domain`. It's also hard to know where to stop with option (1), since you could recategorize all the options under some different scheme at the top level, which might be somewhat more consistent. I tend to go with option (2), but in a tightly controlled module like we're planning, I don't think it's objectively the right choice, just a style difference as I said. --- In the case of the `garage` options above, we sort of have the same question. But in that case there's information we can't easily get out of the options that are available in `services.garage` (e.g. just the port itself), so I think it does make sense to define our own options. Though we should probably discuss with the maintainer of the nixpkgs module if it makes sense to upstream those changes.
Outdated
Review

Though if you are going to define fediversity.pixelfed.domain, it does have to be declared as an option somewhere 😆

Though if you are going to define `fediversity.pixelfed.domain`, it does have to be declared as an option somewhere 😆
}; };
} }

View file

@ -63,12 +63,14 @@ lib.mkIf (config.fediversity.enable && config.fediversity.mastodon.enable) {
services.mastodon = { services.mastodon = {
enable = true; enable = true;
# TODO: set up a domain name, and a DNS service so that this can run not in a vm localDomain = config.fediversity.mastodon.domain;
# localDomain = "domain.social";
configureNginx = true; configureNginx = true;
# TODO: configure a mailserver so this works # TODO: configure a mailserver so this works
# smtp.fromAddress = "mastodon@domain.social"; smtp = {
fromAddress = "noreply@${config.fediversity.mastodon.domain}";
createLocally = false;
};
# TODO: this is hardware-dependent. let's figure it out when we have hardware # TODO: this is hardware-dependent. let's figure it out when we have hardware
# streamingProcesses = 1; # streamingProcesses = 1;
@ -81,4 +83,3 @@ lib.mkIf (config.fediversity.enable && config.fediversity.mastodon.enable) {
# defaults.email = "test@example.com"; # defaults.email = "test@example.com";
}; };
} }

View file

@ -53,6 +53,14 @@ lib.mkIf (config.fediversity.enable && config.fediversity.peertube.enable) {
}; };
services.peertube = { services.peertube = {
enable = true;
localDomain = config.fediversity.peertube.domain;
# TODO: in most of nixpkgs, these are true by default. upstream that unless there's a good reason not to.
redis.createLocally = true;
database.createLocally = true;
configureNginx = true;
settings = { settings = {
object_storage = { object_storage = {
enabled = true; enabled = true;

View file

@ -35,7 +35,10 @@ lib.mkIf (config.fediversity.enable && config.fediversity.pixelfed.enable) {
}; };
}; };
services.pixelfed.enable = true; services.pixelfed = {
enable = true;
domain = config.fediversity.pixelfed.domain;
};
services.pixelfed.settings = { services.pixelfed.settings = {
# DANGEROUSLY_SET_FILESYSTEM_DRIVER = "s3"; # DANGEROUSLY_SET_FILESYSTEM_DRIVER = "s3";

View file

@ -14,14 +14,6 @@
}; };
services.mastodon = { services.mastodon = {
# redirects to localhost, but allows it to have a proper domain name
localDomain = "mastodon.localhost";
smtp = {
fromAddress = "mastodon@mastodon.localhost";
createLocally = false;
};
extraConfig = { extraConfig = {
EMAIL_DOMAIN_ALLOWLIST = "example.com"; EMAIL_DOMAIN_ALLOWLIST = "example.com";
}; };
@ -65,7 +57,7 @@
BIND = "0.0.0.0"; BIND = "0.0.0.0";
# for letter_opener (still doesn't work though) # for letter_opener (still doesn't work though)
REMOTE_DEV = "true"; REMOTE_DEV = "true";
LOCAL_DOMAIN = "mastodon.localhost:8443"; LOCAL_DOMAIN = "${config.fediversity.mastodon.domain}:8443";
}; };
}; };

View file

@ -1,9 +1,11 @@
{ pkgs, modulesPath, ... }: { { pkgs, modulesPath, ... }: {
imports = [ (modulesPath + "/virtualisation/qemu-vm.nix") ];
imports = [
../fediversity
(modulesPath + "/virtualisation/qemu-vm.nix")
];
services.peertube = { services.peertube = {
enable = true;
# redirects to localhost, but allows it to have a proper domain name
localDomain = "peertube.localhost";
enableWebHttps = false; enableWebHttps = false;
settings = { settings = {
listen.hostname = "0.0.0.0"; listen.hostname = "0.0.0.0";
@ -13,11 +15,6 @@
secrets.secretsFile = pkgs.writeText "secret" '' secrets.secretsFile = pkgs.writeText "secret" ''
574e093907d1157ac0f8e760a6deb1035402003af5763135bae9cbd6abe32b24 574e093907d1157ac0f8e760a6deb1035402003af5763135bae9cbd6abe32b24
''; '';
# TODO: in most of nixpkgs, these are true by default. upstream that unless there's a good reason not to.
redis.createLocally = true;
database.createLocally = true;
configureNginx = true;
}; };
virtualisation.forwardPorts = [ virtualisation.forwardPorts = [

View file

@ -13,7 +13,6 @@
networking.firewall.allowedTCPPorts = [ 80 ]; networking.firewall.allowedTCPPorts = [ 80 ];
services.pixelfed = { services.pixelfed = {
domain = "pixelfed.localhost";
# TODO: secrets management! # TODO: secrets management!
secretFile = pkgs.writeText "secrets.env" '' secretFile = pkgs.writeText "secrets.env" ''
APP_KEY=adKK9EcY8Hcj3PLU7rzG9rJ6KKTOtYfA APP_KEY=adKK9EcY8Hcj3PLU7rzG9rJ6KKTOtYfA