Quick ?s
Cheat Sheets
Man Pages
The Lynx

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

       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.

       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

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

       snmpTrapdAddr [:][,...]
	      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

       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

	      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.

       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).

		     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

	      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]]

	      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.

       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

       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.

       printEventNumbers yes
	      enables specialised logging of event-related notifications  from
	      the (long obsolete) M2M-MIB.

       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
	      .*  would  match any enterprise specific notification
	      (including  the  specified  OID  itself).   An  OID   token   of
	      .*  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

		     The  name	of  the  host  that  sent the notification, as
		     determined by gethostbyaddr(3).

		     The IP address of the host that sent the notification.

		     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

		     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

       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.

       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.


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

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

Yals.net is © 1999-2009 Crescendo Communications
Sharing tech info on the web for more than a decade!
This page was generated Thu Apr 30 17:05:30 2009