chiark / gitweb /
peerdb/tripe-newpeers.in: Add a new resolver based on adnshost(1).
[tripe] / peerdb / peers.in.5.in
1 .\" -*-nroff-*-
2 .\".
3 .\" Manual for the peer configuration file
4 .\"
5 .\" (c) 2008 Straylight/Edgeware
6 .\"
7 .
8 .\"----- Licensing notice ---------------------------------------------------
9 .\"
10 .\" This file is part of Trivial IP Encryption (TrIPE).
11 .\"
12 .\" TrIPE is free software: you can redistribute it and/or modify it under
13 .\" the terms of the GNU General Public License as published by the Free
14 .\" Software Foundation; either version 3 of the License, or (at your
15 .\" option) any later version.
16 .\"
17 .\" TrIPE is distributed in the hope that it will be useful, but WITHOUT
18 .\" ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
19 .\" FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
20 .\" for more details.
21 .\"
22 .\" You should have received a copy of the GNU General Public License
23 .\" along with TrIPE.  If not, see <https://www.gnu.org/licenses/>.
24 .
25 .\"--------------------------------------------------------------------------
26 .so ../common/defs.man \"@@@PRE@@@
27 .
28 .\"--------------------------------------------------------------------------
29 .TH peers.in 5tripe "27 March 2008" "Straylight/Edgeware" "TrIPE: Trivial IP Encryption"
30 .
31 .\"--------------------------------------------------------------------------
32 .SH "NAME"
33 .
34 peers.in \- source form for TrIPE peer database
35 .
36 .\"--------------------------------------------------------------------------
37 .SH "DESCRIPTION"
38 .
39 The
40 .B peers.in
41 file is a plain text configuration file.  It is read by
42 .BR tripe-newpeers (8)
43 in order to produce the
44 .BR tripe.cdb (8)
45 database used by services and other tools.
46 .
47 .SS "General structure"
48 The configuration file is line-oriented.  Blank lines are ignored; lines
49 beginning with a hash
50 .RB ` # '
51 or semicolon
52 .RB ` ; '
53 are ignored.  The file is divided into sections by section headers,
54 which are lines of the form
55 .IP
56 .BI [ name ]
57 .PP
58 Within each section are a number of assignments, of the form
59 .IP
60 .IB key " = " value
61 .PP
62 or (entirely equivalent)
63 .IP
64 .IB key ": " value
65 .PP
66 The
67 .I key
68 must start in the left hand column.  The
69 .I value
70 may span multiple lines if subsequent lines begin with whitespace, in
71 the manner of RFC822 headers.
72 .PP
73 There is a special case to be aware of: if a section doesn't specify a
74 value for the key
75 .B name
76 then the section's own name is used as a default.
77 .PP
78 The following substitutions are made in the body of a value.
79 .hP \*o
80 An occurrence of
81 .BI $( key )
82 is replaced by the value assigned to the given
83 .IR key .
84 .hP \*o
85 An occurrence of
86 .BI $ flags [ host ]
87 is replaced by the IP address of the named
88 .IR host .
89 Note that
90 .I host
91 may itself contain
92 .BI $( key )
93 substitutions.  The
94 .I flags
95 consist of zero or more of the following characters:
96 .RB ` 4 '
97 looks up the
98 .IR host 's
99 IPv4 address(es);
100 .RB ` 6 '
101 looks up the
102 .IR host 's
103 IPv6 address(es);
104 and
105 .RB ` * '
106 returns all of the found addresses, separated by spaces, rather than
107 just the first one.  If neither address family is requested, then
108 .RB ` 46 '
109 is assumed.  IPv6 address lookup of names, rather than address literals,
110 depends on the external
111 .BR adnshost (1)
112 program; if it is not present then only IPv4 lookups will be performed.
113 .PP
114 There is a simple concept of
115 .I inheritance
116 for sections.  If a section contains an assignment
117 .IP
118 .BI "@inherit = " parent
119 .RB [[,]
120 .I parent
121 \&...]
122 .PP
123 then any lookups which can't be satisfied in that section will be
124 satisfied instead from its
125 .I parent
126 sections (and, if necessary, their parents in turn, and so on).
127 .PP
128 .hP \*o
129 If a value can be found for a key via multiple parents then all of them
130 must report the
131 .I same
132 value.  This restriction may be relaxed somewhat, if it turns out that a
133 more flexible notion of multiple inheritance is useful.
134 .hP \*o
135 It's not allowed for a section to inherit, possibly indirectly, from
136 itself.  Currently errors of this kind are only diagnosed when a cycle
137 is encountered while looking up a key and none of the sections on the
138 path from the original section up to and round the cycle define a value
139 for it.  Future versions of this program might be more picky.
140 .PP
141 Note that
142 .BI $( key )
143 substitutions in the resulting value will be satisfied from the original
144 section (though falling back to scanning parent sections).  For
145 example, given the sections
146 .VS
147 [parent]
148 detail = in $(name)
149 blurb = expand $(detail)
150
151 [child]
152 @inherit = parent
153 .VE
154 the key
155 .B blurb
156 takes the value
157 .RB ` "expand in parent" '
158 in section
159 .BR parent ,
160 and
161 .RB ` "expand in child" '
162 in section
163 .BR child .
164 .PP
165 Apart from its effect on lookups, as just described, the
166 .B @inherit
167 key is entirely ignored.  In particular, it is never written to the
168 database.
169 .
170 .SS "Standard keys and their meanings"
171 The following keys have meanings to programs in the TrIPE suite.  Other
172 keys may be used by separately distributed extensions or for local use.
173 The descriptions given are summaries only; see the references for
174 details.
175 .TP
176 .B auto
177 If true, include the peer in the
178 .B %AUTO
179 record.  Used by
180 .BR connect (8)
181 and
182 .BR tripe-newpeers (8);
183 described below.
184 .TP
185 .B connect
186 Shell command for initiating connection to this peer.  Used by
187 .BR connect (8).
188 .TP
189 .B cork
190 Don't initiate immediate key exchange.  Used by
191 .BR connect (8).
192 .TP
193 .B disconnect
194 Shell command for closing down connection to this peer.  Used by
195 .BR connect (8).
196 .TP
197 .B every
198 Interval for checking that the peer is still alive and well.  Used by
199 .BR connect (8).
200 .TP
201 .B ifdown
202 Script to bring down tunnel interface connected to the peer.  Used by
203 .BR connect (8).
204 .TP
205 .B ifname
206 Interface name to set for the tunnel interface to the peer.  Used by
207 .BR tripe-ifup (8).
208 .TP
209 .B ifup
210 Script to bring up tunnel interface connected to the peer.  Used by
211 .BR connect (8).
212 .TP
213 .B ifupextra
214 Script containing additional interface setup.  Used by
215 .BR tripe-ifup (8).
216 .TP
217 .B laddr
218 Local address for the tunnel interface to the peer.  Used by
219 .BR tripe-ifup (8).
220 .TP
221 .B keepalive
222 Interval for sending keepalive pings.  Used by
223 .BR connect (8).
224 .TP
225 .B key
226 Key tag to use to authenticate the peer.  Used by
227 .BR connect (8).
228 .TP
229 .B mobile
230 Peer's IP address is highly volatile.  Used by
231 .BR connect (8).
232 .TP
233 .B mtu
234 Maximum transmission unit for the tunnel interface.  Used by
235 .BR tripe-ifup (8).
236 .TP
237 .B nets
238 Networks to be routed over the tunnel interface.  Used by
239 .BR tripe-ifup (8).
240 .TP
241 .B peer
242 Network address for this peer, or
243 .BR PASSIVE .
244 Used by
245 .BR connect (8).
246 .TP
247 .B priv
248 Tag of the private key to use when communicating with the peer.
249 Used by
250 .BR connect (8).
251 .TP
252 .B raddr
253 Remote address for the tunnel interface to the peer.  Used by
254 .BR tripe-ifup (8).
255 .TP
256 .B retries
257 Number of failed ping attempts before attempting reconnection.  Used by
258 .BR connect (8).
259 .TP
260 .B timeout
261 Timeout for ping probes.  Used by
262 .BR connect (8).
263 .TP
264 .B tunnel
265 Tunnel driver to use when adding the peer.  Used by
266 .BR connect (8)).
267 .TP
268 .B user
269 Peer will make active connection as
270 .IR user .
271 Used by
272 .BR connect (8)
273 and
274 .BR tripe-newpeers (8);
275 described below.
276 .
277 .SS "Conversion"
278 This section describes how the textual
279 .B peers.in
280 file is converted into the
281 .BR peers.cdb (5)
282 database.
283 .PP
284 The handling of each section depends on its name.
285 .hP \*o
286 Sections whose names have the form
287 .BI @ whatever
288 are ignored (though their contents may be relevant if the section is
289 named in another section's
290 .B @inherit
291 key).
292 .hP \*o
293 Sections whose names have the form
294 .BI $ whatever
295 are written to local-type database records with the same name.  The keys
296 and values defined in the section (and its parent section, if it
297 contains an
298 .B @inherit
299 key) are stored in the record using
300 .B form-urlencoding
301 as defined in RFC1822, except that the key-value pairs are separated by
302 semicolons
303 .RB ` ; '
304 rather than ampersands
305 .RB ` & '.
306 Keys whose names begin with
307 .RB ` @ '
308 are not written to the database.
309 .hP \*o
310 Other sections are written to peer-type database records, named
311 .BI P name \fR,
312 in exactly the same way as for local-type records.  However, two special
313 actions are also taken.
314 .IP
315 Firstly, if there is a key
316 .B auto
317 in the section (or in its parent, etc.), and the value is
318 .BR y ,
319 .BR yes .
320 .BR t ,
321 .BR true ,
322 .BR 1 ,
323 or
324 .BR on ,
325 then the section's name is added in the special
326 .B %AUTO
327 record.
328 .IP
329 Secondly, if there is a key
330 .B user
331 in the section (or in its parent, etc.), then a user record
332 .BI U user
333 is created whose contents is the section name.
334 .
335 .\"--------------------------------------------------------------------------
336 .SH "SEE ALSO"
337 .
338 .BR cdb (5),
339 .BR tripe (8).
340 .PP
341 .BR tripe-newpeers (8),
342 .BR peers.cdb (5),
343 .BR connect (8),
344 .BR tripe-ifup (8).
345 .
346 .\"--------------------------------------------------------------------------
347 .SH "AUTHOR"
348 .
349 Mark Wooding, <mdw@distorted.org.uk>
350 .
351 .\"----- That's all, folks --------------------------------------------------