930 lines
24 KiB
HTML
930 lines
24 KiB
HTML
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<HTML><HEAD><TITLE>Man page of SNMPD.EXAMPLES</TITLE>
|
|
</HEAD><BODY>
|
|
<H1>SNMPD.EXAMPLES</H1>
|
|
Section: Net-SNMP (5)<BR>Updated: 13 Oct 2006<BR><A HREF="#index">Index</A>
|
|
<A HREF="/cgi-bin/man/man2html">Return to Main Contents</A><HR>
|
|
|
|
<A NAME="lbAB"> </A>
|
|
<H2>NAME</H2>
|
|
|
|
snmpd.examples - example configuration for the Net-SNMP agent
|
|
<A NAME="lbAC"> </A>
|
|
<H2>DESCRIPTION</H2>
|
|
|
|
The
|
|
<I><A HREF="/cgi-bin/man/man2html?5+snmpd.conf">snmpd.conf</A>(5)</I>
|
|
|
|
man page defines the syntax and behaviour of the various
|
|
configuration directives that can be used to control the
|
|
operation of the Net-SNMP agent, and the management information
|
|
it provides.
|
|
<P>
|
|
|
|
This companion man page illustrates these directives, showing
|
|
some practical examples of how they might be used.
|
|
<A NAME="lbAD"> </A>
|
|
<H2>AGENT BEHAVIOUR</H2>
|
|
|
|
<A NAME="lbAE"> </A>
|
|
<H3>Listening addresses</H3>
|
|
|
|
The default agent behaviour (listing on the standard SNMP UDP port on
|
|
all interfaces) is equivalent to the directive:
|
|
<DL COMPACT><DT id="1"><DD>
|
|
agentaddress udp:161
|
|
</DL>
|
|
|
|
or simply
|
|
<DL COMPACT><DT id="2"><DD>
|
|
agentaddress 161
|
|
</DL>
|
|
|
|
The agent can be configured to <I>only</I> accept requests sent to the
|
|
local loopback interface (again listening on the SNMP UDP port), using:
|
|
<DL COMPACT><DT id="3"><DD>
|
|
agentaddress localhost:161 <I># (udp implicit)</I>
|
|
</DL>
|
|
|
|
or
|
|
<DL COMPACT><DT id="4"><DD>
|
|
agentaddress 127.0.0.1 <I># (udp and standard port implicit)</I>
|
|
</DL>
|
|
|
|
It can be configured to accept both UDP and TCP requests (over both IPv4
|
|
and IPv6), using:
|
|
<DL COMPACT><DT id="5"><DD>
|
|
agentaddress udp:161,tcp:161,udp6:161,tcp6:161
|
|
</DL>
|
|
|
|
|
|
|
|
|
|
Other combinations are also valid.
|
|
<A NAME="lbAF"> </A>
|
|
<H3>Run-time privileges</H3>
|
|
|
|
The agent can be configured to relinquish any privileged access once it
|
|
has opened the initial listening ports. Given a suitable "snmp" group
|
|
(defined in <I>/etc/group</I>), this could be done using the directives:
|
|
<DL COMPACT><DT id="6"><DD>
|
|
<PRE>
|
|
agentuser nobody
|
|
agentgroup snmp
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
A similar effect could be achieved using numeric UID and/or GID values:
|
|
<DL COMPACT><DT id="7"><DD>
|
|
<PRE>
|
|
agentuser #10
|
|
agentgroup #10
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
|
|
|
|
|
|
|
|
<A NAME="lbAG"> </A>
|
|
<H3>SNMPv3 Configuration</H3>
|
|
|
|
Rather than being generated pseudo-randomly,
|
|
the engine ID for the agent could be calculated based on the MAC address
|
|
of the second network interface (<I>eth1</I>), using the directives:
|
|
<DL COMPACT><DT id="8"><DD>
|
|
engineIDType 3
|
|
engineIDNic eth1
|
|
</DL>
|
|
|
|
or it could be calculated from the (first) IP address, using:
|
|
<DL COMPACT><DT id="9"><DD>
|
|
engineIDType 1
|
|
</DL>
|
|
|
|
or it could be specified explicitly, using:
|
|
<DL COMPACT><DT id="10"><DD>
|
|
engineID "XXX - WHAT FORMAT"
|
|
</DL>
|
|
|
|
|
|
|
|
|
|
<A NAME="lbAH"> </A>
|
|
<H2>ACCESS CONTROL</H2>
|
|
|
|
<A NAME="lbAI"> </A>
|
|
<H3>SNMPv3 Users</H3>
|
|
|
|
The following directives will create three users, all using exactly
|
|
the same authentication and encryption settings:
|
|
<DL COMPACT><DT id="11"><DD>
|
|
<PRE>
|
|
createUser me MD5 "single pass phrase"
|
|
createUser myself MD5 "single pass phrase" DES
|
|
createUser andI MD5 "single pass phrase" DES "single pass phrase"
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
Note that this defines three <I>distinct</I> users, who could be granted
|
|
different levels of access. Changing the passphrase for any one of
|
|
these would not affect the other two.
|
|
<P>
|
|
|
|
Separate pass phrases can be specified for authentication and
|
|
encryption:
|
|
<DL COMPACT><DT id="12"><DD>
|
|
createUser onering SHA "to rule them all" AES "to bind them"
|
|
</DL>
|
|
|
|
Remember that these <I>createUser</I> directives should be defined in the
|
|
/var/lib/snmp/snmpd.conf file, rather than the usual location.
|
|
|
|
|
|
|
|
|
|
<A NAME="lbAJ"> </A>
|
|
<H3>Traditional Access Control</H3>
|
|
|
|
The SNMPv3 users defined above can be granted access to the full
|
|
MIB tree using the directives:
|
|
<DL COMPACT><DT id="13"><DD>
|
|
<PRE>
|
|
rouser me
|
|
rwuser onering
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
Or selective access to individual subtrees using:
|
|
<DL COMPACT><DT id="14"><DD>
|
|
<PRE>
|
|
rouser myself .1.3.6.1.2
|
|
rwuser andI system
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
<P>
|
|
|
|
Note that a combination repeating the same user, such as:
|
|
<DL COMPACT><DT id="15"><DD>
|
|
<PRE>
|
|
rouser onering
|
|
rwuser onering
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
should <B>not</B> be used. This would configure the user <I>onering</I>
|
|
with read-only access (and ignore the <I>rwuser</I> entry altogether).
|
|
The same holds for the community-based directives.
|
|
<P>
|
|
|
|
The directives:
|
|
<DL COMPACT><DT id="16"><DD>
|
|
<PRE>
|
|
rocommunity public
|
|
rwcommunity private
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
would define the commonly-expected read and write community strings
|
|
for SNMPv1 and SNMPv2c requests. This behaviour is <B>not</B>
|
|
configured by default, and would need to be set up explicitly.
|
|
<DL COMPACT><DT id="17"><DD>
|
|
<DL COMPACT>
|
|
<DT id="18">Note:<DD>
|
|
It would also be a very good idea to change <I>private</I> to something
|
|
a little less predictable!
|
|
</DL>
|
|
</DL>
|
|
|
|
<P>
|
|
|
|
A slightly less vulnerable configuration might restrict what information
|
|
could be retrieved:
|
|
<DL COMPACT><DT id="19"><DD>
|
|
rocommunity public default system
|
|
</DL>
|
|
|
|
or the management systems that settings could be manipulated from:
|
|
<DL COMPACT><DT id="20"><DD>
|
|
rwcommunity private 10.10.10.0/24
|
|
</DL>
|
|
|
|
or a combination of the two.
|
|
<A NAME="lbAK"> </A>
|
|
<H3>VACM Configuration</H3>
|
|
|
|
This last pair of settings are equivalent to the full VACM definitions:
|
|
<DL COMPACT><DT id="21"><DD>
|
|
<PRE>
|
|
<I># sec.name source community</I>
|
|
com2sec public default public
|
|
com2sec mynet 10.10.10.0/24 private
|
|
com2sec6 mynet fec0::/64 private
|
|
|
|
<I># sec.model sec.name</I>
|
|
group worldGroup v1 public
|
|
group worldGroup v2c public
|
|
group myGroup v1 mynet
|
|
group myGroup v2c mynet
|
|
|
|
<I># incl/excl subtree [mask]</I>
|
|
view all included .1
|
|
view sysView included system
|
|
|
|
<I># context model level prefix read write notify (unused)</I>
|
|
access worldGroup "" any noauth exact system none none
|
|
access myGroup "" any noauth exact all all none
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
<P>
|
|
|
|
There are several points to note in this example:
|
|
<P>
|
|
|
|
The <I>group</I> directives must be repeated for
|
|
both SNMPv1 and SNMPv2c requests.
|
|
<P>
|
|
|
|
The <I>com2sec</I> security name is distinct from the community
|
|
string that is mapped to it. They can be the same ("public")
|
|
or different ("mynet"/"private") - but what appears in the
|
|
<I>group</I> directive is the security name, regardless of
|
|
the original community string.
|
|
<P>
|
|
|
|
Both of the <I>view</I> directives are defining simple OID
|
|
subtrees, so neither of these require an explicit mask.
|
|
The same holds for the "combined subtree2 view defined below.
|
|
In fact, a mask field is only needed when defining row slices
|
|
across a table (or similar views), and can almost always be omitted.
|
|
<P>
|
|
|
|
In general, it is advisible not to mix traditional and VACM-based
|
|
access configuration settings, as these can sometimes interfere
|
|
with each other in unexpected ways. Choose a particular style
|
|
of access configuration, and stick to it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<A NAME="lbAL"> </A>
|
|
<H3>Typed-View Configuration</H3>
|
|
|
|
A similar configuration could also be configured as follows:
|
|
<DL COMPACT><DT id="22"><DD>
|
|
<PRE>
|
|
view sys2View included system
|
|
view sys2View included .1.3.6.1.2.1.25.1
|
|
|
|
authcommunity read public default -v sys2View
|
|
authcommunity read,write private 10.10.10.0/8
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
<P>
|
|
|
|
This mechanism allows multi-subtree (or other non-simple) views to
|
|
be used with the one-line <I>rocommunity</I> style of configuration.
|
|
<P>
|
|
|
|
It would also support configuring "write-only" access, should this
|
|
be required.
|
|
|
|
|
|
|
|
<A NAME="lbAM"> </A>
|
|
<H2>SYSTEM INFORMATION</H2>
|
|
|
|
<A NAME="lbAN"> </A>
|
|
<H3>System Group</H3>
|
|
|
|
The full contents of the 'system' group (with the exception of sysUpTime)
|
|
can be explicitly configured using:
|
|
<DL COMPACT><DT id="23"><DD>
|
|
<PRE>
|
|
<I># Override 'uname -a' and hardcoded system OID - inherently read-only values</I>
|
|
sysDescr Universal Turing Machine mk I
|
|
sysObjectID .1.3.6.1.4.1.8072.3.2.1066
|
|
|
|
<I># Override default values from 'configure' - makes these objects read-only</I>
|
|
sysContact <A HREF="mailto:Alan.Turing@pre-cs.man.ac.uk">Alan.Turing@pre-cs.man.ac.uk</A>
|
|
sysName tortoise.turing.com
|
|
sysLocation An idea in the mind of AT
|
|
|
|
<I># Standard end-host behaviour</I>
|
|
sysServices 72
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
<A NAME="lbAO"> </A>
|
|
<H3>Host Resources Group</H3>
|
|
|
|
The list of devices probed for potential inclusion in the
|
|
hrDiskStorageTable (and hrDeviceTable) can be amended using
|
|
any of the following directives:
|
|
<DL COMPACT><DT id="24"><DD>
|
|
ignoredisk /dev/rdsk/c0t2d0
|
|
</DL>
|
|
|
|
which prevents the device <I>/dev/rdsk/c0t2d0</I> from being scanned,
|
|
<DL COMPACT><DT id="25"><DD>
|
|
<PRE>
|
|
ignoredisk /dev/rdsk/c0t[!6]d0
|
|
ignoredisk /dev/rdsk/c0t[0-57-9a-f]d0
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
either of which prevents all devices <I>/dev/rdsk/c0t</I>X<I>d0</I>
|
|
(except .../<I>c0t6d0</I>) from being scanned,
|
|
<DL COMPACT><DT id="26"><DD>
|
|
ignoredisk /dev/rdsk/c1*
|
|
</DL>
|
|
|
|
which prevents all devices whose device names start with <I>/dev/rdsk/c1</I>
|
|
from being scanned, or
|
|
<DL COMPACT><DT id="27"><DD>
|
|
ignoredisk /dev/rdsk/c?t0d0
|
|
</DL>
|
|
|
|
which prevents all devices <I>/dev/rdsk/c</I>X<I>t0d0</I>
|
|
(where 'X' is any single character) from being scanned.
|
|
<A NAME="lbAP"> </A>
|
|
<H3>Process Monitoring </H3>
|
|
|
|
The list of services running on a system can be monitored
|
|
(and provision made for correcting any problems), using:
|
|
<DL COMPACT><DT id="28"><DD>
|
|
<PRE>
|
|
<I># At least one web server process must be running at all times</I>
|
|
proc httpd
|
|
procfix httpd /etc/rc.d/init.d/httpd restart
|
|
|
|
<I># There should never be more than 10 mail processes running
|
|
# (more implies a probable mail storm, so shut down the mail system)</I>
|
|
proc sendmail 10
|
|
procfix sendmail /etc/rc.d/init.d/sendmail stop
|
|
|
|
<I># There should be a single network management agent running
|
|
# ("There can be only one")</I>
|
|
proc snmpd 1 1
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
Also see the "DisMan Event MIB" section later on.
|
|
<A NAME="lbAQ"> </A>
|
|
<H3>Disk Usage Monitoring</H3>
|
|
|
|
The state of disk storage can be monitored using:
|
|
<DL COMPACT><DT id="29"><DD>
|
|
<PRE>
|
|
includeAllDisks 10%
|
|
disk /var 20%
|
|
disk /usr 3%
|
|
<I># Keep 100 MB free for crash dumps</I>
|
|
disk /mnt/crash 100000
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
<A NAME="lbAR"> </A>
|
|
<H3>System Load Monitoring</H3>
|
|
|
|
A simple check for an overloaded system might be:
|
|
<DL COMPACT><DT id="30"><DD>
|
|
load 10
|
|
</DL>
|
|
|
|
A more refined check (to allow brief periods of heavy use,
|
|
but recognise sustained medium-heavy load) might be:
|
|
<DL COMPACT><DT id="31"><DD>
|
|
load 30 10 5
|
|
</DL>
|
|
|
|
<A NAME="lbAS"> </A>
|
|
<H3>Log File Monitoring</H3>
|
|
|
|
<I>TODO</I>
|
|
|
|
<DL COMPACT><DT id="32"><DD>
|
|
file FILE [MAXSIZE]
|
|
</DL>
|
|
|
|
<DL COMPACT><DT id="33"><DD>
|
|
logmatch NAME PATH CYCLETIME REGEX
|
|
</DL>
|
|
|
|
<A NAME="lbAT"> </A>
|
|
<H2>ACTIVE MONITORING</H2>
|
|
|
|
<A NAME="lbAU"> </A>
|
|
<H3>Notification Handling</H3>
|
|
|
|
Configuring the agent to report invalid access attempts might be done by:
|
|
<DL COMPACT><DT id="34"><DD>
|
|
<PRE>
|
|
authtrapenable 1
|
|
trapcommunity public
|
|
trap2sink localhost
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
Alternatively, the second and third directives could be combined
|
|
(and an acknowledgement requested) using:
|
|
<DL COMPACT><DT id="35"><DD>
|
|
informsink localhost public
|
|
</DL>
|
|
|
|
A configuration with repeated sink destinations, such as:
|
|
<DL COMPACT><DT id="36"><DD>
|
|
<PRE>
|
|
trapsink localhost
|
|
trap2sink localhost
|
|
informsink localhost
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
should <B>NOT</B> be used, as this will cause multiple copies
|
|
of each trap to be sent to the same trap receiver.
|
|
<P>
|
|
|
|
<I>TODO - discuss SNMPv3 traps</I>
|
|
|
|
<DL COMPACT><DT id="37"><DD>
|
|
trapsess <I>snmpv3 options</I> localhost:162
|
|
</DL>
|
|
|
|
<P>
|
|
|
|
<I>TODO - mention trapd access configuration</I>
|
|
|
|
<P>
|
|
<A NAME="lbAV"> </A>
|
|
<H3>DisMan Event MIB</H3>
|
|
|
|
The simplest configuration for active self-monitoring of
|
|
the agent, by the agent, for the agent, is probably:
|
|
<DL COMPACT><DT id="38"><DD>
|
|
<PRE>
|
|
<I># Set up the credentials to retrieve monitored values</I>
|
|
createUser _internal MD5 "the first sign of madness"
|
|
iquerySecName _internal
|
|
rouser _internal
|
|
|
|
<I># Active the standard monitoring entries</I>
|
|
defaultMonitors yes
|
|
linkUpDownNotifications yes
|
|
|
|
<I># If there's a problem, then tell someone!</I>
|
|
trap2sink localhost
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
<P>
|
|
|
|
The first block sets up a suitable user for retrieving the
|
|
information to by monitored, while the following pair of
|
|
directives activates various built-in monitoring entries.
|
|
<P>
|
|
|
|
Note that the DisMan directives are not themselves sufficient to
|
|
actively report problems - there also needs to be a suitable
|
|
destination configured to actually send the resulting notifications to.
|
|
<P>
|
|
|
|
A more detailed monitor example is given by:
|
|
<DL COMPACT><DT id="39"><DD>
|
|
monitor -u me -o hrSWRunName "high process memory" hrSWRunPerfMem > 10000
|
|
</DL>
|
|
|
|
<P>
|
|
|
|
This defines an explicit boolean monitor entry, looking for any process
|
|
using more than 10MB of active memory. Such processes will be reported
|
|
using the (standard) DisMan trap mteTriggerFired,
|
|
but adding an extra (wildcarded) varbind hrSWRunName.
|
|
<P>
|
|
|
|
This entry also specifies an explicit user (<I>me</I>, as defined
|
|
earlier) for retrieving the monitored values, and building the trap.
|
|
<P>
|
|
|
|
Objects that could potentially fluctuate around the specified level
|
|
are better monitored using a threshold monitor entry:
|
|
<DL COMPACT><DT id="40"><DD>
|
|
monitor -D -r 10 "network traffic" ifInOctets 1000000 5000000
|
|
</DL>
|
|
|
|
<P>
|
|
|
|
This will send a mteTriggerRising trap whenever the incoming
|
|
traffic rises above (roughly) 500 kB/s on any network interface,
|
|
and a corresponding mteTriggerFalling trap when it falls below
|
|
100 kB/s again.
|
|
<P>
|
|
|
|
Note that this monitors the deltas between successive samples (<I>-D</I>)
|
|
rather than the actual sample values themselves. The same effect
|
|
could be obtained using:
|
|
<DL COMPACT><DT id="41"><DD>
|
|
monitor -r 10 "network traffic" ifInOctets - - 1000000 5000000
|
|
</DL>
|
|
|
|
<P>
|
|
|
|
The <I>linkUpDownNotifications</I> directive above is broadly
|
|
equivalent to:
|
|
<DL COMPACT><DT id="42"><DD>
|
|
<PRE>
|
|
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
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
<P>
|
|
|
|
This defines the traps to be sent (using <I>notificationEvent</I>),
|
|
and explicitly references the relevant notification in the corresponding
|
|
monitor entry (rather than using the default DisMan traps).
|
|
<P>
|
|
|
|
The <I>defaultMonitors</I> directive above is equivalent to a series
|
|
of (boolean) monitor entries:
|
|
<DL COMPACT><DT id="43"><DD>
|
|
<PRE>
|
|
monitor -o prNames -o prErrMessage "procTable" 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
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
and will send a trap whenever any of these entries indicate a problem.
|
|
<P>
|
|
|
|
An alternative approach would be to automatically invoke the corresponding
|
|
"fix" action:
|
|
<DL COMPACT><DT id="44"><DD>
|
|
<PRE>
|
|
setEvent prFixIt prErrFix = 1
|
|
monitor -e prFixIt "procTable" prErrorFlag != 0
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
(and similarly for any of the other <I>defaultMonitor</I> entries).
|
|
<A NAME="lbAW"> </A>
|
|
<H3>DisMan Schedule MIB</H3>
|
|
|
|
The agent could be configured to reload its configuration
|
|
once an hour, using:
|
|
<DL COMPACT><DT id="45"><DD>
|
|
repeat 3600 versionUpdateConfig.0 = 1
|
|
</DL>
|
|
|
|
<P>
|
|
|
|
Alternatively this could be configured to be run at specific
|
|
times of day (perhaps following rotation of the logs):
|
|
<DL COMPACT><DT id="46"><DD>
|
|
cron 10 0 * * * versionUpdateConfig.0 = 1
|
|
</DL>
|
|
|
|
<P>
|
|
|
|
The one-shot style of scheduling is rather less common, but the
|
|
secret SNMP virus could be activated on the next occurance of Friday 13th using:
|
|
<DL COMPACT><DT id="47"><DD>
|
|
at 13 13 13 * 5 snmpVirus.0 = 1
|
|
</DL>
|
|
|
|
<A NAME="lbAX"> </A>
|
|
<H2>EXTENDING AGENT FUNCTIONALITY</H2>
|
|
|
|
<A NAME="lbAY"> </A>
|
|
<H3>Arbitrary Extension Commands</H3>
|
|
|
|
<I>Old Style</I>
|
|
|
|
<DL COMPACT><DT id="48"><DD>
|
|
<PRE>
|
|
exec [MIBOID] NAME PROG ARGS"
|
|
sh [MIBOID] NAME PROG ARGS"
|
|
execfix NAME PROG ARGS"
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
<I>New Style</I>
|
|
|
|
<DL COMPACT><DT id="49"><DD>
|
|
<PRE>
|
|
extend [MIBOID] NAME PROG ARGS"
|
|
extendfix [MIBOID] NAME PROG ARGS"
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
<A NAME="lbAZ"> </A>
|
|
<H3>MIB-Specific Extension Commands</H3>
|
|
|
|
<I>One-Shot</I>
|
|
|
|
<DL COMPACT><DT id="50"><DD>
|
|
"pass [-p priority] MIBOID PROG"
|
|
</DL>
|
|
|
|
<DL COMPACT>
|
|
<DT id="51"><DD>
|
|
<I>Persistent</I>
|
|
|
|
<DL COMPACT><DT id="52"><DD>
|
|
"pass_persist [-p priority] MIBOID PROG"
|
|
</DL>
|
|
|
|
</DL>
|
|
<A NAME="lbBA"> </A>
|
|
<H3>Embedded Perl Support</H3>
|
|
|
|
If embedded perl support is enabled in the agent, the default
|
|
initialisation is equivalent to the directives:
|
|
<DL COMPACT><DT id="53"><DD>
|
|
<PRE>
|
|
disablePerl false
|
|
perlInitFile /usr/share/snmp/snmp_perl.pl
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
The main mechanism for defining embedded perl scripts is the
|
|
<I>perl</I> directive. A very simple (if somewhat pointless)
|
|
MIB handler could be registered using:
|
|
<DL COMPACT><DT id="54"><DD>
|
|
<PRE>
|
|
perl use Data::Dumper;
|
|
perl sub myroutine { print "got called: ",Dumper(@_),"\n"; }
|
|
perl $agent->register('mylink', '.1.3.6.1.8765', \&myroutine);
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
<P>
|
|
|
|
This relies on the <I>$agent</I> object, defined in the example
|
|
snmp_perl.pl file.
|
|
<P>
|
|
|
|
A more realistic MIB handler might be:
|
|
<DL COMPACT><DT id="55"><DD>
|
|
<PRE>
|
|
<I>XXX - WHAT ???</I>
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
Alternatively, this code could be stored in an external file,
|
|
and loaded using:
|
|
<DL COMPACT><DT id="56"><DD>
|
|
perl 'do /usr/share/snmp/perl_example.pl';
|
|
</DL>
|
|
|
|
|
|
|
|
|
|
<A NAME="lbBB"> </A>
|
|
<H3>Dynamically Loadable Modules</H3>
|
|
|
|
<I>TODO</I>
|
|
|
|
<DL COMPACT><DT id="57"><DD>
|
|
dlmod NAME PATH"
|
|
</DL>
|
|
|
|
<A NAME="lbBC"> </A>
|
|
<H3>Proxy Support</H3>
|
|
|
|
A configuration for acting as a simple proxy for two other
|
|
SNMP agents (running on remote systems) might be:
|
|
<DL COMPACT><DT id="58"><DD>
|
|
<PRE>
|
|
com2sec -Cn rem1context rem1user default remotehost1
|
|
com2sec -Cn rem2context rem2user default remotehost2
|
|
|
|
proxy -Cn rem1context -v 1 -c public remotehost1 .1.3
|
|
proxy -Cn rem2context -v 1 -c public remotehost2 .1.3
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
(plus suitable access control entries).
|
|
<P>
|
|
|
|
The same <I>proxy</I> directives would also work with
|
|
(incoming) SNMPv3 requests, which can specify a context directly.
|
|
It would probably be more sensible to use contexts of
|
|
<I>remotehost1</I> and <I>remotehost2</I> - the names above were
|
|
chosen to indicate how these directives work together.
|
|
<P>
|
|
|
|
Note that the administrative settings for the proxied request
|
|
are specified explicitly, and are independent of the settings
|
|
from the incoming request.
|
|
<P>
|
|
|
|
An alternative use for the <I>proxy</I> directive is to pass
|
|
part of the OID tree to another agent (either on a remote host
|
|
or listening on a different port on the same system),
|
|
while handling the rest internally:
|
|
<DL COMPACT><DT id="59"><DD>
|
|
proxy -v 1 -c public localhost:6161 .1.3.6.1.4.1.99
|
|
</DL>
|
|
|
|
This mechanism can be used to link together two separate SNMP agents.
|
|
<P>
|
|
|
|
A less usual approach is to map one subtree into a different area
|
|
of the overall MIB tree (either locally or on a remote system):
|
|
<DL COMPACT><DT id="60"><DD>
|
|
<PRE>
|
|
<I># uses SNMPv3 to access the MIB tree .1.3.6.1.2.1.1 on 'remotehost'
|
|
# and maps this to the local tree .1.3.6.1.3.10</I>
|
|
proxy -v 3 -l noAuthNoPriv -u user remotehost .1.3.6.1.3.10 .1.3.6.1.2.1.1
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
<A NAME="lbBD"> </A>
|
|
<H3>SMUX Sub-Agents</H3>
|
|
|
|
<DL COMPACT><DT id="61"><DD>
|
|
<PRE>
|
|
smuxsocket 127.0.0.1
|
|
smuxpeer .1.3.6.1.2.1.14 ospf_pass
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
<A NAME="lbBE"> </A>
|
|
<H3>AgentX Sub-Agents</H3>
|
|
|
|
The Net-SNMP agent could be configured to operate as an AgentX master
|
|
agent (listening on a non-standard named socket, and running using
|
|
the access privileges defined earlier), using:
|
|
<DL COMPACT><DT id="62"><DD>
|
|
<PRE>
|
|
master agentx
|
|
agentXSocket /tmp/agentx/master
|
|
agentXPerms 0660 0550 nobody snmp
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
|
|
|
|
|
|
|
|
A sub-agent wishing to connect to this master agent would need
|
|
the same <I>agentXSocket</I> directive, or the equivalent code:
|
|
<DL COMPACT><DT id="63"><DD>
|
|
<PRE>
|
|
netsnmp_ds_set_string(NETSNMP_DS_APPLICATION_ID, NETSNMP_DS_AGENT_X_SOCKET,
|
|
"/tmp/agentx/master");
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
<P>
|
|
|
|
A loopback networked AgentX configuration could be set up using:
|
|
<DL COMPACT><DT id="64"><DD>
|
|
<PRE>
|
|
agentXSocket tcp:localhost:705
|
|
agentXTimeout 5
|
|
agentXRetries 2
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
on the master side, and:
|
|
<DL COMPACT><DT id="65"><DD>
|
|
<PRE>
|
|
agentXSocket tcp:localhost:705
|
|
agentXTimeout 10
|
|
agentXRetries 1
|
|
agentXPingInterval 600
|
|
</PRE>
|
|
|
|
</DL>
|
|
|
|
on the client.
|
|
<P>
|
|
|
|
Note that the timeout and retry settings can be asymmetric
|
|
for the two directions, and the sub-agent can poll the master agent
|
|
at regular intervals (600s = every 10 minutes), to ensure the
|
|
connection is still working.
|
|
<A NAME="lbBF"> </A>
|
|
<H2>OTHER CONFIGURATION</H2>
|
|
|
|
<DL COMPACT><DT id="66"><DD>
|
|
override sysDescr.0 octet_str "my own sysDescr"
|
|
</DL>
|
|
|
|
<DL COMPACT><DT id="67"><DD>
|
|
injectHandler stash_cache NAME table_iterator
|
|
</DL>
|
|
|
|
<A NAME="lbBG"> </A>
|
|
<H2>FILES</H2>
|
|
|
|
/etc/snmp/snmpd.conf
|
|
<A NAME="lbBH"> </A>
|
|
<H2>SEE ALSO</H2>
|
|
|
|
<A HREF="/cgi-bin/man/man2html?1+snmpconf">snmpconf</A>(1), <A HREF="/cgi-bin/man/man2html?5+snmpd.conf">snmpd.conf</A>(5), <A HREF="/cgi-bin/man/man2html?5+snmp.conf">snmp.conf</A>(5), <A HREF="/cgi-bin/man/man2html?5+snmp_config">snmp_config</A>(5), <A HREF="/cgi-bin/man/man2html?8+snmpd">snmpd</A>(8), EXAMPLE.conf, <A HREF="/cgi-bin/man/man2html?3+netsnmp_config_api">netsnmp_config_api</A>(3).
|
|
|
|
|
|
|
|
<P>
|
|
|
|
<HR>
|
|
<A NAME="index"> </A><H2>Index</H2>
|
|
<DL>
|
|
<DT id="68"><A HREF="#lbAB">NAME</A><DD>
|
|
<DT id="69"><A HREF="#lbAC">DESCRIPTION</A><DD>
|
|
<DT id="70"><A HREF="#lbAD">AGENT BEHAVIOUR</A><DD>
|
|
<DL>
|
|
<DT id="71"><A HREF="#lbAE">Listening addresses</A><DD>
|
|
<DT id="72"><A HREF="#lbAF">Run-time privileges</A><DD>
|
|
<DT id="73"><A HREF="#lbAG">SNMPv3 Configuration</A><DD>
|
|
</DL>
|
|
<DT id="74"><A HREF="#lbAH">ACCESS CONTROL</A><DD>
|
|
<DL>
|
|
<DT id="75"><A HREF="#lbAI">SNMPv3 Users</A><DD>
|
|
<DT id="76"><A HREF="#lbAJ">Traditional Access Control</A><DD>
|
|
<DT id="77"><A HREF="#lbAK">VACM Configuration</A><DD>
|
|
<DT id="78"><A HREF="#lbAL">Typed-View Configuration</A><DD>
|
|
</DL>
|
|
<DT id="79"><A HREF="#lbAM">SYSTEM INFORMATION</A><DD>
|
|
<DL>
|
|
<DT id="80"><A HREF="#lbAN">System Group</A><DD>
|
|
<DT id="81"><A HREF="#lbAO">Host Resources Group</A><DD>
|
|
<DT id="82"><A HREF="#lbAP">Process Monitoring </A><DD>
|
|
<DT id="83"><A HREF="#lbAQ">Disk Usage Monitoring</A><DD>
|
|
<DT id="84"><A HREF="#lbAR">System Load Monitoring</A><DD>
|
|
<DT id="85"><A HREF="#lbAS">Log File Monitoring</A><DD>
|
|
</DL>
|
|
<DT id="86"><A HREF="#lbAT">ACTIVE MONITORING</A><DD>
|
|
<DL>
|
|
<DT id="87"><A HREF="#lbAU">Notification Handling</A><DD>
|
|
<DT id="88"><A HREF="#lbAV">DisMan Event MIB</A><DD>
|
|
<DT id="89"><A HREF="#lbAW">DisMan Schedule MIB</A><DD>
|
|
</DL>
|
|
<DT id="90"><A HREF="#lbAX">EXTENDING AGENT FUNCTIONALITY</A><DD>
|
|
<DL>
|
|
<DT id="91"><A HREF="#lbAY">Arbitrary Extension Commands</A><DD>
|
|
<DT id="92"><A HREF="#lbAZ">MIB-Specific Extension Commands</A><DD>
|
|
<DT id="93"><A HREF="#lbBA">Embedded Perl Support</A><DD>
|
|
<DT id="94"><A HREF="#lbBB">Dynamically Loadable Modules</A><DD>
|
|
<DT id="95"><A HREF="#lbBC">Proxy Support</A><DD>
|
|
<DT id="96"><A HREF="#lbBD">SMUX Sub-Agents</A><DD>
|
|
<DT id="97"><A HREF="#lbBE">AgentX Sub-Agents</A><DD>
|
|
</DL>
|
|
<DT id="98"><A HREF="#lbBF">OTHER CONFIGURATION</A><DD>
|
|
<DT id="99"><A HREF="#lbBG">FILES</A><DD>
|
|
<DT id="100"><A HREF="#lbBH">SEE ALSO</A><DD>
|
|
</DL>
|
|
<HR>
|
|
This document was created by
|
|
<A HREF="/cgi-bin/man/man2html">man2html</A>,
|
|
using the manual pages.<BR>
|
|
Time: 00:06:06 GMT, March 31, 2021
|
|
</BODY>
|
|
</HTML>
|