There are a large number of directives that can be specified, but these mostly fall into four distinct categories:
Some directives don't fall naturally into any of these four categories, but this covers the majority of the contents of a typical snmpd.conf file. A full list of recognised directives can be obtained by running the command:
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.
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.
If no proc directives are defined, then walking the prTable will fail (noSuchObject).
If neither any disk directives or includeAllDisks are defined, then walking the dskTable will fail (noSuchObject).
Unlike the proc and disk directives, walking the walking the laTable will succeed (assuming the ucd-snmp/loadave module was configured into the agent), even if the load directive is not present.
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).
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
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.
There are three ways of specifying the scheduled action:
exec and sh extensions can only be configured via the snmpd.conf file. They cannot be set up via SNMP SET requests.
pass and pass_persist extensions can only be configured via the snmpd.conf file. They cannot be set up via SNMP SET requests.
Use of this mechanism requires that the agent was built with support for the embedded perl mechanism, which is not part of the default build environment. It must be explicitly included by specifying the '--enable-embedded-perl' option to the configure script when the package is first built.
If enabled, the following directives will be recognised:
perl use Data::Dumper;
perl sub myroutine { print "got called: ",Dumper(@_),"\n"; }
perl $agent->register('mylink', '.1.3.6.1.8765', \&myroutine);
This functionality can also be configured using SNMP SET requests to the UCD-DLMOD-MIB.
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).
Specifying the REMOID parameter will map the local MIB tree rooted at OID to an equivalent subtree rooted at REMOID on the remote agent.
Note the Net-SNMP agent will only operate as a SMUX master agent. It does not support acting in a SMUX subagent role.
There are two directives specifically relevant to running as an AgentX master agent:
net-snmp ships with both C and Perl APIs to develop your own AgentX subagent.
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 stash_cache NAME table_iterator
If you want a table to play with, try walking the nsModuleTable with and without this injected.