Content-type: text/html Manpage of SNMPTRAPD.CONF

SNMPTRAPD.CONF

Section: Net-SNMP (5)
Updated: 29 Jun 2005
Index Return to Main Contents
 

NAME

snmptrapd.conf - configuration file for the Net-SNMP notification receiver  

DESCRIPTION

The Net-SNMP notification receiver (trap daemon) uses one or more configuration files to control its operation and how incoming traps (and INFORM requests) should be processed. This file (snmptrapd.conf) can be located in one of several locations, as described in the  

IMPORTANT

Previously, snmptrapd would accept all incoming notifications, and log them automatically (even if no explicit configuration was provided). Starting with release 5.3, access control checks will be applied to incoming notifications. If snmptrapd is run without a suitable configuration file (or equivalent access control settings), then such traps WILL NOT be processed. See the section ACCESS CONTROL for more details.

As with the agent configuration, the snmptrapd.conf directives can be divided into four distinct groups.  

TRAPD BEHAVIOUR

snmpTrapdAddr [<transport-specifier>:]<transport-address>[,...]
defines a list of listening addresses, on which to receive incoming SNMP notifications. See the section LISTENING ADDRESSES in the snmptrapd(8) manual page and the NOTIFICATION-LOG-MIB for details.
doNotLogTraps yes
disables the logging of notifications altogether. This is useful if the snmptrapd application should only run traphandle hooks and should not log traps to any location.
doNotFork yes
do not fork from the calling shell.
pidFile PATH
defines a file in which to store the process ID of the notification receiver. By default, this ID is not saved.
 

ACCESS CONTROL

Starting with release 5.3, it is necessary to explicitly specify who is authorised to send traps and informs to the notification receiver (and what types of processing these are allowed to trigger). This uses an extension of the VACM model, used in the main SNMP agent.

There are currently three types of processing that can be specified:

log
log the details of the notification - either in a specified file, to standard output (or stderr), or via syslog (or similar).
execute
pass the details of the trap to a specified handler program, including embedded perl.
net
forward the trap to another notification receiver.

In the following directives, TYPES will be a (comma-separated) list of one or more of these tokens. Most commonly, this will typically be log,execute,net to cover any style of processing for a particular category of notification. But it is perfectly possible (even desirable) to limit certain notification sources to selected processing only.

authCommunity TYPES COMMUNITY [SOURCE [OID | -v VIEW ]]
authorises traps (and SNMPv2c INFORM requests) with the specified community to trigger the types of processing listed. By default, this will allow any notification using this community to be processed. The SOURCE field can be used to specify that the configuration should only apply to notifications received from particular sources - see snmpd.conf(5) for more details.
createUser username (MD5|SHA) authpassphrase [DES|AES]
See the  

LOGGING

format1 FORMAT
format2 FORMAT
specify the format used to display SNMPv1 TRAPs and SNMPv2 notifications respectively. Note that SNMPv2c and SNMPv3 both use the same SNMPv2 PDU format.
See snmpcmd(1) manual page for details.
outputOption string
specifies various characteristics of how OIDs and other values should be displayed. See the section OUTPUT OPTIONS in the  

MySQL Logging

There are two configuration variables that work together to control when queued traps are logged to the MySQL database. A non-zero value must be specified for sqlSaveInterval to enable MySQL logging.
sqlMaxQueue max
specifies the maximum number of traps to queue before a forced flush to the MySQL database.
sqlSaveInterval seconds
specified the number of seconds between periodic queue flushes. A value of 0 for will disable MySQL logging.
 

NOTIFICATION PROCESSING

As well as logging incoming notifications, they can also be forwarded on to another notification receiver, or passed to an external program for specialised processing.
traphandle OID|default PROGRAM [ARGS ...]
invokes the specified program (with the given arguments) whenever a notification is received that matches the OID token. For SNMPv2c and SNMPv3 notifications, this token will be compared against the snmpTrapOID value taken from the notification. For SNMPv1 traps, the generic and specific trap values and the enterprise OID will be converted into the equivalent OID (following RFC 2576).
Typically, the OID token will be the name (or numeric OID) of a NOTIFICATION-TYPE object, and the specified program will be invoked for notifications that match this OID exactly. However this token also supports a simple form of wildcard suffixing. By appending the character notification based within subtree rooted at the specified OID. For example, an OID token of .1.3.6.1.4.1* would match any enterprise specific notification (including the specified OID itself). An OID token of .1.3.6.1.4.1.* would would work in much the same way, but would not match this exact OID - just notifications that lay strictly below this root. Note that this syntax does not support full regular expressions or wildcards - an OID token of the form oid.*.subids is not valid.
If the OID field is the token default then the program will be invoked for any notification not matching another (OID specific) traphandle entry.

Details of the notification are fed to the program via its standard input. Note that this will always use the SNMPv2-style notification format, with SNMPv1 traps being converted as per RFC 2576, before being passed to the program. The input format is as follows, one entry per line:

HOSTNAME
The name of the host that sent the notification, as determined by admin@somewhere.com me@somewhere.com
forward OID|default DESTINATION
forwards notifications that match the specified OID to another receiver listening on DESTINATION. The interpretation of OID (and default) is the same as for the traphandle directive).
See the section LISTENING ADDRESSES in the  

NOTES

o
The daemon blocks while executing the traphandle commands. (This should be fixed in the future with an appropriate signal catch and wait() combination).
o
All directives listed with a value of "yes" actually accept a range of boolean values. These will accept any of 1, yes or true to enable the corresponding behaviour, or any of 0, no or false to disable it. The default in each case is for the feature to be turned off, so these directives are typically only used to enable the appropriate behaviour.
 

FILES

/usr/local/etc/snmp/snmptrapd.conf  

SEE ALSO

 

Index

NAME
DESCRIPTION
IMPORTANT
TRAPD BEHAVIOUR
ACCESS CONTROL
LOGGING
MySQL Logging
NOTIFICATION PROCESSING
NOTES
FILES
SEE ALSO
This document was created by man2html, using the manual pages.
Time: 19:05:39 GMT, September 28, 2009