SEARCH
NEW RPMS
DIRECTORIES
ABOUT
FAQ
VARIOUS
BLOG
DONATE


YUM REPOSITORY

 
 

MAN page from Trustix net-snmp-5.4-2tr.i586.rpm

SNMPTRAPD.CONF

Section: Net-SNMP (5)
Updated: 29 Jun 2005
Index 

NAME

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

DESCRIPTION

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

IMPORTANT

Previously,snmptrapdwould 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 toincoming notifications. Ifsnmptrapdis run without a suitable configuration file (or equivalent accesscontrol settings), then such traps WILL NOTbe processed.See the section ACCESS CONTROL for more details.

As with the agent configuration, thesnmptrapd.confdirectives can be divided into four distinct groups. 

TRAPD BEHAVIOUR

snmpTrapdAddr [<transport-specifier>:]<transport-address>[,...]
defines a list of listening addresses, on which to receiveincoming SNMP notifications.See the section LISTENING ADDRESSESin thesnmpd(8)manual page for more information about the format of listeningaddresses.
The default behaviour is tolisten on UDP port 162 on all IPv4 interfaces.
doNotRetainNotificationLogs yes
disables support for the NOTIFICATION-LOG-MIB.Normally the snmptrapd program keeps a record of the trapsreceived, which can be retrieved by queryingthe nlmLogTable and nlmLogvariableTable tables. This directive can be used to suppress this behaviour.
See 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 shouldonly 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 thenotification receiver. By default, this ID is not saved.
 

ACCESS CONTROL

