This tree is intended as a configurator, for generating OpenWrt
$(TOPDIR)/files trees for individual nodes (or suitable for rsync'ing
over a generic FooCab image.

A tab-delimited node database (nodedb.txt) contains the basic
configuration information needed for filling in the template files.
The basic idea is to substitute for PTP_<string>_PTP instances in the
template files, dumping the result into a nearby node-specific
directory tree.  The node database contains the following fields:

  NODE : the node name in wiki name format, prepending "Node" to the
         string value of this variable should generate a valid node
         wiki page name.

  NODENAME : a string value representing the name of the business or
         area sponsoring the node.

  HOSTNAME : a hostname for the gateway device, hopefully already in
         PTP's DNS system.

  BRIDGE : indicates whether LAN ports and wireless should
         be bridged together or on separate networks. (1 = bridged, 0 = not bridged).

  FILTER : indicates if any special filtering should be applied to
         protect the node hosts local private network:

           NONE = no special filtering required;
           WAN = indicates the device is hanging off of the node hosts
                 private network, so disallow any destinations ipaddrs
                 on the immediately upstream network;
           PRIV = prevents sources from the public network from
                 accessing hosts on the private network (doesn't make
                 sense if BRIDGE above is "yes");
           BOTH = adds rules for both WAN and PRIV.
  
  DEVICE : Indicates what device the configuration is for:  WGT or ALIX

  PUBADDR : an ipv4 address in the 10.11.x.y range for the gateway
         device, typically the first valid host ipaddr in the local
         network.

  PUBMASKLEN : the number of ipv4 bits in the network portion,
        typically 26 for coffee shop nodes, but also 25, 24 and 22
        occur.

  LOGOFILE : the name of a logo file to use on the splash page, found
        in the www/images/nodes directory along with the generic
        images.

  DHCPSTART : indicates the offset from the LOCALNET to begin
        allocating addresses.

  PRIVADDR : indicates in non-bridging cases the ipaddr of the
        device's private network interface.

  PRIVMASKLEN : indicates the number of ipv4 bits in the network
        portion for the private network.

Two additional variable can be computed or selected based on the other
values:

  PUBNETMASK : Based on the value of the PUBMASKLEN, thusly:
        22 -> 255.255.252.0
        24 -> 255.255.255.0
        25 -> 255.255.255.128
        26 -> 255.255.255.192

  PUBNET : the PUBADDR bitwise-AND'd against the PUBNETMASK.

likewise, in non-bridging cases,

  PRIVNETMASK 

  PRIVNET

The configurator should recreate the files from the etc, root, and usr
directories, making the substitutions for the variables noted above in
a new tree.  The files in the www and www/images directories should
also be copied into the corresponding directories in the new tree, and
the file www/images/nodes/$(LOGOFILE) should be copied to www/images
in the new tree.

Additionally, unique openvpn keys are needed for each gateway device.
If possible, keys from existing NuCabs can be used.  If necessary,
they can be computed on donk using the mkvpnclient utility:

  sudo mkvpnclient $(HOSTNAME)

with the resulting $(HOSTNAME).crt and $(HOSTNAME).key files copied
into the new tree in etc/openvpn/keys.  This part probably needs doing
manually.

In the near term, we can assume that the upstream network is assigned
using DHCP, but ultimately it is desirable to extend the system to
handle static address configurations on the upstream interface.

OTHER ISSUES:

1) In some cases, like at the First Unitarian Church node(s), local
   administrators have developed their own permutations of the splash
   and accompanying pages.  These should be retained in practice,
   whether by integrating them by hand, or by some automated means.

2) In some cases, splash pages have multiple sponsors
   (NodePioneerSquare and NodeMississippi come to mind).  Again, these
   should be retained in practice, whether by integrating them by
   hand, or by some automated means.

3) Should consider whether to routinely apply my bittorrent auto-nuker
   iptables rules.  Should test layer7 tools in a live node
   environment as a possible alternative to prevent abuse.