SNMPD.CONF(5)

📦

version 5.9.5.2 · 14 versions

💖 NAME 💖

okay bestie, so like — this is the manual page for snmpd.conf, and it's literally the configuration file for the Net-SNMP SNMP agent. that's the whole name. short and iconic. 💅

✨ DESCRIPTION ✨

so here's the vibe: the Net-SNMP agent reads one or more configuration files to control how it operates and what management information it actually hands out. these files are snmpd.conf and snmpd.local.conf, and they can live in one of several locations — all described over in the snmp_config(5) manual page if you wanna go read that too. 🦋

also, there's this (perl) application called snmpconf that can literally generate config files for the most common agent requirements. see the snmpconf(1) manual page for more info, or just try running this:

snmpconf -g basic_setup

like, go on. it's right there. ✨

there are a large number of directives you can specify, but honestly they mostly fall into four distinct categories:

🫶 those controlling who can access the agent
🫶 those configuring the information that is supplied by the agent
🫶 those controlling active monitoring of the local system
🫶 those concerned with extending the functionality of the agent

some directives don't fall naturally into any of these four categories, but ngl this covers the majority of what's in a typical snmpd.conf file. and if you want the full list of recognised directives, run this:

snmpd -H

👑 AGENT BEHAVIOUR 👑

so most configuration directives are all about the MIB information the agent supplies, right? but there's a handful of directives that control the behaviour of snmpd when you think of it simply as a daemon providing a network service. those are the ones we're doing here. periodt. 💅

agentaddress [<transport-specifier>:]<transport-address>[,...] — defines a list of listening addresses where incoming SNMP requests get received. see the section LISTENING ADDRESSES in the snmpd(8) manual page for more info 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 can 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 can 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. lowkey equivalent to specifying -U on the command line. 💀
maxGetbulkRepeats NUM — sets the maximum number of responses allowed for a single variable in a getbulk request. set it to 0 to enable the default, and set it to -1 to enable unlimited. but — because memory is allocated ahead of time, setting this to unlimited is not considered safe if your user population can not be trusted. a repeat number greater than this gets 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 it to 0 to enable the default, and set it to -1 to enable unlimited. again: because memory is allocated ahead of time, setting 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 maxGetbulkResponses number, and the total number returned will be an integer multiple of the number of variables requested times the calculated number of repeats allowed to fit below this number.

also note that the processing of maxGetbulkRepeats is handled first. it's giving pipeline energy.

ifmib_max_num_ifaces NUM — sets the maximum number of interfaces included in IF-MIB data collection. for servers with a lot of interfaces (ppp, dummy, bridge, etc) the IF-MIB processing will take a large chunk of CPU for ioctl calls (on Linux). setting a reasonable maximum for the CPU used will reduce the CPU load for IF-MIB processing. for example, configuring "ifmib_max_num_ifaces 500" will include only the first 500 interfaces based on ifindex and ignore all others for IF-MIB processing. the default (without this configured) is to include all interfaces. 🔥
include_ifmib_iface_prefix PREFIX1 PREFIX2 ... — sets the interface name prefixes to include in the IF-MIB data collection. for servers with a large number of interfaces (ppp, dummy, bridge, etc) the IF-MIB processing will take a large chunk of CPU for ioctl calls (on Linux). a set of space-separated interface name prefixes will reduce the CPU load for IF-MIB processing. for example, configuring "include_ifmib_iface_prefix eth dummy lo" will include only interfaces with these prefixes and ignore all others for IF-MIB processing. if regex support is compiled in, each of the prefixes is a regular expression (which is not permitted to contain a space or tab character). the default (without this configured) is to include all interfaces. 🌸

🔐 SNMPv3 Configuration - Real Security 🔐

okay so this is the good part. SNMPv3 added flexible security models to the SNMP packet structure so that multiple security solutions could be used. SNMPv3 was originally defined with a "User-based Security Model" (USM) [RFC3414] that required maintaining an SNMP-specific user database. this was later determined to be troublesome to maintain and had some minor security issues. 😬

the IETF has since added additional security models to tunnel SNMP over SSH [RFC5592] and DTLS/TLS [RFC-to-be]. Net-SNMP contains robust support for SNMPv3/USM, SNMPv3/TLS, and SNMPv3/DTLS. it contains partial support for SNMPv3/SSH as well but has not been as extensively tested. it also contains code for support for an experimental Kerberos-based SNMPv3 that never got standardized. 💀

hopefully, more SNMP software and devices will eventually support SNMP over (D)TLS or SSH, but it is likely that devices with original support for SNMP will only contain support for USM users. if your network manager supports SNMP over (D)TLS or SNMP over SSH we suggest you use one of these mechanisms instead of using USM — but as always with Net-SNMP we give you the options to pick from so you can make the choice that is best for you. 🫶

🧚 SNMPv3 generic parameters 🧚

these parameters are generic to all the forms of SNMPv3. the SNMPv3 protocol defines "engineIDs" that uniquely identify an agent. the string must be consistent through time and should not change or conflict with another agent's engineID. Ever. 😤

internally, Net-SNMP by default creates a unique engineID that is based off of the current system time and a random number. this should be sufficient for most users unless you're embedding our agent in a device where these numbers won't vary between boxes on the device's initial boot.