Starting with release 5.3, it is necessary to explicitly specifywho is authorised to send traps and informs to the notificationreceiver (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, includingembedded 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 willtypically be log,execute,net to cover any style of processingfor a particular category of notification. But it is perfectlypossible (even desirable) to limit certain notification sources toselected processing only.

authCommunity TYPES COMMUNITY [SOURCE [OID | -v VIEW ]]
authorises traps (and SNMPv2c INFORM requests) with the specifiedcommunity to trigger the types of processing listed.By default, this will allow any notification using this communityto be processed. The SOURCE field can be used to specify that theconfiguration should only apply to notifications received fromparticular sources - see snmpd.conf(5) for more details.
authUser TYPES [-s MODEL] USER [LEVEL [OID | -v VIEW ]]
authorises SNMPv3 notifications with the specifieduser to trigger the types of processing listed.By default, this will accept authenticated requests.(authNoPriv or authPriv). The LEVEL field canbe used to allow unauthenticated notifications (noauth),or to require encryption (priv), just as for the SNMP agent.
With both of these directives, the OID (or -v VIEW) fieldcan be used to retrict this configuration to the processing ofparticular notifications.
Note:
Unlike the VACM processing described in RFC 3415, this view isonly matched against the snmpTrapOID value of theincoming notification. It is not applied to the payload varbindsheld within that notification.
authGroup TYPES [-s MODEL] GROUP [LEVEL [OID | -v VIEW ]]
authAccess TYPES [-s MODEL] GROUP VIEW [LEVEL [CONTEXT]]
setAccess GROUP CONTEXT MODEL LEVEL PREFIX VIEW TYPES
authorise notifications in the specified GROUP(configured using the group directive)to trigger the types of processing listed.See snmpd.conf(5) for more details.
createUser username (MD5|SHA) authpassphrase [DES|AES]
See the snmpd.conf(5)manual page for a description of how to create SNMPv3 users. Thisis roughly the same, but the file name changes to snmptrapd.conf fromsnmpd.conf.
disableAuthorization yes
will disable the above access control checks, and revert to theprevious behaviour of accepting all incoming notifications.
 

LOGGING

format1 FORMAT
format2 FORMAT
specify the format used to display SNMPv1 TRAPs and SNMPv2notifications respectively. Note that SNMPv2c and SNMPv3both use the same SNMPv2 PDU format.
Seesnmptrapd(8)for the layout characters available.
ignoreAuthFailure yes
instructs the receiver to ignore authenticationFailure traps.
Note:
This currently only affects the logging of such notifications.authenticationFailure traps will still be passed to traphandler scripts, and forwarded to other notification receivers.This behaviour should not be relied on, as it is likelyto change in future versions.
logOption string
specifies where notifications should be logged - to standardoutput, standard error, a specified file or via syslog.See the section LOGGING OPTIONS in thesnmpcmd(1) manual page for details.
outputOption string
specifies various characteristics of how OIDs and other valuesshould be displayed.See the section OUTPUT OPTIONS in thesnmpcmd(1) manual page for details.
printEventNumbers yes
enables specialised logging of event-related notifications fromthe (long obsolete) M2M-MIB.
 

NOTIFICATION PROCESSING

As well as logging incoming notifications, they can alsobe forwarded on to another notification receiver, or passedto an external program for specialised processing.
traphandle OID|default PROGRAM [ARGS ...]
invokes the specified program (with the given arguments) whenever anotification is received that matches the OID token. For SNMPv2c andSNMPv3 notifications, this token will be compared against thesnmpTrapOID value taken from the notification. For SNMPv1 traps,the generic and specific trap values and the enterprise OID will beconverted into the equivalent OID (following RFC 2576).
Typically, the OID token will be the name (or numeric OID) of aNOTIFICATION-TYPE object, and the specified program will be invoked fornotifications that match this OID exactly. However this token alsosupports a simple form of wildcard suffixing. By appending the characternotification based within subtree rooted at the specified OID.For example, an OID token of .1.3.6.1.4.1* would match any enterprisespecific 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 strictlybelow this root.Note that this syntax does not support full regular expressions orwildcards - an OID token of the form oid.*.subids is not valid.
If the OID field is the token default then the program will beinvoked 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, withSNMPv1 traps being converted as per RFC 2576, before being passed to theprogram.The input format is as follows, one entry per line:

HOSTNAME
The name of the host that sent the notification, as determined bygethostbyaddr(3).
IPADDRESS
The IP address of the host that sent the notification.
VARBINDS
A list of variable bindings describing the contents of the notification,one per line. The first token on each line (up until a space) is theOID of the varind, and the remainder of the line is its value.The format of both of these are controlled by the outputOptiondirective (or similar configuration).
The first OID should always be SNMPv2-MIB::sysUpTime.0,and the second should be SNMPv2-MIB::snmpTrapOID.0.The remaining lines will contain the payload varbind list.For SNMPv1 traps, the final OID will be SNMPv2-MIB::snmpTrapEnterprise.0.
Example:
A traptoemail script has been included in the Net-SNMP package thatcan be used within a traphandle directive:
traphandle default /usr/bin/perl /usr/bin/traptoemail -s mysmtp.somewhere.com -f admin@somewhere.com meAATTsomewhere.com
forward OID|default DESTINATION
forwards notifications that match the specified OIDto another receiver listening on DESTINATION.The interpretation of OID (and default) is the sameas for the traphandle directive).
See the section LISTENING ADDRESSESin thesnmpd(8)manual page for more information about the format of listeningaddresses.
 

NOTES

o
The daemon blocks while executing the traphandle commands.(This shouldbe fixed in the future with an appropriate signal catch and wait()combination).
o
All directives listed with a value of "yes" actually accept a rangeof boolean values. These will accept any of 1, yes ortrue 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 thesedirectives are typically only used to enable the appropriate behaviour.
 

FILES

/etc/snmp/snmptrapd.conf 

SEE ALSO

snmp_config(5), snmptrapd(8), syslog(8), variables(5), snmpd.conf(5), read_config(3).


 

Index

NAME
DESCRIPTION
IMPORTANT
TRAPD BEHAVIOUR
ACCESS CONTROL
LOGGING
NOTIFICATION PROCESSING
NOTES
FILES
SEE ALSO

This document was created byman2html,using the manual pages.