New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
yggdrasil: init at 0.3.8 and add service module #63863
Conversation
Make sure to use the email address that is linked to your GitHub account for the commits, then they're linked to your profile account. |
homepage = "https://yggdrasil-network.github.io/"; | ||
license = licenses.lgpl3; | ||
maintainers = with maintainers; [ gazally ]; | ||
platforms = platforms.linux; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
platforms = platforms.linux; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've just force pushed a commit which I think addresses all your issues with the package. Please take a look. I'm still working on the service module.
I just pushed a new version which applies many of systemd's sandboxing features to the yggdrasil service. I've got this running on 4 computers in 2 locations including one Raspberry Pi (aarch64) and have verified that local multicast peering and remote peering both work. |
Great work! Any chance for a NixOS test? |
I also think it's a good idea, so I'll find myself a Perl tutorial and see what I can do. Also, I've decided that it would be better to have |
In this latest push, I have:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-ldflags= | ||
-X github.com/yggdrasil-network/yggdrasil-go/src/yggdrasil.buildVersion=${version} | ||
-X github.com/yggdrasil-network/yggdrasil-go/src/yggdrasil.buildName=${pname} | ||
-s -w |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(I know nothing about the go build system but) Should these flags be something included in buildGoModule
instead? nixpkgs typically produces stripped binaries (excluding the dontStrip
and keepDebugInfo
opt-outs) so unless those flags tend to cause widespread problems it may be worth just doing this for all go packages.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kalbasit I think this is a question for you.
I put those flags in ldflags
to make it match what yggdrasil's build script does. I'm also a go build system newbie so I don't know if the way they have set up their build is unusual or not.
''; | ||
|
||
serviceConfig = { | ||
ExecStart = "${cfg.package}/bin/yggdrasil -useconffile /etc/yggdrasil.conf"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ExecStart = "${cfg.package}/bin/yggdrasil -useconffile /etc/yggdrasil.conf"; | |
ExecStart = "${cfg.package}/bin/yggdrasil -useconffile \${RUNTIME_DIRECTORY}/yggdrasil.conf"; |
I think? Though this can just refer to the config path directly unless it needs to be merged by preStart.
networking.firewall.allowedUDPPorts = mkIf cfg.openMulticastPort [ 9001 ]; | ||
|
||
# Make yggdrasilctl available on the command line. | ||
environment.systemPackages = [ cfg.package ]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay so this one's just a personal wish and probably too opinionated but it'd be neat if we could get this to produce multiple outputs somehow, considering only yggdrasilctl
really needs to be in the environment. They could also just be two separate derivations sharing the same source, not sure what's typical/standard for nixpkgs...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One reason to have yggdrasil in the environment is that yggdrasil -genconf
and yggdrasil -genconf -json
are useful commands to have available when you are working on your yggdrasil configuration.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup that's the main reason to run it from outside of the service, though that seems more what nix run nixpkgs.yggdrasil
is for rather than making a one-time command a permanent part of the user environment - also ideally the nixos module documents all the settings so you wouldn't even have to do that!
so whats the state of this? should we merge this now and work on the multiple instance stuff later? or does someone wants to implement it now? |
Would the multiple instance stuff cause breaking api changes? |
I wouldn't bother treating my comments as anything other than discussion points; I'm particularly interested due to how I use yggdrasil but that's not really relevant - and I can of course always continue to use a stripped-down module. The main areas I pointed out were paths that were a bit strangely hard-coded or inefficient/unnecessary, but I don't have a good understanding of nixos conventions or style regarding whether any of that actually matters (e.g. is polluting /etc bad or do plenty of other modules do it too?) Also, what was the reason for meta.platforms being removed? |
Upstream released 0.3.6 last week and I am hoping to find time this week to update the package.
I'm in the same boat. I observed that other NixOS modules put things in /etc and did so too.
That was an accident. Thanks for catching it. |
yggdrasil 0.3.5 and 0.3.6 now do not build due to a broken dependency, and upstream has marked it wontfix. They're recommending use of their develop branch or waiting for 0.3.7. Before that happened I was running into #64346 while trying to test the package on my mix of machines running 19.03 and unstable, so I guess I'll wait a bit. |
I've just pushed an update of the package to the latest version, 0.3.8. There is now an additional commit which removes DynamicUser from the service module. Yggdrasil works with DynamicUser set on systemd 242, but fails to open its network adapter if DynamicUser is set on systemd 243, and systemd 243 is now in Nixpkgs unstable. I have reported this issue to yggdrasil upstream. |
yggdrasil 0.3.8 does not build on Go 1.13, which is pull request #68135. This will be fixed in yggdrasil 0.3.9. |
soo, I guess we can merge this now and fix the building on go1.13 later? |
yggdrasil 0.3.10 is available now, and presumably includes the go 1.13 fix. |
@@ -2350,6 +2350,11 @@ | |||
github = "gavinrogers"; | |||
name = "Gavin Rogers"; | |||
}; | |||
gazally = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You need to add your github id to this as part of recent requirements.
Merged to master, but |
Motivation for this change
Use an encrypted ipv6 overlay network.
Things done
sandbox
innix.conf
on non-NixOS)nix-shell -p nix-review --run "nix-review wip"
./result/bin/
)nix path-info -S
before and after)See also #63855 by @Lassulus, which has a different derivation for
yggdrasil
which also works with the service module. This is my first attempt to write a Go derivation so I'll be happy to rebase this pull request on #63855 if that is preferable.