Difference between revisions of "Mesh/Makenode"
(moves more sections from WalkThrough page) |
|||
(3 intermediate revisions by 2 users not shown) | |||
Line 13: | Line 13: | ||
The story goes that makenode was created to solve a few problems with the sudowrt firmware. Mainly, it was much quicker to implement changes in makenode rather than rebuilding the firmware. This way patches could be rapidly deployed with out a full rebuild and reflash of the firmware (however this is ignoring the existence of a lot of already "made nodes"). This use case of triaging patches before integrating them into a new build of the firmware devolved into using makenode to do perform almost all node configurations. While these configurations are mostly "per-node" | The story goes that makenode was created to solve a few problems with the sudowrt firmware. Mainly, it was much quicker to implement changes in makenode rather than rebuilding the firmware. This way patches could be rapidly deployed with out a full rebuild and reflash of the firmware (however this is ignoring the existence of a lot of already "made nodes"). This use case of triaging patches before integrating them into a new build of the firmware devolved into using makenode to do perform almost all node configurations. While these configurations are mostly "per-node" | ||
1. To retrieve an IP from secrets.peoplesopen.net (our meshnode-database) and then copy it into a lot of config files | 1. To retrieve an IP from secrets.peoplesopen.net (our meshnode-database) and then copy it into a lot of config files | ||
2. To set a root password other per-node configs, such as hostname, private SSID, etc. | 2. To set a root password other per-node configs, such as hostname, private SSID, etc. | ||
3. To perform hardware detection to select which config files to copy onto node | 3. To perform hardware detection to select which config files to copy onto node | ||
== theory for deprecation == | == theory for deprecation == | ||
While makenode does work, it presents a large barrier to inclusion (e.g. doesn't work on Windows, have to be relatively comfortable with terminal) as well as limiting our ability to quickly configure "blank" routers that can be handed out to anyone. | While makenode does work, it presents a large barrier to inclusion (e.g. doesn't work on Windows, have to be relatively comfortable with terminal) as well as limiting our ability to quickly configure "blank" routers that can be handed out to anyone. Instead, it would be preferable to have a version of the firmware that requires "zero configurations", aka zeroconf. To do this, we first need to address the three main reasons for implementation. | ||
1. retrieving a mesh IP: | |||
* this can be done shortly after boot by making a POST request to secrets.peoplesopen.net using curl, the IP can then be then be parse from the json response and inserted into the correct config files using OpenWRT's build UCI configuration tool. | |||
2. setting a root password: | |||
* the quick (but insecure) solution is to set a default root password. The better solution is to limit the access of the root user to only the hardwired interface and/or disable the password after a certain period of time and/or on second boot | |||
* any other non-security-related, per-node configurations could and should be set through the admin dashboard | |||
3. hardware detection: | |||
* an example of this can already be seen for extender nodes in the [https://github.com/paidforby/sudowrt-firmware/blob/master/files_extender-node/etc/uci-defaults/99_wireless 99_wireless script] | |||
* at boot OpenWrt needs to detect number of antennas and ports, | |||
* currently we find ourselves flashing almost exclusively one model of router | |||
== What | However, before tackling these concerns, all the configurations made by makenode must be moved back to the firmware and adapted to be somewhat configurable. To do this, we will create a uci-defaults script that does exactly what make makenode previously did...copy a lot of IP addresses into different config files. | ||
== What does makenode change? == | |||
=== configs/templates/files/opt/mesh/ === | === configs/templates/files/opt/mesh/ === | ||
Line 59: | Line 74: | ||
dnsmasq.conf -> excepts interfaces l2tp0, adhoc0, eth0, why? | dnsmasq.conf -> excepts interfaces l2tp0, adhoc0, eth0, why? | ||
= Original Makenode Instructions = | |||
This section was migrated from [Mesh/WalkThrough]. | |||
=== Install Dependencies === | |||
You first will need to install the dependencies for [https://github.com/sudomesh/makenode makenode]. | |||
==== Linux ==== | |||
If you are working with a fresh installation of one of the operating systems listed in the compatibility checklist, you will need to install a few pieces of software. | |||
To install them, open your terminal and enter the following commands. | |||
sudo apt update | |||
sudo apt install curl git dropbear | |||
curl -o- ht<span>tps://</span>raw.githubusercontent.com/creationix/nvm/v0.33.2/install.sh | bash | |||
export NVM_DIR="$HOME/.nvm" | |||
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" # or you can close and reopen your terminal before using nvm | |||
nvm install 7.10 | |||
===== OS Compatibility checklist ===== | |||
{| class="wikitable" | |||
! OS !! Compatible !! Link to ISO !! Notes | |||
|- | |||
| Ubuntu 16.04 LTS || yes || http://releases.ubuntu.com/16.04/ || | |||
|- | |||
| Ubuntu 14.04 LTS || please verify || http://releases.ubuntu.com/14.04/ || | |||
|- | |||
| Debian 9.3 Stretch || yes || https://www.debian.org/distrib/ || | |||
|- | |||
| Debian 8.1 Jessie || yes || https://www.debian.org/releases/jessie/debian-installer/ || | |||
|- | |||
| Arch Linux || yes || https://www.archlinux.org/download/ || you may have to build dropbear from [https://github.com/mkj/dropbear source] | |||
|- | |||
|} | |||
==== Mac ==== | |||
Install the [http://brew.sh/ Homebrew] package manager, then install the required binaries. | |||
brew install nodejs | |||
brew install git | |||
brew install npm | |||
brew install dropbear | |||
brew install gnu-tar | |||
brew install fakeroot | |||
brew install iproute2mac | |||
==== Windows 10 (Experimental)==== | |||
'''Note: Windows is not currently recommened for setting up a node due to Dropbear not supporting Windows. What follows is instructions for Windows Subsytem for Linux.''' | |||
Due to Dropbear requirements your best bet is to use [[Windows Subsystem for Linux]] (WSL) and follow the instructions for Linux with additional instructions to get WSL set up. Follow the instructions for [https://docs.microsoft.com/en-us/windows/wsl/install-win10 installing] WSL on your Windows 10 PC. For now Ubuntu has been tested and appears to work. SUSE and other WSL flavors have not been tested. | |||
Once WSL is installed. Install dependencies (assuming Ubuntu). | |||
sudo apt update | |||
sudo apt install python | |||
sudo apt install make | |||
sudo apt install build-essential | |||
WSL doesn't fully support SYSV IPC so fakeroot needs to be rebuilt using tcp. | |||
sudo update-alternatives --set fakeroot /usr/bin/fakeroot-tcp | |||
Follow Linux [[Mesh/WalkThrough#Linux | instructions]] for installing Dropbear and dependencies. | |||
=== Install and run makenode === | |||
From your terminal, run the following: | |||
git clone https://github.com/sudomesh/makenode -b 0.0.1 | |||
cd makenode | |||
npm install | |||
cp settings.js.example settings.js | |||
The default settings in <tt>settings.js</tt> should suffice in most cases, but if you need to make changes, do them in <tt>settings.js</tt>. | |||
Make sure the Ethernet cable is connected to the 4th port on the router, and that your computer has a working internet connection (e.g. over WiFi). From a terminal, you should be able to ping the home node at 172.22.0.1 <b>and</b> arbitrary websites like github.com. | |||
Once your network configuration is refreshed, use the following command to run the script and configure your node: | |||
./makenode.js | |||
Now the configuration wizard will ask you a number of questions: | |||
* "enter valid hostname" - name of the box, will only be seen when you SSH into the router - For info on what constitutes a valid hostname, see: [http://stackoverflow.com/questions/3523028/valid-characters-of-a-hostname valid characters of a hostname] | |||
* "max share upstream bandwidth" - how much of your home network upstream bandwidth you wish to share with the mesh network, measured in kbps (kilobits per second). So if you'd like to share 10mbps (megabits per second) enter "10000" or if you want to share 256kbps (kilobits per second) enter "256". You may want to run a [http://www.dslreports.com/speedtest speed test] to find out how much bandwidth you have and determine how much you want to share. | |||
* "max share downstream bandwidth" - how much of your home network upstream bandwidth you wish to share with the mesh network - eg. "512" would share 512 kbps | |||
* "admin user password" - used to log into the admin dashboard where you can modify some settings at http://172.22.0.1 (if on wired connection) or http://172.30.0.1 (if on private wifi network) | |||
* "root user password" - used to SSH into the router so you modify files and manually configure your router. Make sure that your root password is strong! If you don't enter a root password, a strong one will be generated and will be logged to screen. It's generally preferable to not use the root password at all and instead add an ssh key to the device, ssh keys are stored in /etc/dropbear/authorized_keys. | |||
* "wifi transmit power" - set this to 23 dBm (which is equivalent to 200 milliwatts) | |||
* "private wifi SSID" - name of the private wireless network that can be used to administer this router. It will be publicly visible so pick something amusing or descriptive. | |||
* "private wifi password" - password for the private wireless network named in the previous step. It's the one you'll want to give to friends, so come up with something amusing or memorable. Note: it must be at least 8 characters long. | |||
* "operator name" - name that the network admins can associate with the node - so use a unique name like your first name or location name | |||
* "Operator email" - email that network admis can contact you at | |||
* "Expected node address (optional)" - address location of node | |||
= Testing = | |||
After you're finished with the flashing and configuration, your home node should be available for connections via your private WiFi SSID. Additionally the public SSID 'peoplesopen.net' will be available. It should also be populated on the [https://peoplesopen.herokuapp.com monitor]! | |||
A third interface named 'pplsopen.net-node2node' will be detectable as well. This is the interface used for the nodes to mesh with each other. | |||
At this point you're setup. For more information on using your node, such as accessing the web-based management interface, see [[Home and extender nodes#Home_nodes|Home node info]] | |||
For more technical details on the internals of the home node, see the [[Mesh/Technical_Overview]] | |||
For more in depth testing procedures, see our [https://github.com/sudomesh/babeld-lab/blob/master/operator_manual.md mesh node operator's manual]. | |||
= Troubleshooting = | |||
If you get the error "no such file or directory", open a new terminal and run this command to ensure that <tt>node</tt> points to your NodeJS executable: | |||
sudo ln -s nodejs node | |||
In the new terminal, return to the 'makenode' source code directory and try again: | |||
npm install | |||
./makenode.js |
Latest revision as of 22:04, 13 November 2019
makenode is a script that finishes the configuration for People's Open nodes flashed with the sudowrt firmware, see https://github.com/sudomesh/makenode.
This script is in the process of being deprecated, below is ongoing documentation this deprecation.
"Early alpha status. Things may break."
makenode theory
There are two interconnected theories that govern the implementation, usage, and deprecation of the makenode script
theory for implementation
The story goes that makenode was created to solve a few problems with the sudowrt firmware. Mainly, it was much quicker to implement changes in makenode rather than rebuilding the firmware. This way patches could be rapidly deployed with out a full rebuild and reflash of the firmware (however this is ignoring the existence of a lot of already "made nodes"). This use case of triaging patches before integrating them into a new build of the firmware devolved into using makenode to do perform almost all node configurations. While these configurations are mostly "per-node"
1. To retrieve an IP from secrets.peoplesopen.net (our meshnode-database) and then copy it into a lot of config files
2. To set a root password other per-node configs, such as hostname, private SSID, etc.
3. To perform hardware detection to select which config files to copy onto node
theory for deprecation
While makenode does work, it presents a large barrier to inclusion (e.g. doesn't work on Windows, have to be relatively comfortable with terminal) as well as limiting our ability to quickly configure "blank" routers that can be handed out to anyone. Instead, it would be preferable to have a version of the firmware that requires "zero configurations", aka zeroconf. To do this, we first need to address the three main reasons for implementation.
1. retrieving a mesh IP:
- this can be done shortly after boot by making a POST request to secrets.peoplesopen.net using curl, the IP can then be then be parse from the json response and inserted into the correct config files using OpenWRT's build UCI configuration tool.
2. setting a root password:
- the quick (but insecure) solution is to set a default root password. The better solution is to limit the access of the root user to only the hardwired interface and/or disable the password after a certain period of time and/or on second boot
- any other non-security-related, per-node configurations could and should be set through the admin dashboard
3. hardware detection:
- an example of this can already be seen for extender nodes in the 99_wireless script
- at boot OpenWrt needs to detect number of antennas and ports,
- currently we find ourselves flashing almost exclusively one model of router
However, before tackling these concerns, all the configurations made by makenode must be moved back to the firmware and adapted to be somewhat configurable. To do this, we will create a uci-defaults script that does exactly what make makenode previously did...copy a lot of IP addresses into different config files.
What does makenode change?
configs/templates/files/opt/mesh/
- tunnelhook -> callback called by config_load tunneldigger
configs/templates/files/etc/
dropbear/
- authorized keys, i.e. adds developer keys -> remove? or add more people? opt-in option in dashboard
config/
- dhcp -> dnsmasq, mesh pool, private pool
- network -> loopback, lan, adhoc, open, priv
- notdhcpserver -> extender node static ips
- polipo -> daemonised caching web proxy
- rpcd, -> sets ubus username and pass (from where?)
- snmpd -> managment/monitoring, pulls in operator email/name, presumably from makenode.js
- system -> sets hostname and log ip? from makenode.js?
- tunneldigger- > sets tunnel broker ip, l2tp interface, upstream, downstream bandwidth (related to bug #2), and tunnel hook callback script
- uhttpd -> http server, sets index directory, ubus, cgi-bin, locale
init.d/
- log -> copied from openwrt? purpose?
iproute2/
- rt_tables -> moved to makenode by MaxB, unclear purpose? reverses values for ...?
babeld.conf -> allows babel to run on l2tp, adhoc, and open interface, (could address bug #13 here)
banner -> presents version info, move back to firmware
dnsmasq.conf -> excepts interfaces l2tp0, adhoc0, eth0, why?
Original Makenode Instructions
This section was migrated from [Mesh/WalkThrough].
Install Dependencies
You first will need to install the dependencies for makenode.
Linux
If you are working with a fresh installation of one of the operating systems listed in the compatibility checklist, you will need to install a few pieces of software. To install them, open your terminal and enter the following commands.
sudo apt update
sudo apt install curl git dropbear
curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.2/install.sh | bash
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" # or you can close and reopen your terminal before using nvm
nvm install 7.10
OS Compatibility checklist
OS | Compatible | Link to ISO | Notes |
---|---|---|---|
Ubuntu 16.04 LTS | yes | http://releases.ubuntu.com/16.04/ | |
Ubuntu 14.04 LTS | please verify | http://releases.ubuntu.com/14.04/ | |
Debian 9.3 Stretch | yes | https://www.debian.org/distrib/ | |
Debian 8.1 Jessie | yes | https://www.debian.org/releases/jessie/debian-installer/ | |
Arch Linux | yes | https://www.archlinux.org/download/ | you may have to build dropbear from source |
Mac
Install the Homebrew package manager, then install the required binaries.
brew install nodejs brew install git brew install npm brew install dropbear brew install gnu-tar brew install fakeroot brew install iproute2mac
Windows 10 (Experimental)
Note: Windows is not currently recommened for setting up a node due to Dropbear not supporting Windows. What follows is instructions for Windows Subsytem for Linux.
Due to Dropbear requirements your best bet is to use Windows Subsystem for Linux (WSL) and follow the instructions for Linux with additional instructions to get WSL set up. Follow the instructions for installing WSL on your Windows 10 PC. For now Ubuntu has been tested and appears to work. SUSE and other WSL flavors have not been tested.
Once WSL is installed. Install dependencies (assuming Ubuntu).
sudo apt update sudo apt install python sudo apt install make sudo apt install build-essential
WSL doesn't fully support SYSV IPC so fakeroot needs to be rebuilt using tcp.
sudo update-alternatives --set fakeroot /usr/bin/fakeroot-tcp
Follow Linux instructions for installing Dropbear and dependencies.
Install and run makenode
From your terminal, run the following:
git clone https://github.com/sudomesh/makenode -b 0.0.1 cd makenode npm install cp settings.js.example settings.js
The default settings in settings.js should suffice in most cases, but if you need to make changes, do them in settings.js.
Make sure the Ethernet cable is connected to the 4th port on the router, and that your computer has a working internet connection (e.g. over WiFi). From a terminal, you should be able to ping the home node at 172.22.0.1 and arbitrary websites like github.com.
Once your network configuration is refreshed, use the following command to run the script and configure your node:
./makenode.js
Now the configuration wizard will ask you a number of questions:
- "enter valid hostname" - name of the box, will only be seen when you SSH into the router - For info on what constitutes a valid hostname, see: valid characters of a hostname
- "max share upstream bandwidth" - how much of your home network upstream bandwidth you wish to share with the mesh network, measured in kbps (kilobits per second). So if you'd like to share 10mbps (megabits per second) enter "10000" or if you want to share 256kbps (kilobits per second) enter "256". You may want to run a speed test to find out how much bandwidth you have and determine how much you want to share.
- "max share downstream bandwidth" - how much of your home network upstream bandwidth you wish to share with the mesh network - eg. "512" would share 512 kbps
- "admin user password" - used to log into the admin dashboard where you can modify some settings at http://172.22.0.1 (if on wired connection) or http://172.30.0.1 (if on private wifi network)
- "root user password" - used to SSH into the router so you modify files and manually configure your router. Make sure that your root password is strong! If you don't enter a root password, a strong one will be generated and will be logged to screen. It's generally preferable to not use the root password at all and instead add an ssh key to the device, ssh keys are stored in /etc/dropbear/authorized_keys.
- "wifi transmit power" - set this to 23 dBm (which is equivalent to 200 milliwatts)
- "private wifi SSID" - name of the private wireless network that can be used to administer this router. It will be publicly visible so pick something amusing or descriptive.
- "private wifi password" - password for the private wireless network named in the previous step. It's the one you'll want to give to friends, so come up with something amusing or memorable. Note: it must be at least 8 characters long.
- "operator name" - name that the network admins can associate with the node - so use a unique name like your first name or location name
- "Operator email" - email that network admis can contact you at
- "Expected node address (optional)" - address location of node
Testing
After you're finished with the flashing and configuration, your home node should be available for connections via your private WiFi SSID. Additionally the public SSID 'peoplesopen.net' will be available. It should also be populated on the monitor!
A third interface named 'pplsopen.net-node2node' will be detectable as well. This is the interface used for the nodes to mesh with each other.
At this point you're setup. For more information on using your node, such as accessing the web-based management interface, see Home node info
For more technical details on the internals of the home node, see the Mesh/Technical_Overview
For more in depth testing procedures, see our mesh node operator's manual.
Troubleshooting
If you get the error "no such file or directory", open a new terminal and run this command to ensure that node points to your NodeJS executable:
sudo ln -s nodejs node
In the new terminal, return to the 'makenode' source code directory and try again:
npm install ./makenode.js