3 The opmn.xml File

This chapter provides an overview of the opmn.xml file for Oracle Fusion Middleware. It features the following topics:

3.1 opmn.xml

The ORACLE_INSTANCE/config/OPMN/opmn/opmn.xml file is the main configuration file for OPMN. The opmn.xml file contains information for PM and system component specific configuration. The opmn.xml file shows you which system components OPMN is managing on your system.

The opmn.xml file is divided into three main sections: log files, notification-server, and process-manager.

  • log files: The log files configuration by default fully enables the standard log but disables the debug log

  • notification server: The notification-server configuration includes the OPMN listener ports as well as secure connection definition. Optional <topology> opmn.xml file element can be manually added for OPMN discovery.

  • process manager: The process-manager configuration includes all information required for each managed component.

The opmn.xml file does not contain component-specific element names. Component specific management code is located in the PM modules which are loaded by OPMN at startup according to what has been specified in the modules section of the opmn.xml file.

Each level has a specific set of configurations. In addition, there are several configuration elements that are accepted at more than one level to provide the flexibility of applying a configuration across an entire system component or just part of a component.

<ias-component>
   <process-type>
      <process-set>

<ias-component>: This entry represents the system component. It enables management of the component for processes such as starting and stopping.

<process-type>: This subcomponent of the <ias-component> entry declares the type of process to run by association with a specific PM module.

<process-set>: This sub-subcomponent of the <ias-component> entry enables you to declare different sets of optional runtime arguments and environments for the system component. <process-set> is an optional configuration element.

The opmn.xml file contains system component entries arranged in the hierarchical structure shown in the following Example 3-1.

Example 3-1 Element Entries in opmn.xml File

<ias-component id="ohs1"> 
   <process-type id="OHS">
      <process-set id="OHS">....

3.2 Automatic Restart

OPMN gives the user control over automatic death detection and restart of components; you can configure the parameters by which OPMN determines a process has died and disable automatic restart for individual components.

OPMN monitors the operation of its managed processes by the following methods:

  • Operating system level detection of system process death

  • Periodic ping requests to system processes

  • Periodic status notification from system processes (reverse-ping)

The ping and notification functionality is only used where appropriate according to the functionality of the system component.

OPMN automatically restarts system components that terminate unexpectedly. OPMN also restarts processes that are unresponsive according to the result of notification and ping operations.

See Also:

Chapter 6 for more information about the common configuration of the opmn.xml file.

3.3 OPMN Log Files

The log files generated by OPMN provide important information that can help you identify and diagnose performance and configuration issues. The Fusion Middleware Control Console makes reviewing these log files easier by helping you locate and view system component log files.

See Also:

3.4 Security

The OPMN local listener port used by ONS clients and PM administrative processes do not use Secure Socket Layer (SSL) encryption for security, but rely on two other mechanisms to ensure authorized access to the OPMN server:

  • OPMN binds the local listener port to the local host. Users on the local system can connect to this port and issue OPMN process control requests. Information requests are allowed on the OPMN request port, which is bound to the system IP. The request port does not have SSL encryption.

  • When the OPMN server process first starts up and successfully binds to the local port, it creates a string of printable ASCII characters which it uses as a key for local connections. All connection attempts on the local port must include this key or the connection is closed by the OPMN server. The ASCII character string is written into the ORACLE_HOME/opmn/.formfactor file. Processes that cannot access the .formfactor file are not permitted to interact with the OPMN server.

For security reasons, the OPMN server logs any attempts to connect to its local port with an invalid form factor key (a key that does not match the value written by this OPMN process into the .formfactor file). You may encounter the following:

  • You attempt to run the OPMN client manually with the wrong user identification. Only the application server user can read the value from the .formfactor file, and so requests or processes run as the wrong user is not able to provide the correct key to the OPMN server.

  • You attempt to run an OPMN client from the wrong Oracle instance. (It is possible to have multiple Oracle instances set up on the same system.) If the other Oracle instances have OPMN configured to use the same local port then the system process request from the wrong Oracle instance reads the wrong .formfactor file.

  • You have manually changed the local port configuration in the opmn.xml file and started a new OPMN server without first stopping the previous OPMN server. The new OPMN server runs, binds to the new port, and overwrites the .formfactor file. The previous OPMN server is now unreachable through the local port, and can only be shutdown through remote OPMN requests (if SSL and authentication are configured) or by manually stopping the previous OPMN server.

  • Oracle Fusion Middleware and the Oracle Database both use ONS. When these two products are installed onto the same host, an ONS port conflict may arise if the port values configured for ONS are the same for both the Oracle Database and the Oracle Fusion Middleware component.

    ONS with the Oracle Database is only used for special configurations and therefore is typically never started. However, the database listener attempts to connect to the Database ONS server but ends up connecting to the ONS server that was installed with Oracle Fusion Middleware. ONS (as part of OPMN) is always started whenever Oracle Fusion Middleware is started.

    Because the Oracle Database is installed in a different location than that of Oracle Fusion Middleware, the Database ONS does not have access to the .formfactor file that was created when OPMN started up with the Oracle Fusion Middleware. As a result, the database listener attempts to connect to OPMN; the DB listener interprets it as a its standalone ONS) without a form factor string. OPMN logs an error similar to the following in the ons.log file:

    04/11/15 18:43:32 [4] Local connection 0,127.0.0.1,6100 invalid form factor
    

    This is expected OPMN behavior; preventing client access to the ONS server unless they possess the correct formfactor string.

    To avoid having the Oracle Database listener contact the system OPMN server, change the default local and remote port values for the ONS server that was installed with the Oracle Database.

3.5 IPv6 Support

ONS is able to concurrently support the IPv4 and IPv6 network interfaces.

IPv4 is version 4 of the Internet Protocol (IP). It was the first version of the Internet Protocol to be widely deployed, and forms the basis for most of the current Internet (as of 2004).

IPv4 uses 32-bit addresses, limiting it to 4,294,967,296 unique addresses, many of which are reserved for special purposes such as local networks or multicast addresses, reducing the number of addresses that can be allocated as public Internet addresses.

IPv6 is intended to address the concern that there are too few IP addresses available for the future demand of device connectivity (especially cell phones and mobile devices). IPv6 supports 340 undecillion (3.4 × 1038) addresses.

As shown in Figure 3-1, for output, such as debug or log records, each IPv4 identifier is displayed as four, eight bit fields for the address (each a three digit decimal format) and a single 16 bit field for the port (a five digit decimal format).

Each IPv6 identifier is displayed as eight 16 bit fields for the address (each a four digit hexidecimal format) and a single 16 bit field for the port (the five digit decimal format).

Figure 3-1 IPv4 and IPv6 Host Identifier

Description of Figure 3-1 follows
Description of "Figure 3-1 IPv4 and IPv6 Host Identifier"