Skip Navigation Links | |
Exit Print View | |
![]() |
man pages section 4: File Formats Oracle Solaris 10 8/11 Information Library |
- configuration file for the Net-SNMP agent
/etc/sma/snmp/snmpd.conf
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.
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.
The table's index numbers for each of the directives listed below.
The name of the given table entry. It is recommended that this name be unique, but is not required to be.
A flag returning the integer value 1 or 0 if an error is detected for this table entry.
This is a DISPLAY-STRING describing any error triggering the errorFlag above.
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.
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.
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.
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.
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.
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.
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.
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.
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.
To enable AgentX support in the SNMP master agent, insert a line containing the following elements in your snmpd.conf file:
See README.agentx for further details.
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.
Defines the timeout period for an AgentX request. Default is 1 second.
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.
The presence of this parameter makes the subagent try to reconnect every num seconds to the master if it ever becomes disconnected.
To enable an SMUX-based subagent, such as gated, use the smuxpeer configuration entry:
For gated, a useful entry would be:
smuxpeer .1.3.6.1.4.1.4.1.3 secret
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
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.
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.
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.
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.
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.
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.
Defines the mapping from securitymodel/securityname to a group. model is one of v1, v2c, or usm.
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.
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
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.
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.
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.
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.
Sets the value of the system.sysServices.0 object. For a host, a useful value is 72.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
Passes entire control of miboid to the exec program. The exec program is called in one of the following ways:
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.
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
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
![]() | 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:
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.
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:
Monitors the given expression every frequency seconds. The default is 600 (10 minutes).
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.
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.
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
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:
Displays copious debugging information when -Dhelper:debug is passed to the snmpd application.
Forces turning off write support for the given module.
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.
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.
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.
/etc/sma/snmp/snmpd.conf
See attributes(5) for descriptions of the following attributes:
|