SNMPD(8)

SNMPD(8) ๐Ÿ’– the Net-SNMP agent daemon, bestie

okay so you opened the Net-SNMP section-8 page for snmpd and you're like "what is this little guy" โ€” don't worry, I got you. grab a strawberry ๐Ÿ“, we're doing this.


โœจ NAME โœจ

snmpd โ€” daemon to respond to SNMP request packets.

โœจ SYNOPSIS โœจ

snmpd [OPTIONS] [LISTENING ADDRESSES]

โœจ DESCRIPTION โœจ

So snmpd is an SNMP agent ๐Ÿ’… it binds to a port and justโ€ฆ waits. patiently. main character energy, honestly. when some SNMP management software shows up with a request, it processes the request(s), collects the info you asked for and/or performs the operation(s) you asked for, and sends the info right back to whoever asked. it's giving "customer service but make it a daemon." ๐Ÿซถ


๐ŸŒธ OPTIONS ๐ŸŒธ

every single one, no skips, periodt:

  • -a โ€” log the source addresses of incoming requests. know who's knocking. ๐Ÿ‘€
  • -A โ€” append to the log file instead of truncating it. your history stays, bestie. no deleting the receipts. ๐ŸŽ€
  • -c FILE โ€” read FILE as a configuration file (or a comma-separated list of configuration files). heads up though: the loaded file will only understand snmpd.conf tokens, unless the configuration type is specified in the file as described in the snmp_config man page under SWITCHING CONFIGURATION TYPES IN MID-FILE. iykyk.
  • -C โ€” do not read any configuration files except the ones optionally specified by the -c option. and note that this behaviour also covers the persistent configuration files ๐Ÿ˜ญ which may result in dynamically-assigned values being reset following an agent restart, unless the relevant persistent config files are explicitly loaded using the -c option. so likeโ€ฆ choose wisely.
  • -d โ€” dump (in hexadecimal) the sent and received SNMP packets. hex girl summer. ๐Ÿ”ฅ
  • -D[TOKEN[,...]] โ€” turn on debugging output for the given TOKEN(s). without any tokens specified, it defaults to printing all the tokens (which is equivalent to the keyword "ALL"). you might want to try ALL for extremely verbose output. Note: you can not put a space between the -D flag and the listed TOKENs. not one. not even a little one. ๐Ÿ™ˆ
  • -f โ€” do not fork() from the calling shell. stay put, diva. ๐Ÿ’…
  • -g GID โ€” change the group ID of the snmpd process into GID after opening listening sockets. this overrides the agentgroup configuration file parameter.
  • -h, --help โ€” display a brief usage message and then exit. lil help, then bye. ๐Ÿ‘‹
  • -H โ€” display a list of configuration file directives understood by the agent and then exit.
  • -I [-]INITLIST โ€” specifies which modules should (or should not) be initialized when the agent starts up. if the comma-separated INITLIST is preceded with a -, it is the list of modules that should not be started. otherwise this is the list of the only modules that should be started.
    • to get a list of compiled modules, run the agent with the arguments -Dmib_init -H (assuming debugging support has been compiled in). ๐ŸŒˆ
  • -L[eEfFoOsSnN] โ€” specify where logging output should be directed (standard error or output, to a file or via syslog). see LOGGING OPTIONS in snmpcmd(1) for details.
  • -m MIBLIST โ€” specifies a colon separated list of MIB modules to load for this application. this overrides the environment variable MIBS. see snmpcmd(1) for details.
  • -M DIRLIST โ€” specifies a colon separated list of directories to search for MIBs. this overrides the environment variable MIBDIRS. see snmpcmd(1) for details.
  • -n NAME โ€” set an alternative application name (which will affect the configuration files loaded). by default this will be snmpd, regardless of the name of the actual binary. glow-up name change, but make it config. โœจ
  • -p FILE โ€” save the process ID of the daemon in FILE.
  • -q โ€” print simpler output for easier automated parsing. lowercase, low-effort, very demure. ๐ŸŽ€
  • -r โ€” do not require root access to run the daemon. specifically, do not exit if files only accessible to root (such as /dev/kmem etc.) cannot be opened. permission slip: denied, but we're still going. ๐Ÿฆ‹
  • -u UID โ€” change the user ID of the snmpd process into UID (which can be given in numerical or textual form) after opening listening sockets. this overrides the agentuser configuration file parameter.
  • -U โ€” instructs the agent to not remove its pid file (see the -p option) on shutdown. overrides the leave_pidfile token in the snmpd.conf file, see snmpd.conf(5).
  • -v, --version โ€” print version information for the agent and then exit.
  • -V โ€” symbolically dump SNMP transactions. symbolically. ๐Ÿ’ซ
  • -x ADDRESS โ€” listens for AgentX connections on the specified address rather than the default "/var/agentx/master". the address can either be a Unix domain socket path, or the address of a network interface. the format is the same as the format of listening addresses described below.
  • -X โ€” run as an AgentX subagent rather than as an SNMP master agent. supporting role, still iconic. ๐Ÿ‘‘
  • --name="value" โ€” allows one to specify any token ("name") supported in the snmpd.conf file and sets its value to "value". overrides the corresponding token in the snmpd.conf file. see snmpd.conf(5) for the full list of tokens.

