Fediversity/simple-nixos-fediverse
Archived
7
1
Fork 2
Code Issues 23 Pull requests 1 Actions Projects Wiki Activity

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
Conversation 0 Commits 11 Files changed 13 +28 -24
7 changed files with 28 additions and 24 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files
Showing only changes of commit fb02afc6c9 - Show all commits

4
fediversity/default.nix
View file

@ -53,5 +53,9 @@ in {
urlFor = bucket: "http://${bucket}.${rootDomainAndPort}";
};
};
pixelfed.domain = "pixelfed.${config.fediversity.domain}";
mastodon.domain = "mastdodon.${config.fediversity.domain}";
peertube.domain = "peertube.${config.fediversity.domain}";
taeer commented 2024-09-17 23:00:52 +02:00
Outdated
Review
Copy link

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.
taeer commented 2024-09-17 23:01:22 +02:00
Outdated
Review
Copy link

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 😆
};
}

9
fediversity/mastodon.nix
View file

@ -63,12 +63,14 @@ lib.mkIf (config.fediversity.enable && config.fediversity.mastodon.enable) {
services.mastodon = {
enable = true;
# TODO: set up a domain name, and a DNS service so that this can run not in a vm
# localDomain = "domain.social";
localDomain = config.fediversity.mastodon.domain;
configureNginx = true;
# 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
# streamingProcesses = 1;
@ -81,4 +83,3 @@ lib.mkIf (config.fediversity.enable && config.fediversity.mastodon.enable) {
# defaults.email = "test@example.com";
};
}

8
fediversity/peertube.nix
View file

@ -53,6 +53,14 @@ lib.mkIf (config.fediversity.enable && config.fediversity.peertube.enable) {
};
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 = {
object_storage = {
enabled = true;

5
fediversity/pixelfed.nix
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 = {
# DANGEROUSLY_SET_FILESYSTEM_DRIVER = "s3";

10
vm/mastodon-vm.nix
View file

@ -14,14 +14,6 @@
};
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 = {
EMAIL_DOMAIN_ALLOWLIST = "example.com";
};
@ -65,7 +57,7 @@
BIND = "0.0.0.0";
# for letter_opener (still doesn't work though)
REMOTE_DEV = "true";
LOCAL_DOMAIN = "mastodon.localhost:8443";
LOCAL_DOMAIN = "${config.fediversity.mastodon.domain}:8443";
};
};

15
vm/peertube-vm.nix
View file

@ -1,9 +1,11 @@
{ pkgs, modulesPath, ... }: {
imports = [ (modulesPath + "/virtualisation/qemu-vm.nix") ];
imports = [
../fediversity
(modulesPath + "/virtualisation/qemu-vm.nix")
];
services.peertube = {
enable = true;
# redirects to localhost, but allows it to have a proper domain name
localDomain = "peertube.localhost";
enableWebHttps = false;
settings = {
listen.hostname = "0.0.0.0";
@ -13,11 +15,6 @@
secrets.secretsFile = pkgs.writeText "secret" ''
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 = [

1
vm/pixelfed-vm.nix
View file

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