Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
SNMPD.CONF(5)			   Net-SNMP			 SNMPD.CONF(5)

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) man-
       ual 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  pro-
       viding 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	 vari-
	      able  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  con-
	      sidered 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	- 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 con-
       tains partial support for SNMPv3/SSH as well but	has not	been as	exten-
       sively  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 man-
       ager  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  con-
       flict  with  another  agent's engineID.	Ever.  Internally, Net-SNMP by
       default creates a unique	engineID that is based off of the current sys-
       tem 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)  per-
       formed 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	poten-
       tially 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 file-
	      name.   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  com-
	      ponent  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 man-
	      ual 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  verifi-
	      able up until a trust anchor for it.  This trust anchor is typi-
	      cally a CA certificate but it could also be a  self-signed  cer-
	      tificate.	 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 pro-
       gram 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	appro-
	      priately 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	exist-
       ing 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 authentica-
       tion 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 your-
       self instead:

       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  authentica-
	      tion  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) com-
	      mand.

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

	      This   directive	 should	  be   placed	into   the   /var/net-
	      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 pass-
	      word  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  respec-
	      tively.	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 sep-
	      arated  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 dis-
       tinct 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 config-
       uration 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 host-
	      name  (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.	Other-
	      wise 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 mod-
	      els 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 subidenti-
	      fiers 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  subiden-
	      tifier:

		     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	 secu-
	      rity  model  and	minimum	security level,	and in a specific con-
	      text) to one of three views, depending on	the request being pro-
	      cessed.

	      LEVEL is one of noauth, auth, or priv.  PREFX specifies how CON-
	      TEXT should be matched  against  the  context  of	 the  incoming
	      request,	either exact or	prefix.	 READ, WRITE and NOTIFY	speci-
	      fies 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	flexi-
	      bility.	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 auth-
	      community.

       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 unauthen-
	      ticated 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, typi-
	      cally listing the	view types as read or read,write as  appropri-
	      ate.  (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).	  How-
       ever,  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 (sysLoca-
	      tion.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	direc-
	      tives  can be used by a network administrator to configure suit-
	      able 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  sec-
	      onds. 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	imple-
	      mentation	code includes a	list of	disk device patterns appropri-
	      ate  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.  Set-
	      ting 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-calcu-
	      lates these values so they all fit Integer32 and	hrStorageAllo-
	      cationUnits 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 hrStor-
	      ageSize 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 acx") 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 prE-
	      rrFix 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	corre-
	      sponding 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	 indi-
	      vidual  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 par-
	      tition  "/" (which  is  assumed to exist on any UNIX based  sys-
	      tem)  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).

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

       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"

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

       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 pat-
	      tern 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  logMatch-
		     Name under	logMatch/logMatchTable/logMatchEntry/logMatch-
		     Name 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 moni-
		     tor 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  com-
	      munity-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  notifica-
	      tions  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 spec-
	      ification,  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	gener-
	      ated.

	      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 des-
	      tinations.  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/com-
	      mands/snmptrap-v3.html for more information about	SNMPv3 notifi-
	      cation 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.

       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 dis-
       man/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 notifica-
	      tion  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	direc-
	      tive 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	speci-
		     fies 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 cor-
		     rectly.

	      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 dif-
		     ferences between successive sample	values.

       OPTIONS
	      There are	various	options	to control the behaviour of the	 moni-
	      tored 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 subidenti-
		     fiers  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  notifica-
		     tion  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 notifica-
		     tion payloads.

	      -r FREQUENCY
		     monitors the given	expression every FREQUENCY, where FRE-
		     QUENCY 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 eval-
		     uated when	the agent first	starts up.  The	first  evalua-
		     tion  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 be-
		     haviour.

		     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  NOTIFICA-
	      TION-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 wild-
	      carded 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 spec-
	      ified  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 moni-
	      tor entry	by specifying the option -e ENAME (see above).

	      If the monitor entry that	triggered this event involved a	 wild-
	      carded  expression, the suffix of	the matched instance will nor-
	      mally 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  notifica-
	      tion generator feels might be useful.  The most natural approach
	      would be to associate these mandatory varbinds with the  notifi-
	      cationEvent  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, fol-
	      lowed 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  appropri-
	      ate 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 iquery-
       SecName 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 par-
       ticular 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 equiva-
	      lent 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/deliverByNo-
       tify 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  GET-
       NEXTs).	 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	 noti-
       fications.   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  notifica-
       tions.	Researching  the capabilities of your management station soft-
       ware 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  Han-
       dling" 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, col-
	      lect 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 notifica-
	      tion 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 fragmen-
	      tation.	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-PERI-
	      ODIC-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:

       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  com-
       mands  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 exe-
	      cuted 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 num-
	      ber 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) con-
	      taining 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 sep-
	      arate  extend directives can specify the same MIBOID root, with-
	      out conflicting.

	      The exit status and output is cached for	each  entry  individu-
	      ally,  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-com-
	      mand(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	conve-
       nient 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	mecha-
       nism   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	speci-
	      fied 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	excep-
	      tion.

		     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 std-
	      out, 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 registra-
	      tions 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	inter-
       pret perl scripts directly, thus	avoiding the overhead of spawning pro-
       cesses 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	 pack-
       age 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/local/share/snmp/snmp_perl.pl.

	      The  default  initialisation  file creates an instance of	a Net-
	      SNMP::agent object - a variable $agent which can be used to reg-
	      ister 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	 abso-
	      lute 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/local/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 dif-
       ferent 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	appro-
       priate SNMPv3 context in	the incoming request (or using	suitable  con-
       figured 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 authen-
	      ticated using the	password PASS.	If a subagent (or "peer") con-
	      nects to the agent and registers this subtree then requests  for
	      OIDs within it will be passed to that SMUX subagent for process-
	      ing.

	      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 mas-
       ter 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:local-
	      host: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 per-
	      form 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 (pos-
       sibly 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	nsMod-
		     uleTable 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	 prop-
		     erly  (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 snm-
	      pwalk  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 con-
	      figuration 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 fea-
	      ture 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
       /usr/local/etc/snmp/snmpd.conf

SEE ALSO
       snmpconf(1),  snmpusm(1), snmp.conf(5), snmp_config(5), snmpd(8), EXAM-
       PLE.conf, netsnmp_config_api(3).

V5.7.3				  30 Jun 2010			 SNMPD.CONF(5)

NAME | DESCRIPTION | AGENT BEHAVIOUR | ACCESS CONTROL | SYSTEM INFORMATION | ACTIVE MONITORING | EXTENDING AGENT FUNCTIONALITY | OTHER CONFIGURATION | NOTES | EXAMPLE CONFIGURATION FILE | FILES | SEE ALSO

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=snmpd.conf&manpath=FreeBSD+11.2-RELEASE+and+Ports>

home | help