chiark / gitweb /
Build: Kill $(mkdir_p); use $(MKDIR_P).
[tripe] / peerdb / peers.in.5.in
CommitLineData
6005ef9b
MW
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
13.\" it under the terms of the GNU General Public License as published by
14.\" the Free Software Foundation; either version 2 of the License, or
15.\" (at your option) any later version.
16.\"
17.\" TrIPE is distributed in the hope that it will be useful,
18.\" but WITHOUT ANY WARRANTY; without even the implied warranty of
19.\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
20.\" GNU General Public License for more details.
21.\"
22.\" You should have received a copy of the GNU General Public License
23.\" along with TrIPE; if not, write to the Free Software Foundation,
24.\" Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
25.
26.\"--------------------------------------------------------------------------
27.so ../defs.man.in \"@@@PRE@@@
28.
29.\"--------------------------------------------------------------------------
30.TH peers.in 5 "27 March 2008" "Straylight/Edgeware" "TrIPE: Trivial IP Encryption"
31.
32.\"--------------------------------------------------------------------------
33.SH "NAME"
34.
35peers.in \- source form for TrIPE peer database
36.
37.\"--------------------------------------------------------------------------
38.SH "DESCRIPTION"
39.
40The
41.B peers.in
42file is a plain text configuration file. It is read by
43.BR tripe-newpeers (8)
44in order to produce the
45.BR tripe.cdb (8)
46database used by services and other tools.
47.SS "General structure"
48The configuration file is line-oriented. Blank lines are ignored; lines
49beginning with a hash
50.RB ` # '
51or semicolon
52.RB ` ; '
53are ignored. The file is divided into sections by section headers,
54which are lines of the form
55.IP
56.BI [ name ]
57.PP
58Within each section are a number of assignments, of the form
59.IP
60.IB key " = " value
61.PP
62or (entirely equivalent)
63.IP
64.IB key ": " value
65.PP
66The
67.I key
68must start in the left hand column. The
69.I value
70may span multiple lines if subsequent lines begin with whitespace, in
71the manner of RFC822 headers.
72.PP
73There is a special case to be aware of: if a section doesn't specify a
74value for the key
75.B name
76then the section's own name is used as a default.
77.PP
78The following substitutions are made in the body of a value.
79.hP \*o
80An occurrence of
81.BI $( key )
82is replaced by the value assigned to the given
83.IR key .
84.hP \*o
85An occurrence of
86.BI $[ host ]
87is replaced by the IP address of the named
88.IR host .
89Note that
90.I host
91may itself contain
92.BI $( key )
93substitutions.
94.PP
95There is a simple concept of
96.I inheritance
97for sections. If a section contains an assignment
98.IP
99.BI "@inherits = " parent
100.PP
101then any lookups which can't be satisfied in that section will be
102satisfied instead from the
103.I parent
104section (and, if necessary, its parent in turn, and so on). Note that
105.BI $( key )
106substitutions in the resulting value will be satisfied from the original
107section (though falling back to scanning the parent section). For
108example, given the sections
109.VS
110[parent]
111detail = in parent
112blurb = expand $(detail)
113
114.PP
115Apart from its effect on lookups, as just described, the
116.B @inherits
117key is entirely ignored. In particular, it is never written to the
118database.
119.SS "Standard keys and their meanings"
120The following keys have meanings to programs in the TrIPE suite. Other
121keys may be used by separately distributed extensions or for local use.
122The descriptions given are summaries only; see the references for
123details.
124.TP
125.B auto
126If true, include the peer in the
127.B %AUTO
128record. Used by
a62f8e8a
MW
129.BR connect (8)
130and
6005ef9b
MW
131.BR tripe-newpeers (8);
132described below.
133.TP
a62f8e8a
MW
134.B connect
135Shell command for initiating connection to this peer. Used by
136.BR watch (8).
137.TP
138.B cork
139Don't initiate immediate key exchange.. Used by
140.BR connect (8).
141.TP
142.B every
143Interval for checking that the peer is still alive and well. Used by
144.BR watch (8).
145.TP
146.B ifdown
147Script to bring down tunnel interface connected to the peer. Used by
148.BR watch (8).
149.TP
150.B ifname
151Interface name to set for the tunnel interface to the peer. Used by
152.BR tripe-ifup (8).
153.TP
154.B ifup
155Script to bring up tunnel interface connected to the peer. Used by
156.BR watch (8).
157.TP
158.B ifupextra
159Script containing additional interface setup. Used by
160.BR tripe-ifup (8).
161.TP
162.B laddr
163Local address for the tunnel interface to the peer. Used by
164.BR tripe-ifup (8).
165.TP
166.B keepalive
167Interval for sending keepalive pings. Used by
168.BR connect (8).
169.TP
170.B mtu
171Maximum transmission unit for the tunnel interface. Used by
172.BR tripe-ifup (8).
173.TP
174.B nets
175Networks to be routed over the tunnel interface. Used by
176.BR tripe-ifup (8).
177.TP
178.B peer
179Network address for this peer, or
180.BR PASSIVE .
181Used by
182.BR connect (8).
183.TP
184.B raddr
185Remote address for the tunnel interface to the peer. Used by
186.BR tripe-ifup (8).
187.TP
188.B retries
189Number of failed ping attempts before attempting reconnection. Used by
190.BR watch (8).
191.TP
192.B timeout
193Timeout for ping probes. Used by
194.BR watch (8).
195.TP
196.B tunnel
197Tunnel driver to use when adding the peer. Used by
198.BR connect (8)).
199.TP
6005ef9b
MW
200.B user
201Peer will make active connection as
202.IR user .
203Used by
a62f8e8a
MW
204.BR connect (8)
205and
6005ef9b
MW
206.BR tripe-newpeers (8);
207described below.
208.SS "Conversion"
209This section describes how the textual
210.B peers.in
211file is converted into the
212.BR peers.cdb (5)
213database.
214.PP
215The handling of each section depends on its name.
216.hP \*o
217Sections whose names have the form
218.BI @ whatever
219are ignored (though their contents may be relevant if the section is
220named in another section's
221.B @inherits
222key).
223.hP \*o
224Sections whose names have the form
225.BI $ whatever
226are written to local-type database records with the same name. The keys
227and values defined in the section (and its parent section, if it
228contains an
229.B @inherits
230key) are stored in the record using
231.B form-urlencoding
232as defined in RFC1822, except that the key-value pairs are separated by
233semicolons
234.RB ` ; '
235rather than ampersands
236.RB ` & '.
237The
238.B @inherits
239key-value pair is not written to the database.
240.hP \*o
241Other sections are written to peer-type database records, named
242.BI P name \fR,
243in exactly the same way as for local-type records. However, two special
244actions are also taken.
245.IP
246Firstly, if there is a key
247.B auto
248in the section (or in its parent, etc.), and the value is
249.BR y ,
250.BR yes .
251.BR t ,
252.BR true ,
253.BR 1 ,
254or
255.BR on ,
256then the section's name is added in the special
257.B %AUTO
258record.
259.IP
260Secondly, if there is a key
261.B user
262in the section (or in its parent, etc.), then a user record
263.BI U user
264is created whose contents is the section name.
265.
266.\"--------------------------------------------------------------------------
267.SH "SEE ALSO"
268.
269.BR cdb (5),
270.BR tripe (8).
271.PP
272.BR tripe-newpeers (8),
273.BR peers.cdb (5),
a62f8e8a
MW
274.BR connect (8),
275.BR watch (8),
6005ef9b
MW
276.BR tripe-ifup (8).
277.
278.\"--------------------------------------------------------------------------
279.SH "AUTHOR"
280.
281Mark Wooding, <mdw@distorted.org.uk>
282.
283.\"----- That's all, folks --------------------------------------------------