From 4813d3bb690eb9980754442025b7ff0f7edf5ddb Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Joakim=20Walld=C3=A9n?= Date: Wed, 8 Jul 2020 12:57:17 +0200 Subject: [PATCH 1/4] Add files to build Nebula as a snap package --- dist/snap/README.md | 58 ++++++++++++++++++++++++++++++++++++++++ dist/snap/hooks/install | 9 +++++++ dist/snap/snapcraft.yaml | 57 +++++++++++++++++++++++++++++++++++++++ 3 files changed, 124 insertions(+) create mode 100644 dist/snap/README.md create mode 100755 dist/snap/hooks/install create mode 100644 dist/snap/snapcraft.yaml diff --git a/dist/snap/README.md b/dist/snap/README.md new file mode 100644 index 000000000..bdfd92821 --- /dev/null +++ b/dist/snap/README.md @@ -0,0 +1,58 @@ +# Nebula Snap package + +This is an atempt at creating a snap package for the Nebula overlay networking tool. + +Current state: + +* Nebula binary is running in strict confinement. For this to work you will have to provide: + * `config.yaml in /var/snap/nebula/config` + * `ca.crt in /var/snap/nebula/certs` + * `nebula-node.crt and nebula-node.key in /var/snap/nebula/certs` +* CA creation and certificate signing is working. However, the name of the produced certs are hardcoded to: + * `ca.crt` + * `ca.key` + * `nebula-node.crt` + * `nebula-node.key` +* Since created certs are placed in `/var/snap/nebula` the cert-functionality needs sudo permissions. Not optimal perhaps, but necessary. + +## Usage + +### Starting Nebula +After placing a config.yaml in `/var/snap/nebula/config` you can either start Nebula manually or use the provided daemon + +See [here](https://arstechnica.com/gadgets/2019/12/how-to-set-up-your-own-nebula-mesh-vpn-step-by-step/) for instructions on the config file. Also, the [Nebula github page](https://github.com/slackhq/nebula) is a good resource. An example config.yaml can be found there. + +#### Start manually: +`sudo nebula` + +You can NOT provide a location for the config.yaml file. It is hardcoded to `/var/snap/nebula/config` + +#### Start the daemon: +`sudo snap start nebula.daemon` + +:warning: There seems to be an issue with the daemon after a reboot **if the address to the lighthouse is stated as a domain name (e g lighthouse.example.com)**. The daemon is supposed to be started automatically on boot and it gets started. However, Nebula does not get a connection to the lighthouse. A **manual restart of the daemon** fixes this: `sudo snap restart nebula.daemon` +This problem does not, however, occur if the ip of the lighthouse is put into the config file. (See [here](https://github.com/slackhq/nebula/issues/206)) + +To check if the daemon started as expected: +`sudo snap logs nebula.daemon` + +or using systemd:s logging facilities: +`sudo journalctl -r -u snap.nebula.daemon.service` + +#### Enable daemon to start at boot +`sudo snap enable nebula.daemon` + +### Certificate creation + +#### Generate a Certificate Authority: + +`sudo nebula.cert-ca -name ` + +This will generate `ca.crt` and `ca.key` +Again, paths are hardcoded to `/var/snap/nebula/certs` so NOT possible to change this at the moment. + +#### Generate node certificates and sign them with the above created CA key: + +`sudo nebula.cert-sign -name -ip ` + +This will generate `nebula-node.crt` and `nebula-node.key` placed in `/var/snap/nebula/certs` diff --git a/dist/snap/hooks/install b/dist/snap/hooks/install new file mode 100755 index 000000000..8f3f7bf73 --- /dev/null +++ b/dist/snap/hooks/install @@ -0,0 +1,9 @@ +#!/bin/sh + +if [ ! -d "$SNAP_COMMON/config" ]; then + echo "Config and certs dirs does not exist. Creating..." + mkdir -p $SNAP_COMMON/certs + mkdir $SNAP_COMMON/config +fi + +exit 0 \ No newline at end of file diff --git a/dist/snap/snapcraft.yaml b/dist/snap/snapcraft.yaml new file mode 100644 index 000000000..d07618015 --- /dev/null +++ b/dist/snap/snapcraft.yaml @@ -0,0 +1,57 @@ +name: nebula +version: v1.2.0 + +summary: A scalable overlay networking tool. + +description: | + Nebula is a scalable overlay networking tool with a focus on performance, simplicity and security. + It lets you seamlessly connect computers anywhere in the world. Nebula is portable, and runs on Linux, OSX, and Windows. + (Also: keep this quiet, but we have an early prototype running on iOS). + It can be used to connect a small number of computers, but is also able to connect tens of thousands of computers. + + Nebula incorporates a number of existing concepts like encryption, security groups, certificates, + and tunneling, and each of those individual pieces existed before Nebula in various forms. + What makes Nebula different to existing offerings is that it brings all of these ideas together, + resulting in a sum that is greater than its individual parts. + + More info on Nebula https://github.com/slackhq/nebula + + For issues and other matters on this snap https://github.com/jwallden/nebula-snap + +grade: stable +confinement: strict + +base: core18 + +parts: + nebula: + plugin: go + source: https://github.com/slackhq/nebula.git + source-tag: $SNAPCRAFT_PROJECT_VERSION + source-type: git + build-packages: + - gcc + +apps: + nebula: + command: bin/nebula -config $SNAP_COMMON/config/config.yaml + plugs: + - network + - network-control + + cert-ca: + command: bin/nebula-cert ca -out-crt $SNAP_COMMON/certs/ca.crt -out-key $SNAP_COMMON/certs/ca.key + + cert-sign: + command: bin/nebula-cert sign -ca-crt $SNAP_COMMON/certs/ca.crt -ca-key $SNAP_COMMON/certs/ca.key -out-crt $SNAP_COMMON/certs/nebula-node.crt -out-key $SNAP_COMMON/certs/nebula-node.key + + daemon: + command: bin/nebula -config $SNAP_COMMON/config/config.yaml + daemon: simple + plugs: + - network + - network-control + +layout: + /etc/nebula: + bind: $SNAP_COMMON \ No newline at end of file From 068c3a09eccc315298860bdaff97badb6f61b110 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Joakim=20Walld=C3=A9n?= Date: Wed, 8 Jul 2020 13:42:08 +0200 Subject: [PATCH 2/4] Moved readme to snap/local to prevent warning message when building --- dist/snap/{ => local}/README.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename dist/snap/{ => local}/README.md (100%) diff --git a/dist/snap/README.md b/dist/snap/local/README.md similarity index 100% rename from dist/snap/README.md rename to dist/snap/local/README.md From a708d012eedd4132b2729cc1018de5361b31b7a1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Joakim=20Walld=C3=A9n?= Date: Wed, 8 Jul 2020 15:02:28 +0200 Subject: [PATCH 3/4] Upon further investigation the snap enable command does not enable the deamon to start att boot. So removed that from readme... --- dist/snap/local/README.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/dist/snap/local/README.md b/dist/snap/local/README.md index bdfd92821..4c3fb7ba8 100644 --- a/dist/snap/local/README.md +++ b/dist/snap/local/README.md @@ -39,9 +39,6 @@ To check if the daemon started as expected: or using systemd:s logging facilities: `sudo journalctl -r -u snap.nebula.daemon.service` -#### Enable daemon to start at boot -`sudo snap enable nebula.daemon` - ### Certificate creation #### Generate a Certificate Authority: From 0c76eaf15724ecdbd8135d6d535291dcf5a7fa31 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Joakim=20Walld=C3=A9n?= Date: Wed, 8 Jul 2020 16:11:41 +0200 Subject: [PATCH 4/4] Updated readme with how to install with --devmode --- dist/snap/local/README.md | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/dist/snap/local/README.md b/dist/snap/local/README.md index 4c3fb7ba8..f2b45a924 100644 --- a/dist/snap/local/README.md +++ b/dist/snap/local/README.md @@ -15,6 +15,10 @@ Current state: * `nebula-node.key` * Since created certs are placed in `/var/snap/nebula` the cert-functionality needs sudo permissions. Not optimal perhaps, but necessary. +To bypass the above restrictions the snap can be installed with `--devmode`, thereby circumventing the sandboxing in place: + +`sudo snap install --devmode nebula` + ## Usage ### Starting Nebula @@ -27,9 +31,6 @@ See [here](https://arstechnica.com/gadgets/2019/12/how-to-set-up-your-own-nebula You can NOT provide a location for the config.yaml file. It is hardcoded to `/var/snap/nebula/config` -#### Start the daemon: -`sudo snap start nebula.daemon` - :warning: There seems to be an issue with the daemon after a reboot **if the address to the lighthouse is stated as a domain name (e g lighthouse.example.com)**. The daemon is supposed to be started automatically on boot and it gets started. However, Nebula does not get a connection to the lighthouse. A **manual restart of the daemon** fixes this: `sudo snap restart nebula.daemon` This problem does not, however, occur if the ip of the lighthouse is put into the config file. (See [here](https://github.com/slackhq/nebula/issues/206)) @@ -39,6 +40,9 @@ To check if the daemon started as expected: or using systemd:s logging facilities: `sudo journalctl -r -u snap.nebula.daemon.service` +#### Enable daemon to start at boot +`sudo snap enable nebula.daemon` + ### Certificate creation #### Generate a Certificate Authority: