~ubuntu-branches/ubuntu/hardy/net-snmp/hardy-proposed

« back to all changes in this revision

Viewing changes to man/snmptrapd.conf.5.def

  • Committer: Bazaar Package Importer
  • Author(s): Steve Kowalik
  • Date: 2007-05-10 22:20:23 UTC
  • mfrom: (1.1.5 upstream)
  • Revision ID: james.westby@ubuntu.com-20070510222023-2yqbm8wasqpni3c1
Tags: 5.3.1-5ubuntu1
* Merge from Debian unstable.
* Remaining Ubuntu changes:
  - Remove stop links from rc0 and rc6
* Munge Maintainer field as per spec. 

Show diffs side-by-side

added added

removed removed

Lines of Context:
3
3
.SH NAME
4
4
snmptrapd.conf - configuration file for the Net-SNMP notification receiver
5
5
.SH DESCRIPTION
6
 
.B snmptrapd.conf
7
 
is the configuration file(s) which define how the Net-SNMP SNMP notification
8
 
receiver (trap daemon) operates when it receives a notification.  
9
 
These files may contain any of the directives found in the
10
 
.B DIRECTIVES
11
 
section below.  This file is not required for the daemon to operate,
12
 
receive, or report traps.  It is used solely as a method of providing
13
 
extensibility to the trap daemon.
14
 
.SH PLEASE READ FIRST
15
 
First, make sure you have read the
 
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
11
.I snmp_config(5)
17
 
manual page that
18
 
describes how the Net-SNMP configuration files operate, where they
19
 
are located and how they all work together.
20
 
.SH DIRECTIVES
 
12
manual page.
 
13
.SH IMPORTANT
 
14
Previously,
 
15
.B snmptrapd
 
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
 
20
.B snmptrapd
 
21
is run without a suitable configuration file (or equivalent access
 
22
control settings), then such traps \fBWILL NOT\fR
 
23
be processed.
 
24
See the section \fBACCESS CONTROL\fR for more details.
 
25
.PP
 
26
As with the agent configuration, the
 
27
.I snmptrapd.conf
 
28
directives can be divided into four distinct groups.
 
29
.SH TRAPD BEHAVIOUR
 
30
.IP "snmpTrapdAddr [<transport-specifier>:]<transport-address>[,...]"
 
31
defines a list of listening addresses, on which to receive
 
32
incoming SNMP notifications.
 
33
See the section 
 
34
.B LISTENING ADDRESSES
 
35
in the
 
36
.I snmpd(8)
 
37
manual page for more information about the format of listening
 
38
addresses.
 
39
.IP
 
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.
 
48
.IP
 
49
See the 
 
50
.I snmptrapd(8) 
 
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.
 
56
.IP "doNotFork yes"
 
57
do not fork from the calling shell.
 
58
.IP "pidFile PATH"
 
59
defines a file in which to store the process ID of the
 
60
notification receiver.  By default, this ID is not saved.
 
61
.SH ACCESS CONTROL
 
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.
 
66
.PP
 
67
There are currently three types of processing that can be specified:
 
68
.RS
 
69
.IP "log"
 
70
log the details of the notification - either in a specified file,
 
71
to standard output (or stderr), or via \fIsyslog\fR (or similar).
 
72
.IP "execute"
 
73
pass the details of the trap to a specified handler program, including
 
74
embedded perl.
 
75
.IP "net"
 
76
forward the trap to another notification receiver.
 
77
.RE
 
78
.PP
 
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.
 
99
.IP
 
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.
 
103
.RS
 
104
.IP "Note:"
 
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.
 
109
.RE
 
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]"
 
118
See the 
 
119
.I snmpd.conf(5)
 
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
 
122
snmpd.conf.
 
123
.IP "disableAuthorization yes"
 
124
will disable the above access control checks, and revert to the
 
125
previous behaviour of accepting all incoming notifications.
 
126
.IP
 
127
.\" XXX - Explain why this is a Bad Idea
 
128
.\"
 
129
.SH LOGGING
 
130
.IP "format1 FORMAT"
 
131
.IP "format2 FORMAT"
 
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.
 
135
.IP
 
136
See
 
137
.IR snmptrapd(8)
 
138
for the layout characters available.
 
139
.IP "ignoreAuthFailure yes"
 
140
instructs the receiver to ignore \fIauthenticationFailure\fR traps.
 
141
.RS
 
142
.IP Note:
 
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.
 
148
.RE
 
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
 
156
should be displayed.
 
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.
 
162
.\"
 
163
.\" XXX - CHECK EXACTLY WHICH TRAPS
 
164
.\" XXX - THIS FEELS OBSOLETE TO ME!
 
165
.\"
 
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.
21
170
.IP "traphandle OID|default PROGRAM [ARGS ...]"
22
 
The
23
 
.I traphandle
24
 
configuration directive configures the snmptrapd program to launch an
25
 
external program any time it receives a trap matching the OID token.
26
 
If the OID token is the word
27
 
.I default
28
 
then any trap not matching any other trap handler will call this
29
 
default one instead.
30
 
The program is fed details about the trap to its standard input, in the
31
 
following format, one entry per line:
 
171
invokes the specified program (with the given arguments) whenever a
 
172
notification is received with a \fCsnmpTrapOID\fR value matching the
 
173
OID token.  If this field is \fIdefault\fR then the program will be
 
174
invoked for any notification not matching another (OID specific)
 
175
\fItraphandle\fR entry.
 
176
.RS
 
177
.IP Note:
 
178
An SNMPv1 trap will be converted to an equivalent SNMPv2-style
 
179
notification (following RFC 2576), before selecting the trap
 
180
handler(s) to call.  This will affect both the OIDs listed
 
181
in \fItraphandle\fR entries, and the format of the data passed
 
182
to the trap handler program.
 
183
.RE
 
184
The program is fed details about the notification to its standard input,
 
185
in the following format, one entry per line:
32
186
.RS
33
187
.IP HOSTNAME
34
 
The name of the host in question that sent the trap, as determined by
 
188
The name of the host that sent the notification, as determined by
35
189
.IR gethostbyaddr(3) .
36
190
.br
37
191
.IP IPADDRESS
38
 
The IP address of the host that sent the trap.
 
192
The IP address of the host that sent the notification.
 
193
.\"
 
194
.\" XXX - What about non-IPv4 transports?
 
195
.\"
39
196
.IP VARBINDS
40
 
A list of variable bindings that describe the trap and the variables
41
 
enclosed in it.  The first token on the line, up until the space, in
42
 
the OID and the remainder of the line is its value.  The first OID
43
 
should be the system.sysUpTime.0 OID, and the second should be
44
 
the ...snmpTrap.snmpTrapOID.0 OID.  The remainder of the OIDs, with the
45
 
possible exception of the last one, are the variable bindings
46
 
contained within the trap.  For SNMPv1 traps, the very last OID will
47
 
be the ...snmpTrap.snmpTrapEnterprise OID and its value.  Essentially, 
48
 
SNMPv1 traps have been converted to the SNMPv2 trap PDU type by the
49
 
method described in the SNMPv1/SNMPv2/SNMPv3 coexistence document (RFC2576).
 
197
A list of variable bindings describing the contents of the notification,
 
198
one per line.  The first token on each line (up until a space) is the
 
199
OID of the varind, and the remainder of the line is its value.
 
200
The format of both of these are controlled by the \fIoutputOption\fR
 
201
directive (or similar configuration).
 
202
.IP
 
203
The first OID should always be \fCSNMPv2-MIB::sysUpTime.0\fR,
 
204
and the second should be \fCSNMPv2-MIB::snmpTrapOID.0\fR.
 
205
The remaining lines will contain the payload varbind list.
 
206
For SNMPv1 traps, the final OID will be \fCSNMPv2-MIB::snmpTrapEnterprise.0\fR.
50
207
.br
51
208
.IP Example:
52
 
A traptoemail script has been included in the Net-SNMP package that
53
 
can be used as a trap handle directive:
 
209
A \fBtraptoemail\fR script has been included in the Net-SNMP package that
 
210
can be used within a \fItraphandle\fR directive:
54
211
.br
55
212
.RS
56
213
.P
57
214
traphandle default /usr/bin/perl BINDIR/traptoemail -s mysmtp.somewhere.com -f admin@somewhere.com me@somewhere.com
58
215
.RE
59
216
.RE
60
 
.IP "snmptrapdaddr [<transport-specifier>:]<transport-address>[,...]"
61
 
Makes the agent listen on the specified comma-separated list of
62
 
listening addresses instead of the default behaviour, which is to
63
 
listen on UDP port 162 on all IPv4 interfaces.  See the section 
64
 
.B LISTENING ADDRESSES
65
 
in the
66
 
.I snmpd(8)
67
 
manual page for more information about the format of listening
68
 
addresses.
69
 
.IP "dontRetainLogs true"
70
 
Turns off the support for the NOTIFICATION-LOG-MIB and thus doesn't
71
 
retain logged traps.  Normally the snmptrapd program keeps a certain
72
 
number of traps around in memory so they can be retrieved via querying
73
 
the nlmLogTable and nlmLogvariableTable tables.  
74
 
See the 
75
 
.I snmptrapd(8) 
76
 
manual page and the NOTIFICATION-LOG-MIB for details.
77
 
.IP "createUser username (MD5|SHA) authpassphrase [DES|AES]"
78
 
See the 
79
 
.I snmpd.conf(5)
80
 
manual page for a description of how to create SNMPv3 users.  It's
81
 
roughly the same, but the file name changes to snmptrapd.conf from
82
 
snmpd.conf.
83
 
.RE
84
 
.IP "format1 format"
85
 
The format used to print a SNMPv1 TRAP message. See
86
 
.IR snmptrapd(8)
87
 
for the layout characters available.
88
 
.RE
89
 
.IP "format2 format"
90
 
The format used to print a SNMPv2 TRAP2 or INFORM message (note that
91
 
the SNMPv3 protocol uses SNMPv2 style TRAPs and INFORMs).
92
217
.IP "forward OID|default DESTINATION"
93
 
Forwards traps received to DESTINATION if they match the notification
94
 
type indicated by OID (or the word default forwards them all).
95
 
.RE
96
 
.IP "ignoreAuthFailure (1|yes|true|0|no|false)"
97
 
Whether or not ignore authenticationFailure traps.
98
 
.RE
99
 
.IP "doNotLogTraps (1|yes|true|0|no|false)"
100
 
Whether or not to log traps.  This is
101
 
useful if you want the snmptrapd application to only run traphandle 
102
 
hooks and not to log any traps to any location.
103
 
.RE
104
 
.IP "logOption string"
105
 
Specify where logging output should be directed (standard error or 
106
 
output,  to  a file or via syslog).  See LOGGING OPTIONS in 
107
 
snmpcmd(1) for details.
108
 
.RE
109
 
.IP "outputOption string"
110
 
The same output formatting (-O) options as the other Net-SNMP 
111
 
commands.  See the section  OUTPUT  OPTIONS  in  the snmpcmd(1) 
112
 
manual page.
113
 
.RE
114
 
.IP "printEventNumbers (1|yes|true|0|no|false)"
115
 
Whether or not to print event numbers (rising/falling alarm etc.).
116
 
.RE
117
 
.IP "doNotFork (1|yes|true|0|no|false)"
118
 
Whether or not to fork from the calling shell.
119
 
.RE
120
 
.IP "pidFile string"
121
 
What file to store the process id in
 
218
forwards notifications that match the specified OID
 
219
to another receiver listening on DESTINATION.
 
220
The interpretation of OID (and \fIdefault\fR) is the same
 
221
as for the \fItraphandle\fR directive).
 
222
.IP
 
223
See the section 
 
224
.B LISTENING ADDRESSES
 
225
in the
 
226
.I snmpd(8)
 
227
manual page for more information about the format of listening
 
228
addresses.
122
229
.RE
123
230
.SH NOTES
124
231
.IP o
125
 
The daemon blocks on the executing traphandle commands.  (This should
 
232
The daemon blocks while executing the \fItraphandle\fR commands.
 
233
(This should
126
234
be fixed in the future with an appropriate signal catch and wait()
127
235
combination).
 
236
.IP o
 
237
All directives listed with a value of "yes" actually accept a range
 
238
of boolean values.  These will accept any of \fI1\fR, \fIyes\fR or
 
239
\fItrue\fR to enable the corresponding behaviour, 
 
240
or any of \fI0\fR, \fIno\fR or \fIfalse\fR to disable it.
 
241
The default in each case is for the feature to be turned off, so these
 
242
directives are typically only used to enable the appropriate behaviour.
128
243
.SH FILES
129
244
SYSCONFDIR/snmp/snmptrapd.conf
130
245
.SH "SEE ALSO"