![]() |
![]() |
![]() |
![]() |
![]() |
At startup, the Oracle SNMP Agent Integrator (snmp_integrator) and the Oracle SNMP agent (tux_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 Oracle SNMP Agent Integrator and agents read certain configurations in the beamgr.conf file.
Note: If the BEA_SM_BEAMGR_CONF environment variable is not set, the Oracle SNMP Agent Integrator and agents look for beamgr.conf at the following default location:
• Windows systems: C:\etc\beamgr.conf
Note:
• UNIX systems: /etc/beamgr.confIf the Oracle 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.The beamgr.conf configuration file contains information used by the Oracle SNMP Agent Integrator and the Oracle SNMP agents. A configuration entry in the file consist of two or more blank or tab-separated fields:
• Specifies the version in which agent runs. Valid values are
1 (default): Only accepts and sends messages in SNMPv1.
3: Only accepts and sends messages in SNMPv3.
If you do not specify SYS_VERSION, SNMPv1 is used.Specifies that the engineID should be built from the given text STRING. The length of STRING must be less than 26.
Tuxedo SNMP's engineID includes two parts: the header and the given text STRING. The header's hexadecimal digits are 8000008C04.
In addition, snmp_integrator's engineID is built from the given text STRING directly, but tux_snmpd's engineID is built from the give text STRING and its logical name.
For example:
ENGINE_ID tux_snmpd
TMAGENT Dom1_SnmpAgt …
snmp_integrator's engineID is built from string tux_snmpd; its value is 8000008C047475785F736E6D7064.tux_snmpd's engineID is built from string tux_snmpdDom1_SnmpAgt; its value is 8000008C047475785F736E6D7064446F6D315F536E6D70416774.Because these options are put in the configuration file, the keys of authentication and privacy are put in the configuration file rather than the passwords of them. -v option in SNMP utilities is ignored, because only 3 is valid. For more information about command line options, see Oracle SNMP Agent Utilities.
Note: In terms of the community option, if you want to use it for CMD_PARAMETERS, you should specify -c community rather than community.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 Oracle SNMP Agent Integrator and the SNMP agents to determine trap destinations when they generate SNMP trap notifications.In SNMPv1, trap_community means the community name.
In SNMPv3, trap_community indicates a CMD_PARAMETERS paraName value that indicates which security and message processing is to be used in sending messages to a particular target.Indicates the engineID of the authoritative side of the message. The authoritative side is the SNMP agent. Valid values are:
- An octet string of 1 to 32 octets (2 to 64 hex digits).
- A '-' (dash) indicates the default value.
The default value is the local SNMP agent's engineID.Indicates whether the keys defined by authKey and privKey are localized or non-localized. Localized indicates that they have been generated with the appropriate engineID making the key usable only at one snmpEngine. Non-localized indicates the key may be used at different snmpEngines. The authKey and privKey, if both are specified, must both be localized or both be non-localized.
- L indicates keys are localized.
- M indicates keys are non-localized.
- '-' (dash) indicates default value is non-localized key.Authentication protocol to be used on authenticated messages on behalf of this user. It indicates the authentication protocol to be used on authenticated messages on behalf of this user. Valid values are:
- MD5 indicates HMAC-MD5.
- SHA indicates HMAC-SHA.
- '-' (dash) indicates the default value.
The default value is MD5 if an authentication key is specified; if no authentication key is specified, no authentication can be done for messages to/from this user.Authentication key to be used in authenticating messages on behalf of this user. The keyType field will indicate whether the key is localized or non-localized. Valid values are:
- An octet string of 16 bytes (32 hex digits) when authProto is MD5.
- An octet string of 20 bytes (40 hex digits) when authProto is SHA.
Default value is no key, indicating no encryption.Privacy protocol to be used on encrypted messages on behalf of this user. If authentication is not requested, this field is ignored. Valid values are:
- DES indicates CBC-DES (only with the additional encryption product).
- AES indicates CFB128-AES-128 (only with the additional encryption product).
- '-' (dash) indicates default value.
The default value is no privacy, meaning no encryption will be done on messages to/from this user.The privacy key to be used in authenticating message to and from this user. This field will be ignored when privProto is specified or defaulted as '-'. The keyType field will indicate whether the key is localized or non-localized. Privacy can be requested only if authentication is also requested. If authentication is not requested, this field is ignored. The privacy key and the authentication key are assumed to have been generated using the same authentication protocol (HMAC-MD5 or HMAC-SHA). Valid values are:
- An octet string of 16 bytes (32 hex digits) if the key is localized or if the key is non-localized and the authProto is HMAC-MD5.
- An octet string of 20 bytes (40 hex digits) if the key is localized or if the key is non-localized and the authProto is HMAC-SHA.
- '-' (dash) indicates default value.
The default value is no key, indicating no encryption.Maps a security name into a named group. Several group directives can specify the same group name, allowing a single access setting to apply to several users.
- groupName: Group name for the view-based access control model and must be unique to the SNMP agent.
- securityModel: Security model for this entry. The valid value is usm.
- securityName: User name defined by USM_USER.Defines a named view - a subset of the overall OID tree. This is most commonly a single subtree, but several view directives can be given with the same view name (VNAME), to build up a more complex collection of OIDs.Is either included or excluded, which can again define a more complex view. Valid values are: included or excluded.Must be null ("").Indicates the securityLevel for this entry. Valid values are:
- none: Indicates there is no authentication or privacy protocol.
- auth: Indicates authentication protocols are applied but no privacy protocol is applied.
- priv: Indicates both authentication and privacy protocols are applied.Specifies how CONTEXT should be matched against the context of the incoming request. Valid values are:
- exact indicates entire contextName must match.
- prefix indicates only the prefix of the contextName must match.Indicates the name of the view to be applied when read options are performed under control of this entryIndicates the name of the view to be applied when write operations are performed under control of this entry.Sets the Oracle SNMP Agent Integrator timeout in waiting for responses to requests. The default timeout is 30 seconds.You can set the Oracle SNMP Agent Integrator timeout by adding an INTEGRATOR_TIMEOUT entry as follows:Specifies the OIDs supported by an SNMP agent when it is running as a peer of the Oracle SNMP Agent Integrator. For more information, see “NON_SMUX_PEER Entry” on page 8‑9.Specifies an Oracle 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” on page 8‑15.Defines the Oracle Tuxedo domain that an agent is to monitor. There must be one TMAGENT entry for each Tuxedo SNMP agent on a managed node. The format of the entry is as follows:TMAGENT logical_agent_name tuxdir tuxconfig_pathA string that must be unique among all TMEVENT_FILTER entries in the Oracle SNMP Agent configuration file. The maximum length of the string is 16 characters.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.A Tuxedo event name expression. This string can be a maximum of 255 characters long. For information about event name expressions, which are regular expressions, see reference page tpsubscribe(3c) in Oracle Tuxedo ATMI 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 reference page EVENTS(5) in Oracle Tuxedo File Formats, Data Descriptions, MIBs, and System Processes 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 event filter expression. This string can be a maximum of 255 characters long. Each Tuxedo 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. Oracle SNMP Agent uses this filter as an argument for a call to tpsubscribe(). For more information, see reference page tpsubscribe(3c) in Oracle Tuxedo ATMI C Function Reference.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 Oracle 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 Oracle Tuxedo SNMP Agent MIB Reference.To configure the Oracle 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:when the SNMP agent is remote from the Oracle SNMP Agent Integrator. If ip_address or hostname is not specified, the Oracle SNMP Agent Integrator assumes that the peer SNMP agent is on the same managed node as the Oracle SNMP Agent Integrator.In SNMPv1, it specifies the community to be used by the Oracle SNMP Agent Integrator when the SNMP agent is polled. The special value * is used to specify that the Oracle SNMP Agent Integrator should use the community supplied by the SNMP manager.
In SNMPv3, it indicates a CMD_PARAMETERS paraName value that indicates which security and message processing is to be used in sending messages to a particular target.If an SNMP agent tries to register a subtree at a priority that is already taken, the Oracle 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.Specifies the time interval in seconds for which the Oracle 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.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.At any point, the command reinit_agent snmp_integrator can be invoked to force the Oracle SNMP Agent Integrator to re-read its configuration file.The Oracle SNMP Agent Integrator disallows/disregards any attempt to register above, at, or below the SNMP (mib2.snmp) and SMUX subtrees of the MIB.The following examples are provided to illustrate the use of the NON_SMUX_PEER entry:
• Consider the following sample entries in the beamgr.conf file:The first entry tells the Oracle SNMP Agent Integrator to look for an SNMP agent at port 2001. All the requests from Oracle 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 Oracle SNMP Agent Integrator to look for an SNMP agent at port 2002. All the requests from Oracle 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 Oracle 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 Oracle SNMP Agent Integrator sends nevus along to the subagent. (Of course, nevus must be a valid community for the Oracle 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.
• The following entry tells the Oracle SNMP Agent Integrator to look for an agent at port 2008 with a community of *. The agent supports two subtrees. The first has an access of rw, a priority of -1, and a timeout of two seconds; the second has an access of rw, a priority of -1, and a timeout of ten seconds. Although rw and -1 are the defaults for access and priority, these values must be stated explicitly in order to include a timeout value.The timeout values are the maximum amount of time the Oracle 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.
• The priority value decides which agent is consulted by the Oracle SNMP Agent Integrator in the event of a conflict. If more than one agent handles the same object, the one with the lowest number as a priority value is called. In the following entries, the agents on ports 2008 and 2009 both support object .1.3.6.1.2.1.1. The agent at port 2009 has a higher priority (5 is a higher priority than 8), so that is the one the Oracle SNMP Agent Integrator calls. Notice that this entry specifies rw access. The other entry specifies ro access, but since it has a lower priority, it is completely ignored. As far as the Oracle SNMP Agent Integrator is concerned, the only agent supporting .1.3.6.1.2.1.1 is at port 2009.The default is -1 if a priority is not specified. The Oracle 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.
• In the following entries, the Oracle SNMP Agent Integrator assigns a priority of 20 to the first entry and a priority of 19 to the second entry. Since 19 is a higher priority, the agent at port 2009 handles object .1.3.6.1.2.1.1 and the first entry is ignored. As before, the access is rw, since the entry specifying ro access is ignored.
• The MIB tree .1.3.6.1.2.1.11 is a special case, called mib2.snmp. This MIB group is always handled by the Oracle SNMP Agent Integrator itself, and should not be exported by any agent or subagent. Any registration at, above, or below this MIB tree is not permitted. For example, none of the following entries is permitted: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: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: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:The Oracle 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 Oracle 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 Oracle SNMP Agent Integrator for Polling” on page 7‑1.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 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.
• An absolute OID, that is, the full path to the object is specified from the root of the OID tree. An initial dot is used to indicate that the path starts at root. For example: .1.3.6.1.2.1.1.1.0. Note that the trailing zero in this example is the instance index.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: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: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: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:See the table titled “Relations for Defining Conditions” on page 7‑4 for a list of valid relational operators.See the table in “Use of Logical Operators in Conditions” on page 7‑7 for a list of valid logical operators.TRAPID_ERR = numberIndicates that an enterprise-specific SNMP trap with trapid of number should be generated whenever there is a transition from false (OK) to true (ERR).TRAPID_OK = numberIndicates that an enterprise-specific SNMP trap with trapid of number should be generated whenever there is a transition from true (ERR) to false (OK).COMMAND_ERR = commandIndicates that command should be executed whenever there is a transition from false (OK) to true (ERR).COMMAND_OK = commandIndicates that command should be executed whenever there is a transition from true (ERR) to false (OK).The configuration file can contain multiple domains defined by multiple TMAGENTs. The instructions for setting up RULE_ACTION are as follows:
1. The TMAGENT entry defines the Oracle Tuxedo domain that an agent monitors. There must be one TMAGENT entry for a Tuxedo SNMP agent on a single managed node.
2. The RULE_ACTION entry is used to inform the SNMP manager of selective information gathered by the Oracle SNMP Agent Integrator.
3. The optional rule_name component, logical _agent_name, must be appended to rule_name if multiple Tuxedo SNMP agents are running on the same node and the rule uses any Tuxedo MIB objects.Unlike the beamgr.conf configuration file, which is mandatory, the beamgr_snmpd.conf passwords file is an optional configuration file. Even if the Oracle 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.The Oracle SNMP Agent Integrator and agents look for beamgr_snmpd.conf at the following default location:
• For Windows systems: C:\etc\beamgr_snmpd.conf
• For UNIX systems: /etc/beamgr_snmpd.confThe 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 parametersRecognized 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.A SMUX subagent obtains the password at startup by reading the value specified by the BEA_SMUX_PASSWD environment variable. If this variable is not set, the SMUX subagent does not specify a password when registering.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 Oracle 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.