unixdev.net


Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (SunOS-5.10)
Page:
Section:
Apropos / Subsearch:
optional field

snmpd.conf(4)                    File Formats                    snmpd.conf(4)



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

SYNOPSIS
       /etc/sma/snmp/snmpd.conf

DESCRIPTION
       snmpd.conf  is  the  configuration  file  that defines how the Net-SNMP
       agent operates. This file can contain any of the  directives  found  in
       the  DIRECTIVES section below. snmpd.conf is not required for the agent
       to operate and respond to requests.

       It is recommended that you read the snmp_config(4) manual  page,  which
       describes  how the Net-SNMP configuration files operate, where they are
       located, and how they work together.  You might also find it useful  to
       examine  the snmpconf utility (a perl script). This utility enables you
       to build an snmpd.conf file by prompting you for information.  See  the
       snmpconf(1M) manual page for more information.

       The  Net-SNMP  agent can be forced to reread its configuration files in
       either of two ways:

         o  An snmpset of integer(1) to:


            UCD-SNMP-MIB::versionUpdateConfig.0(.1.3.6.1.4.1.2021.100.11.0)

         o  A kill -HUP signal sent to the snmpd agent process.


   Extensible MIB
       The Net-SNMP agent reports much of its information through  queries  to
       the 1.3.6.1.4.1.2021 section of the MIB tree. Every MIB in this section
       has the following table entries in it.

       .1 -- index

           The table's index numbers for each of the directives listed below.



       .2 -- name

           The name of the given table entry. It is recommended that this name
           be unique, but is not required to be.



       .100 -- errorFlag

           A  flag  returning the integer value 1 or 0 if an error is detected
           for this table entry.



       .101 -- errorMsg

           This is a DISPLAY-STRING describing any error triggering the error-
           Flag above.



       .102 -- errorFix

           If  this  entry  is set to the integer value of 1 and the errorFlag
           defined above is indeed a 1, a program or script will get  executed
           with  the table entry name from above as the argument.  The program
           to be executed is configured in the config.h file at compile time.



   Directives
       proc name
       proc name max
       proc name max min

           Checks to see if processes called NAME are  running  on  the  agent
           machine.  An  error  flag  (1)  and  a description message are then
           passed to the 1.3.6.1.4.1.2021.2.1.100 and 1.3.6.1.4.1.2021.2.1.101
           MIB  columns  (respectively)  if the name'd program is not found in
           the process table as reported by /usr/bin/ps -e.

           If max and min are not specified, max is assumed to be infinity and
           min is assumed to be 1.

           If  max is specified but min is not specified, min is assumed to be
           0.





       procfix name prog args

           Registers a command that knows how to fix  errors  with  the  given
           process name. When 1.3.6.1.4.1.2021.2.1.102 for a given name'd pro-
           gram is set to the integer value of 1, this command will be called.
           It defaults to a compiled value set using the PROCFIXCMD definition
           in the config.h file.



       exec name prog args
       exec mibnum name prog args

           If mibnum is not specified, the agent executes the named prog  with
           arguments of args and returns the exit status and the first line of
           the  stdout  output  of  the  prog  program  to  queries   of   the
           1.3.6.1.4.1.2021.8.1.100  and  1.3.6.1.4.1.2021.8.1.101 mib columns
           (respectively). All stdout output beyond the first line is silently
           truncated.

           If  mibnum is specified, it acts as above but returns the exit sta-
           tus to mibnum.100.0 and the entire stdout output to the table  mib-
           num.101  in  a MIB table. In this case, the mibnum.101 mib contains
           the entire stdout output, one MIB table entry per  line  of  output
           (that  is,  the first line is output as mibnum.101.1, the second at
           mibnum.101.2, and so forth).

           The mibnum must be specified in dotted-integer notation and  cannot
           be  specified  as  .iso.org.dod.internet...  (this would instead be
           .1.3.6.1...).

           The agent caches the exit status and stdout of the executed program
           for  30  seconds after the initial query. This is to increase speed
           and maintain  consistency  of  information  for  consecutive  table
           queries.  The  cache  can be flushed by a snmp-set request of inte-
           ger(1) to 1.3.6.1.4.1.2021.100.VERCLEARCACHE.




       execfix name prog args

           Registers a command that knows how to fix  errors  with  the  given
           exec  or sh name.  When 1.3.6.1.4.1.2021.8.1.102 for a given name'd
           entry is set to the integer  value  of  1,  this  command  will  be
           called.  It  defaults  to a compiled value set using the EXECFIXCMD
           definition in the config.h file.



       disk path
       disk path [ minspace | minpercent% ]

           Checks the named disks mounted at path for available disk space. If
           the  disk  space  is less than minspace (kilobytes) if specified or
           less than minpercent  (%)  if  a  percent  sign  is  specified,  or
           DEFDISKMINIMUMSPACE  (kilobytes)  if  not specified, the associated
           entry in the 1.3.6.1.4.1.2021.9.1.100 MIB table will be set to  (1)
           and  a  descriptive  error  message  will be returned to queries of
           1.3.6.1.4.1.2021.9.1.101.




       load max1
       load max1 max5
       load max1 max5 max15

           Checks the load average of the machine and returns  an  error  flag
           (1)    and    a   text-string   error   message   to   queries   of
           1.3.6.1.4.1.2021.10.1.100  and  1.3.6.1.4.1.2021.10.1.101  (respec-
           tively)  when  the 1-minute, 5-minute, or 15-minute averages exceed
           the associated maximum values. If any of the max1, max5,  or  max15
           values are unspecified, they default to a value of DEFMAXLOADAVE.





       file file [maxsize]

           Monitors  file  sizes and makes sure they do not grow beyond a cer-
           tain size (in kilobytes). maxsize defaults to infinite if not spec-
           ified,  and  only  monitors the size without reporting errors about
           it. A maximum of 20 files can be monitored.



   ERRORS
       Any errors in obtaining the information described above are reported by
       means     of    the    1.3.6.1.4.1.2021.101.1.100    flag    and    the
       1.3.6.1.4.1.2021.101.1.101 text-string description.

   AGENTX Subagents
       To enable AgentX support in the SNMP master agent, insert a  line  con-
       taining the following elements in your snmpd.conf file:

       master agentx

           See README.agentx for further details.



       AgentXSocket addr

           This  defines the address at which the master agent listens at. The
           default is /var/agentx/master. By default the Unix Domain socket is
           accessible  only  to  subagents  which  have the same userid as the
           agent. The other supported transports are TCP and UDP.  The  trans-
           port specifier format can be obtained in snmpcmd(1m).  Note that it
           is a possible security risk to expose the  master  agent  listening
           address  through  TCP/UDP.   See  section  9  of  RFC 2741 for more
           details.



       AgentXTimeout addr

           Defines the timeout period for an AgentX request. Default is 1 sec-
           ond.



       AgentXRetries addr

           Defines  the  number of retries for an AgentX request. Default is 5
           retries.



       You can also put the parameter listed below in your subagent.conf  file
       (where  subagent is the name you used in your init_snmp("subagent") API
       call.

       agentPingInterval num

           The presence of this parameter makes the subagent try to  reconnect
           every num seconds to the master if it ever becomes disconnected.



   SMUX Subagents
       To  enable an SMUX-based subagent, such as gated, use the smuxpeer con-
       figuration entry:

       smuxpeer OID password

           For gated, a useful entry would be:


           smuxpeer .1.3.6.1.4.1.4.1.3 secret



   Dynamically Loadable Modules
       If the agent is built with support for the UCD-DLMOD-MIB, it is capable
       of  loading  agent MIB modules dynamically at startup through the dlmod
       directive and during run-time through use  of  the  UCD-DLMOD-MIB.  The
       following  directive  loads  the  shared object module file path, which
       uses the module name prefix name.

       dlmod name path

   Access Control
       snmpd supports the View-Based Access Control Model (VACM) as defined in
       RFC 2575. To this end, it recognizes the following keywords in the con-
       figuration file:

         o  com2sec

         o  group

         o  access

         o  view


       In addition snmpd recognizes some easier-to-use wrapper directives:

         o  rocommunity

         o  rwcommunity

         o  rouser

         o  rwuser


       If IPv6 support has been enabled,  the  rocommunity6  and  rwcommunity6
       tokens  are  also  available. This section defines how to configure the
       snmpd program to accept various types and levels of access.

       rouser user [noauth|auth|priv] [OID]
       rwuser user [noauth|auth|priv] [OID]

           Creates an SNMPv3 USM user in the VACM access configuration tables.
           It  is  more  efficient  (and  powerful) to use the combined group,
           access, and view directives, but these wrapper directives are  much
           simpler.

           The  minimum  level of authentication and privacy the user must use
           is specified by the first token (which defaults to auth).  The  OID
           parameter  restricts  access  for that user to everything below the
           given OID.




       rocommunity community [source] [OID]
       rwcommunity community [source] [OID]

           Create read-only and read-write communities that  can  be  used  to
           access  the agent. They are a quick wrapper around the more complex
           and powerful com2sec, group, access, and view directive lines. They
           are not as
            efficient  as these, because groups are not created, so the tables
           are potentially larger. These directives are  not  recommended  for
           complex  environments.  If your environment is relatively simple or
           you can sustain a small  negative  performance  impact,  use  these
           directives.

           The  format  of the source token is described in the com2sec direc-
           tive section below. The OID token restricts access for that  commu-
           nity to everything below that given OID.




       rocommunity6 community [source] [OID]
       rwcommunity6 community [source] [OID]

           The equivalent directives to the rocommunity and rwcommunity direc-
           tives for the transport domain UDPIPv6.  They  are  valid  only  in
           specifying UDPIPv6 as the transport domain.

           The  format  of the source token is described in the com2sec direc-
           tive section below. The OID token restricts access for that  commu-
           nity to everything below that given OID.




       com2sec name source community

           Specifies  the  mapping  from a source/community pair to a security
           name. source can be a hostname, a subnet, or the  word  default.  A
           subnet   can   be  specified  as  IP/mask  or  IP/bits.  The  first
           source/community combination that matches the  incoming  packet  is
           selected.



       com2sec6 name source community

           The  IPv6  version  of  com2sec.  A  subnet  can  be  specified  as
           IPv6/IPv6mask or IPv6/bits. Valid only in specifing UDPIPv6 as  the
           transport domain.



       group name model security

           Defines  the  mapping  from  securitymodel/securityname to a group.
           model is one of v1, v2c, or usm.



       access name context model level prefx read write notify

           Maps from group/security and model/security level to a view.  model
           is  one  of  any, v1, v2c, or usm. level is one of noauth, auth, or
           priv. prefx specifies how context should  be  matched  against  the
           context  of  the  incoming PDU, either exact or prefix. read, write
           and notify specifies the view to  be  used  for  the  corresponding
           access.  For  v1  or  v2c access, level will be noauth, and context
           will be empty.



       view name type subtree [mask]

           Defines the named view. type is either included or  excluded.  mask
           is  a list of hex octets, separated by a period (.) or a colon (:).
           The mask defaults to ff if not specified.

           Use of the mask allows you to control access to one row in a  table
           in a relatively simple way. As an example, as an ISP you might con-
           sider giving each customer access to his or her own interface:


           view cust1 included interfaces.ifTable.ifEntry.ifIndex.1 ff.a0
           view cust2 included interfaces.ifTable.ifEntry.ifIndex.2 ff.a0

           # interfaces.ifTable.ifEntry.ifIndex.1 == .1.3.6.1.2.1.2.2.1.1.1
           # ff.a0 == 11111111.10100000

           These entries cover up and include the row index, yet  still  allow
           the user to vary the field of the row.



       The following are VACM examples:

       # sec.name source community
       com2sec local localhost private
       com2sec mynet 10.10.10.0/24 public
       com2sec public default public
       com2sec6 mynet fec0::/64 public

       # sec.model sec.name
       group mygroup v1 mynet
       group mygroup v2c mynet
       group mygroup usm mynet
       group local v1 local
       group local v2c local
       group local usm local
       group public v1 public
       group public v2c public
       group public usm public

       # incl/excl subtree mask
       view all included .1 80
       view system included system fe
       view mib2 included .iso.org.dod.internet.mgmt.mib-2 fc

       # context sec.model sec.level prefix read write notify
       access mygroup "" any noauth exact mib2 none none
       access public "" any noauth exact system none none
       access local "" any noauth exact all all all

   Default VACM Model
       The  default  configuration  of  the agent, as shipped, is functionally
       equivalent to the following entries:

       com2sec public default public
       group public v1 public
       group public v2c public
       group public usm public
       view  all included .1
       access public "" any noauth exact all none none

       Please note rwuser, rouser, rwcommunity, and rocommunity  entries  take
       precedence  over  vacm  group entries that have the same user/community
       names.

   SNMPv3 Configuration
       engineID string

           The snmpd agent needs to be configured with an engineID to be  able
           to  respond  to SNMPv3 messages. With this configuration file line,
           the engineID will be configured from string. The default  value  of
           the  engineID is configured with the first IP address found for the
           hostname of the machine.



       createUser username (MD5|SHA) authpassphrase [DES] [privpassphrase]

           MD5 and SHA are the authentication types to use, but you must  have
           built  the  package with OpenSSL installed in order to use SHA. The
           only privacy protocol currently supported  is  DES.  If  the  priv-
           passphrase  is not specified, it is assumed to be the same as priv-
           passphrase. Note that the users created will be useless unless they
           are also added to the VACM access control tables described above.


           Note -  The minimum pass phrase length is 8 characters.

           SNMPv3  users  can be created at runtime using the snmpusm(1M) com-
           mand.

           Rather than figuring out the intricacies of this directive, run:


           # net-snmp-config --create-snmpv3-user

           This command constructs a correctly formed  line  and  inserts  the
           line in 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 password for that user)  and
           replaced with the key that is derived from it. This key is a local-
           ized key, so that if it is stolen it cannot be used to access other
           agents.  If  the password is stolen, however, other agents are com-
           promised.



   Setting System Information
       syslocation string
       syscontact string
       sysname string

           Sets the system location, system contact, or system  name  for  the
           agent.  This  information is reported in the system group the mibII
           tree. Ordinarily, these objects  (sysLocation.0,  sysContact.0  and
           sysName.0) are read-write. However, specifying the value for one of
           these objects by giving the appropriate token makes the correspond-
           ing  object  read-only  and attempts to set the value of the object
           will result in a notWritable error response.





       sysservices number

           Sets the value of the system.sysServices.0 object. For  a  host,  a
           useful value is 72.



       sysdescr string
       sysobjectid oid

           Sets  the  system  description or object ID for the agent. Although
           these values are not SNMP-writable, it is conceivable that  a  net-
           work  administrator might want to configure them to something other
           than the default values.




       agentaddress [<transport-specifier>:]<transport-address>[,...]

           Makes the agent listen on the  specified  comma-separated  list  of
           listening  addresses  instead  of the default behavior, which is to
           listen on UDP port 161 on all IPv4 interfaces. See the section LIS-
           TENING  ADDRESSES in the snmpd(1M) manual page for more information
           about the format of listening addresses. For example, specifying:


           agentaddress 161,tcp:161,localhost:9161

           ...will make the agent listen on UDP port 161 on  all  IPv4  inter-
           faces,  TCP  port 161 on all IPv4 interfaces and UDP port 9161 only
           on the interface associated with the localhost address.



       agentgroup groupid

           Change to groupid after opening a port. The groupid can refer to  a
           group  by name or, if the group number starts with a hash sign (#),
           a number. For example, specifying agentgroup snmp causes the  agent
           to  run as the snmp group; agentgroup #10 makes the agent to run as
           the group with groupid 10.



       agentuser uid

           Change to uid after opening a port. The uid can refer to a user  by
           name  or, if the user number starts with a hash sign (#), a number.
           For example, specifying agentuser snmp causes the agent to  run  as
           the  snmp  user;  agentuser #10 causes the agent to run as the user
           with userid 10.



       interface name type speed

           For interfaces where the agent fails to guess correctly on the type
           and  speed,  this directive can supply additional information. type
           is a type value as given in the IANAifType-MIB.



       ignoredisk string

           This directive ensures that an agent does  not  timeoout  for  disk
           string.  When  scanning for available disk devices, the agent might
           block in trying to open all possible disk devices. This might  lead
           to  a  timeout when walking the device tree. The occurrence of such
           timeouts is highly unpredictable.

           If you experience such behavior, you might add this  directive  and
           give  all  device  names  not  to be checked (that is, opened). You
           might have more than one such directive in your configuration  file
           specifying  all  devices  not  to be opened. You might also specify
           those devices using wildcards similar to the syntax you can use  in
           a Bourne shell, as shown in the examples below.

           The following are example ignoredisk directives:

           The  following  directive prevents the device /dev/rdsk/c0t2d0 from
           being scanned:


           ignoredisk /dev/rdsk/c0t2d0

           The  following  directive  prevents  all  devices  /dev/rdsk/c0tXd0
           except /dev/rdsk/c0t6d0 from being scanned.


           ignoredisk /dev/rdsk/c0t[!6]d0

           For most systems, the following directive is similar:


           ignoredisk /dev/rdsk/c0t[0-57-9a-f]d0

           The  following  directive  prevents  all devices whose device names
           start with /dev/rdsk/c1 from being scanned.


           ignoredisk /dev/rdsk/c1\(**

           The  following  directive  prevents  all  devices  /dev/rdsk/cXt0d0
           (where X can be any character) from being scanned.


           ignoredisk /dev/rdsk/c?t0d0

           You can use more than one such wildcard expression in a such direc-
           tive.



       storageUseNFS number

           Setting storageUseNFS to 1 causes all NFS and NFS-like file systems
           to  be  marked  as  Network  Disks  in  the hrStorageTable. This is
           according to RFC 2790. Not setting storageUseNFS or setting it to 2
           causes  NFS  and NFS-like file systems to be marked as Fixed Disks,
           as it has been in previous versions of the ucd-snmp SNMP agent.



       authtrapenable number

           Setting authtrapenable to 1 enables  generation  of  authentication
           failure  traps.  The  default value is disabled(2). Ordinarily, the
           corresponding object (snmpEnableAuthenTraps.0) is  read-write,  but
           setting its value by means of this token makes the object read-only
           and attempts to set the value  of  the  object  will  result  in  a
           notWritable error response.



       override oid type value

           This  directive allows you to override a particular OID with a dif-
           ferent value (and possibly a different type of value). For example:


           override -rw sysDescr.0 octet_str "my own sysDescr"

           The preceding line sets the sysDescr.0 value to "my  own  sysDescr"
           as  well as make it modifiable with SNMP SETs. The latter result is
           illegal according to the MIB specifications.

           Note that care must be taken when using this directive.  For  exam-
           ple,  if  you  try to override a property of the third interface in
           the ifTable with a new value and later  the  numbering  within  the
           ifTable  changes  its  index  ordering,  you will obtain unexpected
           results.

           Valid types are:


             o
                integer

             o  uinteger

             o  octet_str

             o  bit_str

             o  object_id

             o  counter

             o  gauge

             o  null

           Note that setting an object to null effectively makes it inaccessi-
           ble. No value needs to be given if the object type is null.



   Setting Up Traps and Informing Destinations
       trapcommunity string

           Defines the default community string to be used when sending traps.
           Note that this command must be used prior to any of the three  com-
           mands  (immediately following) that are intended use this community
           string.



       trapsink host[community [port]]
       trap2sink host[community [port]]
       informsink host[community [port]]

           Define the hosts to receive traps  (or  inform  notifications  with
           informsink).  The daemon sends a Cold Start trap when it starts up.
           If enabled, it also sends traps on authentication failures. You can
           specify  multiple trapsink, trap2sink and informsink lines to spec-
           ify multiple destinations. Use trap2sink to send SNMPv2  traps  and
           informsink to send inform notifications. If community is not speci-
           fied, the string from a preceding trapcommunity directive  will  be
           used. If port is not specified, the well-known SNMP trap port (162)
           will be used.





       trapsess [snmpcmd_args] host

           A more generic trap configuration token that  allows  any  type  of
           trap  destination to be specified with any version of SNMP. See the
           SNMP command manual page for further details on the arguments  that
           can be passed as snmpcmd_args . In addition to the arguments listed
           there, the special argument -Ci  specifies  that  you  want  inform
           notifications  to  be  used  instead  of unacknowledged traps. This
           requires that you specify a version number of v2c or v3 as well.



   Proxy Support
       proxy [-Cn contextname] [snmpcmd_args] host oid [remoteoid]

           This token specifies that any incoming requests under oid should be
           proxied  to  another  host. If contextname is specified, it assigns
           the proxied tree to a particular  context  name  within  the  local
           agent.  This  is the correct way to query multiple agents through a
           single proxy, by assigning each remote agent to a different context
           name. After that, you can use:


           # snmpwalk -n contextname1


           ...to walk one remote proxied agent and:


           # snmpwalk -n contextname2


           to  walk  another,  assuming  you  are  using SNMPv3 to talk to the
           proxy. (SNMPv1 and SNMPv2c context mappings are not currently  sup-
           ported.)  Optionally,  relocate the local OID tree to the new loca-
           tion at the remoteoid. To authenticate  host  you  should  use  the
           appropriate  set of snmpcmd_args. See the SNMP command manual pages
           for details.



       The following are examples of proxy support:

       # assigns the entire mib tree on remotehost1 to the context of the
       # same name:
       proxy -Cn remotehost1 -v 1 -c public remotehost1 .1.3

       # same as preceding, but for remotehost 2
       proxy -Cn remotehost2 -v 1 -c public remotehost2 .1.3

       # proxies only the ucdavis enterprises tree to the remote host using snmpv1
       proxy -v 1 -c public remotehost .1.3.6.1.4.1.2021

       # uses v3 to access remotehost and converts the remote .1.3.6.1.2.1.1
       # oid to local .1.3.6.1.3.10 oid (another way to access mulitple hosts
       # without using contexts)
       proxy -v 3 -l noAuthNoPriv -u user remotehost .1.3.6.1.3.10 .1.3.6.1.2.1.1

   Pass-Through Control
       pass miboid exec

           Passes entire control of miboid to the exec program.  The exec pro-
           gram is called in one of the following ways:


           exec -g miboid
           exec -n miboid

               These call lines are compared to SNMP get and getnext requests.
               It is expected that the exec program will  take  the  arguments
               passed  to  it  and return the appropriate response through its
               stdout.

               The first line of stdout should be the miboid of the  returning
               value.  The  second  line should be the type of value returned,
               where type  is  one  of  the  text  strings:  string,  integer,
               unsigned,  objectid,  timeticks, ipaddress, or gauge. The third
               line of stdout should  be  the  value  corresponding  with  the
               returned type.

               For  example, if a script was to return the value integer value
               "42" in response to a request for  .1.3.6.1.4.100,  the  script
               should return the following three lines:


               .1.3.6.1.4.100
               integer
               42

               To  indicate  that  the  script  is  unable  to comply with the
               request because  of  an  end-of-MIB  condition  or  an  invalid
               request,  simply  exit  and return no output to stdout. An SNMP
               error will be generated corresponding to  the  SNMP  noSuchName
               response.





       exec -s miboid type value

           For  SNMP  set  requests, use the call method shown above. The type
           passed to the exec program is one of  the  text  strings:  integer,
           counter, gauge, timeticks, ipaddress, objid, or string. This string
           indicates the type of value passed in the next argument.

           With no return to stdout, you can assume the set to have been  suc-
           cessful.  Otherwise,  return  one of the following error strings to
           signal an error: either not-writable or wrong-type. In  the  latter
           case the appropriate error response will be generated.

           By  default, the only community allowed to write (that is, issue an
           snmpset) to your script will be the "private" community  or  commu-
           nity  #2,  if  defined differently by the community token discussed
           above. Which communities are allowed write access are controlled by
           the RWRITE definition in the snmplib/snmp_impl.h source file.

           The following is an example of this directive, from snmpd.conf:


           pass .1.3.6.1.4.1.2021.255 /path/to/local/passtest



       pass_persist miboid exec

           Passes  entire  control  of  miboid to the exec program. Similar to
           pass, but the exec program  continues  to  run  after  the  initial
           request  is  answered.  Also, both pass and pass_persist block till
           they return.

           Upon initialization, exec is passed the string "PING\n"  in  stdin;
           it should respond by sending "PONG\n" to stdout.

           For get and getnext requests, exec program is passed two lines, the
           command (get or getnext) and the miboid.  It  should  return  three
           lines, the MIB OID, the type of value returned, and the value asso-
           ciated with the returned type.

           For example, if the value for  .1.3.6.1.4.100  was  requested,  the
           following 2 lines would be passed in to stdin:


           get
           .1.3.6.1.4.100

           To return the value of, say, 42, the script would write to stdout:


           .1.3.6.1.4.100
           integer
           42

           To  indicate  that  the script is unable to comply with the request
           due to  an  end-of-MIB  condition  or  an  invalid  request,  print
           "NONE\n" to stdout.

           The following is an example of this directive, in snmpd.conf:


           pass_persist .1.3.6.1.4.1.2021.255 /path/to/local/pass_persisttest



   Sending Traps on Errors
       Caution - This  implementation  has  not been extensively tested and is
                 additionally not known to be entirely complete. The  concepts
                 defined  here  should function appropriately. However, but no
                 promises are made at this time.

       If your agent was compiled with support for  the  DISMAN-EVENT-MIB  you
       have  support for having the agent check its own data at regular inter-
       vals and to send out traps  when  certain  conditions  occur.  You  can
       enable  DISMAN-EVENT-MIB  by running the net-snmp configure script with
       the following argument:

       --with-mib-modules=disman/event-mib

       Traps are sent when expressions are first noticed, not once per evalua-
       tion.  Once  a test expression fires a trap, the test will have to fail
       again before a new trap is sent. See the DISMAN-EVENT-MIB documentation
       for  more  details.  This can be configured either using the MIB tables
       themselves or by using these special key words:

       agentSecName name

           The DISMAN-EVENT-MIB support requires a valid user name with  which
           to  scan  your agent. You can specify this name either by using the
           agentSecName token or by explicitly  listing  one  on  the  monitor
           lines  (with  the  -u switch) described below. Either way, you must
           also specify a rouser line (or equivalent access control  settings)
           with  the same security name. For example, entries such as the fol-
           lowing:


           agentSecName internal
           rouser internal

           ...enable the directives below to work correctly.



       monitor [options] name expression

           This token tells the agent to monitor itself for problems based  on
           expression.  expression  is  a simple expression based on an OID, a
           comparison operator (!=, ==, <&lt;, <&lt;=, >&gt;, >&gt;=)  and  an  integer  value
           (see  the examples below). name is an arbitrary name of your choos-
           ing for administrative purposes only. options include the following
           possibilities:


           -r frequency

               Monitors  the  given  expression  every  frequency seconds. The
               default is 600 (10 minutes).




           -u secname

               Use the secname security name for scanning the local host. This
               secname  must  then  be given access control rights by means of
               the rouser snmpd.conf  token  or  similar  mechanism  for  this
               expression  to  be valid. If not specified, it uses the default
               security name specified by the agentsecname  snmpd.conf  token.
               Either the -u flag or a valid agentsecname token must be speci-
               fied and that name must be given proper access  control  rights
               with a rouser token.



           -o OID

               Specifies  additional  object  values  to  be  delivered in the
               resulting trap, in addition to the normal  trap  objects.  This
               option  is  useful for obtaining other columns in the table for
               the row that triggered the expression. See the  examples  below
               for more details.


           The following example configuration checks the hrSWRunPerfTable ta-
           ble (listing running processes) for any process that  is  consuming
           more  than10 Mb of memory. It performs this check every 600 seconds
           (the default). For every process it finds exceeding the  limit,  it
           will  send  out exactly one notification. In addition to the normal
           hrSWRunPerfMem OID and value sent  in  the  trap,  the  hrSWRunName
           object  will  also be sent. Note that the hrSWRunName object occurs
           in a different table, but since the indexes to the two  tables  are
           the same, you achieve the desired result.


           rouser me
           monitor -u me -o sysUpTime.0 -o hrSWRunName "high process memory" \
           hrSWRunPerfMem > 10000

           The  preceding  line  would produce a trap which, when formatted by
           snmptrapd, would display as follows:


           2002-04-05 13:33:53 localhost.localdomain [udp:127.0.0.1:32931]:
           sysUpTimeInstance = Timeticks: (1629) 0:00:16.29 snmpTrapOID.0 = \
           OID: mteTrigger Fired mteHotTrigger = high process memory \
           mteHotTargetName = mteHotContextName = mteHotOID = \
           OID: hrSWRunPerfMem.1968 mteHotValue = \
           28564 hrSWRunName.1968 = "xemacs"

           The preceding shows an xemacs process using 28 Mb of resident  mem-
           ory.


       defaultMonitors yes

           By  default,  the  agent  and  the DISMAN-EVENT-MIB support are not
           functional until configured. A typical use of the  agent  to  watch
           several  tables  within the UCD-SNMP-MIB that are designed specifi-
           cally for reporting problems. If the defaultMonitors  yes  line  is
           put  into  the  snmpd.conf  file,  accompanied  by  an  appropriate
           agentSecName line and an rouser line, the following monitoring con-
           ditions will be installed:


           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



   Debugging and Other Extensibility Notes
       If  you  are  trying  to figure out aspects of the various MIB modules,
       including some that you might have added yourself, the following  might
       help  you produce useful debugging information. Read the snmpd(1M) man-
       ual page for information on the -D flag. Then use the following config-
       uration  snmpd.conf token, combined with the -D flag, to produce useful
       output:

       injectHandler handler modulename

       The preceding inserts new handlers into the section  of  the  MIB  tree
       referenced by modulename. The types of handlers available for insertion
       are:

       debug

           Displays  copious  debugging  information  when  -Dhelper:debug  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 forces the module to receive only one
           request at a time.



       bulk_to_next

           If  a module registers to handle getbulk support, but for some rea-
           son is failing to implement it properly, this module  converts  all
           getbulk  requests  to  getnext  requests  before  the  final module
           receives it.



       To figure out into which modules you can inject entities, snmpwalk  the
       nsModuleTable.  This  gives  you a list of all named modules registered
       within the agent.

EXAMPLES
       See the example.conf file in the  top  level  source  directory  for  a
       detailed  example  of  how  the information in this man page is used in
       real examples.

FILES
         o  /etc/sma/snmp/snmpd.conf


ATTRIBUTES
       See attributes(5) for descriptions of the following attributes:


       tab()    allbox;    cw(2.750000i)|     cw(2.750000i)     lw(2.750000i)|
       lw(2.750000i).   ATTRIBUTE  TYPEATTRIBUTE  VALUE  AvailabilitySUNWsmmgr
       Interface StabilityExternal


SEE ALSO
       snmpd(1M), snmp_config(4), attributes(5)



SunOS 5.10                        10 Oct 2003                    snmpd.conf(4)