summaryrefslogtreecommitdiff
path: root/doc/omrelp.html
blob: 8049ebaf8875ffe0239e861fb5deca996469ee0d (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html><head>
<meta http-equiv="Content-Language" content="en"><title>RELP Output Module (omrelp)</title>

</head>
<body>
<a href="rsyslog_conf_modules.html">back to rsyslog module documentation</a>

<h1>RELP Output Module (omrelp)</h1>
<p><b>Module Name:&nbsp;&nbsp;&nbsp; omrelp</b></p>
<p><b>Author: </b>Rainer Gerhards
&lt;rgerhards@adiscon.com&gt;</p>
<p><b>Description</b>:</p>
<p>This module supports sending syslog messages over the reliable
RELP protocol. For RELP's advantages over plain tcp syslog, please see
the documentation for <a href="imrelp.html">imrelp</a>
(the server counterpart).&nbsp;</p>
<span style="font-weight: bold;">Setup</span>
<p>Please note that <a href="http://www.librelp.com">librelp</a>
is required for imrelp (it provides the core relp protocol
implementation).</p>
<p><b>Action Configuration Parameters</b>:</p>
<p>This module supports RainerScript configuration starting with
rsyslog 7.3.10. For older versions, legacy configuration directives
must be used.
<ul>
	<li><b>target</b> (mandatory)<br>
	The target server to connect to.
	</li>
	<li><b>template</b> (not mandatory, default "RSYSLOG_ForwardFormat")<br>
	Defines the template to be used for the output.
	</li>
	<li><b>timeout</b> (not mandatory, default 90)<br>
	Timeout for relp sessions. If set too low, valid sessions
	may be considered dead and tried to recover.
	</li>
	<li><b>windowSize</b> (not mandatory, default 0)<br>
	This is an <b>expert parameter</b>. It permits to override the
	RELP window size being used by the client. Changing the window
	size has both an effect on performance as well as potential 
	message duplication in failure case. A larger window size means
	more performance, but also potentially more duplicated 
	messages - and vice versa. The default 0 means that librelp's
	default window size is being used, which is considered a
	compromise between goals reached. For your information:
	at the time of this writing, the librelp default window size
	is 128 messages, but this may change at any time.
	<br>Note that there is no equivalent server parameter, as the
	client proposes and manages the window size in RELP protocol.
        <li><b>tls</b> (not mandatory, values "on","off", default "off")<br>
	If set to "on", the RELP connection will be encrypted by TLS, 		so that the data is protected against observers. Please note 		that both the client and the server must have set TLS to 		either "on" or "off". Other combinations lead to unpredictable 		results.
	</li>
	<li><b>tls.compression</b> (not mandatory, values "on","off", default "off")<br>
	The controls if the TLS stream should be compressed (zipped). While this
	increases CPU use, the network bandwidth should be reduced. Note that
	typical text-based log records usually compress rather well.
	</li>
	<li><b>tls.permittedPeer</b> peer</br>
	Places access restrictions on this forwarder. Only peers which
	have been listed in this parameter may be connected to.
	This guards against rouge servers and man-in-the-middle
	attacks. The validation
	bases on the certficate the remote peer presents.<br>
	The <i>peer</i> parameter lists permitted certificate
	fingerprints. Note that it is an array parameter, so either
	a single or multiple fingerprints can be listed. When a
	non-permitted peer is connected to, the refusal is logged together
	with it's fingerprint. So if the administrator knows this was
	a valid request, he can simple add the fingerprint by copy and
	paste from the logfile to rsyslog.conf. It must be noted, though,
	that this situation should usually not happen after initial
	client setup and administrators should be alert in this case.
	<br>Note that usually a single remote peer should be all that
	is ever needed. Support for multiple peers is primarily included
	in support of load balancing scenarios. If the connection
	goes to a specific server, only one specific certificate is ever
	expected (just like when connecting to a specific ssh server).
	<br>To specify multiple fingerprints, just enclose them
	in braces like this:
	<br>tls.permittedPeer=["SHA1:...1", "SHA1:....2"]
	<br>To specify just a single peer, you can either
	specify the string directly or enclose it in braces.
	</li>
	<li><b>tls.authMode</b> mode</br>
	Sets the mode used for mutual authentication. Supported values are
	either "<i>fingerprint</i>" or "<i>name"</i>.
	<br>Fingerprint mode  basically is what SSH
	does. It does not require a full PKI to be present, instead self-signed
	certs can be used on all peers. Even if a CA certificate is given, the
	validity of the peer cert is NOT verified against it. Only the
	certificate fingerprint counts.
	<br>In "name" mode, certificate validation happens. Here, the matching
	is done against the certificate's subjectAltName and, as a fallback,
	the subject common name. If the certificate contains multiple names,
	a match on any one of these names is considered good and permits the
	peer to talk to rsyslog.
	<li><b>tls.prioritystring</b> (not mandatory, string)<br>
	This parameter permits to specify the so-called "priority string" to
	GnuTLS. This string gives complete control over all crypto parameters,
	including compression setting. For this reason, when the prioritystring
	is specified, the "tls.compression" parameter has no effect and is
	ignored.
	<br>Full information about how to construct a priority string can be
	found in the GnuTLS manual. At the time of this writing, this
	information was contained in
	<a href="http://gnutls.org/manual/html_node/Priority-Strings.html">section 6.10 of the GnuTLS manual</a>.
	<br><b>Note: this is an expert parameter.</b> Do not use if you do
	not exactly know what you are doing.
	</li>
</ul>
<p><b>Sample:</b></p>
<p>The following sample sends all messages to the central server
"centralserv" at port 2514 (note that that server must run imrelp on
port 2514).
</p>
<textarea rows="3" cols="60">module(load="omrelp")
action(type="omrelp" target="centralserv" port="2514")
</textarea>
<p><b>Legacy Configuration Directives</b>:</p>
<p>This module uses old-style action configuration to keep
consistent with the forwarding rule. So far, no additional
configuration directives can be specified. To send a message via RELP,
use</p>
<p>*.*
&nbsp;:omrelp:&lt;sever&gt;:&lt;port&gt;;&lt;template&gt;</p>
<p>just as you use&nbsp;</p>
<p>*.*
&nbsp;@@&lt;sever&gt;:&lt;port&gt;;&lt;template&gt;</p>
<p>to forward a message via plain tcp syslog.</p>
<b>Caveats/Known Bugs:</b>
<p>See <a href="imrelp.html">imrelp</a>,
which documents them.&nbsp;</p>
<p><b>Legacy Sample:</b></p>
<p>The following sample sends all messages to the central server
"centralserv" at port 2514 (note that that server must run imrelp on
port 2514).
</p>
<textarea rows="3" cols="60">$ModLoad omrelp
*.* :omrelp:centralserv:2514
</textarea>
<p>Note: to use IPv6 addresses, encode them in [::1] format.
<p>[<a href="rsyslog_conf.html">rsyslog.conf overview</a>]
[<a href="manual.html">manual index</a>] [<a href="http://www.rsyslog.com/">rsyslog site</a>]</p>
<p><font size="2">This documentation is part of the
<a href="http://www.rsyslog.com/">rsyslog</a>
project.<br>
Copyright © 2008 by <a href="http://www.gerhards.net/rainer">Rainer
Gerhards</a> and
<a href="http://www.adiscon.com/">Adiscon</a>.
Released under the GNU GPL version 3 or higher.</font></p>
</body></html>