Adds CNSPRCY service#870
Conversation
ta1hia
force-pushed
the
cnsprcy-service
branch
4 times, most recently
from
fc785bf to
7411eb5
Compare
| description = "CNSPRCY service"; | ||
| wantedBy = [ "multi-user.target" ]; | ||
| after = [ "nss-user-lookup.target" ]; | ||
| preStart = "printf 'n\n${cfg.hostname}\ny\n' | ${pkgs.cnsprcy}/bin/cnspr config init"; |
There was a problem hiding this comment.
So is hostname only used to be printed in the service logs? I don't think that's necessary as options need to be something that change the service's behaviour rather than for debugging. Although we may have options that control the service's own debugging settings.
There was a problem hiding this comment.
@eljamm the cnspr config init command kicks off an interactive prompt for generating the initial CNSPRCY config file and the printf feeds some responses to the prompt, including setting an identifier for the current machine.
i considered constructing the config from scratch during options setting, but i hit the need for interactively generating keys using the cnspr command later down the road anyway so this approach seemed less finicky to me just to get things going. let me know if you think otherwise!
regardless i should at the very least add a comment here!
There was a problem hiding this comment.
@eljamm the cnspr config init command kicks off an interactive prompt for generating the initial CNSPRCY config file and the printf feeds some responses to the prompt, including setting an identifier for the current machine.
Ah, I see. That's a really clever solution. From what I've seen, we can also use the config init flags to directly set the hostname with -n and we can even choose where to put the database file with -p, so we can put it directly under stateDir:
Usage: cnspr config init [OPTIONS]
Options:
-i, --id <ID> ID to use for this node (omit to generate a new ID)
-n, --name <NAME> Name for this node
-p, --path <PATH> Where to store the new database
-h, --help Print help
Don't know how to make the serve command use it, though.
i considered constructing the config from scratch during options setting, but i hit the need for interactively generating keys using the cnspr command later down the road anyway so this approach seemed less finicky to me just to get things going. let me know if you think otherwise!
Yeah, it's fine to dynamically create it like this for now. We can iterate on the module later on and generate the config using options. It should be fairly easy to do since the config file uses the TOML format, which is supported in nixpkgs (also see how it's used in modules).
ta1hia
force-pushed
the
cnsprcy-service
branch
2 times, most recently
from
4d540ea to
22b6e15
Compare
| description = "CNSPRCY service"; | ||
| wantedBy = [ "multi-user.target" ]; | ||
| after = [ "nss-user-lookup.target" ]; | ||
| preStart = "printf 'n\n${cfg.hostname}\ny\n' | ${pkgs.cnsprcy}/bin/cnspr config init"; |
There was a problem hiding this comment.
@eljamm the cnspr config init command kicks off an interactive prompt for generating the initial CNSPRCY config file and the printf feeds some responses to the prompt, including setting an identifier for the current machine.
Ah, I see. That's a really clever solution. From what I've seen, we can also use the config init flags to directly set the hostname with -n and we can even choose where to put the database file with -p, so we can put it directly under stateDir:
Usage: cnspr config init [OPTIONS]
Options:
-i, --id <ID> ID to use for this node (omit to generate a new ID)
-n, --name <NAME> Name for this node
-p, --path <PATH> Where to store the new database
-h, --help Print help
Don't know how to make the serve command use it, though.
i considered constructing the config from scratch during options setting, but i hit the need for interactively generating keys using the cnspr command later down the road anyway so this approach seemed less finicky to me just to get things going. let me know if you think otherwise!
Yeah, it's fine to dynamically create it like this for now. We can iterate on the module later on and generate the config using options. It should be fairly easy to do since the config file uses the TOML format, which is supported in nixpkgs (also see how it's used in modules).
|
@eljamm thank you for the review! Regarding the config initialization/generation discussion, I included a TODO comment with next step suggestions but left the preStart approach as-is for this PR. I applied all the other suggestions you made. lmk if you have any other notes! |
eljamm
left a comment
eljamm
left a comment
There was a problem hiding this comment.
This is looking good. Could you please clean up the history, next? You can either rebase or just git reset main and make new commits.
|
Thank you @eljamm! Just did the git rebase :) |
2 participants
Adds a service module for CNSPRCY and a more fleshed out basic test. I also went ahead and reorganized the CNSPRCY project directory to follow the project template.
ngi-nix/projects#49