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


   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
   snmp_config(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
   configuration 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 [<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

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


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

                 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.

   authUser   TYPES [-s MODEL] USER  [LEVEL [OID | -v VIEW ]]
          authorises  SNMPv3  notifications  with  the  specified  user to
          trigger 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
          particular 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 ]]


          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 [-e  ENGINEID] 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
          notifications  respectively.   Note that SNMPv2c and SNMPv3 both
          use the same SNMPv2 PDU format.

          specify the format used for different destinations.  DESTINATION
          is  one  of:  print,  print1,  print2, syslog, syslog1, syslog2,
          execute, execute1, execute2.  print1 is used for printing SNMPv1
          traps,  print2  is for SNMPv2.  print is used for both versions.
          syslog is similarly used  when  sending  traps  to  syslog,  and
          execute   used   when   sending  traps  to  a  program  such  as

          The default formats are
          format print1 %.4y-%.2m-%.2l  %.2h:%.2j:%.2k  %B  [%b]  (via  %A
          [%a]): %N\n\t%W Trap (%q) Uptime: %#T\n%v\n
          format print2 %.4y-%.2m-%.2l %.2h:%.2j:%.2k %B [%b]:\n%v\n
          format syslog1 %a: %W Trap (%q) Uptime: %#T%#v\n
          format syslog2 %B [%b]: Trap %#v\n
          format execute %B\n%b\n%V\n%v\n

          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
                 notifications.  authenticationFailure traps will still be
                 passed  to  trap  handler scripts, and forwarded to other
                 notification 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
          snmpcmd(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.


   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  *'  to  the   OID   token,   the
          corresponding program will be invoked for any 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, if you use the default set
   by the "format execute %B\n%b\n%V\n%v\n", one entry per line:

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

                 The transport address, like
                 "[UDP: []:23456->[]]"

                 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

   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
          feature to be turned off, so these directives are typically only
          used to enable the appropriate behaviour.




   snmp_config(5), snmptrapd(8), syslog(8), traptoemail(1),  variables(5),

More Linux Commands

glTexCoord4d(3gl) - set the current texture coordinates.....
glTexCoord specifies texture coordinates in one, two, three, or four dimensions. glTexCoord1 sets the current texture coordinates to (s, 0, 0, 1); a call to glT

CPU_ZERO(3) - macros for manipulating CPU sets (Man Page)...
The cpu_set_t data structure represents a set of CPUs. CPU sets are used by sched_setaffinity(2) and similar interfaces. The cpu_set_t data type is implemented

pthread_attr_setstack(3) - set/get stack attributes in threa
The pthread_attr_setstack() function sets the stack address and stack size attributes of the thread attributes object referred to by attr to the values specifie

isnanf(3) - BSD floating-point classification functions.....
The finite(), finitef(), and finitel() functions return a nonzero value if x is neither infinite nor a not-a-number (NaN) value, and 0 otherwise. The isnan(), i

curl_easy_cleanup(3) - End a libcurl easy session (ManPage)
This function must be the last function to call for an easy session. It is the opposite of the curl_easy_init(3) function and must be called with the same handl

slk_restore(3ncurses) - curses soft label routines (ManPage)
The slk* functions manipulate the set of soft function-key labels that exist on many terminals. For those terminals that do not have soft labels, curses takes o

sha(1ssl) message digests (Commands - Linux manual page)....
The digest functions output the message digest of a supplied file or files in hexadecimal. The digest functions also generate and verify digital signatures usin

getpt(3) - open the pseudoterminal master (PTM) (Man Page)
getpt() opens a pseudoterminal master and returns its file descriptor. It is equivalent to open(/dev/ptmx, O_RDWR | O_NOCTTY); on Linux systems, though the pseu

dmevent_tool(8) - A utility used to load a DSO into dmeventd
dmevent_tool is a userspace utility used to register/unregister DSOs with the daemon dmeventd. If used with the -m command line parameter users can display all

getpmsg(2) - unimplemented system calls - Linux manual page
These system calls are not implemented in the Linux kernel. RETURN VALUE These system calls always return -1 and set errno to ENOSYS. NOTES Note that ftime(3),

menu_opts_on(3menu) - set and get menu options (Man Page)...
The function set_menu_opts sets all the given menus option bits (menu option bits may be logically-ORed together). The function menu_opts_on turns on the given

dbus-uuidgen(1) - Utility to generate UUIDs - Linux man page
The dbus-uuidgen command generates or reads a universally unique ID. Note that the D-Bus UUID has no relationship to RFC 4122 and does not generate UUIDs compat

We can't live, work or learn in freedom unless the software we use is free.