Provided by: snmpd_5.4.3~dfsg-2.4ubuntu1_i386 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:

       o      those controlling who can access the agent

       o      those configuring the information that is supplied by the agent

       o      those controlling active monitoring of the local system

       o      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,  sitting  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,  sitting  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 not that processing of maxGetbulkRepeats is handled first.

   SNMPv3 Configuration
       SNMPv3  requires  an SNMP agent to define a unique "engine ID" in order
       to respond to SNMPv3 requests.  This ID  will  normally  be  determined
       automatically,   using   two  reasonably  non-predictable  values  -  a
       (pseudo-)random number and the current uptime in seconds. This  is  the
       recommended  approach.  However  the  capacity  exists  to  define  the
       engineID in other ways:

       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.

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.
       These fall into four basic groups.

   SNMPv3 Users
       createUser  [-e  ENGINEID]  username (MD5|SHA) authpassphrase [DES|AES]
       [privpassphrase]

              MD5 and SHA 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  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 (preceeded
              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).

   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 USER [noauth|auth|priv [OID | -V VIEW [CONTEXT]]]

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

       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.

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

   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.

   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 (or are both 0), 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").

       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.

              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  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  when  the  agent
              starts  using the setmntent(3) and getmntent(3), or fopen(3) and
              getmntent(3),  or setfsent(3)  and  getfsent(3) system calls. If
              none  of  the  above  system  calls  are available then the root
              partition  "/" (which  is  assumed to exist on  any  UNIX  based
              system)  will  be  monitored.  Disks mounted after the agent has
              started will not be monitored.

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

   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 HOST [COMMUNITY [PORT]]

       trap2sink HOST [COMMUNITY [PORT]]

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

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

              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.

       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.

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

       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.

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:

       o      running external commands (exec, extend, pass)

       o      loading new code dynamically (embedded perl, dlmod)

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

       Both extend and extendfix directives  can  be  configured  dynamically,
       using SNMP SET requests to the NET-SNMP-EXTEND-MIB.

   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,
              or string ), and the third should be the value itself.

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

       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
              This  will  insert new handlers into the section of the mib tree
              referenced by "modulename".  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, read_config(3).