Difference between revisions of "Mesh/Makenode"

From Sudo Room
Jump to navigation Jump to search
Line 20: Line 20:


== 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.


== What is does makenode change? ==
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
 
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/ ===

Revision as of 02:13, 8 March 2018

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?