The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Интерактивная система просмотра системных руководств (man-ов)

 ТемаНаборКатегория 
 
 [Cписок руководств | Печать]

snmpd.conf (4)
  • >> snmpd.conf (4) ( Solaris man: Специальные файлы /dev/* )
  • snmpd.conf (5) ( Разные man: Форматы файлов )
  •  

    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:

    * An snmpset of integer(1) to:

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

    * 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 errorFlag 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 program 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 status to mibnum.100.0 and the entire stdout output to the table mibnum.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 integer(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 (respectively) 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 certain size (in kilobytes). maxsize defaults to infinite if not specified, 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 containing 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 transport 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 second.

    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 configuration 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 configuration file:

    * com2sec

    * group

    * access

    * view

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

    * rocommunity

    * rwcommunity

    * rouser

    * 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 directive section below. The OID token restricts access for that community to everything below that given OID.

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

    The equivalent directives to the rocommunity and rwcommunity directives 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 directive section below. The OID token restricts access for that community 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 consider 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 privpassphrase is not specified, it is assumed to be the same as privpassphrase. 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) command.

    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 localized key, so that if it is stolen it cannot be used to access other agents. If the password is stolen, however, other agents are compromised.

     

    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 corresponding 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 network 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 LISTENING 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 interfaces, 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 directive.

    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 different 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 example, 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:

    * integer

    * uinteger

    * octet_str

    * bit_str

    * object_id

    * counter

    * gauge

    * null

    Note that setting an object to null effectively makes it inaccessible. 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 commands (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 specify multiple destinations. Use trap2sink to send SNMPv2 traps and informsink to send inform notifications. If community is not specified, 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 supported.) Optionally, relocate the local OID tree to the new location 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 program 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 successful. 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 community #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 associated 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 intervals 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 evaluation. 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 following:

    
    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 (!=, ==, <, <=, >, >=) and an integer value (see the examples below). name is an arbitrary name of your choosing 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 specified 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 table (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 memory.

    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 specifically 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 conditions 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) manual page for information on the -D flag. Then use the following configuration 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 reason 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

    * /etc/sma/snmp/snmpd.conf

     

    ATTRIBUTES

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

    ATTRIBUTE TYPEATTRIBUTE VALUE
    AvailabilitySUNWsmmgr
    Interface StabilityExternal

     

    SEE ALSO

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


     

    Index

    NAME
    SYNOPSIS
    DESCRIPTION
    Extensible MIB
    Directives
    ERRORS
    AGENTX Subagents
    SMUX Subagents
    Dynamically Loadable Modules
    Access Control
    Default VACM Model
    SNMPv3 Configuration
    Setting System Information
    Setting Up Traps and Informing Destinations
    Proxy Support
    Pass-Through Control
    Sending Traps on Errors
    Debugging and Other Extensibility Notes
    EXAMPLES
    FILES
    ATTRIBUTES
    SEE ALSO


    Поиск по тексту MAN-ов: 




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру