chiark / gitweb /
Write a pidfile on request, and delete it when finished.
[tripe] / doc / tripe-admin.5
CommitLineData
d6623498 1.\" -*-nroff-*-
2.TH tripe-admin 5 "18 February 2001" "Straylight/Edgeware" "TrIPE: Trivial IP Encryption"
3.SH NAME
4tripe-admin \- administrator commands for TrIPE
5.SH DESCRIPTION
6This manual page describes the administration interface provided by the
7.BR tripe (8)
8daemon.
9.PP
10The
11.BR tripectl (8)
12program can be used either interactively or in scripts to communicate
13with the server using this interface. Alternatively, simple custom
14clients can be written in scripting languages such as Perl, Python or
15Tcl, or more advanced clients such as GUI monitors can be written in C
16with little difficulty.
17.PP
18By default, the server listens for admin connections on the Unix-domain
19socket
20.BR /var/lib/tripe/tripesock .
21Administration commands use a simple textual protocol. Each client
22command or server response consists of a line of ASCII text terminated
23by a single linefeed character.
24.SS "General structure"
25Each command or response line consists of a sequence of
26whitespace-separated words. The number and nature of whitespace
27characters separating two words in a client command is not significant;
28the server always uses a single space character. The first word in a
29line is a
30.I keyword
31identifying the type of command or response contained. Keywords in
32client commands are not case-sensitive; the server always uses uppercase
33for its keywords.
34.SS "Server responses"
35For client command, the server responds with zero or more
36.B INFO
37lines, followed by either an
38.B OK
39line or a
40.B FAIL
41line. Each
42.B INFO
43provides information requested in the command. An
44.B OK
45response contains no further data. A
46.B FAIL
47code is followed by a human-readable explanation of why the command
48failed.
49.PP
50In addition, there are two types of asynchronous `responses', which
51aren't associated with any particular command. The
52.B WARN
53response contains a human-readable message warning of an error
54encountered while processing a command, unexpected or unusual behaviour
55by a peer, or a possible attack by an adversary. Under normal
56conditions, the server shouldn't emit any warnings. The
57.B TRACE
58response contains a human-readable tracing message containing diagnostic
59information. Trace messages are controlled using the
60.B \-T
61command-line option to the server, or the
62.B TRACE
63administration command (see below). Support for tracing can be disabled
64when the package is being configured, and may not be available in your
65version.
66.SS "Command reference"
67The commands provided are:
68.TP
69.B "HELP"
70Causes the server to emit an
71.B INFO
72line for each command it supports. Each line lists the command name,
73followed by the names of the arguments. This may be helpful as a memory
74aid for interactive use, or for program clients probing for features.
75.TP
76.BR "TRACE " [\fIoptions\fP]
77A trace argument consists of a string of letters (listed below)
78selecting trace outputs, optionally interspersed with
79.RB ` + '
80to enable, or
81.RB ` \- '
82to disable, the subsequently listed outputs; the initial behaviour is to
83enable listed outputs. For example, the string
84.B ra\-st+x
85enables tracing of peer management, admin-connection handling and
86key-exchange processing, and disables tracing of symmetric keyset
87management and the system-specific tunnel driver. If no argument is
88given, a table is returned showing the available tracing option letters
89and their meanings. Programs should not attempt to parse this table:
90its format is not guaranteed to remain the same.
91.RS
92Currently, the following tracing options are supported:
93.TP
94.B t
95Tunnel events: reception of packets to be encrypted, and injection of
96successfully-decrypted packets.
97.TP
98.B r
99Peer management events: creation and destruction of peer attachments,
100and arrival of messages.
101.TP
102.B a
103Administration interface: acceptance of new connections, and handling of
104the backgroud name-resolution required by the
105.B ADD
106command.
107.TP
108.B p
109Display contents of packets sent and received by the tunnel and/or peer
110modules.
111.TP
112.B c
113Display inputs, outputs and intermediate results of cryptographic
114operations. This includes plaintext and key material. Use with
115caution.
116.TP
117.B s
118Handling of symmetric keysets: creation and expiry of keysets, and
119encryption and decryption of messages.
120.TP
121.B x
122Key exchange: reception, parsing and emission of key exchange messages.
123.TP
124.B m
125Key management: loading keys and checking for file modifications.
126.PP
127Note that the
128.B p
129(packet contents)
130and
131.B c
132(crypto details)
133outputs provide extra detail for other outputs. Specifying
134.B p
135without
136.B r
137or
138.B t
139isn't useful; neither is specifying
140.B c
141without one of
142.BR s ,
143.B x
144or
145.BR m .
146.RE
147.TP
148.B "PORT"
149Emits an
150.B INFO
151line containing just the number of the UDP port used by the
152.B tripe
153server. If you've allowed your server to allocate a port dynamically,
154this is how to find out which one it chose.
155.TP
156.B "DAEMON"
157Causes the server to disassociate itself from its terminal and become a
158background task. This only works once. A warning is issued.
159.TP
160.B "LIST"
161For each currently-known peer, an
162.B INFO
163line is written containing the peer's name, as given to
164.BR ADD .
165.TP
166.BI "IFNAME " peer
167Emits an
168.B INFO
169line containing the name of the network interface used to collect IP
170packets which are to be encrypted and sent to
171.IR peer .
172Used by configuration scripts so that they can set up routing tables
173appropriately after adding new peers.
174.TP
175.BI "ADDR " peer
176Emits an
177.B INFO
178line reporting the IP address and port number stored for
179.IR peer .
180.TP
181.BI "STATS " peer
182Emits a number of
183.B INFO
184lines, each containing one or more statistics in the form
185.IB name = value \fR.
186The statistics-gathering is experimental and subject to change.
187.TP
188.BI "KILL " peer
189Causes the server to forget all about
190.IR peer .
191All keys are destroyed, and no more packets are sent. No notification
192is sent to the peer: if it's important that the peer be notified, you
193must think of a way to do that yourself.
194.TP
195.BI "ADD " "peer addr port"
196Adds a new peer. The peer is given the name
197.IR peer ;
198the peer's public key is assumed to be in the file
199.B keyring.pub
200(or whatever alternative file was specified in the
201.B \-K
202option on the command line). The peer's
203.B tripe
204implementation may be contacted at the given UDP port and IP address.
205.TP
206.B "QUIT"
207Instructs the server to exit immediately. A warning is sent.
208.SH "SEE ALSO"
209.BR tripectl (1),
210.BR tripe (8).
211.PP
212.IR "The Trivial IP Encryption Protocol" ,
213.SH "AUTHOR"
214Mark Wooding, <mdw@nsict.org>