chiark - git - mdw - tripe/blob - 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 ` * '
  97 returns all of the found addresses, separated by spaces, rather than
  98 just the first one.
  99 .PP
 100 There is a simple concept of
 101 .I inheritance
 102 for sections.  If a section contains an assignment
 103 .IP
 104 .BI "@inherit = " parent
 105 .RB [[,]
 106 .I parent
 107 \&...]
 108 .PP
 109 then any lookups which can't be satisfied in that section will be
 110 satisfied instead from its
 111 .I parent
 112 sections (and, if necessary, their parents in turn, and so on).
 113 .PP
 114 .hP \*o
 115 If a value can be found for a key via multiple parents then all of them
 116 must report the
 117 .I same
 118 value.  This restriction may be relaxed somewhat, if it turns out that a
 119 more flexible notion of multiple inheritance is useful.
 120 .hP \*o
 121 It's not allowed for a section to inherit, possibly indirectly, from
 122 itself.  Currently errors of this kind are only diagnosed when a cycle
 123 is encountered while looking up a key and none of the sections on the
 124 path from the original section up to and round the cycle define a value
 125 for it.  Future versions of this program might be more picky.
 126 .PP
 127 Note that
 128 .BI $( key )
 129 substitutions in the resulting value will be satisfied from the original
 130 section (though falling back to scanning parent sections).  For
 131 example, given the sections
 132 .VS
 133 [parent]
 134 detail = in $(name)
 135 blurb = expand $(detail)
 136
 137 [child]
 138 @inherit = parent
 139 .VE
 140 the key
 141 .B blurb
 142 takes the value
 143 .RB ` "expand in parent" '
 144 in section
 145 .BR parent ,
 146 and
 147 .RB ` "expand in child" '
 148 in section
 149 .BR child .
 150 .PP
 151 Apart from its effect on lookups, as just described, the
 152 .B @inherit
 153 key is entirely ignored.  In particular, it is never written to the
 154 database.
 155 .
 156 .SS "Standard keys and their meanings"
 157 The following keys have meanings to programs in the TrIPE suite.  Other
 158 keys may be used by separately distributed extensions or for local use.
 159 The descriptions given are summaries only; see the references for
 160 details.
 161 .TP
 162 .B auto
 163 If true, include the peer in the
 164 .B %AUTO
 165 record.  Used by
 166 .BR connect (8)
 167 and
 168 .BR tripe-newpeers (8);
 169 described below.
 170 .TP
 171 .B connect
 172 Shell command for initiating connection to this peer.  Used by
 173 .BR connect (8).
 174 .TP
 175 .B cork
 176 Don't initiate immediate key exchange.  Used by
 177 .BR connect (8).
 178 .TP
 179 .B disconnect
 180 Shell command for closing down connection to this peer.  Used by
 181 .BR connect (8).
 182 .TP
 183 .B every
 184 Interval for checking that the peer is still alive and well.  Used by
 185 .BR connect (8).
 186 .TP
 187 .B ifdown
 188 Script to bring down tunnel interface connected to the peer.  Used by
 189 .BR connect (8).
 190 .TP
 191 .B ifname
 192 Interface name to set for the tunnel interface to the peer.  Used by
 193 .BR tripe-ifup (8).
 194 .TP
 195 .B ifup
 196 Script to bring up tunnel interface connected to the peer.  Used by
 197 .BR connect (8).
 198 .TP
 199 .B ifupextra
 200 Script containing additional interface setup.  Used by
 201 .BR tripe-ifup (8).
 202 .TP
 203 .B laddr
 204 Local address for the tunnel interface to the peer.  Used by
 205 .BR tripe-ifup (8).
 206 .TP
 207 .B keepalive
 208 Interval for sending keepalive pings.  Used by
 209 .BR connect (8).
 210 .TP
 211 .B key
 212 Key tag to use to authenticate the peer.  Used by
 213 .BR connect (8).
 214 .TP
 215 .B mobile
 216 Peer's IP address is highly volatile.  Used by
 217 .BR connect (8).
 218 .TP
 219 .B mtu
 220 Maximum transmission unit for the tunnel interface.  Used by
 221 .BR tripe-ifup (8).
 222 .TP
 223 .B nets
 224 Networks to be routed over the tunnel interface.  Used by
 225 .BR tripe-ifup (8).
 226 .TP
 227 .B peer
 228 Network address for this peer, or
 229 .BR PASSIVE .
 230 Used by
 231 .BR connect (8).
 232 .TP
 233 .B priv
 234 Tag of the private key to use when communicating with the peer.
 235 Used by
 236 .BR connect (8).
 237 .TP
 238 .B raddr
 239 Remote address for the tunnel interface to the peer.  Used by
 240 .BR tripe-ifup (8).
 241 .TP
 242 .B retries
 243 Number of failed ping attempts before attempting reconnection.  Used by
 244 .BR connect (8).
 245 .TP
 246 .B timeout
 247 Timeout for ping probes.  Used by
 248 .BR connect (8).
 249 .TP
 250 .B tunnel
 251 Tunnel driver to use when adding the peer.  Used by
 252 .BR connect (8)).
 253 .TP
 254 .B user
 255 Peer will make active connection as
 256 .IR user .
 257 Used by
 258 .BR connect (8)
 259 and
 260 .BR tripe-newpeers (8);
 261 described below.
 262 .
 263 .SS "Conversion"
 264 This section describes how the textual
 265 .B peers.in
 266 file is converted into the
 267 .BR peers.cdb (5)
 268 database.
 269 .PP
 270 The handling of each section depends on its name.
 271 .hP \*o
 272 Sections whose names have the form
 273 .BI @ whatever
 274 are ignored (though their contents may be relevant if the section is
 275 named in another section's
 276 .B @inherit
 277 key).
 278 .hP \*o
 279 Sections whose names have the form
 280 .BI $ whatever
 281 are written to local-type database records with the same name.  The keys
 282 and values defined in the section (and its parent section, if it
 283 contains an
 284 .B @inherit
 285 key) are stored in the record using
 286 .B form-urlencoding
 287 as defined in RFC1822, except that the key-value pairs are separated by
 288 semicolons
 289 .RB ` ; '
 290 rather than ampersands
 291 .RB ` & '.
 292 Keys whose names begin with
 293 .RB ` @ '
 294 are not written to the database.
 295 .hP \*o
 296 Other sections are written to peer-type database records, named
 297 .BI P name \fR,
 298 in exactly the same way as for local-type records.  However, two special
 299 actions are also taken.
 300 .IP
 301 Firstly, if there is a key
 302 .B auto
 303 in the section (or in its parent, etc.), and the value is
 304 .BR y ,
 305 .BR yes .
 306 .BR t ,
 307 .BR true ,
 308 .BR 1 ,
 309 or
 310 .BR on ,
 311 then the section's name is added in the special
 312 .B %AUTO
 313 record.
 314 .IP
 315 Secondly, if there is a key
 316 .B user
 317 in the section (or in its parent, etc.), then a user record
 318 .BI U user
 319 is created whose contents is the section name.
 320 .
 321 .\"--------------------------------------------------------------------------
 322 .SH "SEE ALSO"
 323 .
 324 .BR cdb (5),
 325 .BR tripe (8).
 326 .PP
 327 .BR tripe-newpeers (8),
 328 .BR peers.cdb (5),
 329 .BR connect (8),
 330 .BR tripe-ifup (8).
 331 .
 332 .\"--------------------------------------------------------------------------
 333 .SH "AUTHOR"
 334 .
 335 Mark Wooding, <mdw@distorted.org.uk>
 336 .
 337 .\"----- That's all, folks --------------------------------------------------