๐Ÿฆ‹ LISTENING ADDRESSES ๐Ÿฆ‹

by default, snmpd listens for incoming SNMP requests on UDP port 161 on all IPv4 interfaces. but bestie, you can absolutely modify this behaviour by specifying one or more listening addresses as arguments to snmpd. a listening address takes the form:

[<transport-specifier>:]<transport-address>

at its simplest, a listening address may consist only of a port number, in which case snmpd listens on that UDP port on all IPv4 interfaces. otherwise, the <transport-address> part of the specification is parsed according to this lil lineup:

  • udp (default) โ€” hostname[:port] or IPv4-address[:port]
  • tcp โ€” hostname[:port] or IPv4-address[:port]
  • unix โ€” pathname
  • ipx โ€” [network]:node[/port]
  • aal5pvc or pvc โ€” [interface.][VPI.]VCI
  • udp6 or udpv6 or udpipv6 โ€” hostname[:port] or IPv6-address[:port]
  • tcp6 or tcpv6 or tcpipv6 โ€” hostname[:port] or IPv6-address[:port]
  • ssh โ€” hostname:port
  • dtlsudp โ€” hostname:port

note that <transport-specifier> strings are case-insensitive so that, for example, "tcp" and "TCP" are equivalent. ๐Ÿ’… here are some examples, along with their interpretation:

  • 127.0.0.1:161 โ€” listen on UDP port 161, but only on the loopback interface. this prevents snmpd being queried remotely. the port specification ":161" is not strictly necessary since that is the default SNMP port. private vibes only. ๐ŸŽ€
  • TCP:1161 โ€” listen on TCP port 1161 on all IPv4 interfaces.
  • ipx:/40000 โ€” listen on IPX port 40000 on all IPX interfaces.
  • unix:/tmp/local-agent โ€” listen on the Unix domain socket /tmp/local-agent.
  • /tmp/local-agent โ€” is identical to the previous specification, since the Unix domain is assumed if the first character of the <transport-address> is /.
  • PVC:161 โ€” listen on the AAL5 permanent virtual circuit with VPI=0 and VCI=161 (decimal) on the first ATM adapter in the machine.
  • udp6:10161 โ€” listen on port 10161 on all IPv6 interfaces.
  • ssh:127.0.0.1:22 โ€” allows connections from the snmp subsystem on the ssh server on port 22. the details of using SNMP over SSH are defined below. ๐Ÿงš
  • dtlsudp:127.0.0.1:9161 โ€” listen for connections over DTLS on UDP port 9161. the snmp.conf file must have the serverCert, configuration tokens defined.
