snmpd.conf.5.def
上传用户:wxp200602
上传日期:2007-10-30
资源大小:4028k
文件大小:43k
源码类别:

SNMP编程

开发平台:

Unix_Linux

  1. .TH SNMPD.CONF 5 "08 Feb 2002" VVERSIONINFO "Net-SNMP"
  2. .UC 4
  3. .SH NAME
  4. snmpd.conf - configuration file for the Net-SNMP SNMP agent
  5. .SH DESCRIPTION
  6. .B snmpd.conf
  7. is the configuration file which defines how the Net-SNMP SNMP agent
  8. operates.  These files may contain any of the directives found in the
  9. .B DIRECTIVES
  10. section below.  If this file is not found (or does not contain any
  11. access control directives), the agent will run but will not respond
  12. to any requests.
  13. .SH PLEASE READ FIRST
  14. First, make sure you have read the
  15. .I snmp_config(5) 
  16. manual page that describes how the Net-SNMP configuration files
  17. operate, where they are located and how they all work together.
  18. .PP
  19. Also, you might consider looking into the
  20. .B snmpconf
  21. application (perl script) which can help you build an snmpd.conf file
  22. by prompting you for information.  You should try it.  Really.  Go
  23. ahead.  Right now.  Run:
  24. .RS
  25. .IP "snmpconf -g basic_setup"
  26. .RE
  27. .PP
  28. to get you started. See the
  29. .I snmpconf(1)
  30. manual page for more information.
  31. .SH EXTENSIBLE-MIB
  32. .PP
  33. The Net-SNMP SNMP agent reports much of its information through
  34. queries to the EXTENSIBLEDOTMIB section of the MIB tree.  Every MIB in
  35. this section has the following table entries in it.
  36. .IP ".MIBINDEX -- index"
  37. This is the table's index numbers for each of the DIRECTIVES listed below.
  38. .IP ".ERRORNAME -- name"
  39. The name of the given table entry.  This should be unique, but is not
  40. required to be.
  41. .IP ".ERRORFLAG -- errorFlag"
  42. This is a flag returning either the integer value 1 or 0 if an error
  43. is detected for this table entry.
  44. .IP ".ERRORMSG -- errorMsg"
  45. This is a DISPLAY-STRING describing any error triggering the errorFlag above.
  46. .IP ".ERRORFIX -- errorFix"
  47. If this entry is set to the integer value of 1 AND the errorFlag
  48. defined above is indeed a 1, a program or script will get executed
  49. with the table entry name from above as the argument.  The program to
  50. be executed is configured in the net-snmp-config.h file at compile time.
  51. .SS Directives
  52. .IP "proc NAME"
  53. .IP "proc NAME MAX"
  54. .IP "proc NAME MAX MIN"
  55. .IP
  56. Checks to see if processes called NAME are running on the agent
  57. machine.  An error flag (1) and a description message are then passed
  58. to the EXTENSIBLEDOTMIB.PROCMIBNUM.1.ERRORFLAG and
  59. EXTENSIBLEDOTMIB.PROCMIBNUM.1.ERRORMSG MIB columns (respectively) if
  60. the NAME'd program is not found in the process table as reported by
  61. PSCMD.
  62. .IP
  63. If MAX and MIN are not specified, MAX is assumed to be 
  64. .B infinity
  65. and MIN is assumed to be 1.
  66. .IP
  67. If MAX is specified but MIN is not specified, MIN is assumed to be 0.
  68. .IP "procfix NAME PROG ARGS"
  69. This registers a command that knows how to fix errors with the given
  70. process NAME.  When EXTENSIBLEDOTMIB.PROCMIBNUM.1.ERRORFIX for a given
  71. NAMEd program is set to the integer value of 1, this command will be
  72. called.  It defaults to a compiled value set using the PROCFIXCMD
  73. definition in the net-snmp-config.h file.
  74. .IP "exec NAME PROG ARGS"
  75. .IP "exec MIBNUM NAME PROG ARGS"
  76. .IP
  77. If MIBNUM is not specified, the agent executes the named PROG with
  78. arguments of ARGS and returns the exit status and the first line of
  79. the STDOUT output of the PROG program to queries of the
  80. EXTENSIBLEDOTMIB.SHELLMIBNUM.1.ERRORFLAG and
  81. EXTENSIBLEDOTMIB.SHELLMIBNUM.1.ERRORMSG mib columns (respectively).  All
  82. STDOUT output beyond the first line is silently truncated.
  83. .IP
  84. If MIBNUM is specified, it acts as above but returns the exit status
  85. to MIBNUM.ERRORFLAG.0 and the entire STDOUT output to the table
  86. MIBNUM.ERRORMSG in a MIB table.  In this case, the MIBNUM.ERRORMSG mib
  87. contains the entire STDOUT output, one MIB table entry per line of
  88. output (ie, the first line is output as MIBNUM.ERRORMSG.1, the second
  89. at MIBNUM.ERRORMSG.2, etc...).
  90. .RS
  91. .IP Note:
  92. The PROG argument must be a full path to a real binary, as it is
  93. executed under the exec() system call.  IE, you can not specify a path
  94. to a shell script.  If you want to invoke a shell script, please
  95. specify a path to the interpreter first as the PROG argument and then
  96. a path to the shell script.  IE:  "exec myscript /bin/sh
  97. /path/to/script arg1 ..."
  98. .IP Note:
  99. The MIBNUM must be specified in dotted-integer notation and can
  100. not be specified as ".iso.org.dod.internet..." (should instead
  101. be .1.3.6.1...).
  102. .IP Note: 
  103. The agent caches the exit status and STDOUT of the executed program
  104. for 30 seconds after the initial query.  This is to increase speed and
  105. maintain consistency of information for consecutive table queries.
  106. The cache can be flushed by a snmp-set request of integer(1) to
  107. EXTENSIBLEDOTMIB.VERSIONMIBNUM.VERCLEARCACHE.
  108. .RE
  109. .IP "extend NAME PROG ARGS"
  110. .IP "extend MIBNUM NAME PROG ARGS"
  111. .IP
  112. This is similar to the 'exec' directive, but uses a different MIB output
  113. structure (for both forms) which covers multi-line output as standard.
  114. See NET-SNMP-EXTEND-MIB for details.
  115. Output is cached for each entry separately, controlled by the
  116. NET-SNMP-AGENT-MIB::nsCacheTable.
  117. .IP "execfix NAME PROG ARGS"
  118. This registers a command that knows how to fix errors with the given
  119. exec or sh NAME.  When EXTENSIBLEDOTMIB.SHELLMIBNUM.1.ERRORFIX for a
  120. given NAMEd entry is set to the integer value of 1, this command will
  121. be called.  It defaults to a compiled value set using the EXECFIXCMD
  122. definition in the net-snmp-config.h file.
  123. .IP "disk PATH"
  124. .IP "disk PATH [ MINSPACE | MINPERCENT% ]"
  125. .IP
  126. Checks the named disks mounted at PATH for available disk space.  If
  127. the disk space is less than MINSPACE (kB) if specified or less than
  128. MINPERCENT (%) if a % sign is specified, or DEFDISKMINIMUMSPACE (kB)
  129. if not specified, the associated entry in the
  130. EXTENSIBLEDOTMIB.DISKMIBNUM.1.ERRORFLAG MIB table will be set to (1) and
  131. a descriptive error message will be returned to queries of
  132. EXTENSIBLEDOTMIB.DISKMIBNUM.1.ERRORMSG.
  133. .IP "includeAllDisks MINPERCENT%"
  134. .IP
  135. Adds  all  the  disks  that can be found on the system using the
  136. setmntent(3) and getmntent(3), or fopen(3) and getmntent(3),  or
  137. setfsent(3)  and  getfsent(3) system calls. If none of the above
  138. system calls are available then it adds the root partition  "/",
  139. (which  is  assumed to exist on any UNIX based system) using the
  140. statfs(2) system call.
  141. .IP
  142. There can only be one 'includeAllDisks' directive in the config-
  143. uration  file.  It  can  be  used in conjunction with the 'disk'
  144. directive. They may be used in any order. The  'disk'  directive
  145. overrides  the  disk  usage  specified  by the 'includeAllDisks'
  146. directive, no matter in which order they are  specified  in  the
  147. configuration file.
  148. .IP
  149. The 'includeAllDisks' directive only includes the disks that are
  150. mounted when the snmpd daemon  is  started.  It  cannot  include
  151. disks  that are dynamically loadable, such as with automount. So
  152. the preferred way is to mount all the disks that will ever  need
  153. to be monitored before starting the snmpd daemon.
  154. .IP "load MAX1"
  155. .IP "load MAX1 MAX5"
  156. .IP "load MAX1 MAX5 MAX15"
  157. .IP
  158. Checks the load average of the machine and returns an error flag (1),
  159. and an text-string error message
  160. to queries of EXTENSIBLEDOTMIB.LOADAVEMIBNUM.1.ERRORFLAG and
  161. EXTENSIBLEDOTMIB.LOADAVEMIBNUM.1.ERRORMSG (respectively) when the
  162. 1-minute, 5-minute, or 15-minute averages exceed the associated
  163. maximum values.  If any of the MAX1, MAX5, or MAX15 values are
  164. unspecified, they default to a value of DEFMAXLOADAVE.
  165. .IP "file FILE [MAXSIZE]"
  166. Monitors file sizes and makes sure they don't grow beyond a certain
  167. size (in kilobytes).  MAXSIZE defaults to infinite if not specified,
  168. and only monitors the size without reporting errors about it.
  169. A maximum of 20 files can be monitored.
  170. .IP "logmatch NAME PATH CYCLETIME REGEX"
  171. Configures log file monitoring that can be queried via the
  172. UCD-SNMP-MIB::logMatchTable.
  173. .SS "Errors"
  174. .PP
  175. Any errors in obtaining the above information are reported via the
  176. EXTENSIBLEDOTMIB.ERRORMIBNUM.1.ERRORFLAG flag and the
  177. EXTENSIBLEDOTMIB.ERRORMIBNUM.1.ERRORMSG text-string description.
  178. .SH AGENTX SUB-AGENTS
  179. To enable AgentX support in the SNMP master agent, put the following
  180. line in your snmpd.conf file:
  181. .IP "master agentx"
  182. See README.agentx for further details.
  183. .IP "AgentXSocket addr"
  184. This defines the address the master agent listens at.
  185. The default is /var/agentx/master. By default the Unix Domain socket is
  186. accessible only to subagents which have the same userid as the agent.
  187. Another possibility is localhost:705
  188. .IP "AgentXTimeout addr"
  189. Defines the timeout period for an AgentX request.
  190. Default is 1 second.
  191. .IP "AgentXRetries addr"
  192. Defines the number of retries for an AgentX request.
  193. Default is 5 retries.
  194. .IP "agentxperms socket_perms [directory_perms [username|userid [groupname|groupid]]]"
  195. Defines the permissions of the AgentX socket. socket_perms and directory_perms must be octal digits (see 
  196. .I chmod(1)
  197. ).
  198. .P
  199. You can also put the following in your subagent.conf file (where
  200. "subagent" is the name you used in your init_snmp("subagent") api call:
  201. .IP "agentPingInterval NUM"
  202. This makes the subagent try and reconnect every NUM seconds to the
  203. master if it ever becomes (or starts) disconnected.
  204. .SH SMUX SUB-AGENTS
  205. To enable and SMUX based sub-agent, such as
  206. .IR gated ,
  207. use the
  208. .I smuxpeer
  209. configuration entry
  210. .IP "smuxpeer OID PASS"
  211. For 
  212. .I gated
  213. a sensible entry might be
  214. .I smuxpeer .1.3.6.1.4.1.4.1.3 secret
  215. .SH DYNAMICALLY LOADABLE MODULES
  216. If the agent is built with support for the UCD-DLMOD-MIB it is capable
  217. of loading agent MIB modules dynamically at startup through
  218. the fIdlmodfR directive and during runtime through use of the UCD-DLMOD-MIB.
  219. The following directive loads the shared object module file PATH which
  220. uses the module name prefix NAME.
  221. .IP "dlmod NAME PATH"
  222. .IP
  223. .SH ACCESS CONTROL
  224. .B snmpd
  225. supports the View-Based Access Control Model (VACM) as defined in RFC
  226. 2575.  To this end, it recognizes the following keywords in the
  227. configuration file: fIcom2secfR, fIgroupfR, fIaccessfR, and
  228. fIviewfR as well as some easier-to-use wrapper directives:
  229. fIrocommunityfR, fIrwcommunityfR, fIrouserfR, fIrwuserfR.  If
  230. IPv6 support has been enabled, the fIrocommunity6fR and
  231. fIrwcommunity6fR tokens will also be available.  This section
  232. defines how to configure the snmpd program to accept various types and
  233. levels of access.
  234. .IP "rouser USER [noauth|auth|priv [OID]]"
  235. .IP "rwuser USER [noauth|auth|priv [OID]]"
  236. Creates a SNMPv3 USM user in the VACM access configuration tables.  It
  237. is more efficient (and powerful) to use the combined fIgroupfR,
  238. fIaccessfR, and fIviewfR directives instead, but these wrapper
  239. directives are much simpler.
  240. .IP
  241. The minimum level of authentication and privacy the user must use is
  242. specified by the first token (which defaults to "auth").  The OID
  243. parameter restricts access for that user to everything below the given
  244. OID.
  245. .IP "rocommunity COMMUNITY [SOURCE [OID]]"
  246. .IP "rwcommunity COMMUNITY [SOURCE [OID]]"
  247. These create read-only and read-write communities that can be used to
  248. access the agent.  They are a quick wrapper around the more complex
  249. and powerful fIcom2secfR, fIgroupfR, fIaccessfR, and fIviewfR
  250. directive lines.  They are not as efficient either, as groups aren't
  251. created so the tables are possibly larger.  In other words: don't use
  252. these if you have complex situations to set up.  If your setup is
  253. simple or you don't mind a small performance hit, use these
  254. directives.
  255. .IP
  256. The format of the SOURCE is token is described in the fIcom2secfR
  257. directive section below.  The OID token restricts access for that
  258. community to everything below that given OID.
  259. .IP "rocommunity6 COMMUNITY [SOURCE [OID]]"
  260. .IP "rwcommunity6 COMMUNITY [SOURCE [OID]]"
  261. They are the alternative directives to the fIrocommunityfR,
  262. fIrwcommunityfR for the transport domain UDPIPv6. They are only
  263. valid in specifing fIUDPIPv6fR as transport domain.
  264. .IP
  265. The format of the SOURCE is token is described in the fIcom2sec6fR
  266. directive section below.  The OID token restricts access for that
  267. community to everything below that given OID.
  268. .IP "com2sec [-Cn CONTEXT] NAME SOURCE COMMUNITY"
  269. This directive specifies the mapping from a source/community pair to
  270. a security name. SOURCE can be a hostname, a subnet, or the word
  271. fI"default"fR.
  272. A subnet can be specified as IP/MASK or IP/BITS.
  273. For example, given a directive
  274. "com2sec myLocal 10.10.10.0/24 public"
  275. then this would match requests from IP addresses 10.10.10.0 through
  276. to 10.10.10.255, but not one from 10.10.11.1 or similar.
  277. The first source/community combination that matches the incoming packet
  278. is selected.  If a CONTEXT is specified, the community name gets
  279. mapped to the SNMPv3 CONTEXT of the same name, otherwise the default context
  280. ("") is used.
  281. .IP "com2sec6  [-Cn CONTEXT] NAME SOURCE COMMUNITY"
  282. This directive is the IPv6 version of fIcom2secfR.
  283. A subnet can be specified as IPv6/IPv6MASK or IPv6/BITS.
  284. It is only valid in specifing fIUDPIPv6fR as transport domain.
  285. .IP "com2secunix [-Cn CONTEXT] NAME SOCKPATH COMMUNITY"
  286. This directive is the Unix domain sockets version of fIcom2secfR.
  287. .IP "group NAME MODEL SECURITY"
  288. This directive defines the mapping from securitymodel/securityname to group.
  289. MODEL is one of fIv1fR, fIv2cfR, or fIusmfR.
  290. .IP "access NAME CONTEXT MODEL LEVEL PREFX READ WRITE NOTIFY"
  291. The access directive maps from group/security model/security level to
  292. a view. 
  293. MODEL is one of fIanyfR, fIv1fR, fIv2cfR, or fIusmfR.
  294. LEVEL is one of fInoauthfR, fIauthfR, or fIprivfR.
  295. PREFX specifies how CONTEXT should be matched against the context of
  296. the incoming pdu, either fIexactfR or fIprefixfR.
  297. READ, WRITE and NOTIFY specifies the view to be used for the corresponding 
  298. access.
  299. For v1 or v2c access, LEVEL will be noauth, and CONTEXT will be empty.
  300. .IP "view NAME TYPE SUBTREE [MASK]"
  301. This defines the named view. TYPE is either fIincludedfR or fIexcludedfR.
  302. MASK is a list of hex octets, separated by '.' or ':'.  The MASK
  303. defaults to "ff" if not specified.
  304. .IP
  305. The reason for the mask is, that it allows you to control access to
  306. one row in a table, in a relatively simple way. As an example, as an ISP
  307. you might consider giving each customer access to his or her own interface:
  308. .IP
  309. .nf
  310. view cust1 included interfaces.ifTable.ifEntry.ifIndex.1 ff.a0
  311. view cust2 included interfaces.ifTable.ifEntry.ifIndex.2 ff.a0
  312. .IP
  313. (interfaces.ifTable.ifEntry.ifIndex.1 == .1.3.6.1.2.1.2.2.1.1.1,
  314. ff.a0 == 11111111.10100000. which nicely covers up and including
  315. the row index, but lets the user vary the field of the row)
  316. .IP "VACM Examples:"
  317. .nf
  318. #        sec.name  source          community
  319. com2sec  local     localhost       private
  320. com2sec  mynet     10.10.10.0/24   public
  321. com2sec  public    default         public
  322. com2sec6 mynet     fec0::/64       public
  323. #             sec.model  sec.name
  324. group mygroup v1         mynet
  325. group mygroup v2c        mynet
  326. group mygroup usm        mynet
  327. group local   v1         local
  328. group local   v2c        local
  329. group local   usm        local
  330. group public  v1         public
  331. group public  v2c        public
  332. group public  usm        public
  333. #           incl/excl subtree                          mask
  334. view all    included  .1                               80
  335. view system included  system                           fe
  336. view mib2   included  .iso.org.dod.internet.mgmt.mib-2 fc
  337. #              context sec.model sec.level prefix read   write notify
  338. access mygroup ""      any       noauth    exact  mib2   none  none
  339. access public  ""      any       noauth    exact  system none  none
  340. access local   ""      any       noauth    exact  all    all   all
  341. .IP "Default VACM model"
  342. The default configuration of the agent, as shipped, is functionally
  343. equivalent to the following entries:
  344. .nf
  345. com2sec public default public
  346. group public v1 public
  347. group public v2c public
  348. group public usm public
  349. view  all included .1
  350. access public "" any noauth exact all none none
  351. .fi
  352. .RE
  353. .SH SNMPv3 CONFIGURATION
  354. .PP
  355. .IP "engineID STRING"
  356. The snmpd agent needs to be configured with a unique engineID to be able to
  357. respond to SNMPv3 messages.  With this configuration file line, the
  358. engineID will be configured from STRING. 
  359. .IP "engineIDType 1|2|3"
  360. Defines that the engineID should be built from the IPv4 address (1), IPv6 address (2) or MAC address (3). Beware that you might run into trouble on IP 
  361. address changes!
  362. .IP "engineIDNic interface"
  363. Defines the interface (e.g. "eth1") that should be used to determine the MAC address in case of "engineIDType 3". Default is eth0.
  364. .P
  365. If neither an engineID, engineIDType or engineIDNic directive is present, 
  366. the value of the engineID is built from 2 fairly random elements:
  367. a random number and the current time in seconds. This is the recommended
  368. approach.
  369. .IP "createUser [-e ENGINEID] username (MD5|SHA) authpassphrase [DES|AES] [privpassphrase]"
  370. .IP
  371. MD5 and SHA are the authentication types to use.  DES and AES are the
  372. privacy protocols to use.  If the privacy
  373. passphrase is not specified, it is assumed to be the same as the
  374. authentication passphrase.  Note that the users created will be
  375. useless unless they are also added to the VACM access control tables
  376. described above.
  377. .IP
  378. SHA authentication and DES/AES privacy require OpenSSL to be installed and
  379. the agent to be built with OpenSSL support.  MD5 authentication may be
  380. used without OpenSSL.
  381. .IP
  382. Warning: the minimum pass phrase length is 8 characters.
  383. .IP
  384. SNMPv3 users can be created at runtime using the
  385. .I snmpusm(1)
  386. command.
  387. .IP
  388. Instead of figuring out how to use this directive and where to put it
  389. (see below), just run "net-snmp-config --create-snmpv3-user" instead,
  390. which will add one of these lines to the right place.
  391. .IP
  392. This directive should be placed into the
  393. PERSISTENT_DIRECTORY/snmpd.conf file instead of the other normal
  394. locations.  The reason is that the information is read from the file
  395. and then the line is removed (eliminating the storage of the master
  396. password for that user) and replaced with the key that is derived from
  397. it.  This key is a localized key, so that if it is stolen it can not
  398. be used to access other agents.  If the password is stolen, however,
  399. it can be.
  400. .IP
  401. If you need to localize the user to a particular EngineID (this is
  402. useful mostly in the similar snmptrapd.conf file), you can use the -e
  403. argument to specify an EngineID as a hex value (EG, "0x01020304").
  404. .IP
  405. If you want to generate either your master or localized keys directly,
  406. replace the given password with a hexstring (preceeded by a "0x") and
  407. precede the hex string by a -m or -l token (respectively).  EGs:
  408. .IP
  409. .RS
  410. .nf
  411. [these keys are *not* secure but are easy to visually parse for
  412. counting purposes.  Please generate random keys instead of using
  413. these examples]
  414. createUser myuser SHA -l 0x0001020304050607080900010203040506070809 AES -l 0x00010203040506070809000102030405
  415. createUser myuser SHA -m 0x0001020304050607080900010203040506070809 AES -m 0x0001020304050607080900010203040506070809
  416. .fi
  417. .RE
  418. .IP
  419. Due to the way localization happens, localized privacy keys are
  420. expected to be the length needed by the algorithm (128 bits for all
  421. supported algorithms).  Master encryption keys, though, need to be the
  422. length required by the authentication algorithm not the length
  423. required by the encrypting algorithm (MD5: 16 bytes, SHA: 20 bytes).
  424. .IP
  425. .SH SETTING SYSTEM INFORMATION
  426. .IP "syslocation STRING"
  427. .IP "syscontact STRING"
  428. .IP "sysname STRING"
  429. Sets the system location, system contact or system name for the agent.
  430. This information is reported in the 'system' group the mibII tree.
  431. Ordinarily these objects (sysLocation.0, sysContact.0 and sysName.0)
  432. are read-write.  However, specifying the value for one of these
  433. objects by giving the appropriate token makes the corresponding object
  434. read-only, and attempts to set the value of the object will result in
  435. a notWritable error response.
  436. .IP "sysservices NUMBER"
  437. Sets the value of the system.sysServices.0 object.
  438. For a host, a good value is 72.
  439. .IP "sysdescr STRING"
  440. .IP "sysobjectid OID"
  441. Sets the system description or object ID for the agent.
  442. Although these values are not SNMP-writable, it is conceivable
  443. that a network administrator may wish to configure them to something
  444. other than the default values.
  445. .IP "leave_pidfile yes"
  446. Instructs the agent to not remove its pid file on shutdown. Equivalent to
  447. specifying "-U" on the command line.
  448. .IP "agentaddress [<transport-specifier>:]<transport-address>[,...]"
  449. Makes the agent list on the specified comma-separated list of
  450. listening addresses instead of the default behaviour, which is to
  451. listen on UDP port 161 on all IPv4 interfaces.  See the section 
  452. .B LISTENING ADDRESSES
  453. in the
  454. .I snmpd(8)
  455. manual page for more information about the format of listening
  456. addresses.  For example, specifying
  457. .I "agentaddress 161,tcp:161,localhost:9161"
  458. will make the agent listen on UDP port 161 on all IPv4 interfaces, TCP
  459. port 161 on all IPv4 interfaces and UDP port 9161 only on the interface
  460. associated with the localhost address.
  461. .IP "agentgroup groupid"
  462. Change to this gid after opening port. The groupid may refer to a group
  463. by name or a number if the group number starts with '#'. For example,
  464. specifying
  465. .I agentgroup snmp
  466. will cause the agent to run as the snmp group or
  467. .I agentgroup #10
  468. will cause the agent to run as the group with groupid 10.
  469. .IP "agentuser uid"
  470. Change to this uid after opening port. The userid may refer to a user
  471. by name or a number if the user number starts with '#'. For example,
  472. specifying
  473. .I agentuser snmp
  474. will cause the agent to run as the snmp user or
  475. .I agentuser #10
  476. will cause the agent to run as the user with userid 10.
  477. .IP "interface NAME TYPE SPEED"
  478. For interfaces where the agent fails to guess correctly on the type and
  479. speed, this directive can supply additional information.
  480. TYPE is a type value as given in the IANAifType-MIB.
  481. .IP "ignoredisk STRING"
  482. When scanning for available disk devices the agent might block in trying
  483. to open all possible disk devices. This might lead to a timeout when
  484. walking the device tree. Sometimes the next walk will run without timeout,
  485. sometimes it will timeout every time you try it.
  486. .IP
  487. If you experience such behaviour you might add this directive and give all
  488. device names not to be checked (i.e. opened). You might have more than one
  489. such directive in your configuration file stating all devices not to be
  490. opened. You might also specify those devices using wildcards similar to
  491. the syntax you can use in a bourne shell (see examples below).
  492. .IP
  493. .B Note:
  494. For a list of devices scanned for every system please consult the sources
  495. (host/hr_disk.c) and check for the Add_HR_Disk_entry() calls relevant for
  496. your type of OS.
  497. .IP
  498. Examples:
  499. .IP
  500. ignoredisk /dev/rdsk/c0t2d0
  501. .IP
  502. This directive prevents the device /dev/rdsk/c0t2d0 from being scanned.
  503. .IP
  504. ignoredisk /dev/rdsk/c0t[!6]d0
  505. .IP
  506. This directive prevents all devices /dev/rdsk/c0tXd0 except .../c0t6d0
  507. from being scanned. For most systems similar is the following directive:
  508. .IP
  509. ignoredisk /dev/rdsk/c0t[0-57-9a-f]d0
  510. .IP
  511. ignoredisk /dev/rdsk/c1*
  512. .IP
  513. This directive prevents all devices whose device names start with /dev/rdsk/c1
  514. from being scanned.
  515. .IP
  516. ignoredisk /dev/rdsk/c?t0d0
  517. .IP
  518. This directive prevents all devices /dev/rdsk/cXt0d0 ('X' might be any char)
  519. from being scanned.
  520. .IP
  521. You might use more than one such wildcard expression in any such directive.
  522. .IP "storageUseNFS NUMBER"
  523. Setting storageUseNFS to 1 causes all NFS and NFS-like file systems to be
  524. marked as 'Network Disks' in the hrStorageTable. This is according to RFC 2790.
  525. Not setting storageUseNFS or setting it to 2 causes NFS and NFS-like file
  526. systems to be marked as 'Fixed Disks' as it has been in previous versions of
  527. the ucd-snmp SNMP agent.
  528. .IP "authtrapenable NUMBER"
  529. Setting authtrapenable to 1 enables generation of authentication failure
  530. traps.  The default value is disabled(2).  Ordinarily the corresponding
  531. object (snmpEnableAuthenTraps.0) is read-write, but setting its value
  532. via this token makes the object read-only, and attempts to set the
  533. value of the object will result in a notWritable error response.
  534. .IP "override [-rw] OID TYPE VALUE"
  535. This directive allows you to override a particular OID with a
  536. different value (and possibly a different type of value).  The -rw
  537. flag will allow snmp SETs to modify it's value as well. (note that if
  538. you're overriding original functionality, that functionality will be
  539. entirely lost.  Thus SETS will do nothing more than modify the
  540. internal overridden value and will not perform any of the original
  541. functionality intended to be provided by the MIB object.  It's an
  542. emulation only.)  An example:
  543. .IP
  544. override sysDescr.0 octet_str "my own sysDescr"
  545. .IP
  546. That line will set the sysDescr.0 value to "my own sysDescr" as well
  547. as make it modifiable with SNMP SETs as well (which is actually
  548. illegal according to the MIB specifications).
  549. .IP
  550. Note that care must be taken when using this.  For example, if you try
  551. to override a property of the 3rd interface in the ifTable with a new
  552. value and later the numbering within the ifTable changes it's index
  553. ordering you'll end up with problems and your modified value won't
  554. appear in the right place in the table.
  555. .IP
  556. Valid TYPEs are: integer, uinteger, octet_str, object_id, counter,
  557. null (for gauge's, use "uinteger"; for bit strings, use "octet_str").
  558. Note that setting an object to "null" effectively delete's it as being
  559. accessible.  No VALUE needs to be given if the object type is null.
  560. .IP
  561. More types should be available in the future.
  562. .SH "SETTING UP TRAP AND/OR INFORM DESTINATIONS"
  563. .IP "trapcommunity STRING"
  564. This defines the default community string to be used when sending traps.
  565. Note that this command must be used prior to any of the following three
  566. commands that are intended use this community string.
  567. .IP "trapsink HOST [COMMUNITY [PORT]]"
  568. .IP "trap2sink HOST [COMMUNITY [PORT]]"
  569. .IP "informsink HOST [COMMUNITY [PORT]]"
  570. These commands define
  571. the hosts to receive traps (and/or inform notifications). The
  572. daemon sends a Cold Start trap when it starts up. If enabled, it also sends
  573. traps on authentication failures.  Multiple fItrapsinkfR, fItrap2sinkfR
  574. and fIinformsinkfR lines may be specified to specify multiple destinations.
  575. Use fItrap2sinkfR to send SNMPv2 traps and fIinformsinkfR to send
  576. inform notifications.
  577. If COMMUNITY is not specified, the string from a preceding fItrapcommunityfR
  578. directive will be used. If PORT is not specified, the well known SNMP trap
  579. port (162) will be used.
  580. .IP "trapsess [SNMPCMD_ARGS] HOST"
  581. This is a more generic trap configuration token that allows any type
  582. of trap destination to be specified with any version of SNMP.  See the 
  583. .I snmpcmd(1)
  584. manual page for further details on the arguments that can be passed as
  585. .I "SNMPCMD ARGS".
  586. In addition to the arguments listed there, the special argument
  587. fI-CifR specifies that you want inform notifications to be used
  588. instead of unacknowledged traps (this requires that you also specify a 
  589. version number of v2c or v3 as well).
  590. .SH "PROXY SUPPORT"
  591. .IP "proxy [-Cn CONTEXTNAME] [SNMPCMD ARGS] HOST OID [REMOTEOID]"
  592. .IP
  593. This token specifies that any incoming requests under OID should be
  594. proxied on to another HOST instead.  Use OID .1.3 (not just .1) to proxy 
  595. the entire MIB tree. If a CONTEXTNAME is specified, it
  596. assigns the proxied tree to a particular context name within the local
  597. agent.  This is the proper way to query multiple agents through a
  598. single proxy.  Assign each remote agent to a different context name.
  599. Then you can use "snmpwalk -n contextname1" to walk one remote proxied
  600. agent and "snmpwalk -n contextname2" to walk another, assuming you are
  601. using SNMPv3 to talk to the proxy (snmpv1 and snmpv2c context mappings
  602. aren't currently supported but might be in the future).  Optionally,
  603. relocate the local OID tree to the new location at the REMOTEOID.  To
  604. authenticate to HOST you should use the appropriate set of
  605. .I "SNMPCMD ARGS."
  606. See the
  607. .I snmpcmd(1)
  608. manual page for details.
  609. .IP
  610. Examples:
  611. .RS
  612. .nf
  613. # assigns the entire mib tree on remotehost1 to the context of the
  614. # same name:
  615. proxy -Cn remotehost1 -v 1 -c public remotehost1 .1.3
  616. # ditto, but for remotehost 2
  617. proxy -Cn remotehost2 -v 1 -c public remotehost2 .1.3
  618. # proxies only the ucdavis enterprises tree to the remote host using snmpv1
  619. proxy -v 1 -c public remotehost .1.3.6.1.4.1.2021
  620. # uses v3 to access remotehost and converts the remote .1.3.6.1.2.1.1
  621. # oid to local .1.3.6.1.3.10 oid (another way to access mulitple hosts
  622. # without using contexts)
  623. proxy -v 3 -l noAuthNoPriv -u user remotehost .1.3.6.1.3.10 .1.3.6.1.2.1.1
  624. .fi
  625. .RE
  626. .SH "PASS-THROUGH CONTROL"
  627. .IP "pass MIBOID EXEC"
  628. (If you're writing perl scripts, please see the embedded perl support
  629. information later in this manual page).  Passes entire control of
  630. MIBOID to the EXEC program.  The EXEC program is called in one of the
  631. following three ways:
  632. .RS
  633. .IP "EXEC -g MIBOID"
  634. .IP "EXEC -n MIBOID"
  635. .IP
  636. These call lines match to SNMP get and getnext requests.  It is
  637. expected that the EXEC program will take the arguments passed to it
  638. and return the appropriate response through it's stdout.  
  639. .IP
  640. The first line of stdout should be the MIB OID of the returning value.
  641. The second line should be the TYPE of value returned, where TYPE is
  642. one of the text strings:
  643. .B string, integer, unsigned, objectid, timeticks, ipaddress, counter, 
  644. or
  645. .B gauge.
  646. The third line of stdout should be the VALUE corresponding with the
  647. returned TYPE.
  648. .IP
  649. For instance, if a script was to return the value integer value "42"
  650. when a request for .1.3.6.1.4.100 was requested, the script should
  651. return the following 3 lines:
  652. .br
  653. .RS
  654.   .1.3.6.1.4.100
  655. .br
  656.   integer
  657. .br
  658.   42
  659. .RE
  660. .IP
  661. To indicate that the script is unable to comply with the request due
  662. to an end-of-mib condition or an invalid request, simple exit and
  663. return no output to stdout at all.  An SNMP error will be generated
  664. corresponding to the SNMP noSuchName response.
  665. .IP "EXEC -s MIBOID TYPE VALUE"
  666. .IP 
  667. For SNMP set requests, the above call method is used.  The TYPE passed
  668. to the EXEC program is one of the text strings:
  669. .B integer, counter, gauge, timeticks, ipaddress, objid,
  670. or 
  671. .B string,
  672. indicating the type of value passed in the next argument.
  673. .IP
  674. Return nothing to stdout, and the set will assumed to have been
  675. successful.  Otherwise, return one of the following error strings to
  676. signal an error:
  677. .B not-writable, 
  678. or 
  679. .B wrong-type
  680. and the appropriate error response will be generated instead.
  681. .RS
  682. .IP Note:
  683. By default, the only community allowed to write (ie snmpset) to your
  684. script will be the "private" community,or community #2 if defined
  685. differently by the "community" token discussed above.  Which
  686. communities are allowed write access are controlled by the RWRITE
  687. definition in the snmplib/snmp_impl.h source file.
  688. .RE
  689. .RE
  690. .IP
  691. Example (in snmpd.conf):
  692. .IP
  693. pass .1.3.6.1.4.1.2021.255 /path/to/local/passtest
  694. .RE
  695. .IP "pass_persist MIBOID EXEC"
  696. Passes entire control of MIBOID to the EXEC program.  
  697. Similar to pass, but the EXEC program continues to run after the initial
  698. request is answered.  Also, pass and pass_persist block till they return.
  699. .IP
  700. Upon initialization, EXEC is passed the string "PING\n" in stdin,
  701. and it should respond by printing "PONG\n" to stdout.
  702. .IP
  703. For get and getnext requests, EXEC program is passed two lines,
  704. the command (get or getnext) and the MIB OID.  It should return
  705. three lines, the MIB OID, the TYPE of value returned,
  706. the VALUE corresponding with the returned TYPE.
  707. .IP
  708. For example, if the value for .1.3.6.1.4.100 was requested, the following
  709. 2 lines would be passed in to stdin:
  710. .br
  711. .RS
  712.   get
  713. .br
  714.   .1.3.6.1.4.100  
  715. .RE
  716. .IP
  717. To return the value, say, 42, the script would write to stdout:
  718. .br
  719. .RS
  720.   .1.3.6.1.4.100
  721. .br
  722.   integer
  723. .br
  724.   42
  725. .RE
  726. .IP
  727. To indicate that the script is unable to comply with the request due
  728. to an end-of-mib condition or an invalid request, print "NONE\n" to
  729. stdout.
  730. .IP
  731. Example (in snmpd.conf):
  732. .IP
  733. pass_persist .1.3.6.1.4.1.2021.255 /path/to/local/pass_persisttest
  734. .RE
  735. .SH "EMBEDDED PERL SUPPORT"
  736. .PP
  737. Warning: though embedded perl is working, not much functionality has
  738. been implemented yet and thus writing mib module pieces for the agent
  739. within perl is not trivial at this point.  It should get better in
  740. future releases.
  741. .PP
  742. The net-snmp package has ability to call perl scripts directly inside
  743. the agent through embedded perl technology (similar to mod_perl for
  744. the apache web server).  This must be turned on at compile time by
  745. passing --enable-embedded-perl to the configure script when the
  746. package is built.  To see if your package was built with embedded
  747. perl, run "net-snmp-config --configure-options" and see if that flag
  748. was used.
  749. .PP
  750. If compiled in, it defines the following snmpd.conf configuration
  751. directives:
  752. .IP "disablePerl true"
  753. This will turn off perl support entirely.  If the embedded perl
  754. support stops working due to a change in perl, etc, this will stop any
  755. calls to the perl core.
  756. .IP "perlInitFile FILE"
  757. Use FILE as the initialization file.  This file is normally
  758. DATADIR/snmp/snmp_perl.pl but this token can override that default.
  759. This file performs any in-perl initialization that is needed before
  760. the rest of the perl directives (below) are called.  It is sourced
  761. once just before the first perl directive is parsed.  See the default
  762. file for an example of the initialization it performs.
  763. .IP "perl EXPRESSION"
  764. Calls perl to evaluate an expression.  Normally you'd want to do
  765. something like register a function to call when an OID is requested,
  766. but you can really do anything perl related you want.  For example:
  767. .IP
  768. perl print "hello world\n";
  769. .IP
  770. is the most basic hello world example.
  771. .IP
  772. The init script by default initializes a $agent variable which
  773. is a pointer to a NetSnmp::agent object through which you can register
  774. callbacks when a section of the OID tree is hit:
  775. .nf
  776. perl use Data::Dumper;
  777. perl sub myroutine  { print "got called: ",Dumper(@_),"\n"; }
  778. perl $agent->register('mylink', '.1.3.6.1.8765', \&myroutine);
  779. .fi
  780. .IP
  781. Sourcing an external file:
  782. .RS
  783. .nf
  784. perl 'do /path/to/file.pl';
  785. .fi
  786. .RE
  787. .IP
  788. No better examples exist at the moment, unfortunately.  Look for
  789. improved support in future releases.  Comments on how this looks as an
  790. architecture are certainly appreciated now.
  791. .SH "DISMAN-EVENT-MIB SUPPORT (READ: SENDING TRAPS ON ERRORS)"
  792. .PP
  793. Warning: this implementation has not been extensively tested and is
  794. additionally not known to be entirely complete.  The concepts defined
  795. here should function appropriately, however, but no promises are made
  796. at this time.
  797. .PP
  798. If your agent was compiled with support for the DISMAN-EVENT-MIB (you
  799. can enable this by running the net-snmp configure script with the
  800. --with-mib-modules=disman/event-mib argument) you have support for
  801. having the agent check its own data at regular intervals and to send
  802. out traps when certain conditions occur.  Traps are sent when
  803. expressions are first noticed, not once per evaluation.  Once a test
  804. expression fires a trap, the test will have to fail again before a new
  805. trap is sent.  See the DISMAN-EVENT-MIB documentation for more
  806. details. This can be configured either using the MIB tables themselves
  807. or by using these special key words:
  808. .IP "agentSecName NAME"
  809. The DISMAN-EVENT-MIB support requires a valid user name for which to
  810. scan your agent with.  This can either be specified using the
  811. agentSecName token or by explicitly list one on the "monitor" lines
  812. described below using the -u switch.  Either way, a "rouser" line (or
  813. equivalent access control settings) must also be specified with the
  814. same security name name.  If you need an example, just do something
  815. like this:
  816. .RS
  817. .IP
  818. .nf
  819. agentSecName internal
  820. rouser internal
  821. .fi
  822. .RE
  823. .IP
  824. And everything below should work just fine.
  825. .IP "monitor [OPTIONS] NAME EXPRESSION"
  826. This token tells the agent to monitor itself for problems based on
  827. EXPRESSION.  Expression is a simple expression based on an oid, a
  828. comparison operator (!=, ==, <, <=, >, >=) and an integer value (see
  829. the examples below).  NAME is merely an arbitrary name of your
  830. choosing for administrative purposes only.  OPTIONS include the
  831. following possibilities:
  832. .RS
  833. .IP "-t"
  834. Use a threshold monitor instead of a boolean monitor.  This means that
  835. expression should be a low and high value.  If the given OID passes
  836. beyond the high value, a rising alarm will triggered.  A falling alarm
  837. will then be triggered after it falls below the low value.
  838. .IP "-r FREQUENCY"
  839. Monitors the given expression every FREQUENCY seconds.  The default is
  840. 600 (10 minutes). 
  841. .IP "-u SECNAME"
  842. Use the SECNAME security name for scanning the local host.
  843. Specifically, this SECNAME must then be given access control rights
  844. via something like the "rouser" snmpd.conf token for this expression
  845. to be valid at all.  If not specified, it uses the default security
  846. name specified by the agentsecname snmpd.conf token.  Either the -u
  847. flag or a valid agentsecname token must be specified (and that name
  848. must be given proper access control rights via a "rouser" token).
  849. .IP "-o OID"
  850. Specifies additional object values to be delivered with in the
  851. resulting trap in addition to the normal trap objects.  This is useful
  852. for obtaining other columns in the table for the row that triggered
  853. the expression.  See the examples below for more details.
  854. .IP "-e EVENTNAME"
  855. Specifies an event name that describes what to do when the trigger is
  856. fired.  Currently, this must be the name of a notificationEvent event
  857. as described below.
  858. .RE
  859. .IP
  860. The following example configuration checks the hrSWRunPerfTable table
  861. (listing running processes) for any process which is consuming > 10Mb
  862. of memory.  It performs this check every 600 seconds (the default).
  863. For every process it finds exceeding the limit, it will end out
  864. exactly one notification.  In addition to the normal hrSWRunPerfMem
  865. oid and value sent in the trap, the hrSWRunName object will also be
  866. sent.  Note that the hrSWRunName object actually occurs in a different
  867. table, but since the indexes to the two tables are the same this works
  868. out alright.
  869. .RS
  870. .IP
  871. .nf
  872. rouser me
  873. monitor -u me -o sysUpTime.0 -o hrSWRunName "high process memory" hrSWRunPerfMem > 10000
  874. .fi
  875. .fi
  876. .RE
  877. .IP
  878. The above line would produce a trap which, when formated by snmptrapd, would
  879. look like:
  880. .RS
  881. .IP
  882. .nf
  883. 2002-04-05 13:33:53 localhost.localdomain [udp:127.0.0.1:32931]:
  884.         sysUpTimeInstance = Timeticks: (1629) 0:00:16.29        snmpTrapOID.0 = OID: mteTriggerFired    mteHotTrigger = high process memory     mteHotTargetName =      mteHotContextName =     mteHotOID = OID: hrSWRunPerfMem.1968    mteHotValue = 28564     hrSWRunName.1968 = "xemacs"
  885. .fi
  886. .RE
  887. .IP
  888. This shows my xemacs process using 28Mb of resident memory.  Which,
  889. considering it's xemacs, is not that surprising.
  890. .IP
  891. Threshold example:
  892. .RS
  893. .nf
  894. .IP
  895. monitor -t -r 15 -o prNames -o prErrMessage "process table" prErrorFlag 0 1
  896. .fi
  897. .RE
  898. .IP "notificationEvent NAME NOTIFICATION [[-w] OID_OBJECT ...]"
  899. This will create a notification event, which can be fired by attaching
  900. it to a monitor using a monitor's -e switch and an identical NAME
  901. field.  The NOTIFICATION to be sent should be the OID of a
  902. notification.  Additional objects can be included, and by default the
  903. suffix of the row/object being monitored will be appended to the
  904. object identifier unless it's told not to be a wild-card object by
  905. prefixing it with the -w switch.  EG, if you're monitoring the ifTable
  906. and you want your trap to include the ifDescr object for the row that
  907. was discovered, don't add the -w switch and the .INDEX field will be
  908. appended.  If the OID is fully qualified (EG, "sysContact.0") and no
  909. instance suffix should be appended to it then add a -w switch before
  910. it.  See the linkUpDownNotifications token below for example usage of
  911. this token to send the linkUp and linkDown traps.
  912. .IP "linkUpDownNotifications yes"
  913. This will make the DISMAN-EVENT-MIB support watch the ifTable to
  914. determine when a network interface is taken up or down.  When this
  915. happens, a linkUp or linkDown notification will be triggered.  This is
  916. exactly equivalent to doing:
  917. .RS
  918. .IP
  919. .nf
  920. notificationEvent  linkUpTrap    linkUp   ifIndex ifAdminStatus ifOperStatus
  921. notificationEvent  linkDownTrap  linkDown ifIndex ifAdminStatus ifOperStatus
  922. monitor  -r 60 -e linkUpTrap   "Generate linkUp" ifOperStatus != 2
  923. monitor  -r 60 -e linkDownTrap "Generate linkDown" ifOperStatus == 2
  924. .fi
  925. .RE
  926. .IP "defaultMonitors yes"
  927. By default, the agent and the DISMAN-EVENT-MIB support do nothing
  928. until configured.  Typically people wish to watch a bunch of tables
  929. within the UCD-SNMP-MIB which are designed specifically for reporting
  930. problems.  If the "defaultMonitors yes" line is put into the
  931. snmpd.conf file (which must be accompanied by an appropriate
  932. agentSecName line and a rouser line), the following monitoring
  933. conditions will be installed:
  934. .RS
  935. .IP
  936. .nf
  937. monitor -o prNames -o prErrMessage "process table" prErrorFlag != 0
  938. monitor -o memErrorName -o memSwapErrorMsg "memory" memSwapError != 0
  939. monitor -o extNames -o extOutput "extTable" extResult != 0
  940. monitor -o dskPath -o dskErrorMsg "dskTable" dskErrorFlag != 0
  941. monitor -o laNames -o laErrMessage  "laTable" laErrorFlag != 0
  942. monitor -o fileName -o fileErrorMsg  "fileTable" fileErrorFlag != 0
  943. .fi
  944. .RE
  945. .SH "DEBUGGING AND OTHER EXTENSIBILITY NOTES"
  946. If you're trying to figure out aspects of the various mib modules
  947. (possibly some that you've added yourself), the following may help you
  948. spit out some useful debugging information.  First off, please read
  949. the snmpd manual page on the -D flag.  Then the following
  950. configuration snmpd.conf token, combined with the -D flag, can produce
  951. useful output:
  952. .IP "injectHandler HANDLER modulename"
  953. This will insert new handlers into the section of the mib tree
  954. referenced by "modulename".  The types of handlers available for
  955. insertion are:
  956. .RS
  957. .nf
  958. stash_cache  - Caches information returned from the lower level.  This
  959.                greatly help the performance of the agent, at the cost
  960.                of caching the data such that its no longer "live" for
  961.                30 seconds (in this future, this will be configurable).
  962.                Note that this means snmpd will use more memory as well
  963.                while the information is cached.  Currently this only
  964.                works for handlers registered using the table_iterator
  965.                support, which is only a few mib tables.  To use it,
  966.                you need to make sure to install it before the
  967.                table_iterator point in the chain, so to do this:
  968.                   injectHandler stash_cache NAME table_iterator
  969.                If you want a table to play with, try walking the
  970.                nsModuleTable with and without this injected.
  971. debug        - Prints out lots of debugging information when
  972.                the -Dhelper:debug flag is passed to the snmpd
  973.                application.
  974. read_only    - Forces turning off write support for the given module.
  975. serialize    - If a module is failing to handle multiple requests
  976.                properly (using the new 5.0 module API), this will force
  977.                the module to only receive one request at a time.
  978. bulk_to_next - If a module registers to handle getbulk support, but
  979.                for some reason is failing to implement it properly,
  980.                this module will convert all getbulk requests to
  981.                getnext requests before the final module receives it.
  982. .fi
  983. .RE
  984. .IP "Figuring out module names"
  985. To figure out which modules you can inject things into, snmpwalk the
  986. nsModuleTable which will give you a list of all named modules
  987. registered within the agent.
  988. .SH "EXAMPLE CONFIGURATION FILE"
  989. See the EXAMPLE.CONF file in the top level source directory for a more
  990. detailed example of how the above information is used in real
  991. examples.
  992. .SH "RE-READING snmpd.conf AND snmpd.local.conf"
  993. The Net-SNMP agent can be forced to re-read its configuration files.
  994. It can be told to do so by one of two ways:
  995. .IP 1.
  996. An snmpset of integer(1) to UCD-SNMP-MIB::versionUpdateConfig.0
  997. (.1.3.6.1.4.1.2021.100.11.0)
  998. .IP 2.
  999. A "kill -HUP" signal sent to the snmpd agent process.
  1000. .SH "FILES"
  1001. SYSCONFDIR/snmp/snmpd.conf
  1002. .SH "SEE ALSO"
  1003. snmpconf(1), snmpusm(1), snmp.conf(5), snmp_config(5), snmpd(8), EXAMPLE.conf, read_config(3).
  1004. ." Local Variables:
  1005. ."  mode: nroff
  1006. ." End: