@ju1m thanks a lot for picking this up. I am actually in Berlin with the Radicle team this week, which is why I couldn't review this today. Hopefully tomorrow! :)

How about splitting into more packages? The web stuff is not necessary to run and administer a node. I have sketched that here: #309050 (comment)

How about splitting into more packages? The web stuff is not necessary to run and administer a node. I have sketched that here: #309050 (comment)

Sure, though not being used to Rust packaging I went to the most expedient in this PR. I think the splitting can go in another PR, I'll amend this PR to introduce services.radicle.httpd.{enable,package}.

@ju1m thanks a lot for picking this up. I am actually in Berlin with the Radicle team this week, which is why I couldn't review this today. Hopefully tomorrow! :)

@lorenzleutgeb, no hurry, thanks to the team for making such a promising tool, and thanks to you for pushing its integration into Nixpkgs, that's what caught my attention over it.
I'm not sure I'll commit to using radicle yet due to the "high" level of network I/O and CPU cycles it seems to require to run in sync with the public peers. But the tool is young, so maybe it will get lightweight enough for me at some point. In any case I'm adding myself as a maintainer for now to keep being notified if some help is needed in the future for that service.

Sure, though not being used to Rust packaging I went to the most expedient in this PR. I think the splitting can go in another PR, I'll amend this PR to introduce services.radicle.httpd.{enable,package}.

There even is talk to move radicle-httpd (and I guess also rad-web) into a separate repo. When that happens, at the latest, the justification for the split would be more obvious. I wanted to anticipate this, and keep the changes to Nix users at a minimum (fomr radicle-cli to radicle-node, and then to radicle-web is a bit noisy).

Then there's also the question whether it should be services.radicle-{httpd,node}.* or services.radicle.{httpd,node}.*. I don't know whether there is a clear policy. For example, there is services.buildbot-{master,worker} but also services.salt.{master,minion}.

@lorenzleutgeb, no hurry, thanks to the team for making such a promising tool, and thanks to you for pushing its integration into Nixpkgs, that's what caught my attention over it. I'm not sure I'll commit to using radicle yet due to the "high" level of network I/O and CPU cycles it seems to require to run in sync with the public peers. But the tool is young, so maybe it will get lightweight enough for me at some point. In any case I'm adding myself as a maintainer for now to keep being notified if some help is needed in the future for that service.

Sweet! Yeah, there was some breakage in the protocol recently, and a nodes are now announcing the version they are running, to make upgrades smoother.

Note that high I/O and CPU is being worked on:

• https://radicle.zulipchat.com/#narrow/stream/369873-support/topic/high.20CPU.20use.20while.20disconnected.20from.20network
• https://app.radicle.xyz/nodes/seed.radicle.xyz/rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5/patches/c354a9e6792bf3aa42c42e6ba7ee628b04c802ae

In my module, I implemented a check to catch invalid configuration in settings. Any particular reason not to have this?

https://github.com/radicle-nix/radicle-nix/blob/9c1adbb7d85d12df6236e006c12ac089cb18341b/os/module/services/radicle.nix#L34-L48

Here with a more obviously useless key:

https://github.com/radicle-nix/radicle-nix/blob/9c1adbb7d85d12df6236e006c12ac089cb18341b/hm/module/programs/radicle.nix#L45-L59

• Rebase after the merge of radicle-httpd: init at 0.11.0 #321580

• Drop DynamicUser= for the sake of clarity, since the same level of systemd-analyze security can be achieved without it. Note that therefore the state directory is no longer /var/lib/private/radicle but /var/lib/radicle.

• Rebase after conflict in nixos/doc/manual/release-notes/rl-2411.section.md following the merge of 28512d1

I'd really like to see this merged. Any ideas on how we can get someone with write permissions on board? @SuperSandro2000 could you do another review or merge please? 😃

I just spent a lot of time debugging what came down to:

   services.radicle = {
     enable = true;
     privateKeyFile = "/run/secrets/radicle/seednode";
-    publicKeyFile = "/run/secrets/radicle/seednode-pub";
+    publicKeyFile = "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAINIxyouLgGi/RGEeBycs47NuntkAWn6ZAynImFVYsGN6 dpc@ren";
     httpd.enable = true;
     httpd.nginx.serverName = "radicle.dpc.pw";
   };

Without this fix, the service would fail with:

Jul 24 18:16:55 hetz radicle-httpd[600666]: 2024-07-24T18:16:55.284465Z ERROR Fatal: ssh keygen: length invalid: length invalid: length invalid

apparently because it was trying to parse the path to the pubkey file, instead of its content.

It seems like a gotcha or a bug that privateKeyFile and publicKeyFile are named the same way, but have different semantics. No idea if it's some NixOS convention or not, just reporting for reference, search engines, etc. @ju1m @SuperSandro2000

@dpc, I'm sorry this bug made you loose your time.
Both path and str types should have worked because services.radicle currently uses:

"${if isPath cfg.publicKeyFile then cfg.publicKeyFile else pkgs.writeText "radicle.pub" cfg.publicKeyFile}:${env.RAD_HOME}/keys/radicle.pub"

But using isPath is wrong here, because it does not consider "/run/secrets/radicle/seednode-pub" as a path:

$ nix repl
nix-repl> builtins.isPath "/run/secrets/radicle/seednode-pub"
false
nix-repl> builtins.isPath /run/secrets/radicle/seednode-pub  
true

Instead, types.path.check should have been used to also consider as a path any string prefixed by "/":

check = x: isStringLike x && builtins.substring 0 1 (toString x) == "/";

See #329731 for a fix.

I'm happy to help improve it. :)

BTW. Is there any existing Wiki page/guide? After getting my node set up, I have no idea how to get it to do things for me (like seed my repos).

@dpc, you can rad-system seed $rid,
where rad-system is installed by services.radicle to execute rad inside the namespaces of radicle-node.service,
and $rid is given by rad . in your git repository.

Had connectivity issues because the app wouldn't bind to ipv6.

Setting:

+    node.listenAddress = "[::0]";

fixed it.

BTW. It would be great if:

+    settings = {
+        "web" = {
+          "pinned" = {
+            "repositories" = [
+              "rad:z2eeB9LF8fDNJQaEcvAWxQmU7h2PG"
+            ];
+          };
+        };
+    };

could just have its own key. What do you think?

could just have its own key. What do you think?

@dpc, you mean to add an alias to settings.web.pinned.repositories? what problem would it solve?
Note that we previously reverted from type-checking settings.

@ju1m I wish i could just:

  services.radicle = {
    enable = true;
    # ..
    pinned = [ "rad:z2eeB9LF8fDNJQaEcvAWxQmU7h2PG" ];
  };

as it seems rather common need, and having to figure out and mimick config-file structure
seems like an unnecessary chore. :D

@dpc, you're raising a discoverability concern on NixOS but I will argue that it belongs to Radicle. Using settings and its config-mimicking, instead of inventing ad-hoc options like NixOS used to do before the settings framework existed, is what enables NixOS to let the burden of discoverability/maintainability onto Radicle's documentation/code where it's best addressed. Yet, in NixOS, we can address the common need you raised to set pinned repositories by setting an example for settings.
See https://github.com/NixOS/nixpkgs/pull/330021/files#diff-47ed1acddaad94538b9ee7995ffa8d7cc1376f9667350acee9cec912cec6a3bfR183

Thanks! Fine with me.