EngineIDs are used both as a "context" for selecting information from the device and SNMPv3 with USM uses it to create unique entries for users in its user table.

the Net-SNMP agent offers the following mechanisms for setting the engineID, but again you should only use them if you know what you're doing:

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 network 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. 🎀

🦋 SNMPv3 over TLS 🦋

SNMPv3 may be tunneled over TLS and DTLS. TLS runs over TCP and DTLS is the UDP equivalent. Wes Hardaker (the founder of Net-SNMP) performed a study and presented it at an IETF meeting that showed that TCP-based protocols are sufficient for stable networks but quickly become a problem in unstable networks with even moderate levels of packet loss (~ 20-30%). 😭

if you are going to use TLS or DTLS, you should use the one appropriate for your networking environment. you should potentially turn them both on so your management system can access either the UDP or the TCP port as needed. iykyk. 💅

many of the configuration tokens described below are prefixed with a '[snmp]' tag. if you place these tokens in your snmpd.conf file, this tag is required. see the snmp_config(5) manual page for the meaning of this context switch.

[snmp] localCert <specifier> — this token defines the default X.509 public key to use as the server's identity. it should either be a fingerprint or a filename. to create a public key for use, please run the "net-snmp-cert" utility which will help you create the required certificate. the default value for this is the certificate in the "snmpd" named certificate file. 🔑
[snmp] tlsAlgorithms <algorithms> — this string will select the algorithms to use when negotiating security during (D)TLS session establishment. see the openssl manual page ciphers(1) for details on the format. example strings include:

DEFAULT
ALL
HIGH
HIGH:!AES128-SHA

the default value is whatever openssl itself was configured with. 🌈

[snmp] x509CRLFile — if you are using a Certificate Authority (CA) that publishes a Certificate Revocation List (CRL) then this token can be used to specify the location in the filesystem of a copy of the CRL file. note that Net-SNMP will not pull a CRL over http and this must be a file, not a URL. additionally, OpenSSL does not reload a CRL file when it has changed so modifications or updates to the file will only be noticed upon a restart of the snmpd agent. ⚠️
certSecName PRIORITY FINGERPRINT OPTIONS — OPTIONS can be one of <--sn SECNAME | --rfc822 | --dns | --ip | --cn | --any>. 🎀

The certSecName token is the ✨glow-up✨ moment where you tell snmpd how to map a field from the client's X.509 certificate into an SNMPv3 username. Use the --sn SECNAME flag to directly specify a securityName for a given certificate. The other flags extract a particular component of the certificate for use as an SNMPv3 securityName — those fields are one of: a SubjectAltName containing an rfc822 value (eg hardaker@net-snmp.org), a SubjectAltName containing a dns name value (eg foo.net-snmp.org), an IP address (eg 192.0.2.1) or a common name "Wes Hardaker". The --any flag says any of the subjectAltName fields may be used, whatever's vibing. Big heads-up bestie: once a securityName has been selected, make sure it's actually given authorization via the VACM controls discussed later in this manual page — otherwise it's just a cute name with no permissions 😭

See the http://www.net-snmp.org/wiki/index.php/Using_DTLS web page for more detailed instructions for setting up (D)TLS 💖

trustCert <specifier> — for X509 to properly verify a certificate, it should be verifiable up until a trust anchor for it. This trust anchor is typically a CA certificate but it could also be a self-signed certificate. The trustCert token should be used to load specific trust anchors into the verification engine. It's giving "chain of trust, but make it explicit" 🔥

SNMP over (D)TLS requires the use of the Transport Security Model (TSM), so read the section on the usage of the Transport Security Model as well 👀 Make sure when you configure the VACM to accept connections from (D)TLS that you use the "tsm" security model. E.G.:

rwuser -s tsm hardaker@net-snmp.org

🦋 SNMPv3 over SSH Support 🦋

To use SSH, you'll need to configure sshd to invoke the sshtosnmp program as well as configure the access control settings to allow access through the tsm security model using the user name provided to snmpd by the ssh transport. Two steps, both required, no skipping 🌸

👑 SNMPv3 with the Transport Security Model (TSM) 👑

The Transport Security Model [RFC5591] defines an SNMPv3 security system for use with "tunneled" security protocols like TLS, DTLS and SSH. It's a very simple security model that simply lets properly protected packets pass through into the snmp application. The transport is required to pass a securityName to use to the TSM and the TSM may optionally prefix this with a transport string (see below). Lowkey elegant tbh.

tsmUseTransportPrefix (1|yes|true|0|no|false) — if set to true, the TSM module will take every securityName passed to it from the transports underneath and prefix it with a string that specifically identities the transport it came from. This is useful to avoid securityName clashes with transports that generate identical security names. For example, if the ssh security transport delivered the security name of "hardaker" for a SSH connection and the TLS security transport also delivered the security name of "hardaker" for a TLS connection then it would be impossible to separate out these two users to provide separate access control rights. With the tsmUseTransportPrefix set to true, however, the securityNames would be prefixed appropriately with one of: "tls:", "dtls:" or "ssh:". Problem: solved. Vibe: immaculate. 💅

🎀 SNMPv3 with the User-based Security Model (USM) 🎀

