[bug#41803] Yggdrasil package and accompanying shepherd service (mesh network)

from: https://yggdrasil-network.github.io/
"Yggdrasil is an early-stage implementation of a fully end-to-end
encrypted IPv6 network."

I spent the last few days packaging it and now it's in a state where I
think it's usable.

The configuration can include private keys, so that part should NOT go
in the operating system config, because it would get stored in the
world-readable Guix store. Nix works around this by merging the
generated config with a JSON file and sending it to yggdrasil over its
stdin.

I chose not to do that because I couldn't figure out how to open a
service's stdin and because I think the way I did it is much more
elegant in the long run.

The package is lightly patched to take not one but two config files,
and it simply merges them internally. The patch is completely backwards
compatible and unobtrusive. It took me about an hour to write and debug
and most of that was just figuring out Go's syntax and type system.
I will try to get upstream to accept it, or implement similar
functionality.

Still TODO:
documenting the service as an info page.

The gist of using it is:
1. look at example operating system
2. see yggdrasil -genconf -json for config options
(3.) optional: save output as /etc/yggdrasil-secret.conf
(4.) chmod 600 /etc/yggdrasil-secret.conf
(5.) delete everything but the signing and encryption keys
6. add peers as needed, or set autoconf? to #t to connect through a
local peer

It seems to work fine. I could connect to open peers from one
machine and another one could auto-configure itself to connect through
the first one over the LAN. It's pretty nifty.

Bump.

Could someone look at this?

Le Thu, 11 Jun 2020 15:56:56 +0200,
raingloom <raingloom@riseup.net> a écrit :

> from: https://yggdrasil-network.github.io/
> "Yggdrasil is an early-stage implementation of a fully end-to-end
> encrypted IPv6 network."
> 
> I spent the last few days packaging it and now it's in a state where I
> think it's usable.
> 
> The configuration can include private keys, so that part should NOT go
> in the operating system config, because it would get stored in the
> world-readable Guix store. Nix works around this by merging the
> generated config with a JSON file and sending it to yggdrasil over its
> stdin.
> 
> I chose not to do that because I couldn't figure out how to open a
> service's stdin and because I think the way I did it is much more
> elegant in the long run.
> 
> The package is lightly patched to take not one but two config files,
> and it simply merges them internally. The patch is completely
> backwards compatible and unobtrusive. It took me about an hour to
> write and debug and most of that was just figuring out Go's syntax
> and type system. I will try to get upstream to accept it, or
> implement similar functionality.
> 
> Still TODO:
> documenting the service as an info page.
> 
> The gist of using it is:
> 1. look at example operating system
> 2. see yggdrasil -genconf -json for config options
> (3.) optional: save output as /etc/yggdrasil-secret.conf
> (4.) chmod 600 /etc/yggdrasil-secret.conf
> (5.) delete everything but the signing and encryption keys
> 6. add peers as needed, or set autoconf? to #t to connect through a
> local peer
> 
> It seems to work fine. I could connect to open peers from one
> machine and another one could auto-configure itself to connect through
> the first one over the LAN. It's pretty nifty.

Hi,

this is more of a quick review.

First patch LGTM.

You should split every package you add in the second patch in separate
patches. Also the commit message should say "new variable", no need to
say it's public.

You left a comment about the license for go-github-com-gologme-log.
Have you contacted upstream to tell them about that, what was their
reaction? I think the fact that the readme says bsd implies the
intention is that it is free software, but better safe than sorry.

Otherwise, these packages lgtm.

In the third patch again, the commit message should say "new variable".
You should not use the past tense either, so "Add it".

Is the licenes lgpl3, or lgpl3+?

Not a go programmer, so I'm not reading the patch, but I'm trusting you
that it works :)

For the fourth patch, I don't think you need to list new private
variables in the commit message, nor new dependencies. Only list public
variables, as "New variables".

As you noted, could you add something about it to the manual?

In the system example, should Yggdrasil really be installed in the
system profile? If so, I think you can add a profile-service-type
extension to the service so the package is automatically available. Then
you don't need to specify the package in the os configuration, and it
ensures you install the same package (declared in the service
configuration) for the service and in the system.

Thanks for working on this!

Hi,

I went ahead and pushed your first four patches with changes. I'll need
you to work a bit more before I can push the rest.

I've added a copyright line for you in golang.scm.

For the rest of the packages, could you split all your patches into
one patch per package?  For each package, please run "guix lint" and
fix any issue (except for archival, you can't do anything about it).
This includes: using (file-name (git-file-name name version)) inside
the origin record, making sure the synopsis doesn't start with "A", and
the description ends with a full stop.

I also changed you commit messages: don't include the version number
for added packages and add a full stop at the end of messages.

For yggdrasil, please grep for dist_PATCH_DATA in the git log, you'll
find examples of good commit messages :)

For the service, changes to the documentation are usually made in the
same patch, so could you please merge your last three patches? I don't
know if we can use guile-json directly in a service definition without
causing troubles for people who have different versions of guile-json
in their profile already. I'll have to ask people who are more
knowledgeable than me!

To chown the socket, you'll need an activation service type (if the
socket survives restarts of yggdrasil), or to change the start action
of the shepherd service type.

Your changes to the documentation look good, but incomplete.

Could you rebase and send updated patches for the rest of this series?

Thank you!