Provided by: snmpd_5.9.1+dfsg-1ubuntu2.6_amd64 bug

NAME

       snmpd.conf - configuration file for the Net-SNMP SNMP agent

DESCRIPTION

       The  Net-SNMP  agent uses one or more configuration files to control its operation and the
       management information provided.  These files (snmpd.conf  and  snmpd.local.conf)  can  be
       located in one of several locations, as described in the snmp_config(5) manual page.

       The  (perl)  application snmpconf can be used to generate configuration files for the most
       common agent requirements.  See the snmpconf(1) manual page for more information,  or  try
       running the command:

              snmpconf -g basic_setup

       There  are  a large number of directives that can be specified, but these mostly fall into
       four distinct categories:

       •      those controlling who can access the agent

       •      those configuring the information that is supplied by the agent

       •      those controlling active monitoring of the local system

       •      those concerned with extending the functionality of the agent.

       Some directives don't fall naturally into any of these four categories,  but  this  covers
       the  majority  of  the  contents  of a typical snmpd.conf file.  A full list of recognised
       directives can be obtained by running the command:

              snmpd -H

AGENT BEHAVIOUR

       Although most configuration directives are concerned with the MIB information supplied  by
       the  agent,  there  are  a  handful  of  directives  that  control  the behaviour of snmpd
       considered simply as a daemon providing a network service.

       agentaddress [<transport-specifier>:]<transport-address>[,...]
              defines a list of listening addresses, on which to receive incoming SNMP  requests.
              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 161 on all IPv4 interfaces.

       agentgroup {GROUP|#GID}
              changes to the specified group after opening the listening port(s).  This may refer
              to a group by name (GROUP), or a numeric group ID starting with '#' (#GID).

       agentuser {USER|#UID}
              changes  to the specified user after opening the listening port(s).  This may refer
              to a user by name (USER), or a numeric user ID starting with '#' (#UID).

       leave_pidfile yes
              instructs the agent  to  not  remove  its  pid  file  on  shutdown.  Equivalent  to
              specifying "-U" on the command line.

       maxGetbulkRepeats NUM
              Sets  the  maximum  number  of responses allowed for a single variable in a getbulk
              request.  Set to 0 to enable the default and set it  to  -1  to  enable  unlimited.
              Because  memory  is  allocated  ahead  of  time,  setting  this to unlimited is not
              considered safe if your user population  can  not  be  trusted.   A  repeat  number
              greater than this will be truncated to this value.

              This is set by default to -1.

       maxGetbulkResponses NUM
              Sets the maximum number of responses allowed for a getbulk request.  This is set by
              default to 100.  Set to 0 to enable  the  default  and  set  it  to  -1  to  enable
              unlimited.  Because memory is allocated ahead of time, setting this to unlimited is
              not considered safe if your user population can not be trusted.

              In general, the total number of  responses  will  not  be  allowed  to  exceed  the
              maxGetbulkResponses  number,  and  the  total  number  returned  will be an integer
              multiple of the number of  variables  requested  times  the  calculated  number  of
              repeats allow to fit below this number.

              Also note that processing of maxGetbulkRepeats is handled first.

       ifmib_max_num_ifaces NUM
              Sets  the  maximum  number  of  interfaces included in IF-MIB data collection.  For
              servers with a large number of interfaces (ppp,  dummy,  bridge,  etc)  the  IF-MIB
              processing  will  take  a  large chunk of CPU for ioctl calls (on Linux). Setting a
              reasonable maximum for the CPU used will reduce the CPU load for IF-MIB processing.
              For example, configuring "ifmib_max_num_ifaces 500" will include only the first 500
              interfaces based on ifindex and ignore all others for IF-MIB processing.

              The default (without this configured) is to include all interfaces.

       include_ifmib_iface_prefix PREFIX1 PREFIX2 ...
              Sets the interface name prefixes to include in the  IF-MIB  data  collection.   For
              servers  with  a  large  number  of interfaces (ppp, dummy, bridge, etc) the IF-MIB
              processing will take a large chunk of CPU for ioctl calls  (on  Linux).  A  set  of
              space  separated  interface  name  prefixes  will  reduce  the  CPU load for IF-MIB
              processing.  For example, configuring  "include_ifmib_iface_prefix  eth  dummy  lo"
              will  include  only interfaces with these prefixes and ignore all others for IF-MIB
              processing. If regex support is compiled in, each of  the  prefixes  is  a  regular
              expression (which is not permitted to contain a space or tab character).

              The default (without this configured) is to include all interfaces.

   SNMPv3 Configuration - Real Security
       SNMPv3  is  added  flexible  security models to the SNMP packet structure so that multiple
       security solutions could be used.  SNMPv3 was original defined with a "User-based Security
       Model"  (USM) [RFC3414] that required maintaining a SNMP-specific user database.  This was
       later determined to be troublesome to maintain and had some minor  security  issues.   The
       IETF  has  since  added  additional  security models to tunnel SNMP over SSH [RFC5592] and
       DTLS/TLS [RFC-to-be].  Net-SNMP contains robust support for  SNMPv3/USM,  SNMPv3/TLS,  and
       SNMPv3/DTLS.   It  contains  partial  support  for  SNMPv3/SSH as well but has not been as
       extensively tested.  It also contains code for support for an experimental Kerberos  based
       SNMPv3 that never got standardized.

       Hopefully  more SNMP software and devices will eventually support SNMP over (D)TLS or SSH,
       but it is likely that devices with original support for SNMP will only contain support for
       USM  users.  If your network manager supports SNMP over (D)TLS or SNMP over SSH we suggest
       you use one of these mechanisms instead of using USM, but as always with Net-SNMP we  give
       you the options to pick from so you can make the choice that is best for you.

   SNMPv3 generic parameters
       These  parameters  are  generic  to  all the forms of SNMPv3.  The SNMPv3 protocol defines
       "engineIDs" that uniquely identify an agent.  The string must be consistent  through  time
       and  should not change or conflict with another agent's engineID.  Ever.  Internally, Net-
       SNMP by default creates a unique engineID that is based off of the current system time and
       a  random  number.   This  should be sufficient for most users unless you're embedding our
       agent in a device where these numbers won't vary between  boxes  on  the  devices  initial
       boot.

              EngineIDs  are  used  both as a "context" for selecting information from the device
              and SNMPv3 with USM uses it to create unique entries for users in its user table.

              The Net-SNMP agent offers the following mechanisms for setting  the  engineID,  but
              again you should only use them if you know what you're doing:

       engineID STRING
              specifies that the engineID should be built from the given text STRING.

       engineIDType 1|2|3
              specifies that the engineID should be built from the IPv4 address (1), IPv6 address
              (2) or MAC address (3).  Note that  changing  the  IP  address  (or  switching  the
              network interface card) may cause problems.

       engineIDNic INTERFACE
              defines which interface to use when determining the MAC address.  If engineIDType 3
              is not specified, then this directive has no effect.

              The default is to use eth0.

   SNMPv3 over TLS
       SNMPv3 may be tunneled over TLS and  DTLS.   TLS  runs  over  TCP  and  DTLS  is  the  UDP
       equivalent.   Wes Hardaker (the founder of Net-SNMP) performed a study and presented it at
       an IETF meeting that showed that TCP based protocols are sufficient  for  stable  networks
       but  quickly  becomes  a  problem in unstable networks with even moderate levels of packet
       loss (~ 20-30%).  If you are going to use TLS or DTLS, you should use the one  appropriate
       for  your  networking  environment.   You  should  potentially  turn  them both on so your
       management system can access either the UDP or the TCP port as needed.

       Many of the configuration tokens described below are prefixed with a '[snmp]' tag.  If you
       place these tokens in your snmpd.conf file, this take is required.  See the snmp_config(5)
       manual page for the meaning of this context switch.

       [snmp] localCert <specifier>
              This token defines the default X.509 public key to use as  the  server's  identity.
              It  should  either be a fingerprint or a filename.  To create a public key for use,
              please run the "net-snmp-cert" utility which will  help  you  create  the  required
              certificate.

              The  default  value  for  this  is the certificate in the "snmpd" named certificate
              file.

       [snmp] tlsAlgorithms <algorithms>
              This string will select the algorithms to  use  when  negotiating  security  during
              (D)TLS  session  establishment.  See the openssl manual page ciphers(1) for details
              on the format.  Examples strings include:

              DEFAULT
              ALL
              HIGH
              HIGH:!AES128-SHA

              The default value is whatever openssl itself was configured with.

       [snmp] x509CRLFile
              If you are  using  a  Certificate  Authority  (CA)  that  publishes  a  Certificate
              Revocation  List  (CRL)  then this token can be used to specify the location in the
              filesystem of a copy of the CRL file.  Note that Net-SNMP will not pull a CRL  over
              http  and  this must be a file, not a URL.  Additionally, OpenSSL does not reload a
              CRL file when it has changed so modifications or updates to the file will  only  be
              noticed upon a restart of the snmpd agent.

       certSecName PRIORITY FINGERPRINT OPTIONS
              OPTIONS can be one of <--sn SECNAME | --rfc822 | --dns | --ip | --cn | --any>.

              The certSecName token will specify how to map a certificate field from the client's
              X.509 certificate to a SNMPv3 username.  Use the  --sn  SECNAME  flag  to  directly
              specify  a  securityName  for  a  given  certificate.   The  other  flags extract a
              particular component of the certificate for use as a  snmpv3  securityName.   These
              fields   are   one   of:   A   SubjectAltName   containing   an  rfc822  value  (eg
              hardaker@net-snmp.org),  A  SubjectAltName  containing  a  dns   name   value   (eg
              foo.net-snmp.org),  an  IP  address (eg 192.0.2.1) or a common name "Wes Hardaker".
              The --any flag specifies that any of the subjecAltName fields may  be  used.   Make
              sure  once  a securityName has been selected that it is given authorization via the
              VACM controls discussed later in this manual page.

              See  the  http://www.net-snmp.org/wiki/index.php/Using_DTLS  web  page   for   more
              detailed instructions for setting up (D)TLS.

       trustCert <specifier>
              For X509 to properly verify a certificate, it should be verifiable up until a trust
              anchor for it.  This trust anchor is typically a CA certificate but it  could  also
              be  a  self-signed  certificate.   The  "trustCert"  token  should  be used to load
              specific trust anchors into the verification engine.

       SNMP over (D)TLS requires the use of the Transport  Security  Model  (TSM),  so  read  the
       section  on  the  usage  of  the  Transport  Security  Model  as well.  Make sure when you
       configure the VACM to accept connections from (D)TLS  that  you  use  the  "tsm"  security
       model.  E.G.:

       rwuser -s tsm hardaker@net-snmp.org

   SNMPv3 over SSH Support
       To  use  SSH,  you'll  need  to  configure sshd to invoke the sshtosnmp program as well as
       configure the access control settings to allow access through the tsm security model using
       the user name provided to snmpd by the ssh transport.

   SNMPv3 with the Transport Security Model (TSM)
       The  Transport  Security  Model  [RFC5591]  defines  a SNMPv3 security system for use with
       "tunneled" security protocols like TLS, DTLS and SSH.  It is a very simple security  model
       that  simply  lets  properly  protected packets to pass through into the snmp application.
       The transport is required to pass a securityName to  use  to  the  TSM  and  the  TSM  may
       optionally prefix this with a transport string (see below).

       tsmUseTransportPrefix (1|yes|true|0|no|false)
              If  set  to true, the TSM module will take every securityName passed to it from the
              transports underneath and prefix it with a string that specifically identities  the
              transport  it  came  from.   This  is  useful  to  avoid  securityName clashes with
              transports that generate  identical  security  names.   For  example,  if  the  ssh
              security  transport  delivered the security name of "hardaker" for a SSH connection
              and the TLS security transport also delivered the security name of "hardaker" for a
              TLS  connection  then  it  would  be  impossible to separate out these two users to
              provide separate access control rights.   With  the  tsmUseTransportPrefix  set  to
              true,  however,  the  securityNames  would  be  prefixed appropriately with one of:
              "tls:", "dtls:" or "ssh:".

   SNMPv3 with the User-based Security Model (USM)
       SNMPv3 was originally defined using the User-Based Security Model (USM), which contains  a
       private  list  of  users  and  keys  specific  to  the  SNMPv3  protocol.  The operational
       community, however, declared it a pain to manipulate yet another database and would prefer
       to  use  existing  infrastructure.  To that end the IETF created the ISMS working group to
       battle that problem, and the ISMS working group decided to tunnel SNMP over SSH  and  DTLS
       to make use existing user and authentication infrastructures.

   SNMPv3 USM Users
       To use the USM based SNMPv3-specific users, you'll need to create them.  It is recommended
       you use the net-snmp-config command to do this,  but  you  can  also  do  it  by  directly
       specifying createUser directives yourself instead:

       createUser [-e ENGINEID] username (MD5|SHA|SHA-512|SHA-384|SHA-256|SHA-224) authpassphrase
       [DES|AES] [privpassphrase]

              MD5|SHA|SHA-512|SHA-384|SHA-256|SHA-224 are the authentication types to  use.   DES
              and  AES  are  the  privacy  protocols  to  use.   If the privacy passphrase is not
              specified, it is assumed to be the same as  the  authentication  passphrase.   Note
              that  the  users  created  will  be  useless unless they are also added to the VACM
              access control tables described above.

              SHA|SHA-512|SHA-384|SHA-256|SHA-224  authentication  and  DES/AES  privacy  require
              OpenSSL  to  be  installed  and  the  agent  to be built with OpenSSL support.  MD5
              authentication may be used without OpenSSL.

              Warning: the minimum pass phrase length is 8 characters.

              SNMPv3 users can be created at runtime using the snmpusm(1) command.

              Instead of figuring out how to use this directive and where to put it (see  below),
              just  run  "net-snmp-config  --create-snmpv3-user"  instead,  which will add one of
              these lines to the right place.

              This directive should be placed into the /var/lib/snmp/snmpd.conf file  instead  of
              the  other  normal  locations.  The reason is that the information is read from the
              file and then the line is removed (eliminating the storage of the  master  password
              for  that  user)  and replaced with the key that is derived from it.  This key is a
              localized key, so that if it is stolen it can not be used to access  other  agents.
              If the password is stolen, however, it can be.

              If you need to localize the user to a particular EngineID (this is useful mostly in
              the similar snmptrapd.conf file), you  can  use  the  -e  argument  to  specify  an
              EngineID as a hex value (EG, "0x01020304").

              If  you want to generate either your master or localized keys directly, replace the
              given password with a hexstring (preceded by a "0x") and precede the hex string  by
              a -m or -l token (respectively).  EGs:

              [these keys are *not* secure but are easy to visually parse for
              counting purposes.  Please generate random keys instead of using
              these examples]

              createUser myuser SHA -l 0x0001020304050607080900010203040506070809 AES -l 0x00010203040506070809000102030405
              createUser myuser SHA -m 0x0001020304050607080900010203040506070809 AES -m 0x0001020304050607080900010203040506070809

              Due  to the way localization happens, localized privacy keys are expected to be the
              length needed by the algorithm (128 bits for  all  supported  algorithms).   Master
              encryption  keys,  though,  need  to  be  the length required by the authentication
              algorithm not the length required by the encrypting algorithm (MD5: 16 bytes,  SHA:
              20 bytes).

ACCESS CONTROL

       snmpd  supports  the  View-Based  Access  Control  Model (VACM) as defined in RFC 2575, to
       control who can retrieve or update  information.   To  this  end,  it  recognizes  various
       directives relating to access control.

   Traditional Access Control
       Most   simple   access   control  requirements  can  be  specified  using  the  directives
       rouser/rwuser (for SNMPv3) or rocommunity/rwcommunity (for SNMPv1 or SNMPv2c).

       rouser [-s SECMODEL] USER [noauth|auth|priv [OID | -V VIEW [CONTEXT]]]

       rwuser [-s SECMODEL]  USER [noauth|auth|priv [OID | -V VIEW [CONTEXT]]]
              specify an SNMPv3 user that will be allowed read-only (GET and  GETNEXT)  or  read-
              write  (GET,  GETNEXT  and SET) access respectively.  By default, this will provide
              access to  the  full  OID  tree  for  authenticated  (including  encrypted)  SNMPv3
              requests,  using the default context.  An alternative minimum security level can be
              specified using noauth (to allow unauthenticated requests), or priv (to enforce use
              of encryption).  The OID field restricts access for that user to the subtree rooted
              at the given OID, or the named view.  An optional context can also be specified, or
              "context*"  to  denote  a context prefix.  If no context field is specified (or the
              token "*" is used), the directive will match all possible contexts.

              If SECMODEL is specified then it will be the security model required for that  user
              (note that identical user names may come in over different security models and will
              be appropriately separated via the access control settings).  The default  security
              model  is  "usm"  and  the other common security models are likely "tsm" when using
              (D)TLS or SSH support and "ksm" if the Kerberos support has been compiled in.

       rocommunity COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]

       rwcommunity COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]
              specify an SNMPv1 or SNMPv2c community that will  be  allowed  read-only  (GET  and
              GETNEXT)  or  read-write  (GET,  GETNEXT and SET) access respectively.  By default,
              this will provide access to the full OID tree  for  such  requests,  regardless  of
              where  they  were  sent  from.  The  SOURCE token can be used to restrict access to
              requests from the specified system(s) - see com2sec for the full details.  The  OID
              field  restricts  access for that community to the subtree rooted at the given OID,
              or named view.  Contexts  are  typically  less  relevant  to  community-based  SNMP
              versions, but the same behaviour applies here.

       rocommunity6 COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]

       rwcommunity6 COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]
              are directives relating to requests received using IPv6 (if the agent supports such
              transport domains).  The interpretation of the SOURCE, OID, VIEW and CONTEXT tokens
              are exactly the same as for the IPv4 versions.

       In each case, only one directive should be specified for a given SNMPv3 user, or community
       string.  It is not appropriate to specify both rouser and rwuser directives  referring  to
       the same SNMPv3 user (or equivalent community settings). The rwuser directive provides all
       the access of rouser (as well as allowing SET support).   The  same  holds  true  for  the
       community-based directives.

       More  complex access requirements (such as access to two or more distinct OID subtrees, or
       different views for GET and SET requests) should use  one  of  the  other  access  control
       mechanisms.   Note that if several distinct communities or SNMPv3 users need to be granted
       the same level of  access,  it  would  also  be  more  efficient  to  use  the  main  VACM
       configuration directives.

   VACM Configuration
       The  full  flexibility  of  the  VACM  is  available using four configuration directives -
       com2sec, group, view and access.  These provide direct  configuration  of  the  underlying
       VACM tables.

       com2sec  [-Cn CONTEXT] SECNAME SOURCE COMMUNITY

       com2sec6 [-Cn CONTEXT] SECNAME SOURCE COMMUNITY
              map  an  SNMPv1  or  SNMPv2c  community  string  to a security name - either from a
              particular range of source addresses, or globally ("default").  A restricted source
              can  either  be  a  specific  hostname  (or  address), or a subnet - represented as
              IP/MASK (e.g. 10.10.10.0/255.255.255.0), or IP/BITS (e.g.  10.10.10.0/24),  or  the
              IPv6  equivalents.  A restriction preceded by an exclamation mark (!) denies access
              from that address or subnet, e.g., !10.10.10.0/24 denies requests from that sources
              in  that  subnet.   Deny  restrictions  must be before permit.  E.g., the following
              example permits access from all of 10.0.0.0/8 except for 10.10.10.0/24:
                     com2sec sec1 !10.10.10.0/24 public
                     com2sec sec1 10.0.0.0/8 public

              Access from outside of 10.0.0.0/8 would still be denied.

              The  same  community  string  can  be  specified  in  several  separate  directives
              (presumably   with   different  source  tokens),  and  the  first  source/community
              combination  that  matches  the  incoming  request  will  be   selected.    Various
              source/community combinations can also map to the same security name.

              If  a  CONTEXT  is  specified (using -Cn), the community string will be mapped to a
              security name in the named SNMPv3 context. Otherwise the default context ("")  will
              be used.

       com2secunix [-Cn CONTEXT] SECNAME SOCKPATH COMMUNITY
              is the Unix domain sockets version of com2sec.

       group GROUP {v1|v2c|usm|tsm|ksm} SECNAME
              maps a security name (in the specified security model) into a named group.  Several
              group directives can specify the same group name, allowing a single access  setting
              to apply to several users and/or community strings.

              Note  that  groups must be set up for the two community-based models separately - a
              single com2sec (or equivalent) directive will typically be accompanied by two group
              directives.

       view VNAME TYPE OID [MASK]
              defines  a named "view" - a subset of the overall OID tree. This is most commonly a
              single subtree, but several view directives can be given with the  same  view  name
              (VNAME), to build up a more complex collection of OIDs.  TYPE is either included or
              excluded, which can again define a more complex  view  (e.g  by  excluding  certain
              sensitive objects from an otherwise accessible subtree).

              MASK is a list of hex octets (optionally separated by '.' or ':') with the set bits
              indicating which  subidentifiers  in  the  view  OID  to  match  against.   If  not
              specified,  this defaults to matching the OID exactly (all bits set), thus defining
              a simple OID subtree.  So:
                     view iso1 included .iso  0xf0
                     view iso2 included .iso
                     view iso3 included .iso.org.dod.mgmt  0xf0

              would all define the same view, covering the whole of the  'iso(1)'  subtree  (with
              the third example ignoring the subidentifiers not covered by the mask).

              More  usefully, the mask can be used to define a view covering a particular row (or
              rows) in a table, by matching  against  the  appropriate  table  index  value,  but
              skipping the column subidentifier:

                     view ifRow4 included .1.3.6.1.2.1.2.2.1.0.4  0xff:a0

              Note that a mask longer than 8 bits must use ':' to separate the individual octets.

       access GROUP CONTEXT {any|v1|v2c|usm|tsm|ksm} LEVEL PREFX READ WRITE NOTIFY
              maps  from  a  group  of  users/communities  (with  a particular security model and
              minimum security level, and in a specific context) to one of three views, depending
              on the request being processed.

              LEVEL  is  one  of  noauth,  auth,  or priv.  PREFX specifies how CONTEXT should be
              matched against the context of the incoming request, either exact or prefix.  READ,
              WRITE  and  NOTIFY  specifies  the  view  to  be used for GET*, SET and TRAP/INFORM
              requests (althought the NOTIFY view is not currently used).  For v1 or v2c  access,
              LEVEL will need to be noauth.

   Typed-View Configuration
       The  final  group  of  directives extend the VACM approach into a more flexible mechanism,
       which can be applied to other access control requirements. Rather  than  the  fixed  three
       views of the standard VACM mechanism, this can be used to configure various different view
       types.  As far as the main SNMP agent is concerned, the two main view types are  read  and
       write,  corresponding  to  the READ and WRITE views of the main access directive.  See the
       'snmptrapd.conf(5)' man page for discussion of other view types.

       authcommunity TYPES  COMMUNITY   [SOURCE [OID | -V VIEW [CONTEXT]]]
              is an alternative to the rocommunity/rwcommunity directives.  TYPES will usually be
              read  or  read,write  respectively.   The  view  specification can either be an OID
              subtree (as before), or a named view (defined using the view directive) for greater
              flexibility.  If this is omitted, then access will be allowed to the full OID tree.
              If  CONTEXT  is  specified,  access  is  configured  within  this  SNMPv3  context.
              Otherwise the default context ("") is used.

       authuser   TYPES [-s MODEL] USER  [LEVEL [OID | -V VIEW [CONTEXT]]]
              is an alternative to the rouser/rwuser directives.  The fields TYPES, OID, VIEW and
              CONTEXT have the same meaning as for authcommunity.

       authgroup  TYPES [-s MODEL] GROUP [LEVEL [OID | -V VIEW [CONTEXT]]]
              is a companion to the authuser directive, specifying access for a particular  group
              (defined  using the group directive as usual).  Both authuser and authgroup default
              to authenticated requests - LEVEL can also be specified as noauth or priv to  allow
              unauthenticated  requests,  or  require encryption respectively.  Both authuser and
              authgroup directives also default to configuring access for SNMPv3/USM  requests  -
              use  the  '-s' flag to specify an alternative security model (using the same values
              as for access above).

       authaccess TYPES [-s MODEL] GROUP VIEW [LEVEL [CONTEXT]]
              also configures the access for a particular group, specifying the name and type  of
              view  to  apply.  The MODEL and LEVEL fields are interpreted in the same way as for
              authgroup.  If CONTEXT is  specified,  access  is  configured  within  this  SNMPv3
              context  (or  contexts  with  this  prefix  if  the  CONTEXT  field ends with '*').
              Otherwise the default context ("") is used.

       setaccess GROUP CONTEXT MODEL LEVEL PREFIX VIEW TYPES
              is a direct equivalent to the original access directive, typically listing the view
              types  as read or read,write as appropriate.  (or see 'snmptrapd.conf(5)' for other
              possibilities).  All other fields have the same interpretation as with access.