SNMPv3 was originally defined using the User-Based Security Model (USM), which contains a private list of users and keys specific to the SNMPv3 protocol. The operational community, however, declared it a pain to manipulate yet another database and would prefer to use existing infrastructure. To that end the IETF created the ISMS working group to battle that problem, and the ISMS working group decided to tunnel SNMP over SSH and DTLS to make use existing user and authentication infrastructures. Reuse existing infra, slay. ✨

🍓 SNMPv3 USM Users 🍓

To use the USM based SNMPv3-specific users, you'll need to create them. It is recommended you use the net-snmp-config command to do this, but you can also do it by directly specifying createUser directives yourself instead:

createUser [-e ENGINEID] username
(MD5|SHA|SHA-512|SHA-384|SHA-256|SHA-224) authpassphrase [DES|AES]
[privpassphrase]

MD5|SHA|SHA-512|SHA-384|SHA-256|SHA-224 are the authentication types to use. DES and AES are the privacy protocols 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|SHA-512|SHA-384|SHA-256|SHA-224 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. Old reliable MD5, we see you 💀

⚠️ Warning: the minimum pass phrase length is 8 characters. Do not test the universe on this one, bestie.

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. Honestly? Just do this. 🫶

This directive should be placed into the /var/lib/net-snmp/snmpd.conf file instead of the other normal locations. The reason is that the information is read from the file and then the line is removed (eliminating the storage of the master password for that user) and replaced with the key that is derived from it. This key is a localized key, so that if it is stolen it can not be used to access other agents. If the password is stolen, however, it can be. Read that twice. Localized key theft = contained. Password theft = not contained. 😭

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 (preceded 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 algorithm, not the length required by the encrypting algorithm (MD5: 16 bytes, SHA: 20 bytes). Lengths matter, ok? 📏

🔐 ACCESS CONTROL 🔐

snmpd supports the View-Based Access Control Model (VACM) as defined in RFC 2575, to control who can retrieve or update information. To this end, it recognizes various directives relating to access control. Basically: who gets to peek, and who gets to touch 👀

🌈 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 [-s SECMODEL] USER [noauth|auth|priv [OID | -V VIEW [CONTEXT]]]

rwuser [-s SECMODEL]  USER [noauth|auth|priv [OID | -V VIEW [CONTEXT]]]

rouser / rwuser — 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.

If SECMODEL is specified then it will be the security model required for that user (note that identical user names may come in over different security models and will be appropriately separated via the access control settings). The default security model is "usm" and the other common security models are likely "tsm" when using (D)TLS or SSH support and "ksm" if the Kerberos support has been compiled in. Same name, different model, different access — the VACM keeps them apart, no cap. 💅

rocommunity COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]

rwcommunity COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]

rocommunity / rwcommunity — specify an SNMPv1 or SNMPv2c community 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 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]]]

rocommunity6 / rwcommunity6 — 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. Same energy, v6 edition. 🦋

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 community-based directives. Pick one. Don't stack them. rwuser already ate rouser's whole flow. 🫶

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 mechanisms. 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. iykyk — when the simple stuff stops scaling, go to the big VACM directives. ✨

🌸 VACM Configuration

Okay bestie, so here's where it gets real. You can have the full, unhinged flexibility of the VACM using just four directives — com2sec, group, view and access. These literally give you direct config of the underlying VACM tables. No middleman, no vibe check, just tables. 💅

com2sec [-Cn CONTEXT] SECNAME SOURCE COMMUNITY
com2sec6 [-Cn CONTEXT] SECNAME SOURCE COMMUNITY

These map an SNMPv1 or SNMPv2c community string to a security name — either from a particular range of source addresses, or globally ("default"). A restricted source can 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. A restriction preceded by an exclamation mark (!) denies access from that address or subnet, e.g. !10.10.10.0/24 denies requests from sources in that subnet. Deny restrictions must be before permit. So like, the following example permits access from all of 10.0.0.0/8 except for 10.10.10.0/24:

com2sec sec1 !10.10.10.0/24 public
com2sec sec1 10.0.0.0/8 public

Access from outside of 10.0.0.0/8 would still be denied. 🙅‍♀️

The same community string can be specified in several separate directives (presumably with different source tokens), and the first source/community combination that matches the incoming request will be selected. Various source/community combinations 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. Same energy, different socket. 🧦

group GROUP {v1|v2c|usm|tsm|ksm} 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: 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. Yes, two. Not me making the rules, I'm just the messenger. 😭

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 sensitive objects from an otherwise accessible subtree). Iconic little security move honestly. 🫶

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 specified, 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 skipping the column subidentifier:

view ifRow4 included .1.3.6.1.2.1.2.2.1.0.4  0xff:a0

Heads up bestie: a mask longer than 8 bits must use : to separate the individual octets. That's the whole rule. Don't come for me. 💀

access GROUP CONTEXT {any|v1|v2c|usm|tsm|ksm} LEVEL PREFX READ WRITE NOTIFY

