SNMPTRAPD.CONF(5)		   Net-SNMP		     SNMPTRAPD.CONF(5)



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

DESCRIPTION
       The Net-SNMP notification receiver (trap daemon) uses one or more  con-
       figuration  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 snmp_con-
       fig(5) manual page.

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 configu-
       ration 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 snmpd(8) manual page for more information about
	      the format of listening addresses.

	      The default behaviour is to listen 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  traps  received,	 which
	      can  be  retrieved  by  querying the nlmLogTable and nlmLogvari-
	      ableTable 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  use-
	      ful  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 notifica-
	      tion 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	speci-
		     fied  file, to standard output (or stderr), or via syslog
		     (or similar).

	      execute
		     pass the details of the trap to a specified handler  pro-
		     gram, 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 cate-
       gory 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 speci-
	      fied 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.

       authUser	  TYPES [-s MODEL] USER	 [LEVEL [OID | -v VIEW ]]
	      authorises SNMPv3 notifications with the specified user to trig-
	      ger  the	types  of  processing  listed.	 By default, this will
	      accept authenticated requests.  (authNoPriv  or  authPriv).  The
	      LEVEL  field  can be 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) field can be
	      used to retrict this configuration to the processing of particu-
	      lar notifications.

	      Note:  Unlike  the  VACM	processing described in RFC 3415, this
		     view is only matched against the snmpTrapOID value of the
		     incoming  notification.  It is not applied to the payload
		     varbinds held 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.   This  is roughly the same, but the file
	      name changes to snmptrapd.conf from snmpd.conf.

       disableAuthorization yes
	      will disable the above access control checks, and revert to  the
	      previous behaviour of accepting all incoming notifications.

LOGGING
       format1 FORMAT

       format2 FORMAT
	      specify the format used to display SNMPv1 TRAPs and SNMPv2 noti-
	      fications respectively.  Note that SNMPv2c and SNMPv3  both  use
	      the same SNMPv2 PDU format.

	      See snmptrapd(8) for the layout characters available.

       ignoreAuthFailure yes
	      instructs the receiver to ignore authenticationFailure traps.

	      Note:  This currently only affects the logging of such notifica-
		     tions.  authenticationFailure traps will still be	passed
		     to trap handler scripts, and forwarded to other notifica-
		     tion receivers.  This behaviour should not be relied  on,
		     as it is likely to change in future versions.

       logOption string
	      specifies	 where	notifications  should  be logged - to standard
	      output, standard error, a specified file or via syslog.  See the
	      section  LOGGING	OPTIONS	 in  the  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 snm-
	      pcmd(1) manual page for details.

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)	 when-
	      ever 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 (fol-
	      lowing 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 gethostbyaddr(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 the OID of the varind, and the
		     remainder of the line is its value.  The format  of  both
		     of these are controlled by the outputOption directive (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 that can be used within a traphandle directive:

		     traphandle	 default /usr/bin/perl /usr/bin/traptoemail -s
		     mysmtp.somewhere.com  -f	admin@somewhere.com   me@some-
		     where.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 snmpd(8) manual page
	      for more information about the format of listening addresses.

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 fea-
	      ture to be turned off, so these directives  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).




4th Berkeley Distribution	  29 Jun 2005		     SNMPTRAPD.CONF(5)