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