maps from a group of users/communities (with a particular security model and minimum 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 (although the NOTIFY view is not currently used — she's listed but she's not on stage, iykyk). For v1 or v2c access, LEVEL will need to be noauth.

🦋 Typed-View Configuration

The final group of directives extends 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 subtree (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. Otherwise 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 context (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. Bestie, this is your moment. 👑

🎀 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 writable via suitably authorized SNMP SET requests. However, specifying one of these directives makes the corresponding object read-only and attempts to SET it will result in a notWritable error response. So like, you get what you asked for but it's locked now. 🔒

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. Lowkey handy fr. 🫶

🧚 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).

interface_fadeout TIMEOUT

specifies, for how long the agent keeps entries in ifTable after appropriate interfaces have been removed from system (typically various ppp, tap or tun interfaces). Timeout value is in seconds. Default value is 300 (=5 minutes).

interface_replace_old yes

can be used to remove already existing entries in ifTable when an interface with the same name appears on the system. E.g. when ppp0 interface is removed, it is still listed in the table for interface_fadeout seconds. This option ensures, that the old ppp0 interface is removed even before the interface_fadeout timeout when new ppp0 (with different ifIndex) shows up. She's efficient like that. 💅

💜 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 hrDiskStorageTable (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. Source-reading era, we love to see it. 😭📖

okay so the pattern can include one or more wildcard expressions. peep snmpd.examples(5) for the wildcard syntax flex 💅

ignoremount [-r] STRING — controls which mounts should be left out of hrStorageTable. if the Net-SNMP agent gets hung on accessing a filesystem, or the filesystem is always mostly full (and thus leads to spurious alerts), you can omit it by listing the full path in this directive. if the -r option is provided, the pattern can include one or more regular expressions.
skipNFSInHostResources true — controls whether NFS and NFS-like file systems should be omitted from hrStorageTable (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. alternately, more granular control over which mounts should be omitted from hrStorageTable can be achieved via the ignoremount directive.
storageUseNFS [1|2] — controls how NFS and NFS-like file systems should be reported in hrStorageTable 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 ´Network Disks', as required by the Host Resources MIB.
realStorageUnits — controls how the agent reports hrStorageAllocationUnits, hrStorageSize and hrStorageUsed in hrStorageTable. for big storage drives with small allocation units the agent re-calculates these values so they all fit Integer32 and hrStorageAllocationUnits x hrStorageSize gives real size of the storage.

Example:

Linux xfs 16TB filesystem with 4096 bytes large blocks
will be reported as  hrStorageAllocationUnits = 8192 and
hrStorageSize = 2147483647, so 8192 x 2147483647 gives
real size of the filesystem (=16 TB).

setting this directive to 1 turns off this calculation and the agent reports real hrStorageAllocationUnits, but it might report wrong hrStorageSize for big drives because the value won't fit into Integer32. in this case, hrStorageAllocationUnits x hrStorageSize won't give real size of the storage.

💻 Process Monitoring

the hrSWRun group of the Host Resources MIB provides information about individual processes 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 -acx") 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.

heads up: 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, 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"). if MAX is 0 (and MIN is not), this indicates infinity ("at least MIN"). if both MAX and MIN are 0, this indicates a process that should not be running.

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 cannot 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. disks mounted after the agent has started will not be monitored, unless includeAllDisks option is specified.

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 neither 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.

heads up: 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 (percentage) threshold. the dskTable is dynamically updated, unmounted disks disappear from the table and newly mounted disks are added to the table. the threshold for individual disks can be adjusted using suitable disk directives (which can come either before or after the includeAllDisks directive).

note: whether disk directives appear 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 from HOST-RESOURCES-MIB::hrFSTable.

if neither any disk directives or includeAllDisks are defined, then walking the dskTable will fail (noSuchObject).

🌀 Disk I/O Monitoring

this requires that the agent was built with support for the ucd-snmp/diskio module (which is not included as part of the default build configuration) 💀

by default, all block devices known to the operating system are included in the diskIOTable. on platforms other than Linux, this module has no configuration directives.

on Linux systems, it is possible to exclude several classes of block devices from the diskIOTable in order to avoid cluttering the table with useless zero statistics for pseudo-devices that often are not in use but are configured by default to exist in most recent Linux distributions ✨

diskio_exclude_fd yes — excludes all Linux floppy disk block devices, whose names start with "fd", e.g. "fd0"
diskio_exclude_loop yes — excludes all Linux loopback block devices, whose names start with "loop", e.g. "loop0"
diskio_exclude_ram yes — excludes all Linux ramdisk block devices, whose names start with "ram", e.g. "ram0"
diskio_exclude_md yes — excludes all Linux RAID block devices, whose names start with "md", e.g. "md0"

on Linux systems, it is also possible to report only explicitly whitelisted devices. it may take a significant amount of time to process diskIOTable data on systems with tens of thousands of block devices and whitelisting only the important ones avoids large CPU consumption.

diskio <device> — enables acceptlist of devices and adds the device to the acceptlist. only explicitly acceptlisted devices will be reported. this option may be used multiple times.

📈 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 associated maximum value, then the corresponding laErrorFlag instance will be set to 1, and a suitable description message reported via the laErrMessage instance.

heads up: 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 relevant laErrorFlag or laErrMessage instances, regardless of the current load.

unlike the proc and disk directives, walking the laTable will succeed (assuming 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.

heads up: 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.

heads up: this situation will not automatically trigger a trap to report the problem — see the DisMan Event MIB section later.

note: a maximum of 20 files can be monitored.

note: if no file directives are defined, then walking the fileTable will fail (noSuchObject).

okay so the logmatch directive is literally the "watch this file for me" bestie of the agent, and it goes like this:

logmatch NAME FILE CYCLETIME REGEX — monitors the specified file for occurrences of the specified pattern REGEX. The file position is stored internally, so the entire file is only read initially, and every subsequent pass only reads the new lines added to the file since the last read. 👀✨

Here's what each piece means, because we are not leaving anyone behind:

NAME — the name of the logmatch instance. It will appear as logMatchName under logMatch/logMatchTable/logMatchEntry/logMatchName in the ucd-snmp MIB tree. 🏷️
FILE — absolute path to the logfile to be monitored. Note that this path can contain date/time directives (like in the UNIX date command). See the manual page for strftime for the various directives accepted. 🗓️
CYCLETIME — time interval for each logfile read and internal variable update, in seconds. Note: an SNMPGET* operation will also trigger an immediate logfile read and variable update. ⏱️
REGEX — the regular expression to be used. Note: DO NOT enclose the regular expression in quotes even if there are spaces in the expression, as the quotes will also become part of the pattern to be matched! 🚨

Example, and yes it's iconic:

logmatch apache-GETs
/usr/local/apache/logs/access.log-%Y-%m-%d 60 GET.*HTTP.*

This logmatch instance is named 'apache-GETs', uses 'GET.*HTTP.*' as its regular expression, and it will monitor the file named (assuming today is May 6th 2009): '/usr/local/apache/logs/access.log-2009-05-06'. Tomorrow it will look for 'access.log-2009-05-07'. The logfile is read every 60 seconds. 🎀

Note: A maximum of 250 logmatch directives can be specified. That's the ceiling, bestie. 📚

Note: If no logmatch directives are defined, then walking the logMatchTable will fail (noSuchObject). So yeah, no directives means no table walk. 💀

🌸 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. Main character energy, honestly. 👑

💌 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. Order matters, bestie. 🫶
trapsink [-profile p] [-name n] [-tag t] [-s src] HOST [COMMUNITY [PORT]]
trap2sink [-profile p] [-name n] [-tag t] [-s src] HOST [COMMUNITY [PORT]]
informsink [-profile p] [-name n] [-tag t] [-s src] HOST [COMMUNITY [PORT]]

These three define the address of a notification receiver that should be sent SNMPv1 TRAPs, SNMPv2c TRAP2s, or SNMPv2 INFORM notifications respectively. See the section LISTENING ADDRESSES in the snmpd(8) manual page for more information about the format of listening addresses. If COMMUNITY is not specified, the most recent trapcommunity 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 specified via the transport specification HOST instead. We love a glow-up, but also, heads up. ⚠️

The optional name and tag parameters specify the name or tag that will be used for SNMP-NOTIFICATION-MIB table entries. The profile specifies which notification filter profile entry will be used for filtering outgoing notifications. (See notificationFilter.) 🧚

The optional src parameter specifies the source address that will be used when sending the trap packet to this sink. It is specified as a <transport-address>, using the same <transport-specifier> as the destination HOST. See the section LISTENING ADDRESSES in the snmpd(8) manual page for more information about the format. 📮

If several sink directives are specified, multiple copies of each notification (in the appropriate formats) will be generated. Yes, multiple. The agent said what it said. 💅

Note: It is not normally appropriate to list two (or all three) sink directives with the same destination. Please don't make it weird. 🙈

trapsess [-profile p] [-name n] [-tag t] [-s src] [SNMPCMD_ARGS] HOST — provides a more generic mechanism for defining notification destinations. SNMPCMD_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 unacknowledged 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. 🔥

notificationFilter NAME OID MASK TYPE — specifies a SNMP-NOTIFICATION-MIB notification filter profile, which may be used to filter traps. TYPE must be included or excluded. Some examples, because examples slay:

notificationFilter all_ok .1.3 0x00 included
notificationFilter no_coldstart .1.3 0x00 included
notificationFilter no_coldstart .1.3.6.1.6.3.1.1.5.1 0x00 excluded

trapsink -profile no_coldstart 192.168.1.3:3162 secret3

authtrapenable {1|2} — determines whether to generate authentication failure traps (enabled(1)) or not (disabled(2) — the default). Ordinarily the corresponding MIB object (snmpEnableAuthenTraps.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. So yes, it locks that down. 🔐
v1trapaddress HOST — defines the agent address, which is inserted into SNMPv1 TRAPs. An arbitrary local IPv4 address is chosen if this option is omitted. This option is mainly useful when the agent is visible from the outside world by a specific address only (e.g. because of network address translation or firewall). 🌍

🧚 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. Big brain committee vibes. 🧠✨

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. Not a big deal, but don't say nobody told you. 💀

iquerySecName NAME
agentSecName NAME

These specify 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 appropriate access rights (e.g. rouser). This directive is purely concerned with defining which user should be used — not with actually setting this user up. So don't expect it to do the whole job, bestie. 🫡

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 mteTriggerTable (and related tables). Each monitor line must have a unique NAME. Monitor lines with a duplicate name are discarded and cause snmpd to log a duplicate index complaint. Note also that such monitors use an internal SNMPv3 request to retrieve the values being monitored (even if normal agent queries typically 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. Let's break them down, because we are thorough in this group chat. 💖

🌟 `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 detected. An expression of the form != OID specifies 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 comparison 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. So put the space in, please and thank you. 🚨

🌟 `OID MIN MAX [DMIN DMAX]`

defines a threshold(2) monitor test. MIN and MAX are integer values, specifying 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. And yep, the optional DMIN DMAX are part of that signature too. 📈

Okay so back to the threshold tea ☕ — the rising threshold event only gets re-armed when the monitored value falls below the lower threshold (MIN). Same energy, opposite direction: the falling threshold event gets re-armed by the upper threshold (MAX). 💅

The optional params DMIN and DMAX set up a matching pair of similar threshold tests, but these ones work with the delta differences between successive sample values. ✨

✨ OPTIONS ✨

There are various options to control the behaviour of the monitored expression. These include:

-D — says the expression should be evaluated using delta differences between sample values (rather than the values themselves). 🌀
-d OID — specifies a discontinuity marker for validating delta differences. 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 this option and -di. This option also implies -D. 🫶
-di OID — specifies a discontinuity marker for validating delta differences. A -di object instance will be used exactly as given. If the -I flag is specified, then there is no difference between this option and -d. 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 standard 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 wildcarded object, and the monitor expanded to cover all matching instances. 💖
-i OID — defines additional varbinds to be added to the notification payload when this monitor trigger fires. For a wildcarded expression, OIDs specified using -i will be treated as exact instances. If the -I flag is specified, then there is no difference between this option and -o. See strictDisman for details of the ordering of notification payloads. 🎀
-o OID — defines 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. If the -I flag is specified, then there is no difference between this option and -i. See strictDisman for details of the ordering of notification payloads. 🦋
-r FREQUENCY — monitors the given expression every FREQUENCY, where FREQUENCY is in seconds or optionally suffixed by one of s (for seconds), m (for minutes), h (for hours), d (for days), or w (for weeks). 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 [-m] [-i OID | -o OID ]* — defines a notification event named ENAME. This can be triggered from a given monitor 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 -m 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 notification 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 payload 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 appropriate. 🔥

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, where FREQUENCY is in seconds or optionally suffixed by one of s (for seconds), m (for minutes), h (for hours), d (for days), or w (for weeks). 🔁

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 values. 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 specified by the fields MINUTE to WEEKDAY. The interpretation of these fields is exactly the same as for the cron directive. 🎀

📦 Data Delivery via Notifications 📦

Note: This functionality is only available if the deliver/deliverByNotify mib module was compiled in to the agent 🫶

In some situations it may be advantageous to deliver SNMP data over SNMP Notifications (TRAPs and INFORMs) rather than the typical process of having the manager issue requests for the data (via GETs and GETNEXTs). Reasons for doing this are numerous, but frequently corner cases. The most common reason for wanting this behaviour might be to monitor devices that reside behind NATs or Firewalls that prevent incoming SNMP traffic. 🌈

Okay so real talk about notifications, bestie: most management software is capable of logging them, but very little (if any) management software will update its "knowledge database" based on the contents of SNMP notifications. IE, it won't — for example — update the interface traffic counter history that is used to produce graphs. Most larger network management packages have a separate database for storing data received via SNMP requests (GETs and GETNEXTs) vs those received from notifications. Researching the capabilities of your management station software is required before assuming this functionality will solve your data delivery requirements.

Notifications generated via this mechanism will be sent to the standard set of configured notification targets. See the "Notification Handling" section of this document for further information.

deliverByNotify [-p] [-m] [-s MAXSIZE] FREQUENCY OID — tells the SNMP agent to self-walk the OID, collect all the data, and send it out every FREQUENCY seconds. FREQUENCY is in seconds or optionally suffixed by one of s (for seconds), m (for minutes), h (for hours), d (for days), or w (for weeks). By default, scalars are included in the notification that specify how often the notification will be sent (unless the -p option is specified) and which message number of how many messages a particular notification is (unless -m is specified). To break the notifications into manageable packet sizes, use the -s flag to specify the approximate maximum number of bytes that a notification message should be limited to. If more than MAXSIZE of bytes is needed then multiple notifications will be sent to deliver the data.

Heads up: the calculations for ensuring the maximum size is met are approximations, and thus it can be absolutely guaranteed they'll be under that size — so leave a padding buffer if it is critical that you avoid fragmentation. A value of -1 indicates force everything into a single message no matter how big it is.

Example usage: the following will deliver the contents of the ifTable once an hour and the contents of the system group once every 2 hours:

deliverByNotify 3600 ifTable
deliverByNotify 7200 system

deliverByNotifyMaxPacketSize SIZEINBYTES — sets the default notification size limit (see the -s flag above).
deliverByNotifyOid OID — sets the data OID that the notification will be sent under.
deliverByNotifyFrequencyOid OID — sets the scalar OID.
deliverByNotifyMessageNumberOid OID — sets the message number OID.
deliverByNotifyMaxMessageNumberOid OID — sets the maximum message number OID.

These default to objects in NET-SNMP-PERIODIC-NOTIFY-MIB.

🌸 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 modules, but also by configuring the running agent to report additional information. There are a number of techniques to support this, including:

running external commands (exec, extend, pass)
loading new code dynamically (embedded perl, dlmod)
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 particular 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 — 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. 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.
sh [MIBOID] NAME PROG ARGS — same invoke-the-named-PROG-with-ARGS situation, but for shell scripts; same default extTable reporting of exit status and first line, with extra output discarded.

Note: entries in this table appear in the order they are read from the configuration file. This means that adding new exec (or sh) directives and restarting the agent, may affect the indexing of other entries.

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.

The agent does not cache the exit status or output of the executed program.

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 unaccompanied 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 [-cacheTime TIME] [-execType TYPE] [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 status, 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 separate lines.
- If -cacheTime is specified, then its argument is used as the cache timeout (in whole seconds) for this extend entry. This mechanism provides a non-volatile way to specify the cache timeout.
- If -execType is specified and has a value of sh, then this extend entry will be run in a shell. Otherwise it will be run in the default exec fashion. This mechanism provides a non-volatile way to specify the exec type.
- 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 nsExtendRunType 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 interpret the output. This is a convenient way to make information available quickly and simply, 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, octet, or string), and the third should be the value itself. (Note: octets are sent as ASCII, space-separated hex strings, e.g. "00 3f dd 00 c6 be".)

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 invocation of the command.

Quick callback to the pass situation before we move on: the default registration priority is 127. You can change it with the optional -p flag — and ngl, lower priority registrations get used in preference to higher priority values (yes bestie, lower number wins, it's giving "cheapest bid wins at auction" 🎀).

pass_persist [-p priority] MIBOID PROG — same deal as pass: control of the subtree rooted at MIBOID gets handed off to the specified PROG command. BUT 💅 this one keeps running after the initial request is answered, so all your subsequent requests get processed without the startup overheads. It stays on the clock, it's committed, it's in it for the long haul.

Upon initialization, PROG gets the string "PING\n" on stdin, and should respond by printing "PONG\n" to stdout. (Yes it's a literal ping-pong handshake, iconic behavior, no notes 🏓.)

For GET and GETNEXT requests, PROG gets 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 can't come up with an appropriate varbind, it should print "NONE\n" to stdout (but keep running, bestie, don't ghost us 😭).

For SET requests, PROG gets 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 get signalled by writing one of these strings to stdout — not-writable, wrong-type, wrong-length, wrong-value or inconsistent-value — and the agent will generate the appropriate error response. Either way, the command should continue running. No rage-quitting ✨.

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. Periodt. 🚫

🐪 Embedded Perl Support 🐪

Programs using the previous extension mechanisms can be written in any convenient programming language — including perl, which is a common choice for pass-through extensions in particular (classic perl girlie behavior, love that for you 💜). But the Net-SNMP agent also includes support for embedded perl technology (similar to mod_perl for the Apache web server). This lets the agent interpret perl scripts directly, which dodges the overhead of spawning processes and initializing the whole perl system every time a request comes in. Efficiency slay 🔥.

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. So like… build-time decision, no take-backsies 🫶.

If enabled, the following directives will be recognised:

disablePerl true — turns off embedded perl support entirely (e.g. if there are problems with the perl installation). Basically the "I'm breaking up with perl" button 💀.
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. She's your main character object 👑.

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. Whatever vibe your deployment needs, honestly 🌸.

📦 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 — hot-swapping but make it MIBs 💅. 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 configuration, so you're prob fine).

dlmod NAME PATH — loads the shared object module from the file PATH (an absolute filename), and calls the initialisation routine init_NAME.

Note: If the specified PATH is not a fully qualified filename, it will be interpreted relative to /usr/lib/snmp/dlmod, and .so will be appended to the filename. So like, check your paths bestie, the agent is not a mind reader 🔍.

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 — literally outsourcing, but respecting the remote agent's boundaries ✨. 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] — passes any incoming requests under OID to the agent listening on the port specified 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). This is the classic gotcha, don't be the person who proxies .1, I'm begging 🙈.

The SNMPCMD_ARGS should provide sufficient version and administrative information to generate a valid SNMP request (see snmpcmd(1)).

Note: The proxied request will not use the administrative settings from the original request. Fresh settings only, she does not inherit the outfit 💀.

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 different 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 configured community strings — see the com2sec directive). One proxy, many friends, group-chat energy fr fr 🫶.

Specifying the REMOID parameter will map the local MIB tree rooted at OID to an equivalent subtree rooted at REMOID on the remote agent. Same vibe, different address 🦋.

🧚 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 environment, 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). She's a legacy icon but she is legacy, bestie — don't start new stuff on SMUX 😭.

smuxpeer OID PASS — registers 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 acting in a SMUX subagent role. Master energy only 👑, no switching.

🐝 AgentX Sub-Agents 🐝

The Net-SNMP agent supports the AgentX protocol (RFC 2741) in both master and subagent roles — versatile, bilingual, whatever you need 💅. 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. Security girlie behavior, we love a locked door 🔐.

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. Separation anxiety, but scheduled 🫶.

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 alternative 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 functionality (unlike the -x command-line option). Setting the address is not the same as turning it on, bestie, these are two separate steps 😤.

agentXTimeout NUM — defines the timeout period (NUM seconds) for an AgentX request. Default is 1 second. NUM can also be specified with a suffix of one of s (for seconds), m (for minutes), h (for hours), d (for days), or w (for weeks). Pick your unit, live your truth ⭐.
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. Build your own bestie, she's ready for you 🌈.

✨ OTHER CONFIGURATION ✨

Okay bestie, this is the little advanced drawer of snmpd.conf — the override-and-inject zone. It’s giving “final boss of config files,” but we’re gonna walk through it together. 💅

🪄 `override [-rw] OID TYPE VALUE` 🪄

This directive lets you override a particular OID with a different value — and possibly a different type of value too. The -rw flag will allow snmp SETs to modify its value as well. But listen: if you’re overriding original functionality, that functionality will be entirely lost. So SETs will do nothing more than modify the internal overridden value, and will not perform any of the original functionality intended to be provided by the MIB object. It’s an emulation only. 😭

Example time:

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. Not me committing MIB crimes, but okay. 🙈

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 numbering within the ifTable changes its index ordering, you’ll end up with problems and your modified value won’t appear in the right place in the table. Index chaos is real, bestie.

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 information. 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 [beforeThis]` 🧩

This will insert new handlers into the section of the mib tree referenced by modulename. If beforeThis is specified, then the module will be injected before the named module. This is useful for getting a handler into the exact right position in the chain. Precision placement? We love to see it. ✨

The types of handlers available for insertion are:

stash_cache — Caches information returned from the lower level. This greatly helps the performance of the agent, at the cost of caching the data such that it’s no longer "live" for 30 seconds (in the future, this will be configurable). Note that this means snmpd will use more memory as well while the information 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 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. Quiet on the accepted-connection front, loud on the denied one.

🕵️‍♀️ Figuring out module names 🕵️‍♀️

To figure out which modules you can inject things into, run snmpwalk on the nsModuleTable, which will give a list of all named modules registered within the agent.

🗂️ Internal Data tables 🗂️

The page gives these two forms as-is, bestie:

table NAME

add_row NAME INDEX(ES) VALUE(S)

📝 NOTES 📝

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::versionUpdateConfig.0 (.1.3.6.1.4.1.2021.100.11.0), or by sending a kill -HUP signal to the agent process. Reload her gently, or reload her with a signal — either way, she’s re-reading.
All directives listed with a value of "yes" actually accept a range of boolean values. 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. Boolean range check: passed. Slay.

📚 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. Real examples? In this economy? We love to see it. 💖

📁 FILES 📁

/etc/snmp/snmpd.conf

👀 SEE ALSO 👀

snmpconf(1), snmpusm(1), snmp.conf(5), snmp_config(5), snmpd(8), EXAMPLE.conf, netsnmp_config_api(3).

💖 And that’s the whole SNMPD.CONF(5) page, bestie — source/version V5.9.5.2, dated 30 Jun 2010, and it’s literally iconic. 🎀

📦 where this page comes from

alpine 3.23: net-snmp-doc 5.9.5.2-r0 · Net-SNMP
alpine 3.24: net-snmp-doc 5.9.5.2-r0 · Net-SNMP
💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on 2026-11-04: a language model's rewrite of the original, under its terms

SNMPD.CONF(5)

💖 NAME 💖

✨ DESCRIPTION ✨

👑 AGENT BEHAVIOUR 👑

🔐 SNMPv3 Configuration - Real Security 🔐

🧚 SNMPv3 generic parameters 🧚

🦋 SNMPv3 over TLS 🦋

🦋 SNMPv3 over SSH Support 🦋

👑 SNMPv3 with the Transport Security Model (TSM) 👑

🎀 SNMPv3 with the User-based Security Model (USM) 🎀

🍓 SNMPv3 USM Users 🍓

🔐 ACCESS CONTROL 🔐

🌈 Traditional Access Control 🌈

🌸 VACM Configuration

🦋 Typed-View Configuration

🌈 SYSTEM INFORMATION

🎀 System Group

🧚 Interfaces Group

💜 Host Resources Group

💻 Process Monitoring

💾 Disk Usage Monitoring

🌀 Disk I/O Monitoring

📈 System Load Monitoring

📜 Log File Monitoring

🌸 ACTIVE MONITORING 🌸

💌 Notification Handling 💌

🧚 DisMan Event MIB 🧚

🎀 EXPRESSION 🎀

🌟 OID | ! OID | != OID

🌟 OID OP VALUE

🌟 OID MIN MAX [DMIN DMAX]

✨ OPTIONS ✨

🗓️ DisMan Schedule MIB 🗓️

📦 Data Delivery via Notifications 📦

🌸 EXTENDING AGENT FUNCTIONALITY 🌸

🦋 Arbitrary Extension Commands 🦋

🎀 MIB-Specific Extension Commands 🎀

🐪 Embedded Perl Support 🐪

📦 Dynamically Loadable Modules 📦

🔀 Proxy Support 🔀

🧚 SMUX Sub-Agents 🧚

🐝 AgentX Sub-Agents 🐝

✨ OTHER CONFIGURATION ✨

🪄 override [-rw] OID TYPE VALUE 🪄

🧩 injectHandler HANDLER modulename [beforeThis] 🧩

🕵️‍♀️ dontLogTCPWrappersConnects 🕵️‍♀️

🕵️‍♀️ Figuring out module names 🕵️‍♀️

🗂️ Internal Data tables 🗂️

📝 NOTES 📝

📚 EXAMPLE CONFIGURATION FILE 📚

📁 FILES 📁

👀 SEE ALSO 👀

🌟 `OID | ! OID | != OID`

🌟 `OID OP VALUE`

🌟 `OID MIN MAX [DMIN DMAX]`

🪄 `override [-rw] OID TYPE VALUE` 🪄

🧩 `injectHandler HANDLER modulename [beforeThis]` 🧩

🕵️‍♀️ `dontLogTCPWrappersConnects` 🕵️‍♀️