1
.TH SNMPTRAPD.CONF 5 "29 Jun 2005" VVERSIONINFO "Net-SNMP"
4
snmptrapd.conf - configuration file for the Net-SNMP notification receiver
6
The Net-SNMP notification receiver (trap daemon) uses one or more
7
configuration files to control its operation and how incoming traps
8
(and INFORM requests) should be processed.
9
This file (\fBsnmptrapd.conf\fR) can be located in
10
one of several locations, as described in the
16
would accept all incoming notifications, and log them automatically
17
(even if no explicit configuration was provided).
18
Starting with release 5.3, access control checks will be applied to
19
incoming notifications. If
21
is run without a suitable configuration file (or equivalent access
22
control settings), then such traps \fBWILL NOT\fR
24
See the section \fBACCESS CONTROL\fR for more details.
26
As with the agent configuration, the
28
directives can be divided into four distinct groups.
30
.IP "snmpTrapdAddr [<transport-specifier>:]<transport-address>[,...]"
31
defines a list of listening addresses, on which to receive
32
incoming SNMP notifications.
34
.B LISTENING ADDRESSES
37
manual page for more information about the format of listening
40
The default behaviour is to
41
listen on UDP port 162 on all IPv4 interfaces.
42
.IP "doNotRetainNotificationLogs yes"
43
disables support for the NOTIFICATION-LOG-MIB.
44
Normally the snmptrapd program keeps a record of the traps
45
received, which can be retrieved by querying
46
the \fCnlmLogTable\fR and \fCnlmLogvariableTable\fR tables.
47
This directive can be used to suppress this behaviour.
51
manual page and the NOTIFICATION-LOG-MIB for details.
52
.IP "doNotLogTraps yes"
53
disables the logging of notifications altogether.
54
This is useful if the \fBsnmptrapd\fR application should
55
only run traphandle hooks and should not log traps to any location.
57
do not fork from the calling shell.
59
defines a file in which to store the process ID of the
60
notification receiver. By default, this ID is not saved.
62
Starting with release 5.3, it is necessary to explicitly specify
63
who is authorised to send traps and informs to the notification
64
receiver (and what types of processing these are allowed to trigger).
65
This uses an extension of the VACM model, used in the main SNMP agent.
67
There are currently three types of processing that can be specified:
70
log the details of the notification - either in a specified file,
71
to standard output (or stderr), or via \fIsyslog\fR (or similar).
73
pass the details of the trap to a specified handler program, including
76
forward the trap to another notification receiver.
79
In the following directives, \fITYPES\fR will be a (comma-separated)
80
list of one or more of these tokens. Most commonly, this will
81
typically be \fIlog,execute,net\fR to cover any style of processing
82
for a particular category of notification. But it is perfectly
83
possible (even desirable) to limit certain notification sources to
84
selected processing only.
85
.IP "authCommunity TYPES COMMUNITY [SOURCE [OID | -v VIEW ]]"
86
authorises traps (and SNMPv2c INFORM requests) with the specified
87
community to trigger the types of processing listed.
88
By default, this will allow any notification using this community
89
to be processed. The SOURCE field can be used to specify that the
90
configuration should only apply to notifications received from
91
particular sources - see \fIsnmpd.conf(5)\fR for more details.
92
.IP "authUser TYPES [-s MODEL] USER [LEVEL [OID | -v VIEW ]]"
93
authorises SNMPv3 notifications with the specified
94
user to trigger the types of processing listed.
95
By default, this will accept authenticated requests.
96
(\fIauthNoPriv\fR or \fIauthPriv\fR). The LEVEL field can
97
be used to allow unauthenticated notifications (\fInoauth\fR),
98
or to require encryption (\fIpriv\fR), just as for the SNMP agent.
100
With both of these directives, the OID (or \fI-v VIEW\fR) field
101
can be used to retrict this configuration to the processing of
102
particular notifications.
105
Unlike the VACM processing described in RFC 3415, this view is
106
\fBonly\fR matched against the \fCsnmpTrapOID\fR value of the
107
incoming notification. It is not applied to the payload varbinds
108
held within that notification.
110
.IP "authGroup TYPES [-s MODEL] GROUP [LEVEL [OID | -v VIEW ]]"
111
.IP "authAccess TYPES [-s MODEL] GROUP VIEW [LEVEL [CONTEXT]]"
112
.IP "setAccess GROUP CONTEXT MODEL LEVEL PREFIX VIEW TYPES"
113
authorise notifications in the specified GROUP
114
(configured using the \fIgroup\fR directive)
115
to trigger the types of processing listed.
116
See \fIsnmpd.conf(5)\fR for more details.
117
.IP "createUser username (MD5|SHA) authpassphrase [DES|AES]"
120
manual page for a description of how to create SNMPv3 users. This
121
is roughly the same, but the file name changes to snmptrapd.conf from
123
.IP "disableAuthorization yes"
124
will disable the above access control checks, and revert to the
125
previous behaviour of accepting all incoming notifications.
127
.\" XXX - Explain why this is a Bad Idea
132
specify the format used to display SNMPv1 TRAPs and SNMPv2
133
notifications respectively. Note that SNMPv2c and SNMPv3
134
both use the same SNMPv2 PDU format.
138
for the layout characters available.
139
.IP "ignoreAuthFailure yes"
140
instructs the receiver to ignore \fIauthenticationFailure\fR traps.
143
This currently only affects the logging of such notifications.
144
\fIauthenticationFailure\fR traps will still be passed to trap
145
handler scripts, and forwarded to other notification receivers.
146
This behaviour should not be relied on, as it is likely
147
to change in future versions.
149
.IP "logOption string"
150
specifies where notifications should be logged - to standard
151
output, standard error, a specified file or via \fIsyslog\fR.
152
See the section LOGGING OPTIONS in the
153
\fIsnmpcmd(1)\fR manual page for details.
154
.IP "outputOption string"
155
specifies various characteristics of how OIDs and other values
157
See the section OUTPUT OPTIONS in the
158
\fIsnmpcmd(1)\fR manual page for details.
159
.IP "printEventNumbers yes"
160
enables specialised logging of event-related notifications from
161
the (long obsolete) M2M-MIB.
163
.\" XXX - CHECK EXACTLY WHICH TRAPS
164
.\" XXX - THIS FEELS OBSOLETE TO ME!
166
.SH NOTIFICATION PROCESSING
167
As well as logging incoming notifications, they can also
168
be forwarded on to another notification receiver, or passed
169
to an external program for specialised processing.
170
.IP "traphandle OID|default PROGRAM [ARGS ...]"
171
invokes the specified program (with the given arguments) whenever a
172
notification is received that matches the OID token. For SNMPv2c and
173
SNMPv3 notifications, this token will be compared against the
174
\fCsnmpTrapOID\fR value taken from the notification. For SNMPv1 traps,
175
the generic and specific trap values and the enterprise OID will be
176
converted into the equivalent OID (following RFC 2576).
178
Typically, the OID token will be the name (or numeric OID) of a
179
NOTIFICATION-TYPE object, and the specified program will be invoked for
180
notifications that match this OID exactly. However this token also
181
supports a simple form of wildcard suffixing. By appending the character
182
'*' to the OID token, the corresponding program will be invoked for any
183
notification based within subtree rooted at the specified OID.
184
For example, an OID token of \fC.1.3.6.1.4.1*\fP would match any enterprise
185
specific notification (including the specified OID itself).
186
An OID token of \fC.1.3.6.1.4.1.*\fP would would work in much the same way,
187
but would not match this exact OID - just notifications that lay strictly
189
Note that this syntax does not support full regular expressions or
190
wildcards - an OID token of the form \fCoid.*.subids\fR is \fBnot\fC valid.
192
If the OID field is the token \fIdefault\fR then the program will be
193
invoked for any notification not matching another (OID specific)
194
\fItraphandle\fR entry.
196
Details of the notification are fed to the program via its standard input.
197
Note that this will always use the SNMPv2-style notification format, with
198
SNMPv1 traps being converted as per RFC 2576, before being passed to the
200
The input format is as follows, one entry per line:
203
The name of the host that sent the notification, as determined by
204
.IR gethostbyaddr(3) .
207
The IP address of the host that sent the notification.
209
.\" XXX - What about non-IPv4 transports?
212
A list of variable bindings describing the contents of the notification,
213
one per line. The first token on each line (up until a space) is the
214
OID of the varind, and the remainder of the line is its value.
215
The format of both of these are controlled by the \fIoutputOption\fR
216
directive (or similar configuration).
218
The first OID should always be \fCSNMPv2-MIB::sysUpTime.0\fR,
219
and the second should be \fCSNMPv2-MIB::snmpTrapOID.0\fR.
220
The remaining lines will contain the payload varbind list.
221
For SNMPv1 traps, the final OID will be \fCSNMPv2-MIB::snmpTrapEnterprise.0\fR.
224
A \fBtraptoemail\fR script has been included in the Net-SNMP package that
225
can be used within a \fItraphandle\fR directive:
229
traphandle default /usr/bin/perl BINDIR/traptoemail -s mysmtp.somewhere.com -f admin@somewhere.com me@somewhere.com
232
.IP "forward OID|default DESTINATION"
233
forwards notifications that match the specified OID
234
to another receiver listening on DESTINATION.
235
The interpretation of OID (and \fIdefault\fR) is the same
236
as for the \fItraphandle\fR directive).
239
.B LISTENING ADDRESSES
242
manual page for more information about the format of listening
247
The daemon blocks while executing the \fItraphandle\fR commands.
249
be fixed in the future with an appropriate signal catch and wait()
252
All directives listed with a value of "yes" actually accept a range
253
of boolean values. These will accept any of \fI1\fR, \fIyes\fR or
254
\fItrue\fR to enable the corresponding behaviour,
255
or any of \fI0\fR, \fIno\fR or \fIfalse\fR to disable it.
256
The default in each case is for the feature to be turned off, so these
257
directives are typically only used to enable the appropriate behaviour.
259
SYSCONFDIR/snmp/snmptrapd.conf
261
snmp_config(5), snmptrapd(8), syslog(8), variables(5), snmpd.conf(5), read_config(3).
added
removed
.pc/56_manpage.patch/man/snmptrapd.conf.5.def