โš ๏ธ note that not all the transport domains listed above will always be available; for instance, hosts with no IPv6 support will not be able to use udp6 transport addresses, and attempts to do so will result in the error "Error opening specified endpoint". likewise, since AAL5 PVC support is only currently available on Linux, it will fail with the same error on other platforms. it's not you, it's the platform. ๐Ÿ˜ญ

๐ŸŒˆ Transport Specific Notes ๐ŸŒˆ

ssh

the SSH transport, on the server side, is actually just a unix named pipe that can be connected to via a ssh subsystem configured in the main ssh server. the pipe location (configurable with the sshtosnmpsocket token in snmp.conf) is /var/lib/net-snmp/sshdomainsocket. packets should be submitted to it via the sshtosnmp application, which also sends the user ID as well when starting the connection. the TSM security model should be used when packets should process it.

the sshtosnmp command knows how to connect to this pipe and talk to it. it should be configured in the OpenSSH sshd configuration file (which is normally /etc/ssh/sshd_config) using the following configuration line:

Subsystem snmp /usr/local/bin/sshtosnmp /var/lib/net-snmp/sshdomainsocket

the sshtosnmp command will need read/write access to the /var/lib/net-snmp/sshdomainsocket pipe. although it should be fairly safe to grant access to the average user since it still requires modifications to the ACM settings before the user can perform operations, paranoid administrators may want to make the /var/lib/net-snmp directory accessible only by users in a particular group. use the sshtosnmpsocketperms snmp.conf configure option to set the permissions, owner and group of the created socket.

access control can be granted to the user "foo" using the following style of simple snmpd.conf settings:

rouser -s tsm foo authpriv

note that "authpriv" is acceptable assuming as SSH protects everything that way (assuming you have a non-insane setup). snmpd has no notion of how SSH has actually protected a packet and thus the snmp agent assumes all packets passed through the SSH transport have been protected at the authpriv level. trust but verify, except it literally can't verify, so it just trusts. ๐Ÿ™ˆ

dtlsudp

the DTLS protocol, which is based off of TLS, requires both client and server certificates to establish the connection and authenticate both sides. in order to do this, the client will need to configure the snmp.conf file with the clientCert configuration tokens. the server will need to configure the snmp.conf file with the serverCert configuration tokens defined. mutual, as it should be. ๐Ÿ’–

access control setup is similar to the ssh transport as the TSM security model should be used to protect the packet.


๐ŸŒธ CONFIGURATION FILES ๐ŸŒธ

okay bestie, so snmpd goes looking for these files, and if they're there, it parses them. every single one, here's the whole lineup:

  • /etc/snmp/snmp.conf โ€” the shared config for the agent and the applications. wanna know more? snmp.conf(5), it's all there, go read it ๐Ÿซถ
  • /etc/snmp/snmpd.conf
  • /etc/snmp/snmpd.local.conf โ€” agent-specific configuration, and yup, snmpd.conf(5) has the deets. these two files are optional, but lowkey they're where you set up access control, trap generation, subagent protocols, and honestly a whole bunch of other stuff too. the way that one file can do so much?? iconic.

and heads up โ€” beyond those two files sitting in /etc/snmp, the agent is also gonna read any file named snmpd.conf and any file named snmpd.local.conf that it finds along a colon separated path that you give it in the SNMPCONFPATH environment variable. so like, a:b:c style. yes really. it just goes down the line and reads them all ๐Ÿ’…

  • /usr/share/snmp/mibs/ โ€” the agent also loads every file in this directory as MIBs. but bestie, two things it will NOT do:
    • it will not load any file that begins with a .
    • it will not descend into subdirectories

periodt, that's the rule ๐ŸŽ€


โœจ SEE ALSO โœจ

presented in the recommended reading order, because we're organized like that:

go forth and read, bestie, you got this ๐Ÿ“š๐Ÿ’–


and that's a wrap on SNMPD(8), fr fr ๐Ÿฆ‹ this page is from version V5.9.5.2, dated 30 Jun 2010, so it's giving vintage but the knowledge is timeless, no cap. slay, go configure something beautiful ๐Ÿ‘‘๐ŸŒธ
๐Ÿ“ฆ where this page comes from