On Apache
Under GNU General Public License
2012-05-26 06:40 @38.107.179.237 Crawled by CCBot/1.0 (+http://www.commoncrawl.org/bot.html)
SNMPD.CONF(5) Net-SNMP SNMPD.CONF(5)
NAME
snmpd.conf - configuration file for the Net-SNMP SNMP agent
DESCRIPTION
The Net-SNMP agent uses one or more configuration files to control its operation and the
management information provided. These files (snmpd.conf and snmpd.local.conf) can be
located in one of several locations, as described in the snmp_config(5) manual page.
The (perl) application snmpconf can be used to generate configuration files for the most
common agent requirements. See the snmpconf(1) manual page for more information, or try
running the command:
snmpconf -g basic_setup
There are a large number of directives that can be specified, but these mostly fall into
four distinct categories:
o those controlling who can access the agent
o those configuring the information that is supplied by the agent
o those controlling active monitoring of the local system
o those concerned with extending the functionality of the agent.
Some directives don't fall naturally into any of these four categories, but this covers
the majority of the contents of a typical snmpd.conf file. A full list of recognised
directives can be obtained by running the command:
snmpd -H
AGENT BEHAVIOUR
Although most configuration directives are concerned with the MIB information supplied by
the agent, there are a handful of directives that control the behaviour of snmpd consid-
ered simply as a daemon providing a network service.
agentaddress [<transport-specifier>:]<transport-address>[,...]
defines a list of listening addresses, on which to receive incoming SNMP requests.
See the section LISTENING ADDRESSES in the snmpd(8) manual page for more informa-
tion about the format of listening addresses.
The default behaviour is to listen on UDP port 161 on all IPv4 interfaces.
agentgroup {GROUP|#GID}
changes to the specified group after opening the listening port(s). This may refer
to a group by name (GROUP), or a numeric group ID starting with '#' (#GID).
agentuser {USER|#UID}
changes to the specified user after opening the listening port(s). This may refer
to a user by name (USER), or a numeric user ID starting with '#' (#UID).
leave_pidfile yes
instructs the agent to not remove its pid file on shutdown. Equivalent to specify-
ing "-U" on the command line.
maxGetbulkRepeats NUM
Sets the maximum number of responses allowed for a single variable in a getbulk
request. Set to 0 to enable the default and set it to -1 to enable unlimited.
Because memory is allocated ahead of time, sitting this to unlimited is not consid-
ered safe if your user population can not be trusted. A repeat number greater than
this will be truncated to this value.
This is set by default to -1.
maxGetbulkResponses NUM
Sets the maximum number of responses allowed for a getbulk request. This is set by
default to 100. Set to 0 to enable the default and set it to -1 to enable unlim-
ited. Because memory is allocated ahead of time, sitting this to unlimited is not
considered safe if your user population can not be trusted.
In general, the total number of responses will not be allowed to exceed the maxGet-
bulkResponses number and the total number returned will be an integer multiple of
the number of variables requested times the calculated number of repeats allow to
fit below this number.
Also not that processing of maxGetbulkRepeats is handled first.
SNMPv3 Configuration
SNMPv3 requires an SNMP agent to define a unique "engine ID" in order to respond to SNMPv3
requests. This ID will normally be determined automatically, using two reasonably non-
predictable values - a (pseudo-)random number and the current uptime in seconds. This is
the recommended approach. However the capacity exists to define the engineID in other
ways:
engineID STRING
specifies that the engineID should be built from the given text STRING.
engineIDType 1|2|3
specifies that the engineID should be built from the IPv4 address (1), IPv6 address
(2) or MAC address (3). Note that changing the IP address (or switching the net-
work interface card) may cause problems.
engineIDNic INTERFACE
defines which interface to use when determining the MAC address. If engineIDType 3
is not specified, then this directive has no effect.
The default is to use eth0.
ACCESS CONTROL
snmpd supports the View-Based Access Control Model (VACM) as defined in RFC 2575, to con-
trol who can retrieve or update information. To this end, it recognizes various direc-
tives relating to access control. These fall into four basic groups.
SNMPv3 Users
createUser [-e ENGINEID] username (MD5|SHA) authpassphrase [DES|AES] [privpassphrase]
MD5 and SHA are the authentication types to use. DES and AES are the privacy pro-
tocols to use. If the privacy passphrase is not specified, it is assumed to be the
same as the authentication passphrase. Note that the users created will be useless
unless they are also added to the VACM access control tables described above.
SHA authentication and DES/AES privacy require OpenSSL to be installed and the
agent to be built with OpenSSL support. MD5 authentication may be used without
OpenSSL.
Warning: the minimum pass phrase length is 8 characters.
SNMPv3 users can be created at runtime using the snmpusm(1) command.
Instead of figuring out how to use this directive and where to put it (see below),
just run "net-snmp-config --create-snmpv3-user" instead, which will add one of
these lines to the right place.
This directive should be placed into the /var/lib/snmp/snmpd.conf file instead of
the other normal locations. The reason is that the information is read from the
file and then the line is removed (eliminating the storage of the master password
for that user) and replaced with the key that is derived from it. This key is a
localized key, so that if it is stolen it can not be used to access other agents.
If the password is stolen, however, it can be.
If you need to localize the user to a particular EngineID (this is useful mostly in
the similar snmptrapd.conf file), you can use the -e argument to specify an
EngineID as a hex value (EG, "0x01020304").
If you want to generate either your master or localized keys directly, replace the
given password with a hexstring (preceeded by a "0x") and precede the hex string by
a -m or -l token (respectively). EGs:
[these keys are *not* secure but are easy to visually parse for
counting purposes. Please generate random keys instead of using
these examples]
createUser myuser SHA -l 0x0001020304050607080900010203040506070809 AES -l 0x00010203040506070809000102030405
createUser myuser SHA -m 0x0001020304050607080900010203040506070809 AES -m 0x0001020304050607080900010203040506070809
Due to the way localization happens, localized privacy keys are expected to be the
length needed by the algorithm (128 bits for all supported algorithms). Master
encryption keys, though, need to be the length required by the authentication algo-
rithm not the length required by the encrypting algorithm (MD5: 16 bytes, SHA: 20
bytes).
Traditional Access Control
Most simple access control requirements can be specified using the directives
rouser/rwuser (for SNMPv3) or rocommunity/rwcommunity (for SNMPv1 or SNMPv2c).
rouser USER [noauth|auth|priv [OID | -V VIEW [CONTEXT]]]
rwuser USER [noauth|auth|priv [OID | -V VIEW [CONTEXT]]]
specify an SNMPv3 user that will be allowed read-only (GET and GETNEXT) or read-
write (GET, GETNEXT and SET) access respectively. By default, this will provide
access to the full OID tree for authenticated (including encrypted) SNMPv3
requests, using the default context. An alternative minimum security level can be
specified using noauth (to allow unauthenticated requests), or priv (to enforce use
of encryption). The OID field restricts access for that user to the subtree rooted
at the given OID, or the named view. An optional context can also be specified, or
"context*" to denote a context prefix. If no context field is specified (or the
token "*" is used), the directive will match all possible contexts.
rocommunity COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]
rwcommunity COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]
specify an SNMPv1 or SNMPv2c community that will be allowed read-only (GET and GET-
NEXT) or read-write (GET, GETNEXT and SET) access respectively. By default, this
will provide access to the full OID tree for such requests, regardless of where
they were sent from. The SOURCE token can be used to restrict access to requests
from the specified system(s) - see com2sec for the full details. The OID field
restricts access for that community to the subtree rooted at the given OID, or
named view. Contexts are typically less relevant to community-based SNMP versions,
but the same behaviour applies here.
rocommunity6 COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]
rwcommunity6 COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]
are directives relating to requests received using IPv6 (if the agent supports such
transport domains). The interpretation of the SOURCE, OID, VIEW and CONTEXT tokens
are exactly the same as for the IPv4 versions.
In each case, only one directive should be specified for a given SNMPv3 user, or community
string. It is not appropriate to specify both rouser and rwuser directives referring to
the same SNMPv3 user (or equivalent community settings). The rwuser directive provides all
the access of rouser (as well as allowing SET support). The same holds true for the com-
munity-based directives.
More complex access requirements (such as access to two or more distinct OID subtrees, or
different views for GET and SET requests) should use one of the other access control mech-
anisms. Note that if several distinct communities or SNMPv3 users need to be granted the
same level of access, it would also be more efficient to use the main VACM configuration
directives.
VACM Configuration
The full flexibility of the VACM is available using four configuration directives -
com2sec, group, view and access. These provide direct configuration of the underlying
VACM tables.
com2sec [-Cn CONTEXT] SECNAME SOURCE COMMUNITY
com2sec6 [-Cn CONTEXT] SECNAME SOURCE COMMUNITY
map an SNMPv1 or SNMPv2c community string to a security name - either from a par-
ticular range of source addresses, or globally ("default"). A restricted source
can either be a specific hostname (or address), or a subnet - represented as
IP/MASK (e.g. 10.10.10.0/255.255.255.0), or IP/BITS (e.g. 10.10.10.0/24), or the
IPv6 equivalents.
The same community string can be specified in several separate directives (presum-
ably with different source tokens), and the first source/community combination that
matches the incoming request will be selected. Various source/community combina-
tions can also map to the same security name.
If a CONTEXT is specified (using -Cn), the community string will be mapped to a
security name in the named SNMPv3 context. Otherwise the default context ("") will
be used.
com2secunix [-Cn CONTEXT] SECNAME SOCKPATH COMMUNITY
is the Unix domain sockets version of com2sec.
group GROUP {v1|v2c|usm} SECNAME
maps a security name (in the specified security model) into a named group. Several
group directives can specify the same group name, allowing a single access setting
to apply to several users and/or community strings.
Note that groups must be set up for the two community-based models separately - a
single com2sec (or equivalent) directive will typically be accompanied by two group
directives.
view VNAME TYPE OID [MASK]
defines a named "view" - a subset of the overall OID tree. This is most commonly a
single subtree, but several view directives can be given with the same view name
(VNAME), to build up a more complex collection of OIDs. TYPE is either included or
excluded, which can again define a more complex view (e.g by excluding certain sen-
sitive objects from an otherwise accessible subtree).
MASK is a list of hex octets (optionally separated by '.' or ':') with the set bits
indicating which subidentifiers in the view OID to match against. If not speci-
fied, this defaults to matching the OID exactly (all bits set), thus defining a
simple OID subtree. So:
view iso1 included .iso 0xf0
view iso2 included .iso
view iso3 included .iso.org.dod.mgmt 0xf0
would all define the same view, covering the whole of the 'iso(1)' subtree (with
the third example ignoring the subidentifiers not covered by the mask).
More usefully, the mask can be used to define a view covering a particular row (or
rows) in a table, by matching against the appropriate table index value, but skip-
ping the column subidentifier:
view ifRow4 included .1.3.6.1.2.1.2.2.1.0.4 0xff:a0
Note that a mask longer than 8 bits must use ':' to separate the individual octets.
access GROUP CONTEXT {any|v1|v2c|usm} LEVEL PREFX READ WRITE NOTIFY
maps from a group of users/communities (with a particular security model and mini-
mum security level, and in a specific context) to one of three views, depending on
the request being processed.
LEVEL is one of noauth, auth, or priv. PREFX specifies how CONTEXT should be
matched against the context of the incoming request, either exact or prefix. READ,
WRITE and NOTIFY specifies the view to be used for GET*, SET and TRAP/INFORM
requests (althought the NOTIFY view is not currently used). For v1 or v2c access,
LEVEL will need to be noauth.
Typed-View Configuration
The final group of directives extend the VACM approach into a more flexible mechanism,
which can be applied to other access control requirements. Rather than the fixed three
views of the standard VACM mechanism, this can be used to configure various different view
types. As far as the main SNMP agent is concerned, the two main view types are read and
write, corresponding to the READ and WRITE views of the main access directive. See the
'snmptrapd.conf(5)' man page for discussion of other view types.
authcommunity TYPES COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]
is an alternative to the rocommunity/rwcommunity directives. TYPES will usually be
read or read,write respectively. The view specification can either be an OID sub-
tree (as before), or a named view (defined using the view directive) for greater
flexibility. If this is omitted, then access will be allowed to the full OID tree.
If CONTEXT is specified, access is configured within this SNMPv3 context. Other-
wise the default context ("") is used.
authuser TYPES [-s MODEL] USER [LEVEL [OID | -V VIEW [CONTEXT]]]
is an alternative to the rouser/rwuser directives. The fields TYPES, OID, VIEW and
CONTEXT have the same meaning as for authcommunity.
authgroup TYPES [-s MODEL] GROUP [LEVEL [OID | -V VIEW [CONTEXT]]]
is a companion to the authuser directive, specifying access for a particular group
(defined using the group directive as usual). Both authuser and authgroup default
to authenticated requests - LEVEL can also be specified as noauth or priv to allow
unauthenticated requests, or require encryption respectively. Both authuser and
authgroup directives also default to configuring access for SNMPv3/USM requests -
use the '-s' flag to specify an alternative security model (using the same values
as for access above).
authaccess TYPES [-s MODEL] GROUP VIEW [LEVEL [CONTEXT]]
also configures the access for a particular group, specifying the name and type of
view to apply. The MODEL and LEVEL fields are interpreted in the same way as for
authgroup. If CONTEXT is specified, access is configured within this SNMPv3 con-
text (or contexts with this prefix if the CONTEXT field ends with '*'). Otherwise
the default context ("") is used.
setaccess GROUP CONTEXT MODEL LEVEL PREFIX VIEW TYPES
is a direct equivalent to the original access directive, typically listing the view
types as read or read,write as appropriate. (or see 'snmptrapd.conf(5)' for other
possibilities). All other fields have the same interpretation as with access.
SYSTEM INFORMATION
Most of the information reported by the Net-SNMP agent is retrieved from the underlying
system, or dynamically configured via SNMP SET requests (and retained from one run of the
agent to the next). However, certain MIB objects can be configured or controlled via the
snmpd.conf(5) file.
System Group
Most of the scalar objects in the 'system' group can be configured in this way:
sysLocation STRING
sysContact STRING
sysName STRING
set the system location, system contact or system name (sysLocation.0, sysContact.0
and sysName.0) for the agent respectively. Ordinarily these objects are writeable
via suitably authorized SNMP SET requests. However, specifying one of these direc-
tives makes the corresponding object read-only, and attempts to SET it will result
in a notWritable error response.
sysServices NUMBER
sets the value of the sysServices.0 object. For a host system, a good value is 72
(application + end-to-end layers). If this directive is not specified, then no
value will be reported for the sysServices.0 object.
sysDescr STRING
sysObjectID OID
sets the system description or object ID for the agent. Although these MIB objects
are not SNMP-writable, these directives can be used by a network administrator to
configure suitable values for them.
Interfaces Group
interface NAME TYPE SPEED
can be used to provide appropriate type and speed settings for interfaces where the
agent fails to determine this information correctly. TYPE is a type value as given
in the IANAifType-MIB, and can be specified numerically or by name (assuming this
MIB is loaded).
Host Resources Group
This requires that the agent was built with support for the host module (which is now
included as part of the default build configuration on the major supported platforms).
ignoreDisk STRING
controls which disk devices are scanned as part of populating the hrDiskStor-
ageTable (and hrDeviceTable). The HostRes implementation code includes a list of
disk device patterns appropriate for the current operating system, some of which
may cause the agent to block when trying to open the corresponding disk devices.
This might lead to a timeout when walking these tables, possibly resulting in
inconsistent behaviour. This directive can be used to specify particular devices
(either individually or wildcarded) that should not be checked.
Note: Please consult the source (host/hr_disk.c) and check for the
Add_HR_Disk_entry calls relevant for a particular O/S to determine the list
of devices that will be scanned.
The pattern can include one or more wildcard expressions. See snmpd.examples(5)
for illustration of the wildcard syntax.
skipNFSInHostResources true
controls whether NFS and NFS-like file systems should be omitted from the hrStor-
ageTable (true or 1) or not (false or 0, which is the default). If the Net-SNMP
agent gets hung on NFS-mounted filesystems, you can try setting this to '1'.
storageUseNFS [1|2]
controls how NFS and NFS-like file systems should be reported in the hrStor-
ageTable. as 'Network Disks' (1) or 'Fixed Disks' (2) Historically, the Net-SNMP
agent has reported such file systems as 'Fixed Disks', and this is still the
default behaviour. Setting this directive to '1' reports such file systems as
Process Monitoring
The hrSWRun group of the Host Resources MIB provides information about individual pro-
cesses running on the local system. The prTable of the UCD-SNMP-MIB complements this by
reporting on selected services (which may involve multiple processes). This requires that
the agent was built with support for the ucd-snmp/proc module (which is included as part
of the default build configuration).
proc NAME [MAX [MIN]]
monitors the number of processes called NAME (as reported by "/bin/ps -e") running
on the local system.
If the number of NAMEd processes is less than MIN or greater than MAX, then the
corresponding prErrorFlag instance will be set to 1, and a suitable description
message reported via the prErrMessage instance.
Note: This situation will not automatically trigger a trap to report the problem -
see the DisMan Event MIB section later.
If neither MAX nor MIN are specified (or are both 0), they will default to infinity
and 1 respectively ("at least one"). If only MAX is specified, MIN will default to
0 ("no more than MAX").
procfix NAME PROG ARGS
registers a command that can be run to fix errors with the given process NAME.
This will be invoked when the corresponding prErrFix instance is set to 1.
Note: This command will not be invoked automatically.
The procfix directive must be specified after the matching proc directive, and can-
not be used on its own.
If no proc directives are defined, then walking the prTable will fail (noSuchObject).
Disk Usage Monitoring
This requires that the agent was built with support for the ucd-snmp/disk module (which is
included as part of the default build configuration).
disk PATH [ MINSPACE | MINPERCENT% ]
monitors the disk mounted at PATH for available disk space.
The minimum threshold can either be specified in Kb (MINSPACE) or as a percentage
of the total disk (MINPERCENT% with a '%' character), defaulting to 100Kb if nei-
ther are specified. If the free disk space falls below this threshold, then the
corresponding dskErrorFlag instance will be set to 1, and a suitable description
message reported via the dskErrorMsg instance.
Note: This situation will not automatically trigger a trap to report the problem -
see the DisMan Event MIB section later.
includeAllDisks MINPERCENT%
configures monitoring of all disks found on the system, using the specified (per-
centage) threshold. The threshold for individual disks can be adjusted using suit-
able disk directives (which can come either before or after the includeAllDisks
directive).
Note: Whether disk directives appears before or after includeAllDisks may affect
the indexing of the dskTable.
Only one includeAllDisks directive should be specified - any subsequent copies will
be ignored.
The list of mounted disks will be determined when the agent starts using the setmn-
tent(3) and getmntent(3), or fopen(3) and getmntent(3), or setfsent(3) and getf-
sent(3) system calls. If none of the above system calls are available then the root
partition "/" (which is assumed to exist on any UNIX based system) will be moni-
tored. Disks mounted after the agent has started will not be monitored.
If neither any disk directives or includeAllDisks are defined, then walking the dskTable
will fail (noSuchObject).
System Load Monitoring
This requires that the agent was built with support for either the ucd-snmp/loadave module
or the ucd-snmp/memory module respectively (both of which are included as part of the
default build configuration).
load MAX1 [MAX5 [MAX15]]
monitors the load average of the local system, specifying thresholds for the
1-minute, 5-minute and 15-minute averages. If any of these loads exceed the asso-
ciated maximum value, then the corresponding laErrorFlag instance will be set to 1,
and a suitable description message reported via the laErrMessage instance.
Note: This situation will not automatically trigger a trap to report the problem -
see the DisMan Event MIB section later.
If the MAX15 threshold is omitted, it will default to the MAX5 value. If both MAX5
and MAX15 are omitted, they will default to the MAX1 value. If this directive is
not specified, all three thresholds will default to a value of DEFMAXLOADAVE.
If a threshold value of 0 is given, the agent will not report errors via the rele-
vant laErrorFlag or laErrMessage instances, regardless of the current load.
Unlike the proc and disk directives, walking the walking the laTable will succeed (assum-
ing the ucd-snmp/loadave module was configured into the agent), even if the load directive
is not present.
swap MIN
monitors the amount of swap space available on the local system. If this falls
below the specified threshold (MIN Kb), then the memErrorSwap object will be set to
1, and a suitable description message reported via memSwapErrorMsg.
Note: This situation will not automatically trigger a trap to report the problem -
see the DisMan Event MIB section later.
If this directive is not specified, the default threshold is 16 Mb.
Log File Monitoring
This requires that the agent was built with support for either the ucd-snmp/file or ucd-
snmp/logmatch modules respectively (both of which are included as part of the default
build configuration).
file FILE [MAXSIZE]
monitors the size of the specified file (in Kb). If MAXSIZE is specified, and the
size of the file exceeds this threshold, then the corresponding fileErrorFlag
instance will be set to 1, and a suitable description message reported via the
fileErrorMsg instance.
Note: This situation will not automatically trigger a trap to report the problem -
see the DisMan Event MIB section later.
A maximum of 20 files can be monitored.
If no file directives are defined, then walking the fileTable will fail (noSuchObject).
logmatch NAME PATH CYCLETIME REGEX
monitors the specified file for occurances of the specified pattern REGEX.
A maximum of 50 files can be monitored.
If no logmatch directives are defined, then walking the logMatchTable will fail (noSuchOb-
ject).
ACTIVE MONITORING
The usual behaviour of an SNMP agent is to wait for incoming SNMP requests and respond to
them - if no requests are received, an agent will typically not initiate any actions. This
section describes various directives that can configure snmpd to take a more active role.
Notification Handling
trapcommunity STRING
defines the default community string to be used when sending traps. Note that this
directive must be used prior to any community-based trap destination directives
that need to use it.
trapsink HOST [COMMUNITY [PORT]]
trap2sink HOST [COMMUNITY [PORT]]
informsink HOST [COMMUNITY [PORT]]
define the address of a notification receiver that should be sent SNMPv1 TRAPs,
SNMPv2c TRAP2s, or SNMPv2 INFORM notifications respectively. See the section LIS-
TENING ADDRESSES in the snmpd(8) manual page for more information about the format
of listening addresses. If COMMUNITY is not specified, the most recent trapcommu-
nity string will be used.
If the transport address does not include an explicit port specification, then PORT
will be used. If this is not specified, the well known SNMP trap port (162) will
be used.
Note: This mechanism is being deprecated, and the listening port should be speci-
fied via the transport specification HOST instead.
If several sink directives are specified, multiple copies of each notification (in
the appropriate formats) will be generated.
Note: It is not normally appropriate to list two (or all three) sink directives
with the same destination.
trapsess [SNMPCMD_ARGS] HOST
provides a more generic mechanism for defining notification destinations. SNM-
PCMD_ARGS should be the command-line options required for an equivalent snmptrap
(or snmpinform) command to send the desired notification. The option -Ci can be
used (with -v2c or -v3) to generate an INFORM notification rather than an unac-
knowledged TRAP.
This is the appropriate directive for defining SNMPv3 trap receivers. See
http://www.net-snmp.org/tutorial/tutorial-5/commands/snmptrap-v3.html for more
information about SNMPv3 notification behaviour.
authtrapenable {1|2}
determines whether to generate authentication failure traps (enabled(1)) or not
(disabled(2) - the default). Ordinarily the corresponding MIB object (snmpEn-
ableAuthenTraps.0) is read-write, but specifying this directive makes this object
read-only, and attempts to set the value via SET requests will result in a
notWritable error response.
DisMan Event MIB
The previous directives can be used to configure where traps should be sent, but are not
concerned with when to send such traps (or what traps should be generated). This is the
domain of the Event MIB - developed by the Distributed Management (DisMan) working group
of the IETF.
This requires that the agent was built with support for the disman/event module (which is
now included as part of the default build configuration for the most recent distribution).
Note: The behaviour of the latest implementation differs in some minor respects
from the previous code - nothing too significant, but existing scripts may
possibly need some minor adjustments.
iquerySecName NAME
agentSecName NAME
specifies the default SNMPv3 username, to be used when making internal queries to
retrieve any necessary information (either for evaluating the monitored expression,
or building a notification payload). These internal queries always use SNMPv3,
even if normal querying of the agent is done using SNMPv1 or SNMPv2c.
Note that this user must also be explicitly created (createUser) and given appro-
priate access rights (e.g. rouser). This directive is purely concerned with defin-
ing which user should be used - not with actually setting this user up.
monitor [OPTIONS] NAME EXPRESSION
defines a MIB object to monitor. If the EXPRESSION condition holds (see below),
then this will trigger the corresponding event, and either send a notification or
apply a SET assignment (or both). Note that the event will only be triggered once,
when the expression first matches. This monitor entry will not fire again until
the monitored condition first becomes false, and then matches again. NAME is an
administrative name for this expression, and is used for indexing the mteTrig-
gerTable (and related tables). Note also that such monitors use an internal SNMPv3
request to retrieve the values being monitored (even if normal agent queries typi-
cally use SNMPv1 or SNMPv2c). See the iquerySecName token described above.
EXPRESSION
There are three types of monitor expression supported by the Event MIB - existence,
boolean and threshold tests.
OID | ! OID | != OID
defines an existence(0) monitor test. A bare OID specifies a present(0)
test, which will fire when (an instance of) the monitored OID is created.
An expression of the form ! OID specifies an absent(1) test, which will fire
when the monitored OID is delected. An expression of the form != OID speci-
fies a changed(2) test, which will fire whenever the monitored value(s)
change. Note that there must be whitespace before the OID token.
OID OP VALUE
defines a boolean(1) monitor test. OP should be one of the defined compari-
son operators (!=, ==, <, <=, >, >=) and VALUE should be an integer value to
compare against. Note that there must be whitespace around the OP token. A
comparison such as OID !=0 will not be handled correctly.
OID MIN MAX [DMIN DMAX]
defines a threshold(2) monitor test. MIN and MAX are integer values, speci-
fying lower and upper thresholds. If the value of the monitored OID falls
below the lower threshold (MIN) or rises above the upper threshold (MAX),
then the monitor entry will trigger the corresponding event.
Note that the rising threshold event will only be re-armed when the moni-
tored value falls below the lower threshold (MIN). Similarly, the falling
threshold event will be re-armed by the upper threshold (MAX).
The optional parameters DMIN and DMAX configure a pair of similar threshold
tests, but working with the delta differences between successive sample val-
ues.
OPTIONS
There are various options to control the behaviour of the monitored expression.
These include:
-D indicates that the expression should be evaluated using delta differences
between sample values (rather than the values themselves).
-d OID
-di OID
specifies a discontinuity marker for validating delta differences. A -di
object instance will be used exactly as given. A -d object will have the
instance subidentifiers from the corresponding (wildcarded) expression
object appended. If the -I flag is specified, then there is no difference
between these two options.
This option also implies -D.
-e EVENT
specifies the event to be invoked when this monitor entry is triggered. If
this option is not given, the monitor entry will generate one of the stan-
dard notifications defined in the DISMAN-EVENT-MIB.
-I indicates that the monitored expression should be applied to the specified
OID as a single instance. By default, the OID will be treated as a wild-
carded object, and the monitor expanded to cover all matching instances.
-i OID
-o OID define additional varbinds to be added to the notification payload when this
monitor trigger fires. For a wildcarded expression, the suffix of the
matched instance will be added to any OIDs specified using -o, while OIDs
specified using -i will be treated as exact instances. If the -I flag is
specified, then there is no difference between these two options.
See strictDisman for details of the ordering of notification payloads.
-r FREQUENCY
monitors the given expression every FREQUENCY seconds. By default, the
expression will be evaluated every 600s (10 minutes).
-S indicates that the monitor expression should not be evaluated when the agent
first starts up. The first evaluation will be done once the first repeat
interval has expired.
-s indicates that the monitor expression should be evaluated when the agent
first starts up. This is the default behaviour.
Note: Notifications triggered by this initial evaluation will be sent
before the coldStart trap.
-u SECNAME
specifies a security name to use for scanning the local host, instead of the
default iquerySecName. Once again, this user must be explicitly created and
given suitable access rights.
notificationEvent ENAME NOTIFICATION [-n] [-i OID | -o OID ]*
defines a notification event named ENAME. This can be triggered from a given moni-
tor entry by specifying the option -e ENAME (see above). NOTIFICATION should be
the OID of the NOTIFICATION-TYPE definition for the notification to be generated.
If the -n option is given, the notification payload will include the standard
varbinds as specified in the OBJECTS clause of the notification MIB definition.
This option must come after the NOTIFICATION OID (and the relevant MIB file must be
available and loaded by the agent). Otherwise, these varbinds must be listed
explicitly (either here or in the corresponding monitor directive).
The -i OID and -o OID options specify additional varbinds to be appended to the
notification payload, after the standard list. If the monitor entry that triggered
this event involved a wildcarded expression, the suffix of the matched instance
will be added to any OIDs specified using -o, while OIDs specified using -i will be
treated as exact instances. If the -I flag was specified to the monitor directive,
then there is no difference between these two options.
setEvent ENAME [-I] OID = VALUE
defines a set event named ENAME, assigning the (integer) VALUE to the specified
OID. This can be triggered from a given monitor entry by specifying the option -e
ENAME (see above).
If the monitor entry that triggered this event involved a wildcarded expression,
the suffix of the matched instance will normally be added to the OID. If the -I
flag was specified to either of the monitor or setEvent directives, the specified
OID will be regarded as an exact single instance.
strictDisman yes
The definition of SNMP notifications states that the varbinds defined in the OBJECT
clause should come first (in the order specified), followed by any "extra" varbinds
that the notification generator feels might be useful. The most natural approach
would be to associate these mandatory varbinds with the notificationEvent entry,
and append any varbinds associated with the monitor entry that triggered the noti-
fication to the end of this list. This is the default behaviour of the Net-SNMP
Event MIB implementation.
Unfortunately, the DisMan Event MIB specifications actually state that the trigger-
related varbinds should come first, followed by the event-related ones. This
directive can be used to restore this strictly-correct (but inappropriate)
behaviour.
Note: Strict DisMan ordering may result in generating invalid notifications pay-
load lists if the notificationEvent -n flag is used together with monitor -o
(or -i) varbind options.
If no monitor entries specify payload varbinds, then the setting of this directive
is irrelevant.
linkUpDownNotifications yes
will configure the Event MIB tables to monitor the ifTable for network interfaces
being taken up or down, and triggering a linkUp or linkDown notification as appro-
priate.
This is exactly equivalent to the configuration:
notificationEvent linkUpTrap linkUp ifIndex ifAdminStatus ifOperStatus
notificationEvent linkDownTrap linkDown ifIndex ifAdminStatus ifOperStatus
monitor -r 60 -e linkUpTrap "Generate linkUp" ifOperStatus != 2
monitor -r 60 -e linkDownTrap "Generate linkDown" ifOperStatus == 2
defaultMonitors yes
will configure the Event MIB tables to monitor the various UCD-SNMP-MIB tables for
problems (as indicated by the appropriate xxErrFlag column objects).
This is exactly equivalent to the configuration:
monitor -o prNames -o prErrMessage "process table" prErrorFlag != 0
monitor -o memErrorName -o memSwapErrorMsg "memory" memSwapError != 0
monitor -o extNames -o extOutput "extTable" extResult != 0
monitor -o dskPath -o dskErrorMsg "dskTable" dskErrorFlag != 0
monitor -o laNames -o laErrMessage "laTable" laErrorFlag != 0
monitor -o fileName -o fileErrorMsg "fileTable" fileErrorFlag != 0
In both these latter cases, the snmpd.conf must also contain a iquerySecName directive,
together with a corresponding createUser entry and suitable access control configuration.
DisMan Schedule MIB
The DisMan working group also produced a mechanism for scheduling particular actions (a
specified SET assignment) at given times. This requires that the agent was built with
support for the disman/schedule module (which is included as part of the default build
configuration for the most recent distribution).
There are three ways of specifying the scheduled action:
repeat FREQUENCY OID = VALUE
configures a SET assignment of the (integer) VALUE to the MIB instance OID, to be
run every FREQUENCY seconds.
cron MINUTE HOUR DAY MONTH WEEKDAY OID = VALUE
configures a SET assignment of the (integer) VALUE to the MIB instance OID, to be
run at the times specified by the fields MINUTE to WEEKDAY. These follow the same
pattern as the equivalent crontab(5) fields.
Note: These fields should be specified as a (comma-separated) list of numeric val-
ues. Named values for the MONTH and WEEKDAY fields are not supported, and
neither are value ranges. A wildcard match can be specified as '*'.
The DAY field can also accept negative values, to indicate days counting backwards
from the end of the month.
at MINUTE HOUR DAY MONTH WEEKDAY OID = VALUE
configures a one-shot SET assignment, to be run at the first matching time as spec-
ified by the fields MINUTE to WEEKDAY. The interpretation of these fields is
exactly the same as for the cron directive.
EXTENDING AGENT FUNCTIONALITY
One of the first distinguishing features of the original UCD suite was the ability to
extend the functionality of the agent - not just by recompiling with code for new MIB mod-
ules, but also by configuring the running agent to report additional information. There
are a number of techniques to support this, including:
o running external commands (exec, extend, pass)
o loading new code dynamically (embedded perl, dlmod)
o communicating with other agents (proxy, SMUX, AgentX)
Arbitrary Extension Commands
The earliest extension mechanism was the ability to run arbitrary commands or shell
scripts. Such commands do not need to be aware of SNMP operations, or conform to any par-
ticular behaviour - the MIB structures are designed to accommodate any form of command
output. Use of this mechanism requires that the agent was built with support for the ucd-
snmp/extensible and/or agent/extend modules (which are both included as part of the
default build configuration).
exec [MIBOID] NAME PROG ARGS
sh [MIBOID] NAME PROG ARGS
invoke the named PROG with arguments of ARGS. By default the exit status and first
line of output from the command will be reported via the extTable, discarding any
additional output.
Note: Entries in this table appear in the order they are read from the configura-
tion file. This means that adding new exec (or sh) directives and restart-
ing the agent, may affect the indexing of other entries.
The PROG argument for exec directives must be a full path to a real binary, as it
is executed via the exec() system call. To invoke a shell script, use the sh
directive instead.
If MIBOID is specified, then the results will be rooted at this point in the OID
tree, returning the exit statement as MIBOID.100.0 and the entire command output in
a pseudo-table based at MIBNUM.101 - with one 'row' for each line of output.
Note: The layout of this "relocatable" form of exec (or sh) output does not
strictly form a valid MIB structure. This mechanism is being deprecated -
please see the extend directive (described below) instead.
In either case, the exit statement and output will be cached for 30s after the ini-
tial query. This cache can be flushed by a SET request of the integer value 1 to
the MIB instance versionClearCache.0.
execfix NAME PROG ARGS
registers a command that can be invoked on demand - typically to respond to or fix
errors with the corresponding exec or sh entry. When the extErrFix instance for a
given NAMEd entry is set to the integer value of 1, this command will be called.
Note: This directive can only be used in combination with a corresponding exec or
sh directive, which must be defined first. Attempting to define an unaccom-
panied execfix directive will fail.
exec and sh extensions can only be configured via the snmpd.conf file. They cannot be set
up via SNMP SET requests.
extend [MIBOID] NAME PROG ARGS
works in a similar manner to the exec directive, but with a number of improvements.
The MIB tables (nsExtendConfigTable etc) are indexed by the NAME token, so are
unaffected by the order in which entries are read from the configuration files.
There are two result tables - one (nsExtendOutput1Table) containing the exit sta-
tus, the first line and full output (as a single string) for each extend entry, and
the other (nsExtendOutput2Table) containing the complete output as a series of sep-
arate lines.
If MIBOID is specified, then the configuration and result tables will be rooted at
this point in the OID tree, but are otherwise structured in exactly the same way.
This means that several separate extend directives can specify the same MIBOID
root, without conflicting.
The exit status and output is cached for each entry individually, and can be
cleared (and the caching behaviour configured) using the nsCacheTable.
extendfix NAME PROG ARGS
registers a command that can be invoked on demand, by setting the appropriate nsEx-
tendRunType instance to the value run-command(3). Unlike the equivalent execfix,
this directive does not need to be paired with a corresponding extend entry, and
can appear on its own.
Both extend and extendfix directives can be configured dynamically, using SNMP SET
requests to the NET-SNMP-EXTEND-MIB.
MIB-Specific Extension Commands
The first group of extension directives invoke arbitrary commands, and rely on the MIB
structure (and management applications) having the flexibility to accommodate and inter-
pret the output. This is a convenient way to make information available quickly and sim-
ply, but is of no use when implementing specific MIB objects, where the extension must
conform to the structure of the MIB (rather than vice versa). The remaining extension
mechanisms are all concerned with such MIB-specific situations - starting with "pass-
through" scripts. Use of this mechanism requires that the agent was built with support
for the ucd-snmp/pass and ucd-snmp/pass_persist modules (which are both included as part
of the default build configuration).
pass [-p priority] MIBOID PROG
will pass control of the subtree rooted at MIBOID to the specified PROG command.
GET and GETNEXT requests for OIDs within this tree will trigger this command,
called as:
PROG -g OID
PROG -n OID
respectively, where OID is the requested OID. The PROG command should return the
response varbind as three separate lines printed to stdout - the first line should
be the OID of the returned value, the second should be its TYPE (one of the text
strings integer, gauge, counter, timeticks, ipaddress, objectid, or string ), and
the third should be the value itself.
If the command cannot return an appropriate varbind - e.g the specified OID did not
correspond to a valid instance for a GET request, or there were no following
instances for a GETNEXT - then it should exit without producing any output. This
will result in an SNMP noSuchName error, or a noSuchInstance exception.
Note: The SMIv2 type counter64 and SNMPv2 noSuchObject exception are not
supported.
A SET request will result in the command being called as:
PROG -s OID TYPE VALUE
where TYPE is one of the tokens listed above, indicating the type of the value
passed as the third parameter.
If the assignment is successful, the PROG command should exit without producing any
output. Errors should be indicated by writing one of the strings not-writable, or
wrong-type to stdout, and the agent will generate the appropriate error response.
Note: The other SNMPv2 errors are not supported.
In either case, the command should exit once it has finished processing. Each
request (and each varbind within a single request) will trigger a separate invoca-
tion of the command.
The default registration priority is 127. This can be changed by supplying the
optional -p flag, with lower priority registrations being used in preference to
higher priority values.
pass_persist [-p priority] MIBOID PROG
will also pass control of the subtree rooted at MIBOID to the specified PROG com-
mand. However this command will continue to run after the initial request has been
answered, so subsequent requests can be processed without the startup overheads.
Upon initialization, PROG will be passed the string "PING\n" on stdin, and should
respond by printing "PONG\n" to stdout.
For GET and GETNEXT requests, PROG will be passed two lines on stdin, the command
(get or getnext) and the requested OID. It should respond by printing three lines
to stdout - the OID for the result varbind, the TYPE and the VALUE itself - exactly
as for the pass directive above. If the command cannot return an appropriate
varbind, it should print print "NONE\n" to stdout (but continue running).
For SET requests, PROG will be passed three lines on stdin, the command (set) and
the requested OID, followed by the type and value (both on the same line). If the
assignment is successful, the command should print "DONE\n" to stdout. Errors
should be indicated by writing one of the strings not-writable, wrong-type, wrong-
length, wrong-value or inconsistent-value to stdout, and the agent will generate
the appropriate error response. In either case, the command should continue run-
ning.
The registration priority can be changed using the optional -p flag, just as for
the pass directive.
pass and pass_persist extensions can only be configured via the snmpd.conf file. They
cannot be set up via SNMP SET requests.
Embedded Perl Support
Programs using the previous extension mechanisms can be written in any convenient program-
ming language - including perl, which is a common choice for pass-through extensions in
particular. However the Net-SNMP agent also includes support for embedded perl technology
(similar to mod_perl for the Apache web server). This allows the agent to interpret perl
scripts directly, thus avoiding the overhead of spawning processes and initializing the
perl system when a request is received.
Use of this mechanism requires that the agent was built with support for the embedded perl
mechanism, which is not part of the default build environment. It must be explicitly
included by specifying the '--enable-embedded-perl' option to the configure script when
the package is first built.
If enabled, the following directives will be recognised:
disablePerl true
will turn off embedded perl support entirely (e.g. if there are problems with the
perl installation).
perlInitFile FILE
loads the specified initialisation file (if present) immediately before the first
perl directive is parsed. If not explicitly specified, the agent will look for the
default initialisation file /usr/share/snmp/snmp_perl.pl.
The default initialisation file creates an instance of a NetSNMP::agent object - a
variable $agent which can be used to register perl-based MIB handler routines.
perl EXPRESSION
evaluates the given expression. This would typically register a handler routine to
be called when a section of the OID tree was requested:
perl use Data::Dumper;
perl sub myroutine { print "got called: ",Dumper(@_),"\n"; }
perl $agent->register('mylink', '.1.3.6.1.8765', \&myroutine);
This expression could also source an external file:
perl 'do /path/to/file.pl';
or perform any other perl-based processing that might be required.
Dynamically Loadable Modules
Most of the MIBs supported by the Net-SNMP agent are implemented as C code modules, which
were compiled and linked into the agent libraries when the suite was first built. Such
implementation modules can also be compiled independently and loaded into the running
agent once it has started. Use of this mechanism requires that the agent was built with
support for the ucd-snmp/dlmod module (which is included as part of the default build con-
figuration).
dlmod NAME PATH
will load the shared object module from the file PATH (an absolute filename), and
call the initialisation routine init_NAME.
Note: If the specified PATH is not a fully qualified filename, it will be inter-
preted relative to /usr/lib/snmp/dlmod, and .so will be appended to the
filename.
This functionality can also be configured using SNMP SET requests to the UCD-DLMOD-MIB.
Proxy Support
Another mechanism for extending the functionality of the agent is to pass selected
requests (or selected varbinds) to another SNMP agent, which can be running on the same
host (presumably listening on a different port), or on a remote system. This can be
viewed either as the main agent delegating requests to the remote one, or acting as a
proxy for it. Use of this mechanism requires that the agent was built with support for
the ucd-snmp/proxy module (which is included as part of the default build configuration).
proxy [-Cn CONTEXTNAME] [SNMPCMD_ARGS] HOST OID [REMOTEOID]
will pass any incoming requests under OID to the agent listening on the port speci-
fied by the transport address HOST. See the section LISTENING ADDRESSES in the
snmpd(8) manual page for more information about the format of listening addresses.
Note: To proxy the entire MIB tree, use the OID .1.3 (not the top-level .1)
The SNMPCMD_ARGS should provide sufficient version and administrative information to gen-
erate a valid SNMP request (see snmpcmd(1)).
Note: The proxied request will not use the administrative settings from the original
request.
If a CONTEXTNAME is specified, this will register the proxy delegation within the named
context in the local agent. Defining multiple proxy directives for the same OID but dif-
ferent contexts can be used to query several remote agents through a single proxy, by
specifying the appropriate SNMPv3 context in the incoming request (or using suitable con-
figured community strings - see the com2sec directive).
Specifying the REMOID parameter will map the local MIB tree rooted at OID to an equivalent
subtree rooted at REMOID on the remote agent.
SMUX Sub-Agents
The Net-SNMP agent supports the SMUX protocol (RFC 1227) to communicate with SMUX-based
subagents (such as gated, zebra or quagga). Use of this mechanism requires that the agent
was built with support for the smux module, which is not part of the default build envi-
ronment, and must be explicitly included by specifying the '--with-mib-modules=smux'
option to the configure script when the package is first built.
Note: This extension protocol has been officially deprecated in favour of AgentX
(see below).
smuxpeer OID PASS
will register a subtree for SMUX-based processing, to be authenticated using the
password PASS. If a subagent (or "peer") connects to the agent and registers this
subtree then requests for OIDs within it will be passed to that SMUX subagent for
processing.
A suitable entry for an OSPF routing daemon (such as gated, zebra or quagga) might
be something like
smuxpeer .1.3.6.1.2.1.14 ospf_pass
smuxsocket <IPv4-address>
defines the IPv4 address for SMUX peers to communicate with the Net-SNMP agent.
The default is to listen on all IPv4 interfaces ("0.0.0.0"), unless the package has
been configured with "--enable-local-smux" at build time, which causes it to only
listen on 127.0.0.1 by default. SMUX uses the well-known TCP port 199.
Note the Net-SNMP agent will only operate as a SMUX master agent. It does not support act-
ing in a SMUX subagent role.
AgentX Sub-Agents
The Net-SNMP agent supports the AgentX protocol (RFC 2741) in both master and subagent
roles. Use of this mechanism requires that the agent was built with support for the
agentx module (which is included as part of the default build configuration), and also
that this support is explicitly enabled (e.g. via the snmpd.conf file).
There are two directives specifically relevant to running as an AgentX master agent:
master agentx
will enable the AgentX functionality and cause the agent to start listening for
incoming AgentX registrations. This can also be activated by specifying the '-x'
command-line option (to specify an alternative listening socket).
agentXPerms SOCKPERMS [DIRPERMS [USER|UID [GROUP|GID]]]
Defines the permissions and ownership of the AgentX Unix Domain socket, and the
parent directories of this socket. SOCKPERMS and DIRPERMS must be octal digits
(see chmod(1) ). By default this socket will only be accessible to subagents which
have the same userid as the agent.
There is one directive specifically relevant to running as an AgentX sub-agent:
agentXPingInterval NUM
will make the subagent try and reconnect every NUM seconds to the master if it ever
becomes (or starts) disconnected.
The remaining directives are relevant to both AgentX master and sub-agents:
agentXSocket [<transport-specifier>:]<transport-address>[,...]
defines the address the master agent listens at, or the subagent should connect to.
The default is the Unix Domain socket "/var/agentx/master". Another common alter-
native is tcp:localhost:705. See the section LISTENING ADDRESSES in the snmpd(8)
manual page for more information about the format of addresses.
Note: Specifying an AgentX socket does not automatically enable AgentX functional-
ity (unlike the '-x' command-line option).
agentXTimeout NUM
defines the timeout period (NUM seconds) for an AgentX request. Default is 1 sec-
ond.
agentXRetries NUM
defines the number of retries for an AgentX request. Default is 5 retries.
net-snmp ships with both C and Perl APIs to develop your own AgentX subagent.
OTHER CONFIGURATION
override [-rw] OID TYPE VALUE
This directive allows you to override a particular OID with a different value (and
possibly a different type of value). The -rw flag will allow snmp SETs to modify
it's value as well. (note that if you're overriding original functionality, that
functionality will be entirely lost. Thus SETS will do nothing more than modify
the internal overridden value and will not perform any of the original functional-
ity intended to be provided by the MIB object. It's an emulation only.) An exam-
ple:
override sysDescr.0 octet_str "my own sysDescr"
That line will set the sysDescr.0 value to "my own sysDescr" as well as make it
modifiable with SNMP SETs as well (which is actually illegal according to the MIB
specifications).
Note that care must be taken when using this. For example, if you try to override
a property of the 3rd interface in the ifTable with a new value and later the num-
bering within the ifTable changes it's index ordering you'll end up with problems
and your modified value won't appear in the right place in the table.
Valid TYPEs are: integer, uinteger, octet_str, object_id, counter, null (for
gauges, use "uinteger"; for bit strings, use "octet_str"). Note that setting an
object to "null" effectively delete's it as being accessible. No VALUE needs to be
given if the object type is null.
More types should be available in the future.
If you're trying to figure out aspects of the various mib modules (possibly some that
you've added yourself), the following may help you spit out some useful debugging informa-
tion. First off, please read the snmpd manual page on the -D flag. Then the following
configuration snmpd.conf token, combined with the -D flag, can produce useful output:
injectHandler HANDLER modulename
This will insert new handlers into the section of the mib tree referenced by "modu-
lename". The types of handlers available for insertion are:
stash_cache
Caches information returned from the lower level. This greatly help the
performance of the agent, at the cost of caching the data such that its no
longer "live" for 30 seconds (in this future, this will be configurable).
Note that this means snmpd will use more memory as well while the informa-
tion is cached. Currently this only works for handlers registered using the
table_iterator support, which is only a few mib tables. To use it, you need
to make sure to install it before the table_iterator point in the chain, so
to do this:
injectHandler stash_cache NAME table_iterator
If you want a table to play with, try walking the nsModuleTable with and
without this injected.
debug Prints out lots of debugging information when the -Dhelper:debug flag is
passed to the snmpd application.
read_only
Forces turning off write support for the given module.
serialize
If a module is failing to handle multiple requests properly (using the new
5.0 module API), this will force the module to only receive one request at a
time.
bulk_to_next
If a module registers to handle getbulk support, but for some reason is
failing to implement it properly, this module will convert all getbulk
requests to getnext requests before the final module receives it.
dontLogTCPWrappersConnects
If the snmpd was compiled with TCP Wrapper support, it logs every connection made
to the agent. This setting disables the log messages for accepted connections.
Denied connections will still be logged.
Figuring out module names
To figure out which modules you can inject things into, run snmpwalk on the nsMod-
uleTable which will give a list of all named modules registered within the agent.
Internal Data tables
table NAME
add_row NAME INDEX(ES) VALUE(S)
NOTES
o The Net-SNMP agent can be instructed to re-read the various configuration files,
either via an snmpset assignment of integer(1) to UCD-SNMP-MIB::versionUpdateCon-
fig.0 (.1.3.6.1.4.1.2021.100.11.0), or by sending a kill -HUP signal to the agent
process.
o All directives listed with a value of "yes" actually accept a range of boolean val-
ues. These will accept any of 1, yes or true to enable the corresponding
behaviour, or any of 0, no or false to disable it. The default in each case is for
the feature to be turned off, so these directives are typically only used to enable
the appropriate behaviour.
EXAMPLE CONFIGURATION FILE
See the EXAMPLE.CONF file in the top level source directory for a more detailed example of
how the above information is used in real examples.
FILES
/etc/snmp/snmpd.conf
SEE ALSO
snmpconf(1), snmpusm(1), snmp.conf(5), snmp_config(5), snmpd(8), EXAMPLE.conf, read_con-
fig(3).
4th Berkeley Distribution 08 Feb 2002 SNMPD.CONF(5)
Generated by $Id: phpMan.php,v 4.49 2006/02/26 13:18:18 chedong Exp $ Author: Che Dong
On Apache
Under GNU General Public License
2012-05-26 06:40 @38.107.179.237 Crawled by CCBot/1.0 (+http://www.commoncrawl.org/bot.html)