SYSTEM INFORMATION

       Most of the information reported by the Net-SNMP agent is retrieved  from  the  underlying
       system,  or dynamically configured via SNMP SET requests (and retained from one run of the
       agent to the next).  However, certain MIB objects can be configured or controlled via  the
       snmpd.conf(5) file.

   System Group
       Most of the scalar objects in the 'system' group can be configured in this way:

       sysLocation STRING

       sysContact STRING

       sysName STRING
              set the system location, system contact or system name (sysLocation.0, sysContact.0
              and sysName.0) for the agent respectively.  Ordinarily these objects  are  writable
              via  suitably  authorized  SNMP  SET  requests.   However,  specifying one of these
              directives makes the corresponding object read-only, and attempts to  SET  it  will
              result in a notWritable error response.

       sysServices NUMBER
              sets  the value of the sysServices.0 object.  For a host system, a good value is 72
              (application + end-to-end layers).  If this directive is  not  specified,  then  no
              value will be reported for the sysServices.0 object.

       sysDescr STRING

       sysObjectID OID
              sets the system description or object ID for the agent.  Although these MIB objects
              are not SNMP-writable, these directives can be used by a network  administrator  to
              configure suitable values for them.

   Interfaces Group
       interface NAME TYPE SPEED
              can be used to provide appropriate type and speed settings for interfaces where the
              agent fails to determine this information correctly.  TYPE is a type value as given
              in  the  IANAifType-MIB, and can be specified numerically or by name (assuming this
              MIB is loaded).

       interface_fadeout TIMEOUT
              specifies, for how long the  agent  keeps  entries  in  ifTable  after  appropriate
              interfaces  have  been  removed  from  system  (typically  various  ppp, tap or tun
              interfaces). Timeout value is in seconds. Default value is 300 (=5 minutes).

       interface_replace_old yes
              can be used to remove already existing entries in ifTable when  an  interface  with
              the  same  name  appears  on the system. E.g. when ppp0 interface is removed, it is
              still listed in the table for interface_fadeout seconds. This option ensures,  that
              the  old  ppp0  interface is removed even before the interface_fadeout timeour when
              new ppp0 (with different ifIndex) shows up.

   Host Resources Group
       This requires that the agent was built with support for the  host  module  (which  is  now
       included as part of the default build configuration on the major supported platforms).

       ignoreDisk STRING
              controls   which   disk   devices   are   scanned   as   part   of  populating  the
              hrDiskStorageTable (and hrDeviceTable).  The HostRes implementation code includes a
              list  of disk device patterns appropriate for the current operating system, some of
              which may cause the agent to block when  trying  to  open  the  corresponding  disk
              devices.   This  might  lead  to  a  timeout  when  walking  these tables, possibly
              resulting in inconsistent  behaviour.   This  directive  can  be  used  to  specify
              particular devices (either individually or wildcarded) that should not be checked.

              Note:  Please   consult   the   source   (host/hr_disk.c)   and   check   for   the
                     Add_HR_Disk_entry calls relevant for a particular O/S to determine the  list
                     of devices that will be scanned.

              The  pattern  can  include one or more wildcard expressions.  See snmpd.examples(5)
              for illustration of the wildcard syntax.

       skipNFSInHostResources true
              controls whether  NFS  and  NFS-like  file  systems  should  be  omitted  from  the
              hrStorageTable  (true or 1) or not (false or 0, which is the default).  If the Net-
              SNMP agent gets hung on NFS-mounted filesystems, you can try setting this to '1'.

       storageUseNFS [1|2]
              controls  how  NFS  and  NFS-like  file  systems  should   be   reported   in   the
              hrStorageTable.  as 'Network Disks' (1) or 'Fixed Disks' (2) Historically, the Net-
              SNMP agent has reported such file systems as 'Fixed Disks', and this is  still  the
              default  behaviour.   Setting  this  directive  to '1' reports such file systems as
              ´Network Disks', as required by the Host Resources MIB.

       realStorageUnits
              controlls  how  the  agent  reports  hrStorageAllocationUnits,  hrStorageSize   and
              hrStorageUsed  in  hrStorageTable.   For  big  storage drives with small allocation
              units  the  agent  re-calculates  these  values  so  they  all  fit  Integer32  and
              hrStorageAllocationUnits x hrStorageSize gives real size of the storage.

              Example:
                     Linux  xfs  16TB filesystem with 4096 bytes large blocks will be reported as
                     hrStorageAllocationUnits = 8192 and hrStorageSize = 2147483647,  so  8192  x
                     2147483647 gives real size of the filesystem (=16 TB).

              Setting this directive to '1' turns off this calculation and the agent reports real
              hrStorageAllocationUnits, but it might report wrong hrStorageSize  for  big  drives
              because  the value won't fit into Integer32. In this case, hrStorageAllocationUnits
              x hrStorageSize won't give real size of the storage.

   Process Monitoring
       The hrSWRun group  of  the  Host  Resources  MIB  provides  information  about  individual
       processes  running  on the local system.  The prTable of the UCD-SNMP-MIB complements this
       by reporting on selected services (which may involve multiple processes).   This  requires
       that  the  agent was built with support for the ucd-snmp/proc module (which is included as
       part of the default build configuration).

       proc NAME [MAX [MIN]]
              monitors the number of processes called NAME (as reported by "/bin/ps -e")  running
              on the local system.

              If  the  number  of  NAMEd processes is less than MIN or greater than MAX, then the
              corresponding prErrorFlag instance will be set to 1,  and  a  suitable  description
              message reported via the prErrMessage instance.

              Note:  This situation will not automatically trigger a trap to report the problem -
                     see the DisMan Event MIB section later.

              If neither MAX nor  MIN  are  specified,  they  will  default  to  infinity  and  1
              respectively  ("at  least  one").   If only MAX is specified, MIN will default to 0
              ("no more than MAX").  If MAX is 0 (and MIN is not), this indicates  infinity  ("at
              least  MIN").   If both MAX and MIN are 0, this indicates a process that should not
              be running.

       procfix NAME PROG ARGS
              registers a command that can be run to fix errors  with  the  given  process  NAME.
              This will be invoked when the corresponding prErrFix instance is set to 1.

              Note:  This command will not be invoked automatically.

              The  procfix  directive  must  be  specified after the matching proc directive, and
              cannot be used on its own.

       If no proc directives are defined, then walking the prTable will fail (noSuchObject).

   Disk Usage Monitoring
       This requires that the agent was built with support for the ucd-snmp/disk module (which is
       included as part of the default build configuration).

       disk PATH [ MINSPACE | MINPERCENT% ]
              monitors  the  disk  mounted at PATH for available disk space.  Disks mounted after
              the agent has started will not  be  monitored,  unless  includeAllDisks  option  is
              specified.

              The  minimum  threshold can either be specified in kB (MINSPACE) or as a percentage
              of the total disk (MINPERCENT% with  a  '%'  character),  defaulting  to  100kB  if
              neither are specified.  If the free disk space falls below this threshold, then the
              corresponding dskErrorFlag instance will be set to 1, and  a  suitable  description
              message reported via the dskErrorMsg instance.

              Note:  This situation will not automatically trigger a trap to report the problem -
                     see the DisMan Event MIB section later.

       includeAllDisks MINPERCENT%
              configures monitoring of all  disks  found  on  the  system,  using  the  specified
              (percentage)  threshold.   The  dskTable  is  dynamically  updated, unmounted disks
              disappear from the table and newly mounted disks  are  added  to  the  table.   The
              threshold  for  individual  disks  can  be  adjusted using suitable disk directives
              (which can come either before or after the includeAllDisks directive).

              Note:  Whether disk directives appears before or after includeAllDisks  may  affect
                     the indexing of the dskTable.

              Only one includeAllDisks directive should be specified - any subsequent copies will
              be ignored.

              The list of mounted disks will be determined from HOST-RESOURCES-MIB::hrFSTable.

       If neither any disk directives or includeAllDisks are defined, then walking  the  dskTable
       will fail (noSuchObject).

   Disk I/O Monitoring
       This  requires that the agent was built with support for the ucd-snmp/diskio module (which
       is not included as part of the default build configuration).

       By default, all  block  devices  known  to  the  operating  system  are  included  in  the
       diskIOTable. On platforms other than Linux, this module has no configuration directives.

       On  Linux  systems,  it  is  possible to exclude several classes of block devices from the
       diskIOTable in order to avoid cluttering  the  table  with  useless  zero  statistics  for
       pseudo-devices  that  often  are not in use but are configured by default to exist in most
       recent Linux distributions.

       diskio_exclude_fd yes
              Excludes all Linux floppy disk block devices, whose names  start  with  "fd",  e.g.
              "fd0"

       diskio_exclude_loop yes
              Excludes  all  Linux  loopback  block  devices, whose names start with "loop", e.g.
              "loop0"

       diskio_exclude_ram yes
              Excludes all LInux ramdisk block  devices,  whose  names  start  with  "ram",  e.g.
              "ram0"

       On  Linux  systems, it is also possible to report only explicitly accepted devices. It may
       take significant amount of time to process  diskIOTable  data  on  systems  with  tens  of
       thousands  of  block  devices  and  accept  only  the  important  ones  avoids  large  CPU
       consumption.

       diskio <device>
              Enables acceptlist  of  devices  and  adds  the  device  to  the  acceptlist.  Only
              explicitly  acceptlisted devices will be reported. This option may be used multiple
              times.

   System Load Monitoring
       This requires that the agent was built with support for either the ucd-snmp/loadave module
       or  the  ucd-snmp/memory  module  respectively  (both of which are included as part of the
       default build configuration).

       load MAX1 [MAX5 [MAX15]]
              monitors the load average of  the  local  system,  specifying  thresholds  for  the
              1-minute,  5-minute  and  15-minute  averages.   If  any  of these loads exceed the
              associated maximum value, then the corresponding laErrorFlag instance will  be  set
              to 1, and a suitable description message reported via the laErrMessage instance.

              Note:  This situation will not automatically trigger a trap to report the problem -
                     see the DisMan Event MIB section later.

              If the MAX15 threshold is omitted, it will default to the MAX5 value.  If both MAX5
              and  MAX15  are omitted, they will default to the MAX1 value.  If this directive is
              not specified, all three thresholds will default to a value of DEFMAXLOADAVE.

              If a threshold value of 0 is given, the  agent  will  not  report  errors  via  the
              relevant laErrorFlag or laErrMessage instances, regardless of the current load.

       Unlike  the  proc  and  disk  directives,  walking  the  walking  the laTable will succeed
       (assuming the ucd-snmp/loadave module was configured into the agent),  even  if  the  load
       directive is not present.

       swap MIN
              monitors  the  amount  of  swap space available on the local system.  If this falls
              below the specified threshold (MIN kB), then the memErrorSwap object will be set to
              1, and a suitable description message reported via memSwapErrorMsg.

              Note:  This situation will not automatically trigger a trap to report the problem -
                     see the DisMan Event MIB section later.
       If this directive is not specified, the default threshold is 16 MB.

   Log File Monitoring
       This requires that the agent was built  with  support  for  either  the  ucd-snmp/file  or
       ucd-snmp/logmatch  modules respectively (both of which are included as part of the default
       build configuration).

       file FILE [MAXSIZE]
              monitors the size of the specified file (in kB).  If MAXSIZE is specified, and  the
              size  of  the  file  exceeds  this  threshold, then the corresponding fileErrorFlag
              instance will be set to 1, and a suitable  description  message  reported  via  the
              fileErrorMsg instance.

              Note:  This situation will not automatically trigger a trap to report the problem -
                     see the DisMan Event MIB section later.

              Note: A maximum of 20 files can be monitored.

              Note: If no file directives are defined,  then  walking  the  fileTable  will  fail
              (noSuchObject).

       logmatch NAME FILE CYCLETIME REGEX
              monitors the specified file for occurances of the specified pattern REGEX. The file
              position is stored internally so the entire file  is  only  read  initially,  every
              subsequent pass will only read the new lines added to the file since the last read.

              NAME   name   of   the   logmatch  instance  (will  appear  as  logMatchName  under
                     logMatch/logMatchTable/logMatchEntry/logMatchName in the ucd-snmp MIB tree)

              FILE   absolute path to the logfile to  be  monitored.  Note  that  this  path  can
                     contain  date/time  directives  (like  in  the UNIX 'date' command). See the
                     manual page for 'strftime' for the various directives accepted.

              CYCLETIME
                     time interval for each logfile read and internal variable update in seconds.
                     Note:  an SNMPGET* operation will also trigger an immediate logfile read and
                     variable update.

              REGEX  the regular expression  to  be  used.  Note:  DO  NOT  enclose  the  regular
                     expression  in  quotes  even  if  there  are spaces in the expression as the
                     quotes will also become part of the pattern to be matched!

              Example:

                     logmatch    apache-GETs    /usr/local/apache/logs/access.log-%Y-%m-%d     60
                     GET.*HTTP.*

                     This  logmatch  instance  is  named 'apache-GETs', uses 'GET.*HTTP.*' as its
                     regular expression and it will monitor the file named (assuming today is May
                     6th  2009): '/usr/local/apache/logs/access.log-2009-05-06', tomorrow it will
                     look for 'access.log-2009-05-07'. The logfile is read every 60 seconds.

              Note: A maximum of 250 logmatch directives can be specified.

              Note: If no logmatch directives are defined, then walking  the  logMatchTable  will
              fail (noSuchObject).

ACTIVE MONITORING

       The  usual behaviour of an SNMP agent is to wait for incoming SNMP requests and respond to
       them - if no requests are received, an agent will typically not initiate any actions. This
       section describes various directives that can configure snmpd to take a more active role.

   Notification Handling
       trapcommunity STRING
              defines the default community string to be used when sending traps.  Note that this
              directive must be used prior to any  community-based  trap  destination  directives
              that need to use it.

       trapsink [-profile p] [-name n] [-tag t] [-s src] HOST [COMMUNITY [PORT]]

       trap2sink [-profile p] [-name n] [-tag t] [-s src] HOST [COMMUNITY [PORT]]

       informsink [-profile p] [-name n] [-tag t] [-s src] HOST [COMMUNITY [PORT]]
              define  the  address  of  a notification receiver that should be sent SNMPv1 TRAPs,
              SNMPv2c TRAP2s, or SNMPv2  INFORM  notifications  respectively.   See  the  section
              LISTENING  ADDRESSES  in  the  snmpd(8)  manual page for more information about the
              format of listening addresses.  If COMMUNITY is  not  specified,  the  most  recent
              trapcommunity string will be used.

              If the transport address does not include an explicit port specification, then PORT
              will be used.  If this is not specified, the well known SNMP trap port  (162)  will
              be used.

              Note:  This  mechanism  is  being  deprecated,  and  the  listening  port should be
                     specified via the transport specification HOST instead.

              The optional name and tag parameters specifies the name or tag that  will  be  used
              for  SNMP-NOTIFICATION-MIB  table entries. The profile specifies which notification
              filter profile entry will  be  used  for  filtering  outgoing  notifications.  (See
              notificationFilter)

              The  optional  src  parameter  specifies  the source address that will be used when
              sending the trap packet to this sink.  It is specified  as  a  <transport-address>,
              using  the  same  <transport-specifier>  as  the destination HOST.  See the section
              LISTENING ADDRESSES in the snmpd(8) manual page  for  more  information  about  the
              format.

              If  several sink directives are specified, multiple copies of each notification (in
              the appropriate formats) will be generated.

              Note:  It is not normally appropriate to list two (or all  three)  sink  directives
                     with the same destination.

       trapsess [-profile p] [-name n] [-tag t] [-s src] [SNMPCMD_ARGS] HOST
              provides   a   more  generic  mechanism  for  defining  notification  destinations.
              SNMPCMD_ARGS should be the command-line options required for an equivalent snmptrap
              (or  snmpinform)  command  to send the desired notification.  The option -Ci can be
              used (with -v2c  or  -v3)  to  generate  an  INFORM  notification  rather  than  an
              unacknowledged TRAP.

              The  optional  name  and tag parameters specifies the name or tag that will be used
              for SNMP-NOTIFICATION-MIB table entries. The profile specifies  which  notification
              filter  profile  entry  will  be  used  for  filtering outgoing notifications. (See
              notificationFilter)

              This is  the  appropriate  directive  for  defining  SNMPv3  trap  receivers.   See
              http://www.net-snmp.org/tutorial/tutorial-5/commands/snmptrap-v3.html    for   more
              information about SNMPv3 notification behaviour.

       notificationFilter NAME OID MASK TYPE
              specifies a SNMP-NOTIFICATION-MIB notification filter profile, which may be used to
              filter traps. TYPE must be included or excluded, Some examples:

                     notificationFilter all_ok .1.3 0x00 included
                     notificationFilter no_coldstart .1.3 0x00 included
                     notificationFilter no_coldstart .1.3.6.1.6.3.1.1.5.1 0x00 excluded

                     trapsink -profile no_coldstart 192.168.1.3:3162 secret3

       authtrapenable {1|2}
              determines  whether  to  generate  authentication failure traps (enabled(1)) or not
              (disabled(2)  -  the   default).    Ordinarily   the   corresponding   MIB   object
              (snmpEnableAuthenTraps.0)  is  read-write, but specifying this directive makes this
              object read-only, and attempts to set the value via SET requests will result  in  a
              notWritable error response.

       v1trapaddress HOST
              defines  the  agent  address,  which is inserted into SNMPv1 TRAPs. Arbitrary local
              IPv4 address is chosen if this option is ommited. This option is useful mainly when
              the  agent is visible from outside world by specific address only (e.g.  because of
              network address translation or firewall).

   DisMan Event MIB
       The previous directives can be used to configure where traps should be sent, but  are  not
       concerned  with  when to send such traps (or what traps should be generated).  This is the
       domain of the Event MIB - developed by the Distributed Management (DisMan)  working  group
       of the IETF.

       This  requires that the agent was built with support for the disman/event module (which is
       now included as part of the default build configuration for the most recent distribution).

              Note:  The behaviour of the latest implementation differs in  some  minor  respects
                     from  the  previous code - nothing too significant, but existing scripts may
                     possibly need some minor adjustments.

       iquerySecName NAME

       agentSecName NAME
              specifies the default SNMPv3 username, to be used when making internal  queries  to
              retrieve any necessary information (either for evaluating the monitored expression,
              or building a notification payload).  These internal  queries  always  use  SNMPv3,
              even if normal querying of the agent is done using SNMPv1 or SNMPv2c.

              Note  that  this  user  must  also  be  explicitly  created  (createUser) and given
              appropriate access rights (e.g. rouser).  This directive is purely  concerned  with
              defining which user should be used - not with actually setting this user up.

       monitor [OPTIONS] NAME EXPRESSION
              defines  a  MIB  object to monitor.  If the EXPRESSION condition holds (see below),
              then this will trigger the corresponding event, and either send a  notification  or
              apply a SET assignment (or both).  Note that the event will only be triggered once,
              when the expression first matches.  This monitor entry will not  fire  again  until
              the  monitored  condition  first becomes false, and then matches again.  NAME is an
              administrative  name  for  this  expression,  and  is   used   for   indexing   the
              mteTriggerTable  (and  related  tables). Each monitor line must have a unique NAME.
              Monitor lines with a duplicate  name  are  discarded  and  cause  snmpd  to  log  a
              duplicate  index  complaint.   Note  also that such monitors use an internal SNMPv3
              request to retrieve the values  being  monitored  (even  if  normal  agent  queries
              typically use SNMPv1 or SNMPv2c).  See the iquerySecName token described above.

       EXPRESSION
              There are three types of monitor expression supported by the Event MIB - existence,
              boolean and threshold tests.

              OID | ! OID | != OID
                     defines an existence(0) monitor test.  A bare  OID  specifies  a  present(0)
                     test,  which  will  fire when (an instance of) the monitored OID is created.
                     An expression of the form ! OID specifies an absent(1) test, which will fire
                     when  the  monitored  OID  is  delected.   An  expression of the form != OID
                     specifies a changed(2) test, which will fire whenever the monitored value(s)
                     change.  Note that there must be whitespace before the OID token.

              OID OP VALUE
                     defines  a  boolean(1)  monitor  test.   OP  should  be  one  of the defined
                     comparison operators (!=, ==, <, <=, >, >=) and VALUE should be  an  integer
                     value  to compare against.  Note that there must be whitespace around the OP
                     token.  A comparison such as OID !=0 will not be handled correctly.

              OID MIN MAX [DMIN DMAX]
                     defines a threshold(2) monitor  test.   MIN  and  MAX  are  integer  values,
                     specifying  lower  and  upper thresholds.  If the value of the monitored OID
                     falls below the lower threshold (MIN) or rises  above  the  upper  threshold
                     (MAX), then the monitor entry will trigger the corresponding event.

                     Note  that  the  rising  threshold  event  will  only  be  re-armed when the
                     monitored value falls below  the  lower  threshold  (MIN).   Similarly,  the
                     falling threshold event will be re-armed by the upper threshold (MAX).

                     The  optional parameters DMIN and DMAX configure a pair of similar threshold
                     tests, but working with the  delta  differences  between  successive  sample
                     values.

       OPTIONS
              There  are  various  options  to control the behaviour of the monitored expression.
              These include:

              -D     indicates that the expression should be evaluated  using  delta  differences
                     between sample values (rather than the values themselves).

              -d OID

              -di OID
                     specifies  a  discontinuity  marker for validating delta differences.  A -di
                     object instance will be used exactly as given.  A -d object  will  have  the
                     instance  subidentifiers  from  the  corresponding  (wildcarded)  expression
                     object appended.  If the -I flag is specified, then there is  no  difference
                     between these two options.

                     This option also implies -D.

              -e EVENT
                     specifies  the event to be invoked when this monitor entry is triggered.  If
                     this option is not given,  the  monitor  entry  will  generate  one  of  the
                     standard notifications defined in the DISMAN-EVENT-MIB.

              -I     indicates  that  the monitored expression should be applied to the specified
                     OID as a single instance.   By  default,  the  OID  will  be  treated  as  a
                     wildcarded object, and the monitor expanded to cover all matching instances.

              -i OID

              -o OID define additional varbinds to be added to the notification payload when this
                     monitor trigger fires.  For a  wildcarded  expression,  the  suffix  of  the
                     matched  instance  will  be added to any OIDs specified using -o, while OIDs
                     specified using -i will be treated as exact instances.  If the  -I  flag  is
                     specified, then there is no difference between these two options.

                     See strictDisman for details of the ordering of notification payloads.

              -r FREQUENCY
                     monitors the given expression every FREQUENCY, where FREQUENCY is in seconds
                     or optionally suffixed by one of s (for seconds), m (for  minutes),  h  (for
                     hours),  d (for days), or w (for weeks).  By default, the expression will be
                     evaluated every 600s (10 minutes).

              -S     indicates that the monitor expression should not be evaluated when the agent
                     first  starts  up.   The first evaluation will be done once the first repeat
                     interval has expired.

              -s     indicates that the monitor expression should be  evaluated  when  the  agent
                     first starts up.  This is the default behaviour.

                     Note:  Notifications  triggered  by  this  initial  evaluation  will be sent
                            before the coldStart trap.

              -u SECNAME
                     specifies a security name to use for scanning the local host, instead of the
                     default iquerySecName.  Once again, this user must be explicitly created and
                     given suitable access rights.

       notificationEvent ENAME NOTIFICATION [-m] [-i OID | -o OID ]*
              defines a notification event named ENAME.  This  can  be  triggered  from  a  given
              monitor  entry  by specifying the option -e ENAME (see above).  NOTIFICATION should
              be the  OID  of  the  NOTIFICATION-TYPE  definition  for  the  notification  to  be
              generated.

              If  the  -m  option  is  given,  the notification payload will include the standard
              varbinds as specified in the OBJECTS clause of  the  notification  MIB  definition.
              This option must come after the NOTIFICATION OID (and the relevant MIB file must be
              available and loaded by the agent).   Otherwise,  these  varbinds  must  be  listed
              explicitly (either here or in the corresponding monitor directive).

              The  -i  OID  and  -o OID options specify additional varbinds to be appended to the
              notification payload, after the standard list.  If the monitor entry that triggered
              this  event  involved  a  wildcarded expression, the suffix of the matched instance
              will be added to any OIDs specified using -o, while OIDs specified using -i will be
              treated as exact instances.  If the -I flag was specified to the monitor directive,
              then there is no difference between these two options.

       setEvent ENAME [-I] OID = VALUE
              defines a set event named ENAME, assigning the (integer)  VALUE  to  the  specified
              OID.   This can be triggered from a given monitor entry by specifying the option -e
              ENAME (see above).

              If the monitor entry that triggered this event involved  a  wildcarded  expression,
              the  suffix  of  the matched instance will normally be added to the OID.  If the -I
              flag was specified to either of the monitor or setEvent directives,  the  specified
              OID will be regarded as an exact single instance.

       strictDisman yes
              The definition of SNMP notifications states that the varbinds defined in the OBJECT
              clause should come first (in the order specified), followed by any "extra" varbinds
              that  the  notification generator feels might be useful.  The most natural approach
              would be to associate these mandatory varbinds with  the  notificationEvent  entry,
              and  append  any  varbinds  associated  with  the  monitor entry that triggered the
              notification to the end of this list.  This is the default behaviour  of  the  Net-
              SNMP Event MIB implementation.

              Unfortunately, the DisMan Event MIB specifications actually state that the trigger-
              related varbinds should come first,  followed  by  the  event-related  ones.   This
              directive  can  be  used  to  restore  this  strictly-correct  (but  inappropriate)
              behaviour.

              Note:  Strict DisMan  ordering  may  result  in  generating  invalid  notifications
                     payload lists if the notificationEvent -n flag is used together with monitor
                     -o (or -i) varbind options.

              If no monitor entries specify payload varbinds, then the setting of this  directive
              is irrelevant.

       linkUpDownNotifications yes
              will  configure  the Event MIB tables to monitor the ifTable for network interfaces
              being taken up or down,  and  triggering  a  linkUp  or  linkDown  notification  as
              appropriate.

              This is exactly equivalent to the configuration:

                     notificationEvent  linkUpTrap    linkUp   ifIndex ifAdminStatus ifOperStatus
                     notificationEvent  linkDownTrap  linkDown ifIndex ifAdminStatus ifOperStatus

                     monitor  -r 60 -e linkUpTrap   "Generate linkUp" ifOperStatus != 2
                     monitor  -r 60 -e linkDownTrap "Generate linkDown" ifOperStatus == 2

       defaultMonitors yes
              will  configure the Event MIB tables to monitor the various UCD-SNMP-MIB tables for
              problems (as indicated by the appropriate xxErrFlag column objects).

              This is exactly equivalent to the configuration:

                     monitor   -o prNames -o prErrMessage "process table" prErrorFlag != 0
                     monitor   -o memErrorName -o memSwapErrorMsg "memory" memSwapError != 0
                     monitor   -o extNames -o extOutput "extTable" extResult != 0
                     monitor   -o dskPath -o dskErrorMsg "dskTable" dskErrorFlag != 0
                     monitor   -o laNames -o laErrMessage  "laTable" laErrorFlag != 0
                     monitor   -o fileName -o fileErrorMsg  "fileTable" fileErrorFlag != 0

       In both these latter cases, the snmpd.conf must also contain  a  iquerySecName  directive,
       together with a corresponding createUser entry and suitable access control configuration.

   DisMan Schedule MIB
       The  DisMan  working  group also produced a mechanism for scheduling particular actions (a
       specified SET assignment) at given times.  This requires that the  agent  was  built  with
       support  for  the  disman/schedule  module (which is included as part of the default build
       configuration for the most recent distribution).

       There are three ways of specifying the scheduled action:

       repeat FREQUENCY OID = VALUE
              configures a SET assignment of the (integer) VALUE to the MIB instance OID,  to  be
              run  every  FREQUENCY seconds, where FREQUENCY is in seconds or optionally suffixed
              by one of s (for seconds), m (for minutes), h (for hours), d (for days), or w  (for
              weeks).

       cron MINUTE HOUR DAY MONTH WEEKDAY  OID = VALUE
              configures  a  SET assignment of the (integer) VALUE to the MIB instance OID, to be
              run at the times specified by the fields MINUTE to WEEKDAY.  These follow the  same
              pattern as the equivalent crontab(5) fields.

              Note:  These  fields  should  be  specified  as a (comma-separated) list of numeric
                     values.  Named values for the MONTH and WEEKDAY fields  are  not  supported,
                     and neither are value ranges. A wildcard match can be specified as '*'.

              The  DAY field can also accept negative values, to indicate days counting backwards
              from the end of the month.

       at MINUTE HOUR DAY MONTH WEEKDAY  OID = VALUE
              configures a one-shot SET assignment, to be run  at  the  first  matching  time  as
              specified  by  the fields MINUTE to WEEKDAY.  The interpretation of these fields is
              exactly the same as for the cron directive.

   Data Delivery via Notfiications
       Note: this functionality is only available if the deliver/deliverByNotify mib  module  was
       complied in to the agent

       In  some  situations  it  may be advantageous to deliver SNMP data over SNMP Notifications
       (TRAPs and INFORMs) rather than the typical process of having the manager  issue  requests
       for the data (via GETs and GETNEXTs).  Reasons for doing this are numerous, but frequently
       corner cases.  The most common reason for wanting  this  behaviour  might  be  to  monitor
       devices that reside behind NATs or Firewalls that prevent incoming SNMP traffic.

       It  should  be  noted  that  although  most  management  software  is  capable  of logging
       notifications, very little (if any) management  software  will  updated  their  "knowledge
       database"  based on the contents of SNMP notifications.  IE, it won't (for example) update
       the interface traffic counter history that is used to produce graphs.  Most larger network
       management  packages  have a separate database for storing data received via SNMP requests
       (GETs and GETNEXTs) vs those received from notifications.  Researching the capabilities of
       your management station software is required before assuming this functionality will solve
       your data delivery requirements.

       Notifications generated via this mechanism will be sent to the standard set of  configured
       notification  targets.   See  the  "Notification  Handling"  section  of this document for
       further information.

       deliverByNotify [-p] [-m] [-s MAXSIZE] FREQUENCY OID
              This directive tells the SNMP agent to self-walk the OID, collect all the data  and
              send  it  out  every FREQUENCY seconds, where FREQUENCY is in seconds or optionally
              suffixed by one of s (for seconds), m (for minutes), h (for hours), d  (for  days),
              or w (for weeks).  By default scalars are included in the notification that specify
              the how often the notification will be sent (unless the -p option is specified) and
              which  message  number of how many messages a particular notification is (unless -m
              is specified).  To break the notifications into manageable packet sizes, use the -s
              flag to specify the approximate maximum number of bytes that a notification message
              should be limited to.  If more than  MAXSIZE  of  bytes  is  needed  then  multiple
              notifications  will  be  sent  to deliver the data.  Note that the calculations for
              ensuring the maximum size is met are approximations and thus it can  be  absolutely
              guaranteed  they'll be under that size, so leave a padding buffer if it is critical
              that you avoid fragmentation.  A value of -1  indicates  force  everything  into  a
              single message no matter how big it is.

              Example  usage: the following will deliver the contents of the ifTable once an hour
              and the contents of the system group once every 2 hours:

              deliverByNotify 3600 ifTable
              deliverByNotify 7200 system

       deliverByNotifyMaxPacketSize SIZEINBYTES
              Sets the default notification size limit (see the -s flag above).

       deliverByNotifyOid OID

       deliverByNotifyFrequencyOid OID

       deliverByNotifyMessageNumberOid OID

       deliverByNotifyMaxMessageNumberOid OID
              These set the data OID that the notification will be sent under,  the  scalar  OID,
              the  message  number  OID,  and  the  maximum message number OID.  These default to
              objects in the NET-SNMP-PERIODIC-NOTIFY-MIB.

EXTENDING AGENT FUNCTIONALITY

       One of the first distinguishing features of the original UCD  suite  was  the  ability  to
       extend  the  functionality  of  the  agent - not just by recompiling with code for new MIB
       modules, but also by configuring the running agent to report additional information. There
       are a number of techniques to support this, including:

       •      running external commands (exec, extend, pass)

       •      loading new code dynamically (embedded perl, dlmod)

       •      communicating with other agents (proxy, SMUX, AgentX)

   Arbitrary Extension Commands
       The  earliest  extension  mechanism  was  the  ability  to run arbitrary commands or shell
       scripts. Such commands do not need to be aware of  SNMP  operations,  or  conform  to  any
       particular  behaviour - the MIB structures are designed to accommodate any form of command
       output.  Use of this mechanism requires that the agent was  built  with  support  for  the
       ucd-snmp/extensible  and/or  agent/extend  modules (which are both included as part of the
       default build configuration).

       exec [MIBOID] NAME PROG ARGS

       sh [MIBOID] NAME PROG ARGS
              invoke the named PROG with arguments of ARGS.  By default the exit status and first
              line  of  output from the command will be reported via the extTable, discarding any
              additional output.

              Note:  Entries  in  this  table  appear  in  the  order  they  are  read  from  the
                     configuration  file.  This means that adding new exec (or sh) directives and
                     restarting the agent, may affect the indexing of other entries.

              The PROG argument for exec directives must be a full path to a real binary,  as  it
              is  executed  via  the  exec()  system  call.  To invoke a shell script, use the sh
              directive instead.

              If MIBOID is specified, then the results will be rooted at this point  in  the  OID
              tree, returning the exit statement as MIBOID.100.0 and the entire command output in
              a pseudo-table based at MIBNUM.101 - with one 'row' for each line of output.

              Note:  The layout of this "relocatable" form  of  exec  (or  sh)  output  does  not
                     strictly  form  a valid MIB structure.  This mechanism is being deprecated -
                     please see the extend directive (described below) instead.

              The agent does not cache the exit status or output of the executed program.

       execfix NAME PROG ARGS
              registers a command that can be invoked on demand - typically to respond to or  fix
              errors  with the corresponding exec or sh entry.  When the extErrFix instance for a
              given NAMEd entry is set to the integer value of 1, this command will be called.

              Note:  This directive can only be used in combination with a corresponding exec  or
                     sh  directive,  which  must  be  defined  first.   Attempting  to  define an
                     unaccompanied execfix directive will fail.

       exec and sh extensions can only be configured via the snmpd.conf file.  They cannot be set
       up via SNMP SET requests.

       extend [-cacheTime TIME] [-execType TYPE] [MIBOID] NAME PROG ARGS
              works in a similar manner to the exec directive, but with a number of improvements.
              The MIB tables (nsExtendConfigTable etc) are indexed by  the  NAME  token,  so  are
              unaffected  by  the  order  in which entries are read from the configuration files.
              There are two result  tables  -  one  (nsExtendOutput1Table)  containing  the  exit
              status,  the first line and full output (as a single string) for each extend entry,
              and the other (nsExtendOutput2Table) containing the complete output as a series  of
              separate lines.

              If  -cacheTime  is  specified,  then  its argument is used as the cache timeout (in
              whole seconds) for this extend entry. This mechanism provides a non-volatile way to
              specify the cache timeout.

              If -execType is specified and has a value of sh, then this extend entry will be run
              in a shell. Otherwise it will be run in the default exec  fashion.  This  mechanism
              provides a non-volatile way to specify the exec type.

              If  MIBOID is specified, then the configuration and result tables will be rooted at
              this point in the OID tree, but are otherwise structured in exactly the  same  way.
              This  means  that  several  separate  extend directives can specify the same MIBOID
              root, without conflicting.

              The exit status and output is cached  for  each  entry  individually,  and  can  be
              cleared (and the caching behaviour configured) using the nsCacheTable.

       extendfix NAME PROG ARGS
              registers  a  command  that  can  be  invoked on demand, by setting the appropriate
              nsExtendRunType instance  to  the  value  run-command(3).   Unlike  the  equivalent
              execfix,  this  directive  does  not  need to be paired with a corresponding extend
              entry, and can appear on its own.

   MIB-Specific Extension Commands
       The first group of extension directives invoke arbitrary commands, and  rely  on  the  MIB
       structure  (and  management  applications)  having  the  flexibility  to  accommodate  and
       interpret the output.  This is a convenient way to make information available quickly  and
       simply,  but is of no use when implementing specific MIB objects, where the extension must
       conform to the structure of the MIB (rather than vice  versa).   The  remaining  extension
       mechanisms  are  all  concerned  with  such MIB-specific situations - starting with "pass-
       through" scripts.  Use of this mechanism requires that the agent was  built  with  support
       for  the  ucd-snmp/pass and ucd-snmp/pass_persist modules (which are both included as part
       of the default build configuration).

       pass [-p priority] MIBOID PROG
              will pass control of the subtree rooted at MIBOID to the  specified  PROG  command.
              GET  and  GETNEXT  requests  for  OIDs  within this tree will trigger this command,
              called as:

                     PROG -g OID

                     PROG -n OID

              respectively, where OID is the requested OID.  The PROG command should  return  the
              response  varbind as three separate lines printed to stdout - the first line should
              be the OID of the returned value, the second should be its TYPE (one  of  the  text
              strings  integer,  gauge, counter, timeticks, ipaddress, objectid, octet, or string
              ), and the third should be the value itself.  (Note:  octets  are  sent  as  ASCII,
              space-separated hex strings, e.g. "00 3f dd 00 c6 be".)

              If the command cannot return an appropriate varbind - e.g the specified OID did not
              correspond to a valid instance for a  GET  request,  or  there  were  no  following
              instances  for  a GETNEXT - then it should exit without producing any output.  This
              will result in an SNMP noSuchName error, or a noSuchInstance exception.

                     Note:  The SMIv2 type counter64 and SNMPv2 noSuchObject  exception  are  not
                            supported.

              A SET request will result in the command being called as:

                     PROG -s OID TYPE VALUE

              where  TYPE  is  one  of  the tokens listed above, indicating the type of the value
              passed as the third parameter.

              If the assignment is successful, the PROG command should exit without producing any
              output.  Errors  should be indicated by writing one of the strings not-writable, or
              wrong-type to stdout, and the agent will generate the appropriate error response.

                     Note:  The other SNMPv2 errors are not supported.

              In either case, the command should exit once  it  has  finished  processing.   Each
              request  (and  each  varbind  within  a  single  request)  will  trigger a separate
              invocation of the command.

              The default registration priority is 127.  This can be  changed  by  supplying  the
              optional  -p  flag,  with  lower priority registrations being used in preference to
              higher priority values.

       pass_persist [-p priority] MIBOID PROG
              will also pass control of the subtree  rooted  at  MIBOID  to  the  specified  PROG
              command.   However  this command will continue to run after the initial request has
              been answered,  so  subsequent  requests  can  be  processed  without  the  startup
              overheads.

              Upon  initialization,  PROG will be passed the string "PING\n" on stdin, and should
              respond by printing "PONG\n" to stdout.

              For GET and GETNEXT requests, PROG will be passed two lines on stdin,  the  command
              (get  or getnext) and the requested OID.  It should respond by printing three lines
              to stdout - the OID for the result varbind, the TYPE and the VALUE itself - exactly
              as  for  the  pass  directive  above.   If the command cannot return an appropriate
              varbind, it should print print "NONE\n" to stdout (but continue running).

              For SET requests, PROG will be passed three lines on stdin, the command  (set)  and
              the  requested OID, followed by the type and value (both on the same line).  If the
              assignment is successful, the command should  print  "DONE\n"  to  stdout.   Errors
              should  be  indicated  by  writing  one  of  the  strings not-writable, wrong-type,
              wrong-length, wrong-value or inconsistent-value  to  stdout,  and  the  agent  will
              generate  the  appropriate  error  response.   In  either  case, the command should
              continue running.

              The registration priority can be changed using the optional -p flag,  just  as  for
              the pass directive.

       pass  and  pass_persist  extensions  can only be configured via the snmpd.conf file.  They
       cannot be set up via SNMP SET requests.

   Embedded Perl Support
       Programs using the  previous  extension  mechanisms  can  be  written  in  any  convenient
       programming  language  -  including  perl,  which  is  a  common  choice  for pass-through
       extensions in particular.  However the Net-SNMP agent also includes support  for  embedded
       perl technology (similar to mod_perl for the Apache web server).  This allows the agent to
       interpret perl scripts directly, thus avoiding the  overhead  of  spawning  processes  and
       initializing the perl system when a request is received.

       Use of this mechanism requires that the agent was built with support for the embedded perl
       mechanism, which is not part of the default  build  environment.  It  must  be  explicitly
       included  by  specifying  the '--enable-embedded-perl' option to the configure script when
       the package is first built.

       If enabled, the following directives will be recognised:

       disablePerl true
              will turn off embedded perl support entirely (e.g. if there are problems  with  the
              perl installation).

       perlInitFile FILE
              loads  the  specified initialisation file (if present) immediately before the first
              perl directive is parsed.  If not explicitly specified, the agent will look for the
              default initialisation file /usr/share/snmp/snmp_perl.pl.

              The  default initialisation file creates an instance of a NetSNMP::agent object - a
              variable $agent which can be used to register perl-based MIB handler routines.

       perl EXPRESSION
              evaluates the given expression.  This would typically register a handler routine to
              be called when a section of the OID tree was requested:
                     perl use Data::Dumper;
                     perl sub myroutine  { print "got called: ",Dumper(@_),"\n"; }
                     perl $agent->register('mylink', '.1.3.6.1.8765', \&myroutine);

              This expression could also source an external file:
                     perl 'do /path/to/file.pl';

              or perform any other perl-based processing that might be required.

   Dynamically Loadable Modules
       Most  of the MIBs supported by the Net-SNMP agent are implemented as C code modules, which
       were compiled and linked into the agent libraries when the suite was  first  built.   Such
       implementation  modules  can  also  be  compiled independently and loaded into the running
       agent once it has started.  Use of this mechanism requires that the agent was  built  with
       support  for  the  ucd-snmp/dlmod  module  (which is included as part of the default build
       configuration).

       dlmod NAME PATH
              will load the shared object module from the file PATH (an absolute  filename),  and
              call the initialisation routine init_NAME.

              Note:  If  the  specified  PATH  is  not  a  fully  qualified  filename, it will be
                     interpreted relative to /usr/lib/x86_64-linux-gnu/snmp/dlmod, and  .so  will
                     be appended to the filename.

       This functionality can also be configured using SNMP SET requests to the UCD-DLMOD-MIB.

   Proxy Support
       Another  mechanism  for  extending  the  functionality  of  the  agent is to pass selected
       requests (or selected varbinds) to another SNMP agent, which can be running  on  the  same
       host  (presumably  listening  on  a  different  port), or on a remote system.  This can be
       viewed either as the main agent delegating requests to the remote  one,  or  acting  as  a
       proxy  for  it.   Use of this mechanism requires that the agent was built with support for
       the ucd-snmp/proxy module (which is included as part of the default build configuration).

       proxy [-Cn CONTEXTNAME] [SNMPCMD_ARGS] HOST OID [REMOTEOID]
              will pass any incoming requests under OID  to  the  agent  listening  on  the  port
              specified  by  the  transport address HOST.  See the section LISTENING ADDRESSES in
              the snmpd(8) manual page  for  more  information  about  the  format  of  listening
              addresses.

              Note:  To proxy the entire MIB tree, use the OID .1.3 (not the top-level .1)

       The  SNMPCMD_ARGS  should  provide  sufficient  version  and administrative information to
       generate a valid SNMP request (see snmpcmd(1)).

       Note:  The proxied request will not use the  administrative  settings  from  the  original
              request.

       If  a  CONTEXTNAME  is specified, this will register the proxy delegation within the named
       context in the local agent.  Defining multiple proxy  directives  for  the  same  OID  but
       different  contexts  can be used to query several remote agents through a single proxy, by
       specifying the appropriate SNMPv3 context in  the  incoming  request  (or  using  suitable
       configured community strings - see the com2sec directive).

       Specifying the REMOID parameter will map the local MIB tree rooted at OID to an equivalent
       subtree rooted at REMOID on the remote agent.

   SMUX Sub-Agents
       The Net-SNMP agent supports the SMUX protocol (RFC 1227) to  communicate  with  SMUX-based
       subagents (such as gated, zebra or quagga).  Use of this mechanism requires that the agent
       was built with support for the smux module,  which  is  not  part  of  the  default  build
       environment,  and  must be explicitly included by specifying the '--with-mib-modules=smux'
       option to the configure script when the package is first built.

              Note:  This extension protocol has been officially deprecated in favour  of  AgentX
                     (see below).

       smuxpeer OID PASS
              will  register  a  subtree for SMUX-based processing, to be authenticated using the
              password PASS.  If a subagent (or "peer") connects to the agent and registers  this
              subtree  then  requests for OIDs within it will be passed to that SMUX subagent for
              processing.

              A suitable entry for an OSPF routing daemon (such as gated, zebra or quagga)  might
              be something like
                     smuxpeer .1.3.6.1.2.1.14 ospf_pass

       smuxsocket <IPv4-address>
              defines  the  IPv4  address  for SMUX peers to communicate with the Net-SNMP agent.
              The default is to listen on all IPv4 interfaces ("0.0.0.0"), unless the package has
              been  configured  with "--enable-local-smux" at build time, which causes it to only
              listen on 127.0.0.1 by default. SMUX uses the well-known TCP port 199.

       Note the Net-SNMP agent will only operate as a SMUX master  agent.  It  does  not  support
       acting in a SMUX subagent role.

   AgentX Sub-Agents
       The  Net-SNMP  agent  supports  the AgentX protocol (RFC 2741) in both master and subagent
       roles.  Use of this mechanism requires that the agent  was  built  with  support  for  the
       agentx  module  (which  is  included as part of the default build configuration), and also
       that this support is explicitly enabled (e.g. via the snmpd.conf file).

       There are two directives specifically relevant to running as an AgentX master agent:

       master agentx
              will enable the AgentX functionality and cause the agent  to  start  listening  for
              incoming  AgentX  registrations.  This can also be activated by specifying the '-x'
              command-line option (to specify an alternative listening socket).

       agentXPerms SOCKPERMS [DIRPERMS [USER|UID [GROUP|GID]]]
              Defines the permissions and ownership of the AgentX Unix  Domain  socket,  and  the
              parent  directories  of  this  socket.  SOCKPERMS and DIRPERMS must be octal digits
              (see chmod(1) ). By default this socket will only be accessible to subagents  which
              have the same userid as the agent.

       There is one directive specifically relevant to running as an AgentX sub-agent:

       agentXPingInterval NUM
              will make the subagent try and reconnect every NUM seconds to the master if it ever
              becomes (or starts) disconnected.

       The remaining directives are relevant to both AgentX master and sub-agents:

       agentXSocket [<transport-specifier>:]<transport-address>[,...]
              defines the address the master agent listens at, or the subagent should connect to.
              The  default  is  the  Unix  Domain  socket  "/var/agentx/master".   Another common
              alternative is tcp:localhost:705.  See  the  section  LISTENING  ADDRESSES  in  the
              snmpd(8) manual page for more information about the format of addresses.

              Note:  Specifying   an   AgentX   socket   does  not  automatically  enable  AgentX
                     functionality (unlike the '-x' command-line option).

       agentXTimeout NUM
              defines the timeout period (NUM seconds) for  an  AgentX  request.   Default  is  1
              second.   NUM  also  be  specified  with a suffix of one of s (for seconds), m (for
              minutes), h (for hours), d (for days), or w (for weeks).

       agentXRetries NUM
              defines the number of retries for an AgentX request.  Default is 5 retries.

       net-snmp ships with both C and Perl APIs to develop your own AgentX subagent.

OTHER CONFIGURATION

       override [-rw] OID TYPE VALUE
              This directive allows you to override a particular OID with a different value  (and
              possibly  a  different type of value).  The -rw flag will allow snmp SETs to modify
              it's value as well. (note that if you're overriding  original  functionality,  that
              functionality  will  be  entirely lost.  Thus SETS will do nothing more than modify
              the  internal  overridden  value  and  will  not  perform  any  of   the   original
              functionality  intended to be provided by the MIB object.  It's an emulation only.)
              An example:

                     override sysDescr.0 octet_str "my own sysDescr"

              That line will set the sysDescr.0 value to "my own sysDescr" as  well  as  make  it
              modifiable  with  SNMP SETs as well (which is actually illegal according to the MIB
              specifications).

              Note that care must be taken when using this.  For example, if you try to  override
              a  property  of  the  3rd  interface  in the ifTable with a new value and later the
              numbering within the ifTable  changes  it's  index  ordering  you'll  end  up  with
              problems and your modified value won't appear in the right place in the table.

              Valid  TYPEs  are:  integer,  uinteger,  octet_str,  object_id,  counter, null (for
              gauges, use "uinteger"; for bit strings, use "octet_str").  Note  that  setting  an
              object to "null" effectively delete's it as being accessible.  No VALUE needs to be
              given if the object type is null.

              More types should be available in the future.

       If you're trying to figure out aspects of the various  mib  modules  (possibly  some  that
       you've  added  yourself),  the  following  may  help  you  spit  out some useful debugging
       information.  First off, please read the snmpd manual page  on  the  -D  flag.   Then  the
       following  configuration  snmpd.conf  token, combined with the -D flag, can produce useful
       output:

       injectHandler HANDLER modulename [beforeThis]
              This will insert new handlers into the  section  of  the  mib  tree  referenced  by
              "modulename".  If "beforeThis" is specified then the module will be injected before
              the named module.  This is useful for  getting  a  handler  into  the  exact  right
              position in the chain.

              The types of handlers available for insertion are:

              stash_cache
                     Caches  information  returned  from  the lower level.  This greatly help the
                     performance of the agent, at the cost of caching the data such that  its  no
                     longer  "live"  for  30 seconds (in this future, this will be configurable).
                     Note that  this  means  snmpd  will  use  more  memory  as  well  while  the
                     information  is  cached.   Currently this only works for handlers registered
                     using the table_iterator support, which is only a few mib  tables.   To  use
                     it,  you  need to make sure to install it before the table_iterator point in
                     the chain, so to do this:

                       injectHandler stash_cache NAME table_iterator

                     If you want a table to play with, try walking  the  nsModuleTable  with  and
                     without this injected.

              debug  Prints  out  lots  of  debugging information when the -Dhelper:debug flag is
                     passed to the snmpd application.

              read_only
                     Forces turning off write support for the given module.

              serialize
                     If a module is failing to handle multiple requests properly (using  the  new
                     5.0 module API), this will force the module to only receive one request at a
                     time.

              bulk_to_next
                     If a module registers to handle getbulk support,  but  for  some  reason  is
                     failing  to  implement  it  properly,  this  module will convert all getbulk
                     requests to getnext requests before the final module receives it.

       dontLogTCPWrappersConnects
              If the snmpd was compiled with TCP Wrapper support, it logs every  connection  made
              to  the  agent.  This  setting  disables the log messages for accepted connections.
              Denied connections will still be logged.

       Figuring out module names
              To figure out which modules you  can  inject  things  into,  run  snmpwalk  on  the
              nsModuleTable  which  will  give  a list of all named modules registered within the
              agent.

   Internal Data tables
       table NAME

       add_row NAME INDEX(ES) VALUE(S)

NOTES

       o      The Net-SNMP agent can be instructed to re-read the  various  configuration  files,
              either      via      an      snmpset      assignment      of      integer(1)     to
              UCD-SNMP-MIB::versionUpdateConfig.0 (.1.3.6.1.4.1.2021.100.11.0), or by  sending  a
              kill -HUP signal to the agent process.

       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.

EXAMPLE CONFIGURATION FILE

       See the EXAMPLE.CONF file in the top level source directory for a more detailed example of
       how the above information is used in real examples.

FILES

       /etc/snmp/snmpd.conf

SEE ALSO

       snmpconf(1),   snmpusm(1),   snmp.conf(5),   snmp_config(5),    snmpd(8),    EXAMPLE.conf,
       netsnmp_config_api(3).