-
Notifications
You must be signed in to change notification settings - Fork 3
/
README
111 lines (82 loc) · 4.38 KB
/
README
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
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.