|
|
|
|
|
|
| | | |
Configuration Files
The following sections describe the configuration files accessed by the BEA SNMP Agent Integrator and the BEA SNMP agents:
BEA SNMP Agent Configuration File: beamgr.conf
At startup, the BEA SNMP Agent Integrator (snmp_integrator) and the BEA SNMP agents (tux_snmpd, wle_snmpd) read the absolute pathname specified by the BEA_SM_BEAMGR_CONF environment variable to locate the beamgr.conf configuration file on the host system. The BEA SNMP Agent Integrator and agents read certain configurations in the beamgr.conf file.
Note: The BEA_SM_BEAMGR_CONF setting ends with filename beamgr.conf.
Default Location
If the BEA_SM_BEAMGR_CONF environment variable is not set, the BEA SNMP Agent Integrator and agents look for beamgr.conf at the following default location:
If the BEA SNMP Agent Integrator and agents cannot find the beamgr.conf file on the host system, they will print an error message and not start. The beamgr.conf file is a mandatory configuration file.
Description
The beamgr.conf configuration file contains information used by the BEA SNMP Agent Integrator and the BEA SNMP agents. A configuration entry in the file consist of two or more blank or tab-separated fields:
KEYWORD parameters
If an entry is too long, you can use the backslash (\) character as a continuation character at the end of the line. There should be a newline character immediately following the \ character.
The following keywords have corresponding MIB objects:
Keywords Used by All BEA SNMP Agent Components
Host name, port number, and community name necessary to send SNMP traps.
host_name trap_port trap_community
host_hame
The name of the target destination machine for the trap notification. The default is the local host.
You can have multiple TRAP_HOST entries in the configuration file if you need to send traps to multiple destinations.
The TRAP_HOST entry is used by the BEA SNMP Agent Integrator and the SNMP agents to determine trap destinations when they generate SNMP trap notifications.
Contains a value that indicates whether the SNMP agent is permitted to generate authentication-failure traps. If the value is 1, the SNMP agent generates authentication-failure traps when an invalid request (according to the community profile) is received. If the value is not 1, no authentication-failure trap is generated.
The OID is a unique number assigned to each object in the MIB as an object identifier. OIDs fall into specific categories or classes. When the SNMP agent accesses a specific object, it traverses the OID tree in the MIB file to find the object. An OID identifies an object by specifying a unique path to the object from the root of the OID tree.
Keywords Used by the BEA SNMP Agent Integrator
Sets the BEA SNMP Agent Integrator timeout in waiting for responses to requests. The default timeout is 30 seconds.You can set the BEA SNMP Agent Integrator timeout by adding an INTEGRATOR_TIMEOUT entry as follows:
BEA_PEER MAX_WAIT 30
Sets the maximum number of times the BEA SNMP Agent Integrator permits requests to an SNMP peer or SMUX subagent to time out before disregarding any further requests for that agent or subagent. The default is 3.
Specifies the OIDs supported by an SNMP agent when it is running as a peer of the BEA SNMP Agent Integrator. For more information, see NON_SMUX_PEER Entry.
Specifies an BEA SNMP Agent Integrator polling rule. This allows threshold-checking to be offloaded from the network management system to the distributed integrator agents on managed nodes. For more information, see RULE_ACTION Entry.
Keywords Used by the BEA SNMP Agent
Defines the Tuxedo or WLE domain that an agent is to monitor. There must be one TMAGENT entry for each Tuxedo or WLE agent on a managed node. The format of the entry is as follows:
TMAGENT logical_agent_name tuxdir tuxconfig_path
Monitoring of multiple domains is performed by running a separate Tuxedo or WLE agent for each domain being monitored. These agents must be run as SMUX subagents under the BEA SNMP Agent Integrator.
When there are multiple Tuxedo or WLE SNMP agents running as SMUX subagents on a managed node, the logical agent name must be used to modify the community in Set or Get requests. The community must be of the following form:
community@logical_agent_name
For example:
public@payrollagent
The community does not need to be qualified with the logical agent name when there is only one Tuxedo or WLE SNMP agent running on the managed node.
Defines a subset of Tuxedo event notifications that are to be forwarded as SNMP trap notifications. By default, if no filter is provided, BEA SNMP Agent forwards all Tuxedo events as SNMP traps. The format of the entry is:
TMEVENT_FILTER filter_id logical_agent_name tux_evt_expr
tux_evt_filter status
Note that the strings used for each of the parameters must not have blanks or white space.
filter_id
A string that must be unique among all TMEVENT_FILTER entries in the BEA SNMP Agent configuration file. The maximum length of the string is 16 characters.
logical_agent_name
Maps the event filter to a particular agent on that node. A logical agent name is a string up to 32 characters long. The logical agent name is the name given to the Windows service on a Windows system that starts the agent, or the name specified in the -l option when starting the agent from the command line on a UNIX system.
tux_evt_expr
A Tuxedo event name expression. This string can be a maximum of 255 characters long. For information about event name expressions, see the reference page recomp, rematch(3c) in the BEA Tuxedo C Function Reference.
This name must match a Tuxedo event name for that event to be forwarded as an SNMP trap. For a list of event names, see the reference page EVENTS(5) in the BEA Tuxedo File Formats and Data Descriptions Reference.
The default is all events. If NONE is used, no events are forwarded and the other parameters in the TMEVENT_FILTER entry can be omitted. An entry of NONE overrides all other event filter entries for the same logical agent name. For example:
An entry of
\.Sys.*
matches all events.
An entry of
\.SysServer.*
matches all system events related to servers.
tux_evt_filter
An event filter expression. This string can be a maximum of 255 characters long. Each Tuxedo or WLE event is accompanied by an FML buffer that contains pertinent information about the event. The buffer is evaluated with respect to this filter if the filter is present. If the buffer content is evaluated to TRUE, the event is forwarded; otherwise the event is not forwarded. BEA SNMP Agent uses this filter as an argument for a call to tpsubscribe(). For more information, see the reference page tpsubscribe(3c) in the BEA Tuxedo C Function Reference.
status
Can be either active or inactive. If the status is active, the filter is being used; otherwise the filter is not being used.
There is a MIB table that corresponds to the TMEVENT_FILTER entries in the BEA SNMP Agent configuration file. These entries can be updated dynamically using an SNMP Set request. For more information, see the beaEvtFilterTable object in "Core MIB" in the BEA SNMP Agent MIB Reference.
NON_SMUX_PEER Entry
To configure the BEA SNMP Agent Integrator to access MIB objects through a peer SNMP agent (for example, a non-SMUX master agent or a non-SMUX peer agent), add the NON_SMUX_PEER entry to the beamgr.conf file in the following format:
NON_SMUX_PEER port community|*
OID_Node[,ro|rw][,priority][,timeout] ...
The keyword for the entry.
Specifies the UDP port number on which the SNMP agent is listening. This value may be specified in either of the following forms:
ip_address.port
hostname.port
when the SNMP agent is remote from the BEA SNMP Agent Integrator. If ip_address or hostname is not specified, the BEA SNMP Agent Integrator assumes that the peer SNMP agent is on the same managed node as the BEA SNMP Agent Integrator.
Specifies the community to be used by the BEA SNMP Agent Integrator when the SNMP agent is polled. The special value * is used to specify that the BEA SNMP Agent Integrator should use the community supplied by the SNMP manager.
Specifies the OID of the root of the MIB tree that is supported by this SNMP agent.
ro|rw
Specifies whether this OID tree is being exported as read-only or as read-write. The default is rw.
priority
A positive number that specifies the priority at which the OID tree is being exported. The lower the number, the higher the priority. If there are multiple agents/subagents supporting the same MIB tree, the subagent with the highest priority is consulted. Multiple SNMP agents and SMUX subagents can register the same subtree; however, they must do so at different priorities.
If an SNMP agent tries to register a subtree at a priority that is already taken, the BEA SNMP Agent Integrator repeatedly increments the integer value (lowering the priority) until an unused priority is found. A special priority -1, causes the selection of the highest available priority. When a request is made to register with priority -1, registration is made at the highest available number below 20. If the priority field is missing, the MIB tree is exported at a -1 priority.
timeout
Specifies the time interval in seconds for which the BEA SNMP Agent Integrator waits for the replies from this SNMP agent for the particular MIB group. The default value is three seconds. This default can be changed by setting the BEA_PEER_MAX_WAIT environment variable to a different value.
The access (ro or rw), priority, and timeout fields are optional. However, you must specify access and priority if you need to specify timeout, and you must specify access if you need to specify priority for a MIB tree.
You can list multiple OID nodes.
Note that a subtree registration hides the registrations by other SNMP agents/subagents of objects within the subtree. So, if an agent A registers subtree .1.3.6.1.4.1.140 and another agent/subagent, B, registers subtree .1.3.6.1.4.1.140.1, agent/subagent A is consulted for all the objects under the .1.3.6.1.4.1.140.1 subtree.
Also, when the BEA SNMP Agent Integrator reads this entry, an SNMP agent should be running on the specified port. Otherwise, the BEA SNMP Agent Integrator disregards this entry. Also, if three consecutive requests to this SNMP agent time out, it is assumed that the SNMP agent specified by this entry is no longer alive and this entry is disregarded.
At any point, the command reinit_agent snmp_integrator can be invoked to force the BEA SNMP Agent Integrator to re-read its configuration file.
The BEA SNMP Agent Integrator disallows/disregards any attempt to register above, at, or below the SNMP (mib2.snmp) and SMUX subtrees of the MIB.
NON_SMUX_PEER Examples
The following examples are provided to illustrate the use of the NON_SMUX_PEER entry:
NON_SMUX_PEER 2001 snmp .1.3.6.1.2.1.1,ro
NON_SMUX_PEER 2002 squid .1.3.6.1.4.1.141 .1.3.6.1.4.1.145
NON_SMUX_PEER 2008 * .1.3.6.1.4.1,ro
NON_SMUX_PEER 2005 * .1.3.6.1.4.1.140 .1.3.6.1.4.1.145,rw
The first entry tells the BEA SNMP Agent Integrator to look for an SNMP agent at port 2001. All the requests from BEA SNMP Agent Integrator to this SNMP agent use snmp as the community. The agent supports the subtree .1.3.6.1.2.1.1, and is available for read-only commands.
The second entry tells the BEA SNMP Agent Integrator to look for an SNMP agent at port 2002. All the requests from BEA SNMP Agent Integrator to this SNMP agent use squid as the community. The agent supports the subtrees .1.3.6.1.4.1.141 and .1.3.6.1.4.1.145. Since no access option is specified, both subtrees default to rw.
The third entry specifies a non-SMUX agent at port 2008 with a community of *. The * tells the BEA SNMP Agent Integrator to pass along the same community information it receives from the SNMP manager. For example, if the SNMP manager sends the community nevus, the BEA SNMP Agent Integrator sends nevus along to the subagent. (Of course, nevus must be a valid community for the BEA SNMP Agent Integrator in the first place.)
The fourth entry lists an agent at port 2005 with a community of *. The agent supports two subtrees: .1.3.6.1.4.1.140 and .1.3.6.1.4.1.145. Since the first subtree lists no access information, access defaults to rw. The second subtree specifically lists rw. This means exactly the same thing; the rw could have been left off with no effect.
If the rw is redundant, then why have it at all? Because each OID node can have three arguments: access (ro or rw), priority, and timeout. If you specify any of these arguments, you must also specify all the arguments that come before it. For example, if you specify priority, you must also specify access. If you specify timeout, you must specify both access and priority.
NON_SMUX_PEER 2008 * .1.3.6.1.2.1.1,rw,-1,2
.1.3.6.1.2.1.2,rw,-1,10
The timeout values are the maximum amount of time the BEA SNMP Agent Integrator waits for a response from the SNMP agent for a given object. In this case, two seconds for a response if the object falls under MIB tree .1.3.6.1.2.1.1, and ten seconds for a response if the object falls under the .1.3.6.1.2.1.2 MIB group. The default value is three seconds. This default value can be changed by setting the environment variable BEA_PEER_MAX_WAIT.
NON_SMUX_PEER 2008 * .1.3.6.1.2.1.1,ro,8
NON_SMUX_PEER 2009 * .1.3.6.1.2.1.1,rw,5
The default is -1 if a priority is not specified. The BEA SNMP Agent Integrator reads through the file sequentially. When it comes to an object with a -1 priority, it tries to assign it a priority of 20. If 20 has already been assigned to that MIB group (in another entry), it tries to assign 19. It keeps trying each successive lower number until it finds one that is not taken, or until it reaches 0, in which case an error message appears.
NON_SMUX_PEER 2008 * .1.3.6.1.2.1.1,ro
NON_SMUX_PEER 2009 * .1.3.6.1.2.1.1
NON_SMUX_PEER 2005 * .1.3.6.1.2.1
NON_SMUX_PEER 2006 * .1.3.6.1.2.1.11
NON_SMUX_PEER 2007 * .1.3.6.1.2.1.11.7
The first includes mib2.snmp, the second specifies it exactly, and the third specifies a part of it.
If an SNMP agent wants to support mib2 (except for the snmp group, as it is not permitted), you need to enter each of the mib2 subtrees explicitly:
NON_SMUX_PEER 2002 * .1.3.6.1.2.1.1 .1.3.6.1.2.1.2
.1.3.6.1.2.1.3 .1.3.6.1.2.1.4 .1.3.6.1.2.1.5
.1.3.6.1.2.1.6 .1.3.6.1.2.1.7 .1.3.6.1.2.1.8
.1.3.6.1.2.1.9 .1.3.6.1.2.1.10
Note: To continue an entry on another line, use a backslash. Make sure that there are no characters (other than the carriage return) immediately following the backslash.
NON_SMUX_PEER 2000 * .1.3.6.1.4.1.140.100.5.1.2.1
specifies row 1 of the second column of table object .1.3.6.1.4.1.140.100.5.1. Row 1 is not necessarily the first row. 1 is simply a unique identifier for the row.
Notice that .1.3.6.1.4.1.140.100.5.1.2 refers to the whole second column. To associate the two rows with different subagents, you need to specify each object in the row:
NON_SMUX_PEER 2000 * .1.3.6.1.4.1.140.100.5.1.1.1
.1.3.6.1.4.1.140.100.5.1.2.1 .1.3.6.1.4.1.140.100.5.1.3.1
.1.3.6.1.4.1.140.100.5.1.4.1
.1.3.6.1.4.1.140.100.5.1.5.1
NON_SMUX_PEER 2002 * .1.3.6.1.4.1.140.100.5.1.1.2
.1.3.6.1.4.1.140.100.5.1.2.2 .1.3.6.1.4.1.140.100.5.1.3.2
.1.3.6.1.4.1.140.100.5.1.4.2
.1.3.6.1.4.1.140.100.5.1.5.2
The first entry lists the object in row 1 in each of the five columns. The second entry lists the object in row 2 in each of the five columns.
OID_CLASS Entry
This entry is used by the SMUX subagents. Normally, these SMUX subagents register all the MIB groups they know about with the SMUX master agent. But you can limit the MIB groups exported by the SMUX subagents. To do so, you need to add an OID_CLASS entry to beamgr.conf in the following format:
OID_CLASS agent_name OID_Node[,ro|rw] [,priority] ..
The keyword for the entry.
Specifies the name of the SMUX subagent for which this entry is applicable.
Specifies the OID of the tree that is supported by this SMUX subagent.
Specifies whether this OID tree is being exported as read-only or as read-write. The default is rw.
A positive number that specifies the sequence in which the OID tree is being exported. The lower the number, the higher the priority. If there are multiple subagents supporting the same MIB tree, the subagent with the highest priority is consulted. If the priority field is missing, the MIB tree is exported at the highest available priority. This entry is mainly used to limit the OID subtrees being exported by the BEA SNMP Agent Integrator SMUX subagents. If this entry is not present, the SMUX subagent exports all the MIB groups it knows about.
Multiple OID nodes can be listed.
RULE_ACTION Entry
The BEA SNMP Agent Integrator can be configured to manage locally on the managed node and inform the SNMP manager selectively to reduce polling traffic generated by the SNMP manager. The user can define rules in terms of MIB objects available locally using a C-like "IF" syntax, and accordingly send SNMP traps or execute commands locally (or both). The MIB object can be the one supported by the BEA SNMP Agent Integrator itself or the one supported by one of its SNMP agents or SMUX subagents. For a discussion of RULE_ACTION entries, with examples, see Using the BEA SNMP Agent Integrator for Polling.
The configuration is done in the beamgr.conf file. Syntax of the entry looks like the following:
RULE_ACTION rule_name frequency_in_secs
if (VAL(oid) rel_operator value) logical_op ( cond_2 ) ...
{ TRAPID_ERR=enterprise_specific_trapid
TRAPID_OK=enterprise_specific_trapid
COMMAND_ERR=executable COMMAND_OK=executable }
Note: The whole entry should appear on the same line, else the backslash (\) should be used as a continuation character. If \ is being used as a continuation character, a newline character should immediately follow it.
A keyword to identify this entry.
A unique identifier for each RULE_ACTION entry that is passed as a command-line argument to any commands specified as actions in the rule. This identifier can be a maximum of eight characters long.
The polling frequency (in seconds) at which the snmp_integrator should check the condition.
Each left-hand side of a condition should have this keyword, which should be followed by the object identifier (within parentheses) of the MIB object. Each rule can contain a maximum of ten VAL keywords.
An object identifier (OID). The OID must be specified only in numeric form and can be in one of the following formats:
mib-2.number.number ...
When the reserved word mib-2 appears as the leading sub-oid, .1.3.6.1.2.1. is assumed to be prefixed to the rest of the OID. For example:
mib-2.1.1.0
represents the absolute OID:
.1.3.6.1.2.1.1.1.0
enterprises.number.number ...
When the reserved word enterprises appears as the leading sub-oid, .1.3.6.1.4.1. is assumed to be prefixed to the rest of the OID. For example:
enterprises.140.1.0
represents the absolute OID:
.1.3.6.1.4.1.140.1.0
number.number.number ... ,
If there is no leading "." and the OID starts with a number, .1.3.6.1.4.1. is assumed to be prefixed to the rest of OID. For example:
140.1.1.0
represents the absolute OID:
.1.3.6.1.4.1.140.1.1.0
Columnar objects are used to represent a column of a tabular MIB group. Columnar objects, accordingly, can have multiple instances. The last number in an OID is used to specify the particular instance. A specific number can be used to specify a particular instance or the asterisk (*) wildcard can be used to specify all instances. Zero is used as the instance index in the case of scalar objects (objects that can have only one instance). The asterisk wildcard is only used to represent all instances of a columnar object. For example:
.1.3.6.1.4.1.140.1.1.0
specifies the single instance of a scalar object while
1.3.6.1.4.1.140.2.22.1.2.*
specifies all of the instances of a columnar object.
Note: When you specify multiple OIDs in a complex rule, you should not combine an OID that specifies a particular instance with an OID that uses a wildcard in the same rule. Also, when you use multiple OIDs with wildcards in a single rule, all the OIDs should specify objects only within the same table.
See the table titled Relations for Defining Conditions for a list of valid relational operators.
The RHS in a condition can be one of the following: number, string, IP address: number1.number2.number3.number4, or OID (as previously explained).
If RHS is an OID it must be enclosed in single quotes. Also, the type of value on RHS should correspond to the type of VALUE of the OID in LHS of the condition.
See the table titled Logical Operators for Specifying Complex Conditions for a list of valid logical operators.
Specifying Actions
You can take two actions whenever there is a transition in the state of a rule from true (ERR) to false (OK) and false (OK) to true (ERR)—namely, execute a command and/or generate an SNMP trap. When generic OIDs (those that use an asterisk to specify all instances of a columnar object) are used to define a rule, the rule state transitions from the OK state to the ERR state if the threshold evaluates to true for any row in the table; and the rule state transitions from ERR to OK if the threshold evaluates to false for all rows in the MIB table. Initially, the rule states of all rules are set to OK when the BEA SNMP Agent Integrator starts up (or is re-initialized using the reinit_agent command). Specify actions using the following keywords:
Indicates that an enterprise-specific SNMP trap with trapid of number should be generated whenever there is a transition from false (OK) to true (ERR).
Indicates that an enterprise-specific SNMP trap with trapid of number should be generated whenever there is a transition from true (ERR) to false (OK).
Indicates that command should be executed whenever there is a transition from false (OK) to true (ERR).
Indicates that command should be executed whenever there is a transition from true (ERR) to false (OK).
Setting Up RULE_ACTION for Multiple Domains
The configuration file can contain multiple domains defined by multiple TMAGENTs. The instructions for setting up RULE_ACTION are as follows:
TMAGENT logical_agent_name TUXDIR TUXCONFIG
RULE_ACTION rule_name frequency_in_secs
RULE_ACTION rule_name@logical_agent_name frequency_in_seconds
if (...
For example:
RULE_ACTION rule1@tux_snmpd10...
BEA SNMP Agent Passwords File: beamgr_snmpd.conf
Unlike the beamgr.conf configuration file, which is mandatory, the beamgr_snmpd.conf passwords file is an optional configuration file. Even if the BEA SNMP Agent Integrator and agents cannot find the beamgr_snmpd.conf file on the host system, they will still run as long as they can find the beamgr.conf file.
Default Location
The BEA SNMP Agent Integrator and agents look for beamgr_snmpd.conf at the following default location:
Description
The beamgr_snmpd.conf passwords file contains the SNMP community strings used as passwords in communication between agents and managers. On a UNIX system, the beamgr_snmpd.conf passwords file is installed with access privileges for root only. For password security, the read and write permissions for the beamgr_snmpd.conf file should be set to permit access only by root.
A configuration entry in the beamgr_snmpd.conf file consists of two or more blank or tab-separated fields:
KEYWORD parameters
Recognized values for KEYWORD are:
The string following this keyword specifies the read-write community for the agent. If this keyword is not present in the configuration file, the SNMP agent uses iview as the read-write community. Entries with this keyword can be repeated more than one time to specify more than one read-write community.
The string following this keyword specifies the read-only community for the agent. If this keyword is not present in the configuration file, the SNMP agent uses public as the read-only community. Entries with this keyword can be repeated more than one time to specify more than one read-only community.
The string following this keyword specifies the SMUX password. Any SMUX subagent that needs to register with the BEA SNMP Agent Integrator should specify this password. If this keyword is not present, no authentication is done by the BEA SNMP Agent Integrator.
The possible values for this keyword are YES or NO, with NO being the default. If set to YES, Set access for all SNMP agents is disabled.
If the BEA SNMP Agent Integrator and agents cannot find the beamgr_snmpd.conf file on the host system, they will use the default values for COMMUNITY_RW, COMMUNITY_RO, SMUX_PASSWD, and DISABLE_SET.
|
|
|
|
|
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|