1SNMPD.CONF(5) Net-SNMP SNMPD.CONF(5)
2
6 snmpd.conf - configuration file for the Net-SNMP SNMP agent
7
9 The Net-SNMP agent uses one or more configuration files to control its
10 operation and the management information provided. These files
11 (snmpd.conf and snmpd.local.conf) can be located in one of several
12 locations, as described in the snmp_config(5) manual page.
13 The (perl) application snmpconf can be used to generate configuration
15 files for the most common agent requirements. See the snmpconf(1) man‐
16 ual page for more information, or try running the command:
17 snmpconf -g basic_setup
19 There are a large number of directives that can be specified, but these
21 mostly fall into four distinct categories:
22 · those controlling who can access the agent
24 · those configuring the information that is supplied by the agent
26 · those controlling active monitoring of the local system
28 · those concerned with extending the functionality of the agent.
30 Some directives don't fall naturally into any of these four categories,
32 but this covers the majority of the contents of a typical snmpd.conf
33 file. A full list of recognised directives can be obtained by running
34 the command:
35 snmpd -H
37
39 Although most configuration directives are concerned with the MIB
40 information supplied by the agent, there are a handful of directives
41 that control the behaviour of snmpd considered simply as a daemon pro‐
42 viding a network service.
43 agentaddress [<transport-specifier>:]<transport-address>[,...]
45 defines a list of listening addresses, on which to receive
46 incoming SNMP requests. See the section LISTENING ADDRESSES in
47 the snmpd(8) manual page for more information about the format
48 of listening addresses.
49 The default behaviour is to listen on UDP port 161 on all IPv4
51 interfaces.
52 agentgroup {GROUP|#GID}
54 changes to the specified group after opening the listening
55 port(s). This may refer to a group by name (GROUP), or a
56 numeric group ID starting with '#' (#GID).
57 agentuser {USER|#UID}
59 changes to the specified user after opening the listening
60 port(s). This may refer to a user by name (USER), or a numeric
61 user ID starting with '#' (#UID).
62 leave_pidfile yes
64 instructs the agent to not remove its pid file on shutdown.
65 Equivalent to specifying "-U" on the command line.
66 maxGetbulkRepeats NUM
68 Sets the maximum number of responses allowed for a single vari‐
69 able in a getbulk request. Set to 0 to enable the default and
70 set it to -1 to enable unlimited. Because memory is allocated
71 ahead of time, setting this to unlimited is not considered safe
72 if your user population can not be trusted. A repeat number
73 greater than this will be truncated to this value.
74 This is set by default to -1.
76 maxGetbulkResponses NUM
78 Sets the maximum number of responses allowed for a getbulk
79 request. This is set by default to 100. Set to 0 to enable the
80 default and set it to -1 to enable unlimited. Because memory is
81 allocated ahead of time, setting this to unlimited is not con‐
82 sidered safe if your user population can not be trusted.
83 In general, the total number of responses will not be allowed to
85 exceed the maxGetbulkResponses number, and the total number
86 returned will be an integer multiple of the number of variables
87 requested times the calculated number of repeats allow to fit
88 below this number.
89 Also note that processing of maxGetbulkRepeats is handled first.
91 SNMPv3 Configuration - Real Security
93 SNMPv3 is added flexible security models to the SNMP packet structure
94 so that multiple security solutions could be used. SNMPv3 was original
95 defined with a "User-based Security Model" (USM) [RFC3414] that
96 required maintaining a SNMP-specific user database. This was later
97 determined to be troublesome to maintain and had some minor security
98 issues. The IETF has since added additional security models to tunnel
99 SNMP over SSH [RFC5592] and DTLS/TLS [RFC-to-be]. Net-SNMP contains
100 robust support for SNMPv3/USM, SNMPv3/TLS, and SNMPv3/DTLS. It con‐
101 tains partial support for SNMPv3/SSH as well but has not been as exten‐
102 sively tested. It also contains code for support for an experimental
103 Kerberos based SNMPv3 that never got standardized.
104 Hopefully more SNMP software and devices will eventually support SNMP
106 over (D)TLS or SSH, but it is likely that devices with original support
107 for SNMP will only contain support for USM users. If your network man‐
108 ager supports SNMP over (D)TLS or SNMP over SSH we suggest you use one
109 of these mechanisms instead of using USM, but as always with Net-SNMP
110 we give you the options to pick from so you can make the choice that is
111 best for you.
112 SNMPv3 generic parameters
114 These parameters are generic to all the forms of SNMPv3. The SNMPv3
115 protocol defines "engineIDs" that uniquely identify an agent. The
116 string must be consistent through time and should not change or con‐
117 flict with another agent's engineID. Ever. Internally, Net-SNMP by
118 default creates a unique engineID that is based off of the current sys‐
119 tem time and a random number. This should be sufficient for most users
120 unless you're embedding our agent in a device where these numbers won't
121 vary between boxes on the devices initial boot.
122 EngineIDs are used both as a "context" for selecting information
124 from the device and SNMPv3 with USM uses it to create unique
125 entries for users in its user table.
126 The Net-SNMP agent offers the following mechanisms for setting
128 the engineID, but again you should only use them if you know
129 what you're doing:
130 engineID STRING
132 specifies that the engineID should be built from the given text
133 STRING.
134 engineIDType 1|2|3
136 specifies that the engineID should be built from the IPv4
137 address (1), IPv6 address (2) or MAC address (3). Note that
138 changing the IP address (or switching the network interface
139 card) may cause problems.
140 engineIDNic INTERFACE
142 defines which interface to use when determining the MAC address.
143 If engineIDType 3 is not specified, then this directive has no
144 effect.
145 The default is to use eth0.
147 SNMPv3 over TLS
149 SNMPv3 may be tunneled over TLS and DTLS. TLS runs over TCP and DTLS
150 is the UDP equivalent. Wes Hardaker (the founder of Net-SNMP) per‐
151 formed a study and presented it at an IETF meeting that showed that TCP
152 based protocols are sufficient for stable networks but quickly becomes
153 a problem in unstable networks with even moderate levels of packet loss
154 (~ 20-30%). If you are going to use TLS or DTLS, you should use the
155 one appropriate for your networking environment. You should poten‐
156 tially turn them both on so your management system can access either
157 the UDP or the TCP port as needed.
158 Many of the configuration tokens described below are prefixed with a
160 '[snmp]' tag. If you place these tokens in your snmpd.conf file, this
161 take is required. See the snmp_config(5) manual page for the meaning
162 of this context switch.
163 [snmp] localCert <specifier>
165 This token defines the default X.509 public key to use as the
166 server's identity. It should either be a fingerprint or a file‐
167 name. To create a public key for use, please run the
168 "net-snmp-cert" utility which will help you create the required
169 certificate.
170 The default value for this is the certificate in the "snmpd"
172 named certificate file.
173 [snmp] tlsAlgorithms <algorithms>
175 This string will select the algorithms to use when negotiating
176 security during (D)TLS session establishment. See the openssl
177 manual page ciphers(1) for details on the format. Examples
178 strings include:
179 DEFAULT
181 ALL
182 HIGH
183 HIGH:!AES128-SHA
184 The default value is whatever openssl itself was configured
186 with.
187 [snmp] x509CRLFile
189 If you are using a Certificate Authority (CA) that publishes a
190 Certificate Revocation List (CRL) then this token can be used to
191 specify the location in the filesystem of a copy of the CRL
192 file. Note that Net-SNMP will not pull a CRL over http and this
193 must be a file, not a URL. Additionally, OpenSSL does not
194 reload a CRL file when it has changed so modifications or
195 updates to the file will only be noticed upon a restart of the
196 snmpd agent.
197 certSecName PRIORITY FINGERPRINT OPTIONS
200 OPTIONS can be one of <--sn SECNAME | --rfc822 | --dns | --ip |
201 --cn | --any>.
202 The certSecName token will specify how to map a certificate
204 field from the client's X.509 certificate to a SNMPv3 username.
205 Use the --sn SECNAME flag to directly specify a securityName for
206 a given certificate. The other flags extract a particular com‐
207 ponent of the certificate for use as a snmpv3 securityName.
208 These fields are one of: A SubjectAltName containing an rfc822
209 value (eg hardaker@net-snmp.org), A SubjectAltName containing a
210 dns name value (eg foo.net-snmp.org), an IP address (eg
211 192.0.2.1) or a common name "Wes Hardaker". The --any flag
212 specifies that any of the subjecAltName fields may be used.
213 Make sure once a securityName has been selected that it is given
214 authorization via the VACM controls discussed later in this man‐
215 ual page.
216 See the http://www.net-snmp.org/wiki/index.php/Using_DTLS web
218 page for more detailed instructions for setting up (D)TLS.
219 trustCert <specifier>
221 For X509 to properly verify a certificate, it should be verifi‐
222 able up until a trust anchor for it. This trust anchor is typi‐
223 cally a CA certificate but it could also be a self-signed cer‐
224 tificate. The "trustCert" token should be used to load specific
225 trust anchors into the verification engine.
226 SNMP over (D)TLS requires the use of the Transport Security Model
228 (TSM), so read the section on the usage of the Transport Security Model
229 as well. Make sure when you configure the VACM to accept connections
230 from (D)TLS that you use the "tsm" security model. E.G.:
231 rwuser -s tsm hardaker@net-snmp.org
233 SNMPv3 over SSH Support
235 To use SSH, you'll need to configure sshd to invoke the sshtosnmp pro‐
236 gram as well as configure the access control settings to allow access
237 through the tsm security model using the user name provided to snmpd by
238 the ssh transport.
239 SNMPv3 with the Transport Security Model (TSM)
241 The Transport Security Model [RFC5591] defines a SNMPv3 security system
242 for use with "tunneled" security protocols like TLS, DTLS and SSH. It
243 is a very simple security model that simply lets properly protected
244 packets to pass through into the snmp application. The transport is
245 required to pass a securityName to use to the TSM and the TSM may
246 optionally prefix this with a transport string (see below).
247 tsmUseTransportPrefix (1|yes|true|0|no|false)
249 If set to true, the TSM module will take every securityName
250 passed to it from the transports underneath and prefix it with a
251 string that specifically identities the transport it came from.
252 This is useful to avoid securityName clashes with transports
253 that generate identical security names. For example, if the ssh
254 security transport delivered the security name of "hardaker" for
255 a SSH connection and the TLS security transport also delivered
256 the security name of "hardaker" for a TLS connection then it
257 would be impossible to separate out these two users to provide
258 separate access control rights. With the tsmUseTransportPrefix
259 set to true, however, the securityNames would be prefixed appro‐
260 priately with one of: "tls:", "dtls:" or "ssh:".
261 SNMPv3 with the User-based Security Model (USM)
263 SNMPv3 was originally defined using the User-Based Security Model
264 (USM), which contains a private list of users and keys specific to the
265 SNMPv3 protocol. The operational community, however, declared it a
266 pain to manipulate yet another database and would prefer to use exist‐
267 ing infrastructure. To that end the IETF created the ISMS working
268 group to battle that problem, and the ISMS working group decided to
269 tunnel SNMP over SSH and DTLS to make use existing user and authentica‐
270 tion infrastructures.
271 SNMPv3 USM Users
273 To use the USM based SNMPv3-specific users, you'll need to create them.
274 It is recommended you use the net-snmp-config command to do this, but
275 you can also do it by directly specifying createUser directives your‐
276 self instead:
277 createUser [-e ENGINEID] username
279 (MD5|SHA|SHA-512|SHA-384|SHA-256|SHA-224) authpassphrase [DES|AES]
280 [privpassphrase]
281 MD5|SHA|SHA-512|SHA-384|SHA-256|SHA-224 are the authentication
283 types to use. DES and AES are the privacy protocols to use. If
284 the privacy passphrase is not specified, it is assumed to be the
285 same as the authentication passphrase. Note that the users cre‐
286 ated will be useless unless they are also added to the VACM
287 access control tables described above.
288 SHA|SHA-512|SHA-384|SHA-256|SHA-224 authentication and DES/AES
290 privacy require OpenSSL to be installed and the agent to be
291 built with OpenSSL support. MD5 authentication may be used
292 without OpenSSL.
293 Warning: the minimum pass phrase length is 8 characters.
295 SNMPv3 users can be created at runtime using the snmpusm(1) com‐
297 mand.
298 Instead of figuring out how to use this directive and where to
300 put it (see below), just run "net-snmp-config --cre‐
301 ate-snmpv3-user" instead, which will add one of these lines to
302 the right place.
303 This directive should be placed into the /var/lib/net-
305 snmp/snmpd.conf file instead of the other normal locations. The
306 reason is that the information is read from the file and then
307 the line is removed (eliminating the storage of the master pass‐
308 word for that user) and replaced with the key that is derived
309 from it. This key is a localized key, so that if it is stolen
310 it can not be used to access other agents. If the password is
311 stolen, however, it can be.
312 If you need to localize the user to a particular EngineID (this
314 is useful mostly in the similar snmptrapd.conf file), you can
315 use the -e argument to specify an EngineID as a hex value (EG,
316 "0x01020304").
317 If you want to generate either your master or localized keys
319 directly, replace the given password with a hexstring (preceded
320 by a "0x") and precede the hex string by a -m or -l token
321 (respectively). EGs:
322 [these keys are *not* secure but are easy to visually parse for
324 counting purposes. Please generate random keys instead of using
325 these examples]
326 createUser myuser SHA -l 0x0001020304050607080900010203040506070809 AES -l 0x00010203040506070809000102030405
328 createUser myuser SHA -m 0x0001020304050607080900010203040506070809 AES -m 0x0001020304050607080900010203040506070809
329 Due to the way localization happens, localized privacy keys are
331 expected to be the length needed by the algorithm (128 bits for
332 all supported algorithms). Master encryption keys, though, need
333 to be the length required by the authentication algorithm not
334 the length required by the encrypting algorithm (MD5: 16 bytes,
335 SHA: 20 bytes).
336
338 snmpd supports the View-Based Access Control Model (VACM) as defined in
339 RFC 2575, to control who can retrieve or update information. To this
340 end, it recognizes various directives relating to access control.
341 Traditional Access Control
343 Most simple access control requirements can be specified using the
344 directives rouser/rwuser (for SNMPv3) or rocommunity/rwcommunity (for
345 SNMPv1 or SNMPv2c).
346 rouser [-s SECMODEL] USER [noauth|auth|priv [OID | -V VIEW [CONTEXT]]]
348 rwuser [-s SECMODEL] USER [noauth|auth|priv [OID | -V VIEW [CONTEXT]]]
350 specify an SNMPv3 user that will be allowed read-only (GET and
351 GETNEXT) or read-write (GET, GETNEXT and SET) access respec‐
352 tively. By default, this will provide access to the full OID
353 tree for authenticated (including encrypted) SNMPv3 requests,
354 using the default context. An alternative minimum security
355 level can be specified using noauth (to allow unauthenticated
356 requests), or priv (to enforce use of encryption). The OID
357 field restricts access for that user to the subtree rooted at
358 the given OID, or the named view. An optional context can also
359 be specified, or "context*" to denote a context prefix. If no
360 context field is specified (or the token "*" is used), the
361 directive will match all possible contexts.
362 If SECMODEL is specified then it will be the security model
364 required for that user (note that identical user names may come
365 in over different security models and will be appropriately sep‐
366 arated via the access control settings). The default security
367 model is "usm" and the other common security models are likely
368 "tsm" when using (D)TLS or SSH support and "ksm" if the Kerberos
369 support has been compiled in.
370 rocommunity COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]
372 rwcommunity COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]
374 specify an SNMPv1 or SNMPv2c community that will be allowed
375 read-only (GET and GETNEXT) or read-write (GET, GETNEXT and SET)
376 access respectively. By default, this will provide access to
377 the full OID tree for such requests, regardless of where they
378 were sent from. The SOURCE token can be used to restrict access
379 to requests from the specified system(s) - see com2sec for the
380 full details. The OID field restricts access for that community
381 to the subtree rooted at the given OID, or named view. Contexts
382 are typically less relevant to community-based SNMP versions,
383 but the same behaviour applies here.
384 rocommunity6 COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]
386 rwcommunity6 COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]
388 are directives relating to requests received using IPv6 (if the
389 agent supports such transport domains). The interpretation of
390 the SOURCE, OID, VIEW and CONTEXT tokens are exactly the same as
391 for the IPv4 versions.
392 In each case, only one directive should be specified for a given SNMPv3
394 user, or community string. It is not appropriate to specify both
395 rouser and rwuser directives referring to the same SNMPv3 user (or
396 equivalent community settings). The rwuser directive provides all the
397 access of rouser (as well as allowing SET support). The same holds
398 true for the community-based directives.
399 More complex access requirements (such as access to two or more dis‐
401 tinct OID subtrees, or different views for GET and SET requests) should
402 use one of the other access control mechanisms. Note that if several
403 distinct communities or SNMPv3 users need to be granted the same level
404 of access, it would also be more efficient to use the main VACM config‐
405 uration directives.
406 VACM Configuration
408 The full flexibility of the VACM is available using four configuration
409 directives - com2sec, group, view and access. These provide direct
410 configuration of the underlying VACM tables.
411 com2sec [-Cn CONTEXT] SECNAME SOURCE COMMUNITY
413 com2sec6 [-Cn CONTEXT] SECNAME SOURCE COMMUNITY
415 map an SNMPv1 or SNMPv2c community string to a security name -
416 either from a particular range of source addresses, or globally
417 ("default"). A restricted source can either be a specific host‐
418 name (or address), or a subnet - represented as IP/MASK (e.g.
419 10.10.10.0/255.255.255.0), or IP/BITS (e.g. 10.10.10.0/24), or
420 the IPv6 equivalents. A restriction preceded by an exclamation
421 mark (!) denies access from that address or subnet, e.g.,
422 !10.10.10.0/24 denies requests from that sources in that subnet.
423 Deny restrictions must be before permit. E.g., the following
424 example permits access from all of 10.0.0.0/8 except for
425 10.10.10.0/24:
426 com2sec sec1 !10.10.10.0/24 public
427 com2sec sec1 10.0.0.0/8 public
428 Access from outside of 10.0.0.0/8 would still be denied.
430 The same community string can be specified in several separate
432 directives (presumably with different source tokens), and the
433 first source/community combination that matches the incoming
434 request will be selected. Various source/community combinations
435 can also map to the same security name.
436 If a CONTEXT is specified (using -Cn), the community string will
438 be mapped to a security name in the named SNMPv3 context. Other‐
439 wise the default context ("") will be used.
440 com2secunix [-Cn CONTEXT] SECNAME SOCKPATH COMMUNITY
442 is the Unix domain sockets version of com2sec.
443 group GROUP {v1|v2c|usm|tsm|ksm} SECNAME
445 maps a security name (in the specified security model) into a
446 named group. Several group directives can specify the same
447 group name, allowing a single access setting to apply to several
448 users and/or community strings.
449 Note that groups must be set up for the two community-based mod‐
451 els separately - a single com2sec (or equivalent) directive will
452 typically be accompanied by two group directives.
453 view VNAME TYPE OID [MASK]
455 defines a named "view" - a subset of the overall OID tree. This
456 is most commonly a single subtree, but several view directives
457 can be given with the same view name (VNAME), to build up a more
458 complex collection of OIDs. TYPE is either included or
459 excluded, which can again define a more complex view (e.g by
460 excluding certain sensitive objects from an otherwise accessible
461 subtree).
462 MASK is a list of hex octets (optionally separated by '.' or
464 ':') with the set bits indicating which subidentifiers in the
465 view OID to match against. If not specified, this defaults to
466 matching the OID exactly (all bits set), thus defining a simple
467 OID subtree. So:
468 view iso1 included .iso 0xf0
469 view iso2 included .iso
470 view iso3 included .iso.org.dod.mgmt 0xf0
471 would all define the same view, covering the whole of the
473 'iso(1)' subtree (with the third example ignoring the subidenti‐
474 fiers not covered by the mask).
475 More usefully, the mask can be used to define a view covering a
477 particular row (or rows) in a table, by matching against the
478 appropriate table index value, but skipping the column subiden‐
479 tifier:
480 view ifRow4 included .1.3.6.1.2.1.2.2.1.0.4 0xff:a0
482 Note that a mask longer than 8 bits must use ':' to separate the
484 individual octets.
485 access GROUP CONTEXT {any|v1|v2c|usm|tsm|ksm} LEVEL PREFX READ WRITE
487 NOTIFY
488 maps from a group of users/communities (with a particular secu‐
489 rity model and minimum security level, and in a specific con‐
490 text) to one of three views, depending on the request being pro‐
491 cessed.
492 LEVEL is one of noauth, auth, or priv. PREFX specifies how CON‐
494 TEXT should be matched against the context of the incoming
495 request, either exact or prefix. READ, WRITE and NOTIFY speci‐
496 fies the view to be used for GET*, SET and TRAP/INFORM requests
497 (althought the NOTIFY view is not currently used). For v1 or
498 v2c access, LEVEL will need to be noauth.
499 Typed-View Configuration
501 The final group of directives extend the VACM approach into a more
502 flexible mechanism, which can be applied to other access control
503 requirements. Rather than the fixed three views of the standard VACM
504 mechanism, this can be used to configure various different view types.
505 As far as the main SNMP agent is concerned, the two main view types are
506 read and write, corresponding to the READ and WRITE views of the main
507 access directive. See the 'snmptrapd.conf(5)' man page for discussion
508 of other view types.
509 authcommunity TYPES COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]
511 is an alternative to the rocommunity/rwcommunity directives.
512 TYPES will usually be read or read,write respectively. The view
513 specification can either be an OID subtree (as before), or a
514 named view (defined using the view directive) for greater flexi‐
515 bility. If this is omitted, then access will be allowed to the
516 full OID tree. If CONTEXT is specified, access is configured
517 within this SNMPv3 context. Otherwise the default context ("")
518 is used.
519 authuser TYPES [-s MODEL] USER [LEVEL [OID | -V VIEW [CONTEXT]]]
521 is an alternative to the rouser/rwuser directives. The fields
522 TYPES, OID, VIEW and CONTEXT have the same meaning as for auth‐
523 community.
524 authgroup TYPES [-s MODEL] GROUP [LEVEL [OID | -V VIEW [CONTEXT]]]
526 is a companion to the authuser directive, specifying access for
527 a particular group (defined using the group directive as usual).
528 Both authuser and authgroup default to authenticated requests -
529 LEVEL can also be specified as noauth or priv to allow unauthen‐
530 ticated requests, or require encryption respectively. Both
531 authuser and authgroup directives also default to configuring
532 access for SNMPv3/USM requests - use the '-s' flag to specify an
533 alternative security model (using the same values as for access
534 above).
535 authaccess TYPES [-s MODEL] GROUP VIEW [LEVEL [CONTEXT]]
537 also configures the access for a particular group, specifying
538 the name and type of view to apply. The MODEL and LEVEL fields
539 are interpreted in the same way as for authgroup. If CONTEXT is
540 specified, access is configured within this SNMPv3 context (or
541 contexts with this prefix if the CONTEXT field ends with '*').
542 Otherwise the default context ("") is used.
543 setaccess GROUP CONTEXT MODEL LEVEL PREFIX VIEW TYPES
545 is a direct equivalent to the original access directive, typi‐
546 cally listing the view types as read or read,write as appropri‐
547 ate. (or see 'snmptrapd.conf(5)' for other possibilities). All
548 other fields have the same interpretation as with access.
549
551 Most of the information reported by the Net-SNMP agent is retrieved
552 from the underlying system, or dynamically configured via SNMP SET
553 requests (and retained from one run of the agent to the next). How‐
554 ever, certain MIB objects can be configured or controlled via the
555 snmpd.conf(5) file.
556 System Group
558 Most of the scalar objects in the 'system' group can be configured in
559 this way:
560 sysLocation STRING
562 sysContact STRING
564 sysName STRING
566 set the system location, system contact or system name (sysLoca‐
567 tion.0, sysContact.0 and sysName.0) for the agent respectively.
568 Ordinarily these objects are writable via suitably authorized
569 SNMP SET requests. However, specifying one of these directives
570 makes the corresponding object read-only, and attempts to SET it
571 will result in a notWritable error response.
572 sysServices NUMBER
574 sets the value of the sysServices.0 object. For a host system,
575 a good value is 72 (application + end-to-end layers). If this
576 directive is not specified, then no value will be reported for
577 the sysServices.0 object.
578 sysDescr STRING
580 sysObjectID OID
582 sets the system description or object ID for the agent.
583 Although these MIB objects are not SNMP-writable, these direc‐
584 tives can be used by a network administrator to configure suit‐
585 able values for them.
586 Interfaces Group
588 interface NAME TYPE SPEED
589 can be used to provide appropriate type and speed settings for
590 interfaces where the agent fails to determine this information
591 correctly. TYPE is a type value as given in the IANAifType-MIB,
592 and can be specified numerically or by name (assuming this MIB
593 is loaded).
594 interface_fadeout TIMEOUT
596 specifies, for how long the agent keeps entries in ifTable after
597 appropriate interfaces have been removed from system (typically
598 various ppp, tap or tun interfaces). Timeout value is in sec‐
599 onds. Default value is 300 (=5 minutes).
600 interface_replace_old yes
602 can be used to remove already existing entries in ifTable when
603 an interface with the same name appears on the system. E.g. when
604 ppp0 interface is removed, it is still listed in the table for
605 interface_fadeout seconds. This option ensures, that the old
606 ppp0 interface is removed even before the interface_fadeout
607 timeour when new ppp0 (with different ifIndex) shows up.
608 Host Resources Group
610 This requires that the agent was built with support for the host module
611 (which is now included as part of the default build configuration on
612 the major supported platforms).
613 ignoreDisk STRING
615 controls which disk devices are scanned as part of populating
616 the hrDiskStorageTable (and hrDeviceTable). The HostRes imple‐
617 mentation code includes a list of disk device patterns appropri‐
618 ate for the current operating system, some of which may cause
619 the agent to block when trying to open the corresponding disk
620 devices. This might lead to a timeout when walking these
621 tables, possibly resulting in inconsistent behaviour. This
622 directive can be used to specify particular devices (either
623 individually or wildcarded) that should not be checked.
624 Note: Please consult the source (host/hr_disk.c) and check for
626 the Add_HR_Disk_entry calls relevant for a particular O/S
627 to determine the list of devices that will be scanned.
628 The pattern can include one or more wildcard expressions. See
630 snmpd.examples(5) for illustration of the wildcard syntax.
631 skipNFSInHostResources true
633 controls whether NFS and NFS-like file systems should be omitted
634 from the hrStorageTable (true or 1) or not (false or 0, which is
635 the default). If the Net-SNMP agent gets hung on NFS-mounted
636 filesystems, you can try setting this to '1'.
637 storageUseNFS [1|2]
639 controls how NFS and NFS-like file systems should be reported in
640 the hrStorageTable. as 'Network Disks' (1) or 'Fixed Disks' (2)
641 Historically, the Net-SNMP agent has reported such file systems
642 as 'Fixed Disks', and this is still the default behaviour. Set‐
643 ting this directive to '1' reports such file systems as ´Network
644 Disks', as required by the Host Resources MIB.
645 realStorageUnits
647 controlls how the agent reports hrStorageAllocationUnits,
648 hrStorageSize and hrStorageUsed in hrStorageTable. For big
649 storage drives with small allocation units the agent re-calcu‐
650 lates these values so they all fit Integer32 and hrStorageAllo‐
651 cationUnits x hrStorageSize gives real size of the storage.
652 Example:
654 Linux xfs 16TB filesystem with 4096 bytes large blocks
655 will be reported as hrStorageAllocationUnits = 8192 and
656 hrStorageSize = 2147483647, so 8192 x 2147483647 gives
657 real size of the filesystem (=16 TB).
658 Setting this directive to '1' turns off this calculation and the
660 agent reports real hrStorageAllocationUnits, but it might report
661 wrong hrStorageSize for big drives because the value won't fit
662 into Integer32. In this case, hrStorageAllocationUnits x hrStor‐
663 ageSize won't give real size of the storage.
664 Process Monitoring
666 The hrSWRun group of the Host Resources MIB provides information about
667 individual processes running on the local system. The prTable of the
668 UCD-SNMP-MIB complements this by reporting on selected services (which
669 may involve multiple processes). This requires that the agent was
670 built with support for the ucd-snmp/proc module (which is included as
671 part of the default build configuration).
672 proc NAME [MAX [MIN]]
674 monitors the number of processes called NAME (as reported by
675 "/usr/bin/ps -e") running on the local system.
676 If the number of NAMEd processes is less than MIN or greater
678 than MAX, then the corresponding prErrorFlag instance will be
679 set to 1, and a suitable description message reported via the
680 prErrMessage instance.
681 Note: This situation will not automatically trigger a trap to
683 report the problem - see the DisMan Event MIB section
684 later.
685 If neither MAX nor MIN are specified, they will default to
687 infinity and 1 respectively ("at least one"). If only MAX is
688 specified, MIN will default to 0 ("no more than MAX"). If MAX
689 is 0 (and MIN is not), this indicates infinity ("at least MIN").
690 If both MAX and MIN are 0, this indicates a process that should
691 not be running.
692 procfix NAME PROG ARGS
694 registers a command that can be run to fix errors with the given
695 process NAME. This will be invoked when the corresponding prE‐
696 rrFix instance is set to 1.
697 Note: This command will not be invoked automatically.
699 The procfix directive must be specified after the matching proc
701 directive, and cannot be used on its own.
702 If no proc directives are defined, then walking the prTable will fail
704 (noSuchObject).
705 Disk Usage Monitoring
707 This requires that the agent was built with support for the
708 ucd-snmp/disk module (which is included as part of the default build
709 configuration).
710 disk PATH [ MINSPACE | MINPERCENT% ]
712 monitors the disk mounted at PATH for available disk space.
713 Disks mounted after the agent has started will not be monitored,
714 unless includeAllDisks option is specified.
715 The minimum threshold can either be specified in kB (MINSPACE)
717 or as a percentage of the total disk (MINPERCENT% with a '%'
718 character), defaulting to 100kB if neither are specified. If
719 the free disk space falls below this threshold, then the corre‐
720 sponding dskErrorFlag instance will be set to 1, and a suitable
721 description message reported via the dskErrorMsg instance.
722 Note: This situation will not automatically trigger a trap to
724 report the problem - see the DisMan Event MIB section
725 later.
726 includeAllDisks MINPERCENT%
728 configures monitoring of all disks found on the system, using
729 the specified (percentage) threshold. The dskTable is dynami‐
730 cally updated, unmounted disks disappear from the table and
731 newly mounted disks are added to the table. The threshold for
732 individual disks can be adjusted using suitable disk directives
733 (which can come either before or after the includeAllDisks
734 directive).
735 Note: Whether disk directives appears before or after
737 includeAllDisks may affect the indexing of the dskTable.
738 Only one includeAllDisks directive should be specified - any
740 subsequent copies will be ignored.
741 The list of mounted disks will be determined from HOST-
743 RESOURCES-MIB::hrFSTable.
744 If neither any disk directives or includeAllDisks are defined, then
746 walking the dskTable will fail (noSuchObject).
747 Disk I/O Monitoring
749 This requires that the agent was built with support for the
750 ucd-snmp/diskio module (which is not included as part of the default
751 build configuration).
752 By default, all block devices known to the operating system are
754 included in the diskIOTable. On platforms other than Linux, this module
755 has no configuration directives.
756 On Linux systems, it is possible to exclude several classes of block
758 devices from the diskIOTable in order to avoid cluttering the table
759 with useless zero statistics for pseudo-devices that often are not in
760 use but are configured by default to exist in most recent Linux distri‐
761 butions.
762 diskio_exclude_fd yes
764 Excludes all Linux floppy disk block devices, whose names start
765 with "fd", e.g. "fd0"
766 diskio_exclude_loop yes
768 Excludes all Linux loopback block devices, whose names start
769 with "loop", e.g. "loop0"
770 diskio_exclude_ram yes
772 Excludes all LInux ramdisk block devices, whose names start with
773 "ram", e.g. "ram0"
774 On Linux systems, it is also possible to report only explicitly
776 whitelisted devices. It may take significant amount of time to process
777 diskIOTable data on systems with tens of thousands of block devices and
778 whitelisting only the important ones avoids large CPU consumption.
779 diskio <device>
781 Enables whitelisting of devices and adds the device to the
782 whitelist. Only explicitly whitelisted devices will be reported.
783 This option may be used multiple times.
784 System Load Monitoring
786 This requires that the agent was built with support for either the
787 ucd-snmp/loadave module or the ucd-snmp/memory module respectively
788 (both of which are included as part of the default build configura‐
789 tion).
790 load MAX1 [MAX5 [MAX15]]
792 monitors the load average of the local system, specifying
793 thresholds for the 1-minute, 5-minute and 15-minute averages.
794 If any of these loads exceed the associated maximum value, then
795 the corresponding laErrorFlag instance will be set to 1, and a
796 suitable description message reported via the laErrMessage
797 instance.
798 Note: This situation will not automatically trigger a trap to
800 report the problem - see the DisMan Event MIB section
801 later.
802 If the MAX15 threshold is omitted, it will default to the MAX5
804 value. If both MAX5 and MAX15 are omitted, they will default to
805 the MAX1 value. If this directive is not specified, all three
806 thresholds will default to a value of DEFMAXLOADAVE.
807 If a threshold value of 0 is given, the agent will not report
809 errors via the relevant laErrorFlag or laErrMessage instances,
810 regardless of the current load.
811 Unlike the proc and disk directives, walking the walking the laTable
813 will succeed (assuming the ucd-snmp/loadave module was configured into
814 the agent), even if the load directive is not present.
815 swap MIN
817 monitors the amount of swap space available on the local system.
818 If this falls below the specified threshold (MIN kB), then the
819 memErrorSwap object will be set to 1, and a suitable description
820 message reported via memSwapErrorMsg.
821 Note: This situation will not automatically trigger a trap to
823 report the problem - see the DisMan Event MIB section
824 later.
825 If this directive is not specified, the default threshold is 16 MB.
826 Log File Monitoring
828 This requires that the agent was built with support for either the
829 ucd-snmp/file or ucd-snmp/logmatch modules respectively (both of which
830 are included as part of the default build configuration).
831 file FILE [MAXSIZE]
833 monitors the size of the specified file (in kB). If MAXSIZE is
834 specified, and the size of the file exceeds this threshold, then
835 the corresponding fileErrorFlag instance will be set to 1, and a
836 suitable description message reported via the fileErrorMsg
837 instance.
838 Note: This situation will not automatically trigger a trap to
840 report the problem - see the DisMan Event MIB section
841 later.
842 Note: A maximum of 20 files can be monitored.
844 Note: If no file directives are defined, then walking the
846 fileTable will fail (noSuchObject).
847 logmatch NAME FILE CYCLETIME REGEX
849 monitors the specified file for occurances of the specified pat‐
850 tern REGEX. The file position is stored internally so the entire
851 file is only read initially, every subsequent pass will only
852 read the new lines added to the file since the last read.
853 NAME name of the logmatch instance (will appear as logMatch‐
855 Name under logMatch/logMatchTable/logMatchEntry/logMatch‐
856 Name in the ucd-snmp MIB tree)
857 FILE absolute path to the logfile to be monitored. Note that
859 this path can contain date/time directives (like in the
860 UNIX 'date' command). See the manual page for 'strftime'
861 for the various directives accepted.
862 CYCLETIME
864 time interval for each logfile read and internal variable
865 update in seconds. Note: an SNMPGET* operation will also
866 trigger an immediate logfile read and variable update.
867 REGEX the regular expression to be used. Note: DO NOT enclose
869 the regular expression in quotes even if there are spaces
870 in the expression as the quotes will also become part of
871 the pattern to be matched!
872 Example:
874 logmatch apache-GETs
876 /usr/local/apache/logs/access.log-%Y-%m-%d 60 GET.*HTTP.*
877 This logmatch instance is named 'apache-GETs', uses
879 'GET.*HTTP.*' as its regular expression and it will moni‐
880 tor the file named (assuming today is May 6th 2009):
881 '/usr/local/apache/logs/access.log-2009-05-06', tomorrow
882 it will look for 'access.log-2009-05-07'. The logfile is
883 read every 60 seconds.
884 Note: A maximum of 250 logmatch directives can be specified.
886 Note: If no logmatch directives are defined, then walking the
888 logMatchTable will fail (noSuchObject).
889
891 The usual behaviour of an SNMP agent is to wait for incoming SNMP
892 requests and respond to them - if no requests are received, an agent
893 will typically not initiate any actions. This section describes various
894 directives that can configure snmpd to take a more active role.
895 Notification Handling
897 trapcommunity STRING
898 defines the default community string to be used when sending
899 traps. Note that this directive must be used prior to any com‐
900 munity-based trap destination directives that need to use it.
901 trapsink [-profile p] [-name n] [-tag t] HOST [COMMUNITY [PORT]]
903 trap2sink [-profile p] [-name n] [-tag t] HOST [COMMUNITY [PORT]]
905 informsink [-profile p] [-name n] [-tag t] HOST [COMMUNITY [PORT]]
907 define the address of a notification receiver that should be
908 sent SNMPv1 TRAPs, SNMPv2c TRAP2s, or SNMPv2 INFORM notifica‐
909 tions respectively. See the section LISTENING ADDRESSES in the
910 snmpd(8) manual page for more information about the format of
911 listening addresses. If COMMUNITY is not specified, the most
912 recent trapcommunity string will be used.
913 If the transport address does not include an explicit port spec‐
915 ification, then PORT will be used. If this is not specified,
916 the well known SNMP trap port (162) will be used.
917 Note: This mechanism is being deprecated, and the listening
919 port should be specified via the transport specification
920 HOST instead.
921 The optional name and tag parameters specifies the name or tag
923 that will be used for SNMP-NOTIFICATION-MIB table entries. The
924 profile specifies which notification filter profile entry will
925 be used for filtering outgoing notifications. (See notification‐
926 Filter)
927 If several sink directives are specified, multiple copies of
929 each notification (in the appropriate formats) will be gener‐
930 ated.
931 Note: It is not normally appropriate to list two (or all three)
933 sink directives with the same destination.
934 trapsess [-profile p] [-name n] [-tag t] [SNMPCMD_ARGS] HOST
936 provides a more generic mechanism for defining notification des‐
937 tinations. SNMPCMD_ARGS should be the command-line options
938 required for an equivalent snmptrap (or snmpinform) command to
939 send the desired notification. The option -Ci can be used (with
940 -v2c or -v3) to generate an INFORM notification rather than an
941 unacknowledged TRAP.
942 The optional name and tag parameters specifies the name or tag
944 that will be used for SNMP-NOTIFICATION-MIB table entries. The
945 profile specifies which notification filter profile entry will
946 be used for filtering outgoing notifications. (See notification‐
947 Filter)
948 This is the appropriate directive for defining SNMPv3 trap
950 receivers. See http://www.net-snmp.org/tutorial/tutorial-5/com‐
951 mands/snmptrap-v3.html for more information about SNMPv3 notifi‐
952 cation behaviour.
953 notificationFilter NAME OID MASK TYPE
955 specifies a SNMP-NOTIFICATION-MIB notification filter profile,
956 which may be used to filter traps. TYPE must be included or
957 excluded, Some examples:
958 notificationFilter all_ok .1.3 0x00 included
960 notificationFilter no_coldstart .1.3 0x00 included
961 notificationFilter no_coldstart .1.3.6.1.6.3.1.1.5.1 0x00 excluded
962 trapsink -profile no_coldstart 192.168.1.3:3162 secret3
964 authtrapenable {1|2}
966 determines whether to generate authentication failure traps
967 (enabled(1)) or not (disabled(2) - the default). Ordinarily the
968 corresponding MIB object (snmpEnableAuthenTraps.0) is read-
969 write, but specifying this directive makes this object read-
970 only, and attempts to set the value via SET requests will result
971 in a notWritable error response.
972 v1trapaddress HOST
974 defines the agent address, which is inserted into SNMPv1 TRAPs.
975 Arbitrary local IPv4 address is chosen if this option is
976 ommited. This option is useful mainly when the agent is visible
977 from outside world by specific address only (e.g. because of
978 network address translation or firewall).
979 DisMan Event MIB
981 The previous directives can be used to configure where traps should be
982 sent, but are not concerned with when to send such traps (or what traps
983 should be generated). This is the domain of the Event MIB - developed
984 by the Distributed Management (DisMan) working group of the IETF.
985 This requires that the agent was built with support for the dis‐
987 man/event module (which is now included as part of the default build
988 configuration for the most recent distribution).
989 Note: The behaviour of the latest implementation differs in
991 some minor respects from the previous code - nothing too
992 significant, but existing scripts may possibly need some
993 minor adjustments.
994 iquerySecName NAME
996 agentSecName NAME
998 specifies the default SNMPv3 username, to be used when making
999 internal queries to retrieve any necessary information (either
1000 for evaluating the monitored expression, or building a notifica‐
1001 tion payload). These internal queries always use SNMPv3, even
1002 if normal querying of the agent is done using SNMPv1 or SNMPv2c.
1003 Note that this user must also be explicitly created (createUser)
1005 and given appropriate access rights (e.g. rouser). This direc‐
1006 tive is purely concerned with defining which user should be used
1007 - not with actually setting this user up.
1008 monitor [OPTIONS] NAME EXPRESSION
1010 defines a MIB object to monitor. If the EXPRESSION condition
1011 holds (see below), then this will trigger the corresponding
1012 event, and either send a notification or apply a SET assignment
1013 (or both). Note that the event will only be triggered once,
1014 when the expression first matches. This monitor entry will not
1015 fire again until the monitored condition first becomes false,
1016 and then matches again. NAME is an administrative name for this
1017 expression, and is used for indexing the mteTriggerTable (and
1018 related tables). Note also that such monitors use an internal
1019 SNMPv3 request to retrieve the values being monitored (even if
1020 normal agent queries typically use SNMPv1 or SNMPv2c). See the
1021 iquerySecName token described above.
1022 EXPRESSION
1024 There are three types of monitor expression supported by the
1025 Event MIB - existence, boolean and threshold tests.
1026 OID | ! OID | != OID
1028 defines an existence(0) monitor test. A bare OID speci‐
1029 fies a present(0) test, which will fire when (an instance
1030 of) the monitored OID is created. An expression of the
1031 form ! OID specifies an absent(1) test, which will fire
1032 when the monitored OID is delected. An expression of the
1033 form != OID specifies a changed(2) test, which will fire
1034 whenever the monitored value(s) change. Note that there
1035 must be whitespace before the OID token.
1036 OID OP VALUE
1038 defines a boolean(1) monitor test. OP should be one of
1039 the defined comparison operators (!=, ==, <, <=, >, >=)
1040 and VALUE should be an integer value to compare against.
1041 Note that there must be whitespace around the OP token.
1042 A comparison such as OID !=0 will not be handled cor‐
1043 rectly.
1044 OID MIN MAX [DMIN DMAX]
1046 defines a threshold(2) monitor test. MIN and MAX are
1047 integer values, specifying lower and upper thresholds.
1048 If the value of the monitored OID falls below the lower
1049 threshold (MIN) or rises above the upper threshold (MAX),
1050 then the monitor entry will trigger the corresponding
1051 event.
1052 Note that the rising threshold event will only be re-
1054 armed when the monitored value falls below the lower
1055 threshold (MIN). Similarly, the falling threshold event
1056 will be re-armed by the upper threshold (MAX).
1057 The optional parameters DMIN and DMAX configure a pair of
1059 similar threshold tests, but working with the delta dif‐
1060 ferences between successive sample values.
1061 OPTIONS
1063 There are various options to control the behaviour of the moni‐
1064 tored expression. These include:
1065 -D indicates that the expression should be evaluated using
1067 delta differences between sample values (rather than the
1068 values themselves).
1069 -d OID
1071 -di OID
1073 specifies a discontinuity marker for validating delta
1074 differences. A -di object instance will be used exactly
1075 as given. A -d object will have the instance subidenti‐
1076 fiers from the corresponding (wildcarded) expression
1077 object appended. If the -I flag is specified, then there
1078 is no difference between these two options.
1079 This option also implies -D.
1081 -e EVENT
1083 specifies the event to be invoked when this monitor entry
1084 is triggered. If this option is not given, the monitor
1085 entry will generate one of the standard notifications
1086 defined in the DISMAN-EVENT-MIB.
1087 -I indicates that the monitored expression should be applied
1089 to the specified OID as a single instance. By default,
1090 the OID will be treated as a wildcarded object, and the
1091 monitor expanded to cover all matching instances.
1092 -i OID
1094 -o OID define additional varbinds to be added to the notifica‐
1096 tion payload when this monitor trigger fires. For a
1097 wildcarded expression, the suffix of the matched instance
1098 will be added to any OIDs specified using -o, while OIDs
1099 specified using -i will be treated as exact instances.
1100 If the -I flag is specified, then there is no difference
1101 between these two options.
1102 See strictDisman for details of the ordering of notifica‐
1104 tion payloads.
1105 -r FREQUENCY
1107 monitors the given expression every FREQUENCY, where FRE‐
1108 QUENCY is in seconds or optionally suffixed by one of s
1109 (for seconds), m (for minutes), h (for hours), d (for
1110 days), or w (for weeks). By default, the expression will
1111 be evaluated every 600s (10 minutes).
1112 -S indicates that the monitor expression should not be eval‐
1114 uated when the agent first starts up. The first evalua‐
1115 tion will be done once the first repeat interval has
1116 expired.
1117 -s indicates that the monitor expression should be evaluated
1119 when the agent first starts up. This is the default be‐
1120 haviour.
1121 Note: Notifications triggered by this initial evaluation
1123 will be sent before the coldStart trap.
1124 -u SECNAME
1126 specifies a security name to use for scanning the local
1127 host, instead of the default iquerySecName. Once again,
1128 this user must be explicitly created and given suitable
1129 access rights.
1130 notificationEvent ENAME NOTIFICATION [-m] [-i OID | -o OID ]*
1132 defines a notification event named ENAME. This can be triggered
1133 from a given monitor entry by specifying the option -e ENAME
1134 (see above). NOTIFICATION should be the OID of the NOTIFICA‐
1135 TION-TYPE definition for the notification to be generated.
1136 If the -m option is given, the notification payload will include
1138 the standard varbinds as specified in the OBJECTS clause of the
1139 notification MIB definition. This option must come after the
1140 NOTIFICATION OID (and the relevant MIB file must be available
1141 and loaded by the agent). Otherwise, these varbinds must be
1142 listed explicitly (either here or in the corresponding monitor
1143 directive).
1144 The -i OID and -o OID options specify additional varbinds to be
1146 appended to the notification payload, after the standard list.
1147 If the monitor entry that triggered this event involved a wild‐
1148 carded expression, the suffix of the matched instance will be
1149 added to any OIDs specified using -o, while OIDs specified using
1150 -i will be treated as exact instances. If the -I flag was spec‐
1151 ified to the monitor directive, then there is no difference
1152 between these two options.
1153 setEvent ENAME [-I] OID = VALUE
1155 defines a set event named ENAME, assigning the (integer) VALUE
1156 to the specified OID. This can be triggered from a given moni‐
1157 tor entry by specifying the option -e ENAME (see above).
1158 If the monitor entry that triggered this event involved a wild‐
1160 carded expression, the suffix of the matched instance will nor‐
1161 mally be added to the OID. If the -I flag was specified to
1162 either of the monitor or setEvent directives, the specified OID
1163 will be regarded as an exact single instance.
1164 strictDisman yes
1166 The definition of SNMP notifications states that the varbinds
1167 defined in the OBJECT clause should come first (in the order
1168 specified), followed by any "extra" varbinds that the notifica‐
1169 tion generator feels might be useful. The most natural approach
1170 would be to associate these mandatory varbinds with the notifi‐
1171 cationEvent entry, and append any varbinds associated with the
1172 monitor entry that triggered the notification to the end of this
1173 list. This is the default behaviour of the Net-SNMP Event MIB
1174 implementation.
1175 Unfortunately, the DisMan Event MIB specifications actually
1177 state that the trigger-related varbinds should come first, fol‐
1178 lowed by the event-related ones. This directive can be used to
1179 restore this strictly-correct (but inappropriate) behaviour.
1180 Note: Strict DisMan ordering may result in generating invalid
1182 notifications payload lists if the notificationEvent -n
1183 flag is used together with monitor -o (or -i) varbind
1184 options.
1185 If no monitor entries specify payload varbinds, then the setting
1187 of this directive is irrelevant.
1188 linkUpDownNotifications yes
1190 will configure the Event MIB tables to monitor the ifTable for
1191 network interfaces being taken up or down, and triggering a
1192 linkUp or linkDown notification as appropriate.
1193 This is exactly equivalent to the configuration:
1195 notificationEvent linkUpTrap linkUp ifIndex ifAdminStatus ifOperStatus
1197 notificationEvent linkDownTrap linkDown ifIndex ifAdminStatus ifOperStatus
1198 monitor -r 60 -e linkUpTrap "Generate linkUp" ifOperStatus != 2
1200 monitor -r 60 -e linkDownTrap "Generate linkDown" ifOperStatus == 2
1201 defaultMonitors yes
1203 will configure the Event MIB tables to monitor the various
1204 UCD-SNMP-MIB tables for problems (as indicated by the appropri‐
1205 ate xxErrFlag column objects).
1206 This is exactly equivalent to the configuration:
1208 monitor -o prNames -o prErrMessage "process table" prErrorFlag != 0
1210 monitor -o memErrorName -o memSwapErrorMsg "memory" memSwapError != 0
1211 monitor -o extNames -o extOutput "extTable" extResult != 0
1212 monitor -o dskPath -o dskErrorMsg "dskTable" dskErrorFlag != 0
1213 monitor -o laNames -o laErrMessage "laTable" laErrorFlag != 0
1214 monitor -o fileName -o fileErrorMsg "fileTable" fileErrorFlag != 0
1215 In both these latter cases, the snmpd.conf must also contain a iquery‐
1217 SecName directive, together with a corresponding createUser entry and
1218 suitable access control configuration.
1219 DisMan Schedule MIB
1221 The DisMan working group also produced a mechanism for scheduling par‐
1222 ticular actions (a specified SET assignment) at given times. This
1223 requires that the agent was built with support for the disman/schedule
1224 module (which is included as part of the default build configuration
1225 for the most recent distribution).
1226 There are three ways of specifying the scheduled action:
1228 repeat FREQUENCY OID = VALUE
1230 configures a SET assignment of the (integer) VALUE to the MIB
1231 instance OID, to be run every FREQUENCY seconds, where FREQUENCY
1232 is in seconds or optionally suffixed by one of s (for seconds),
1233 m (for minutes), h (for hours), d (for days), or w (for weeks).
1234 cron MINUTE HOUR DAY MONTH WEEKDAY OID = VALUE
1236 configures a SET assignment of the (integer) VALUE to the MIB
1237 instance OID, to be run at the times specified by the fields
1238 MINUTE to WEEKDAY. These follow the same pattern as the equiva‐
1239 lent crontab(5) fields.
1240 Note: These fields should be specified as a (comma-separated)
1242 list of numeric values. Named values for the MONTH and
1243 WEEKDAY fields are not supported, and neither are value
1244 ranges. A wildcard match can be specified as '*'.
1245 The DAY field can also accept negative values, to indicate days
1247 counting backwards from the end of the month.
1248 at MINUTE HOUR DAY MONTH WEEKDAY OID = VALUE
1250 configures a one-shot SET assignment, to be run at the first
1251 matching time as specified by the fields MINUTE to WEEKDAY. The
1252 interpretation of these fields is exactly the same as for the
1253 cron directive.
1254 Data Delivery via Notfiications
1256 Note: this functionality is only available if the deliver/deliverByNo‐
1257 tify mib module was complied in to the agent
1258 In some situations it may be advantageous to deliver SNMP data over
1260 SNMP Notifications (TRAPs and INFORMs) rather than the typical process
1261 of having the manager issue requests for the data (via GETs and GET‐
1262 NEXTs). Reasons for doing this are numerous, but frequently corner
1263 cases. The most common reason for wanting this behaviour might be to
1264 monitor devices that reside behind NATs or Firewalls that prevent
1265 incoming SNMP traffic.
1266 It should be noted that although most management software is capable of
1268 logging notifications, very little (if any) management software will
1269 updated their "knowledge database" based on the contents of SNMP noti‐
1270 fications. IE, it won't (for example) update the interface traffic
1271 counter history that is used to produce graphs. Most larger network
1272 management packages have a separate database for storing data received
1273 via SNMP requests (GETs and GETNEXTs) vs those received from notifica‐
1274 tions. Researching the capabilities of your management station soft‐
1275 ware is required before assuming this functionality will solve your
1276 data delivery requirements.
1277 Notifications generated via this mechanism will be sent to the standard
1279 set of configured notification targets. See the "Notification Han‐
1280 dling" section of this document for further information.
1281 deliverByNotify [-p] [-m] [-s MAXSIZE] FREQUENCY OID
1283 This directive tells the SNMP agent to self-walk the OID, col‐
1284 lect all the data and send it out every FREQUENCY seconds, where
1285 FREQUENCY is in seconds or optionally suffixed by one of s (for
1286 seconds), m (for minutes), h (for hours), d (for days), or w
1287 (for weeks). By default scalars are included in the notifica‐
1288 tion that specify the how often the notification will be sent
1289 (unless the -p option is specified) and which message number of
1290 how many messages a particular notification is (unless -m is
1291 specified). To break the notifications into manageable packet
1292 sizes, use the -s flag to specify the approximate maximum number
1293 of bytes that a notification message should be limited to. If
1294 more than MAXSIZE of bytes is needed then multiple notifications
1295 will be sent to deliver the data. Note that the calculations
1296 for ensuring the maximum size is met are approximations and thus
1297 it can be absolutely guaranteed they'll be under that size, so
1298 leave a padding buffer if it is critical that you avoid fragmen‐
1299 tation. A value of -1 indicates force everything into a single
1300 message no matter how big it is.
1301 Example usage: the following will deliver the contents of the
1303 ifTable once an hour and the contents of the system group once
1304 every 2 hours:
1305 deliverByNotify 3600 ifTable
1307 deliverByNotify 7200 system
1308 deliverByNotifyMaxPacketSize SIZEINBYTES
1310 Sets the default notification size limit (see the -s flag
1311 above).
1312 deliverByNotifyOid OID
1314 deliverByNotifyFrequencyOid OID
1316 deliverByNotifyMessageNumberOid OID
1318 deliverByNotifyMaxMessageNumberOid OID
1320 These set the data OID that the notification will be sent under,
1321 the scalar OID, the message number OID, and the maximum message
1322 number OID. These default to objects in the NET-SNMP-PERI‐
1323 ODIC-NOTIFY-MIB.
1324
1326 One of the first distinguishing features of the original UCD suite was
1327 the ability to extend the functionality of the agent - not just by
1328 recompiling with code for new MIB modules, but also by configuring the
1329 running agent to report additional information. There are a number of
1330 techniques to support this, including:
1331 · running external commands (exec, extend, pass)
1333 · loading new code dynamically (embedded perl, dlmod)
1335 · communicating with other agents (proxy, SMUX, AgentX)
1337 Arbitrary Extension Commands
1339 The earliest extension mechanism was the ability to run arbitrary com‐
1340 mands or shell scripts. Such commands do not need to be aware of SNMP
1341 operations, or conform to any particular behaviour - the MIB structures
1342 are designed to accommodate any form of command output. Use of this
1343 mechanism requires that the agent was built with support for the
1344 ucd-snmp/extensible and/or agent/extend modules (which are both
1345 included as part of the default build configuration).
1346 exec [MIBOID] NAME PROG ARGS
1348 sh [MIBOID] NAME PROG ARGS
1350 invoke the named PROG with arguments of ARGS. By default the
1351 exit status and first line of output from the command will be
1352 reported via the extTable, discarding any additional output.
1353 Note: Entries in this table appear in the order they are read
1355 from the configuration file. This means that adding new
1356 exec (or sh) directives and restarting the agent, may
1357 affect the indexing of other entries.
1358 The PROG argument for exec directives must be a full path to a
1360 real binary, as it is executed via the exec() system call. To
1361 invoke a shell script, use the sh directive instead.
1362 If MIBOID is specified, then the results will be rooted at this
1364 point in the OID tree, returning the exit statement as
1365 MIBOID.100.0 and the entire command output in a pseudo-table
1366 based at MIBNUM.101 - with one 'row' for each line of output.
1367 Note: The layout of this "relocatable" form of exec (or sh)
1369 output does not strictly form a valid MIB structure.
1370 This mechanism is being deprecated - please see the
1371 extend directive (described below) instead.
1372 The agent does not cache the exit status or output of the exe‐
1374 cuted program.
1375 execfix NAME PROG ARGS
1377 registers a command that can be invoked on demand - typically to
1378 respond to or fix errors with the corresponding exec or sh
1379 entry. When the extErrFix instance for a given NAMEd entry is
1380 set to the integer value of 1, this command will be called.
1381 Note: This directive can only be used in combination with a
1383 corresponding exec or sh directive, which must be defined
1384 first. Attempting to define an unaccompanied execfix
1385 directive will fail.
1386 exec and sh extensions can only be configured via the snmpd.conf file.
1388 They cannot be set up via SNMP SET requests.
1389 extend [-cacheTime TIME] [-execType TYPE] [MIBOID] NAME PROG ARGS
1391 works in a similar manner to the exec directive, but with a num‐
1392 ber of improvements. The MIB tables (nsExtendConfigTable etc)
1393 are indexed by the NAME token, so are unaffected by the order in
1394 which entries are read from the configuration files. There are
1395 two result tables - one (nsExtendOutput1Table) containing the
1396 exit status, the first line and full output (as a single string)
1397 for each extend entry, and the other (nsExtendOutput2Table) con‐
1398 taining the complete output as a series of separate lines.
1399 If -cacheTime is specified, then its argument is used as the
1401 cache timeout (in whole seconds) for this extend entry. This
1402 mechanism provides a non-volatile way to specify the cache time‐
1403 out.
1404 If -execType is specified and has a value of sh, then this
1406 extend entry will be run in a shell. Otherwise it will be run in
1407 the default exec fashion. This mechanism provides a non-volatile
1408 way to specify the exec type.
1409 If MIBOID is specified, then the configuration and result tables
1411 will be rooted at this point in the OID tree, but are otherwise
1412 structured in exactly the same way. This means that several sep‐
1413 arate extend directives can specify the same MIBOID root, with‐
1414 out conflicting.
1415 The exit status and output is cached for each entry individu‐
1417 ally, and can be cleared (and the caching behaviour configured)
1418 using the nsCacheTable.
1419 extendfix NAME PROG ARGS
1421 registers a command that can be invoked on demand, by setting
1422 the appropriate nsExtendRunType instance to the value run-com‐
1423 mand(3). Unlike the equivalent execfix, this directive does not
1424 need to be paired with a corresponding extend entry, and can
1425 appear on its own.
1426 Both extend and extendfix directives can be configured dynamically,
1428 using SNMP SET requests to the NET-SNMP-EXTEND-MIB.
1429 MIB-Specific Extension Commands
1431 The first group of extension directives invoke arbitrary commands, and
1432 rely on the MIB structure (and management applications) having the
1433 flexibility to accommodate and interpret the output. This is a conve‐
1434 nient way to make information available quickly and simply, but is of
1435 no use when implementing specific MIB objects, where the extension must
1436 conform to the structure of the MIB (rather than vice versa). The
1437 remaining extension mechanisms are all concerned with such MIB-specific
1438 situations - starting with "pass-through" scripts. Use of this mecha‐
1439 nism requires that the agent was built with support for the
1440 ucd-snmp/pass and ucd-snmp/pass_persist modules (which are both
1441 included as part of the default build configuration).
1442 pass [-p priority] MIBOID PROG
1444 will pass control of the subtree rooted at MIBOID to the speci‐
1445 fied PROG command. GET and GETNEXT requests for OIDs within
1446 this tree will trigger this command, called as:
1447 PROG -g OID
1449 PROG -n OID
1451 respectively, where OID is the requested OID. The PROG command
1453 should return the response varbind as three separate lines
1454 printed to stdout - the first line should be the OID of the
1455 returned value, the second should be its TYPE (one of the text
1456 strings integer, gauge, counter, timeticks, ipaddress, objectid,
1457 octet, or string ), and the third should be the value itself.
1458 (Note: octets are sent as ASCII, space-separated hex strings,
1459 e.g. "00 3f dd 00 c6 be".)
1460 If the command cannot return an appropriate varbind - e.g the
1462 specified OID did not correspond to a valid instance for a GET
1463 request, or there were no following instances for a GETNEXT -
1464 then it should exit without producing any output. This will
1465 result in an SNMP noSuchName error, or a noSuchInstance excep‐
1466 tion.
1467 Note: The SMIv2 type counter64 and SNMPv2 noSuchObject
1469 exception are not supported.
1470 A SET request will result in the command being called as:
1472 PROG -s OID TYPE VALUE
1474 where TYPE is one of the tokens listed above, indicating the
1476 type of the value passed as the third parameter.
1477 If the assignment is successful, the PROG command should exit
1479 without producing any output. Errors should be indicated by
1480 writing one of the strings not-writable, or wrong-type to std‐
1481 out, and the agent will generate the appropriate error response.
1482 Note: The other SNMPv2 errors are not supported.
1484 In either case, the command should exit once it has finished
1486 processing. Each request (and each varbind within a single
1487 request) will trigger a separate invocation of the command.
1488 The default registration priority is 127. This can be changed
1490 by supplying the optional -p flag, with lower priority registra‐
1491 tions being used in preference to higher priority values.
1492 pass_persist [-p priority] MIBOID PROG
1494 will also pass control of the subtree rooted at MIBOID to the
1495 specified PROG command. However this command will continue to
1496 run after the initial request has been answered, so subsequent
1497 requests can be processed without the startup overheads.
1498 Upon initialization, PROG will be passed the string "PING\n" on
1500 stdin, and should respond by printing "PONG\n" to stdout.
1501 For GET and GETNEXT requests, PROG will be passed two lines on
1503 stdin, the command (get or getnext) and the requested OID. It
1504 should respond by printing three lines to stdout - the OID for
1505 the result varbind, the TYPE and the VALUE itself - exactly as
1506 for the pass directive above. If the command cannot return an
1507 appropriate varbind, it should print print "NONE\n" to stdout
1508 (but continue running).
1509 For SET requests, PROG will be passed three lines on stdin, the
1511 command (set) and the requested OID, followed by the type and
1512 value (both on the same line). If the assignment is successful,
1513 the command should print "DONE\n" to stdout. Errors should be
1514 indicated by writing one of the strings not-writable,
1515 wrong-type, wrong-length, wrong-value or inconsistent-value to
1516 stdout, and the agent will generate the appropriate error
1517 response. In either case, the command should continue running.
1518 The registration priority can be changed using the optional -p
1520 flag, just as for the pass directive.
1521 pass and pass_persist extensions can only be configured via the
1523 snmpd.conf file. They cannot be set up via SNMP SET requests.
1524 Embedded Perl Support
1526 Programs using the previous extension mechanisms can be written in any
1527 convenient programming language - including perl, which is a common
1528 choice for pass-through extensions in particular. However the Net-SNMP
1529 agent also includes support for embedded perl technology (similar to
1530 mod_perl for the Apache web server). This allows the agent to inter‐
1531 pret perl scripts directly, thus avoiding the overhead of spawning pro‐
1532 cesses and initializing the perl system when a request is received.
1533 Use of this mechanism requires that the agent was built with support
1535 for the embedded perl mechanism, which is not part of the default build
1536 environment. It must be explicitly included by specifying the
1537 '--enable-embedded-perl' option to the configure script when the pack‐
1538 age is first built.
1539 If enabled, the following directives will be recognised:
1541 disablePerl true
1543 will turn off embedded perl support entirely (e.g. if there are
1544 problems with the perl installation).
1545 perlInitFile FILE
1547 loads the specified initialisation file (if present) immediately
1548 before the first perl directive is parsed. If not explicitly
1549 specified, the agent will look for the default initialisation
1550 file /usr/share/snmp/snmp_perl.pl.
1551 The default initialisation file creates an instance of a Net‐
1553 SNMP::agent object - a variable $agent which can be used to reg‐
1554 ister perl-based MIB handler routines.
1555 perl EXPRESSION
1557 evaluates the given expression. This would typically register a
1558 handler routine to be called when a section of the OID tree was
1559 requested:
1560 perl use Data::Dumper;
1561 perl sub myroutine { print "got called: ",Dumper(@_),"\n"; }
1562 perl $agent->register('mylink', '.1.3.6.1.8765', \&myroutine);
1563 This expression could also source an external file:
1565 perl 'do /path/to/file.pl';
1566 or perform any other perl-based processing that might be
1568 required.
1569 Dynamically Loadable Modules
1571 Most of the MIBs supported by the Net-SNMP agent are implemented as C
1572 code modules, which were compiled and linked into the agent libraries
1573 when the suite was first built. Such implementation modules can also
1574 be compiled independently and loaded into the running agent once it has
1575 started. Use of this mechanism requires that the agent was built with
1576 support for the ucd-snmp/dlmod module (which is included as part of the
1577 default build configuration).
1578 dlmod NAME PATH
1580 will load the shared object module from the file PATH (an abso‐
1581 lute filename), and call the initialisation routine init_NAME.
1582 Note: If the specified PATH is not a fully qualified filename,
1584 it will be interpreted relative to
1585 /usr/lib(64)/snmp/dlmod, and .so will be appended to the
1586 filename.
1587 This functionality can also be configured using SNMP SET requests to
1589 the UCD-DLMOD-MIB.
1590 Proxy Support
1592 Another mechanism for extending the functionality of the agent is to
1593 pass selected requests (or selected varbinds) to another SNMP agent,
1594 which can be running on the same host (presumably listening on a dif‐
1595 ferent port), or on a remote system. This can be viewed either as the
1596 main agent delegating requests to the remote one, or acting as a proxy
1597 for it. Use of this mechanism requires that the agent was built with
1598 support for the ucd-snmp/proxy module (which is included as part of the
1599 default build configuration).
1600 proxy [-Cn CONTEXTNAME] [SNMPCMD_ARGS] HOST OID [REMOTEOID]
1602 will pass any incoming requests under OID to the agent listening
1603 on the port specified by the transport address HOST. See the
1604 section LISTENING ADDRESSES in the snmpd(8) manual page for more
1605 information about the format of listening addresses.
1606 Note: To proxy the entire MIB tree, use the OID .1.3 (not the
1608 top-level .1)
1609 The SNMPCMD_ARGS should provide sufficient version and administrative
1611 information to generate a valid SNMP request (see snmpcmd(1)).
1612 Note: The proxied request will not use the administrative settings
1614 from the original request.
1615 If a CONTEXTNAME is specified, this will register the proxy delegation
1617 within the named context in the local agent. Defining multiple proxy
1618 directives for the same OID but different contexts can be used to query
1619 several remote agents through a single proxy, by specifying the appro‐
1620 priate SNMPv3 context in the incoming request (or using suitable con‐
1621 figured community strings - see the com2sec directive).
1622 Specifying the REMOID parameter will map the local MIB tree rooted at
1624 OID to an equivalent subtree rooted at REMOID on the remote agent.
1625 SMUX Sub-Agents
1627 The Net-SNMP agent supports the SMUX protocol (RFC 1227) to communicate
1628 with SMUX-based subagents (such as gated, zebra or quagga). Use of
1629 this mechanism requires that the agent was built with support for the
1630 smux module, which is not part of the default build environment, and
1631 must be explicitly included by specifying the '--with-mib-modules=smux'
1632 option to the configure script when the package is first built.
1633 Note: This extension protocol has been officially deprecated in
1635 favour of AgentX (see below).
1636 smuxpeer OID PASS
1638 will register a subtree for SMUX-based processing, to be authen‐
1639 ticated using the password PASS. If a subagent (or "peer") con‐
1640 nects to the agent and registers this subtree then requests for
1641 OIDs within it will be passed to that SMUX subagent for process‐
1642 ing.
1643 A suitable entry for an OSPF routing daemon (such as gated,
1645 zebra or quagga) might be something like
1646 smuxpeer .1.3.6.1.2.1.14 ospf_pass
1647 smuxsocket <IPv4-address>
1649 defines the IPv4 address for SMUX peers to communicate with the
1650 Net-SNMP agent. The default is to listen on all IPv4 interfaces
1651 ("0.0.0.0"), unless the package has been configured with
1652 "--enable-local-smux" at build time, which causes it to only
1653 listen on 127.0.0.1 by default. SMUX uses the well-known TCP
1654 port 199.
1655 Note the Net-SNMP agent will only operate as a SMUX master agent. It
1657 does not support acting in a SMUX subagent role.
1658 AgentX Sub-Agents
1660 The Net-SNMP agent supports the AgentX protocol (RFC 2741) in both mas‐
1661 ter and subagent roles. Use of this mechanism requires that the agent
1662 was built with support for the agentx module (which is included as part
1663 of the default build configuration), and also that this support is
1664 explicitly enabled (e.g. via the snmpd.conf file).
1665 There are two directives specifically relevant to running as an AgentX
1667 master agent:
1668 master agentx
1670 will enable the AgentX functionality and cause the agent to
1671 start listening for incoming AgentX registrations. This can
1672 also be activated by specifying the '-x' command-line option (to
1673 specify an alternative listening socket).
1674 agentXPerms SOCKPERMS [DIRPERMS [USER|UID [GROUP|GID]]]
1676 Defines the permissions and ownership of the AgentX Unix Domain
1677 socket, and the parent directories of this socket. SOCKPERMS
1678 and DIRPERMS must be octal digits (see chmod(1) ). By default
1679 this socket will only be accessible to subagents which have the
1680 same userid as the agent.
1681 There is one directive specifically relevant to running as an AgentX
1683 sub-agent:
1684 agentXPingInterval NUM
1686 will make the subagent try and reconnect every NUM seconds to
1687 the master if it ever becomes (or starts) disconnected.
1688 The remaining directives are relevant to both AgentX master and sub-
1690 agents:
1691 agentXSocket [<transport-specifier>:]<transport-address>[,...]
1693 defines the address the master agent listens at, or the subagent
1694 should connect to. The default is the Unix Domain socket
1695 "/var/agentx/master". Another common alternative is tcp:local‐
1696 host:705. See the section LISTENING ADDRESSES in the snmpd(8)
1697 manual page for more information about the format of addresses.
1698 Note: Specifying an AgentX socket does not automatically enable
1700 AgentX functionality (unlike the '-x' command-line
1701 option).
1702 agentXTimeout NUM
1704 defines the timeout period (NUM seconds) for an AgentX request.
1705 Default is 1 second. NUM also be specified with a suffix of one
1706 of s (for seconds), m (for minutes), h (for hours), d (for
1707 days), or w (for weeks).
1708 agentXRetries NUM
1710 defines the number of retries for an AgentX request. Default is
1711 5 retries.
1712 net-snmp ships with both C and Perl APIs to develop your own AgentX
1714 subagent.
1715
1717 override [-rw] OID TYPE VALUE
1718 This directive allows you to override a particular OID with a
1719 different value (and possibly a different type of value). The
1720 -rw flag will allow snmp SETs to modify it's value as well.
1721 (note that if you're overriding original functionality, that
1722 functionality will be entirely lost. Thus SETS will do nothing
1723 more than modify the internal overridden value and will not per‐
1724 form any of the original functionality intended to be provided
1725 by the MIB object. It's an emulation only.) An example:
1726 override sysDescr.0 octet_str "my own sysDescr"
1728 That line will set the sysDescr.0 value to "my own sysDescr" as
1730 well as make it modifiable with SNMP SETs as well (which is
1731 actually illegal according to the MIB specifications).
1732 Note that care must be taken when using this. For example, if
1734 you try to override a property of the 3rd interface in the
1735 ifTable with a new value and later the numbering within the
1736 ifTable changes it's index ordering you'll end up with problems
1737 and your modified value won't appear in the right place in the
1738 table.
1739 Valid TYPEs are: integer, uinteger, octet_str, object_id,
1741 counter, null (for gauges, use "uinteger"; for bit strings, use
1742 "octet_str"). Note that setting an object to "null" effectively
1743 delete's it as being accessible. No VALUE needs to be given if
1744 the object type is null.
1745 More types should be available in the future.
1747 If you're trying to figure out aspects of the various mib modules (pos‐
1749 sibly some that you've added yourself), the following may help you spit
1750 out some useful debugging information. First off, please read the
1751 snmpd manual page on the -D flag. Then the following configuration
1752 snmpd.conf token, combined with the -D flag, can produce useful output:
1753 injectHandler HANDLER modulename [beforeThis]
1755 This will insert new handlers into the section of the mib tree
1756 referenced by "modulename". If "beforeThis" is specified then
1757 the module will be injected before the named module. This is
1758 useful for getting a handler into the exact right position in
1759 the chain.
1760 The types of handlers available for insertion are:
1762 stash_cache
1764 Caches information returned from the lower level. This
1765 greatly help the performance of the agent, at the cost of
1766 caching the data such that its no longer "live" for 30
1767 seconds (in this future, this will be configurable).
1768 Note that this means snmpd will use more memory as well
1769 while the information is cached. Currently this only
1770 works for handlers registered using the table_iterator
1771 support, which is only a few mib tables. To use it, you
1772 need to make sure to install it before the table_iterator
1773 point in the chain, so to do this:
1774 injectHandler stash_cache NAME table_iterator
1776 If you want a table to play with, try walking the nsMod‐
1778 uleTable with and without this injected.
1779 debug Prints out lots of debugging information when the
1782 -Dhelper:debug flag is passed to the snmpd application.
1783 read_only
1786 Forces turning off write support for the given module.
1787 serialize
1790 If a module is failing to handle multiple requests prop‐
1791 erly (using the new 5.0 module API), this will force the
1792 module to only receive one request at a time.
1793 bulk_to_next
1796 If a module registers to handle getbulk support, but for
1797 some reason is failing to implement it properly, this
1798 module will convert all getbulk requests to getnext
1799 requests before the final module receives it.
1800 dontLogTCPWrappersConnects
1802 If the snmpd was compiled with TCP Wrapper support, it logs
1803 every connection made to the agent. This setting disables the
1804 log messages for accepted connections. Denied connections will
1805 still be logged.
1806 Figuring out module names
1808 To figure out which modules you can inject things into, run snm‐
1809 pwalk on the nsModuleTable which will give a list of all named
1810 modules registered within the agent.
1811 Internal Data tables
1813 table NAME
1814 add_row NAME INDEX(ES) VALUE(S)
1816
1818 o The Net-SNMP agent can be instructed to re-read the various con‐
1819 figuration files, either via an snmpset assignment of integer(1)
1820 to UCD-SNMP-MIB::versionUpdateConfig.0
1821 (.1.3.6.1.4.1.2021.100.11.0), or by sending a kill -HUP signal
1822 to the agent process.
1823 o All directives listed with a value of "yes" actually accept a
1825 range of boolean values. These will accept any of 1, yes or
1826 true to enable the corresponding behaviour, or any of 0, no or
1827 false to disable it. The default in each case is for the fea‐
1828 ture to be turned off, so these directives are typically only
1829 used to enable the appropriate behaviour.
1830
1832 See the EXAMPLE.CONF file in the top level source directory for a more
1833 detailed example of how the above information is used in real examples.
1834
1836 /etc/snmp/snmpd.conf
1837
1839 snmpconf(1), snmpusm(1), snmp.conf(5), snmp_config(5), snmpd(8), EXAM‐
1840 PLE.conf, netsnmp_config_api(3).
1841V5.8 30 Jun 2010 SNMPD.CONF(5)