C Abstract Hostnames in Detail

The instructions below should be followed during the Discover phase of Cloning process to help obtain the correct abstract hostnames for Fusion Applications, Identity Management and Databases.

Abstract hostnames are the source hostnames (whether physical or virtual) that are present in Oracle Fusion Applications directory paths, configuration files and metadata, and which will be maintained across clones. They must be added to the /etc/hosts file in each one of the target environment nodes so that those references resolve to the destination environment itself, not to the source.

For example: When MyCompany provisioned their source environment, the hostname used in the Provisioning wizard was fahost.mycompany.com. Thus, their environment will contain fahost.mycompany.com in many places, such as directory paths, configuration files, and metadata. When they clone this environment, the clones will also contain fahost.mycompany.com in the same places, as the cloning script does not edit these settings. In the destination environment, fahost.mycompany.com is an abstract hostname and must be added to the /etc/hosts file in each one of the target environment nodes.

Note: abstract hostnames are not the only hostnames that must be added to /etc/hosts on the target environment. This requirement also exists for internal HTTP endpoints and VIPs used for failover, which are also discussed in this document.

This chapter includes the following aspects of how to discover abstract hostnames for cloning:

• Section C.1.1, "Discovering Fusion Applications Nodes"

• Section C.1.2, "Discovering Identity Management Nodes"

• Section C.1.3, "Discovering Database Nodes"

C.1 How to Discover Abstract Hostnames for Cloning

There are separate processes for the Fusion Applications components and the Identity Management components.

C.1.1 Discovering Fusion Applications Nodes

In Fusion Applications nodes, the easiest way to determine the abstract hostname is to check the provisioning.rsp file in the source environment. The hostnames used in the Provisioning wizard (Domain Topology Configuration and Web Tier Configuration screens) are saved to the response file in the #Domain Topology and #Webtier Configuration sections. These are the abstract names used in the Discovery Workbook for their respective nodes. During the Clone phase, the cloning script uses Fusion Applications abstract hostnames to determine the path to each node's nodemanager startup script, when run in the famt mode.

Table C-1 Fusion Applications Example: Simple

Fusion Applications installed on host with hostname	fahost.mycompany.com
Hostname provided on the Provisioning wizard (Domain Topology)	fahost.mycompany.com
Hostname provided on the Provisioning wizard (Web Tier)	fahost.mycompany.com
Abstract hostname for node (must be added to /etc/hosts)	fahost.mycompany.com

C.1.1.1 Special Case: Web Tier and Fusion Applications on Same Node but Different Hostname Were Provided

If the web tier is installed on the same node as the rest of Fusion Applications, the entry for the web tier hostname in the provisioning response file (WEBTIER_HOST) is normally the same as for the Fusion Applications node. If for any reason it's different (yet they are in the same node), use the Fusion Applications hostname as the abstract name for that node and add the web tier hostname to the "Additional /etc/hosts File Entries" table in the "Virtual Hosts" tab of the Discovery Workbook. Both hostnames will have to be added to the /etc/hosts file before running the cloning scripts.

Table C-2 Single Node Install with Two Hostnames Special Case

Hostname as returned by the hostname command	fahost.mycompany.com
Hostname provided on the Provisioning wizard (Domain Topology)	fahost.mycompany.com
Hostname provided on the Provisioning wizard (Web Tier)	fawebtiervirtual.mycompany.com
Abstract hostname for node (must be added to /etc/hosts)	fahost.mycompany.com
Additional /etc/hosts file entries (all other hostnames	fawebtiervirtual.mycompany.com

C.1.1.2 Special case: Hostnames Provided during Provisioning Differ from Actual Hostnames

Normally, the hostname in the provisioning response file will match the physical hostname, as returned by the UNIX "hostname" command. If a source environment setup was done so that the hostname as returned by the UNIX hostname command and the hostname provided to the Provisioning Wizard were not the same, then there are two abstract names and both must be added to the /etc/hosts file.

In this case, the hostname provided to the Provisioning Wizard (and found in the provisioning.rsp file) is used in the Discovery Workbook as the Abstract Hostname of the respective node. The hostname as returned by the Unix hostname command should be added to the "Additional /etc/hosts File Entries" table in the "Virtual Hosts" tab.

Table C-3 Single Node Install with Web Tier All Using Different Names

Hostname as returned by the hostname command	fahost.mycompany.com
Hostname provided on the Provisioning wizard (Domain Topology)	favirtual.mycompany.com
Hostname provided on the Provisioning wizard (Web Tier)	fawebtiervirtual.mycompany.com
Abstract hostname for node (must be added to /etc/hosts)	favirtual.mycompany.com
Additional /etc/hosts file entries (all other hostnames	fahost.mycompany.com fawebtiervirtual.mycompany.com

C.1.2 Discovering Identity Management Nodes

For Identity Management (as installed in the Oracle Identity Management Enterprise Deployment Guide), abstract hostnames may vary depending on the topology and the hostnames/VIPs provided during the installation and configuration. As a rule of thumb, abstract hostnames for Identity Management nodes match the hostnames as returned by the Unix hostname command.

Identity Management abstract hostnames are not used by the cloning scripts; however they are used by the clone tool during validation, when "idm" mode is used. The tool will use the abstract hostname of the OAM and OVD nodes to validate the environment's OAM settings. Thus it is important to match the instructions below.

In any case, all Identity Management hostnames, as returned by the UNIX hostname command, and all virtual hostnames used during the Identity management installation must be added to the /etc/hosts file. Therefore, if any are not listed in the Abstract Hostname column of the Topology tab of the Discovery Workbook, ensure that they are added to the "Additional /etc/hosts file entries" table in the "Virtual Hosts" tab.

Note:

if the servers where IDM and Fusion Applications were installed have more than one network card, and the additional network cards are registered in DNS with a different name, these additional names may have ended up in some of the configuration files, even if the 'hostname' command returned the correct one.

More specifically, this has happened with the EMAGENT component and the unexpected hostname turned up on targets.xml.

These additional hostnames must also be added to /etc/hosts on the target.

C.1.2.1 Abstract Hostname of the OAM Node

Ensure the abstract hostname of the node containing OAM is the same as displayed on the OAM Console (System Configuration tab/ Common Configuration/ Server Instances area) in the field labeled "Host". If they don't match, running the cloning tool in validate idm mode may fail. However, it does not affect the actual clone creation.

C.1.2.2 Abstract hostname of the OVD Node

Ensure the abstract hostname of the node containing OVD is the same as displayed on the OAM Console (System Configuration tab/ Common Configuration/ Data Sources/User Identity Stores/ OIMIDStore page), in the field labeled "Location". If they don't match, running the cloning tool in validate idm mode may fail. However, it does not affect the actual clone creation.

C.1.2.2.1 Special case: OVD and OAM share the same node but have different abstract hostnames

In this case, use the OAM abstract hostname (Section C.1.2.1) as the Abstract Hostname of the respective node in the Discovery Workbook. Add the OVD abstract hostname (Section C.1.2.2) to the "Additional /etc/hosts file entries" table in the "Virtual Hosts" tab of the Discovery Workbook. In this case, running the cloning tool in validate idm mode may fail since the OVD abstract hostname does not exactly match the entry in the OAM configuration.However, it does not affect the actual clone creation.

C.1.2.2.2 Special case: Other components share the same node with different hostnames used during install

If any other components share the same node with OVD or OAM, follow the notes above to ensure the abstract hostnames match the appropriate hostname for OAM or OVD. For all other cases, simply use the hostnames as returned by the UNIX hostname command.

Table C-4 Single Node Install Identity Management Install

Hostname as returned by the hostname command	idmhost.mycompany.com
Hostnames provided during install and configuration	idstore.mycompany.com policystore.mycompany.comldaphost1.mycompany.comwebhost1.mycompany.comidmhost.mycompany.comidmhost
Hostname as displayed on the OAM Console	idmhost.mycompany.com
Abstract hostname for node (must be added to /etc/hosts)	idmhost.mycompany.com (matches the hostname displayed on the OAM Console)
Additional /etc/hosts file entries (all other hostnames	idstore.mycompany.compolicystore.mycompany.comldaphost1.mycompany.comwebhost1.mycompany.comidmhost

Table C-5 Two-Node Identity Management Install

Node 1 (OVD and OID)	Hostname as returned by the hostname command	idmhost1.mycompany.com
	Hostnames provided during install and configuration	idstore.mycompany.com policystore.mycompany.com ldaphost.mycompany.com idmhost1.mycompany.com idmhost1
	Hostname as displayed on the OAM Console	idstore.mycompany.com
	Abstract hostname for node (must be added to /etc/hosts)	idstore.mycompany.com(matches the hostname displayed on the OAM Console
	Additional /etc/hosts file entries (all other hostnames	idmhost1.mycompany.compolicystore.mycompany.comldaphost.mycompany.comwebhost.mycompany.comidmhost1
	Hostname as returned by the hostname command	idmhost2.mycompany.com
Node 2 (WLS and OHS)	Hostnames provided during install and configuration	webhost.mycompany.com idmhost2.mycompany.com idmhost2
	Hostname as displayed on the OAM Console	idmhost2.mycompany.com
	Abstract hostname for node (must be added to /etc/hosts)	idmhost2.mycompany.com (matches the hostname displayed on the OAM Console)
	Additional /etc/hosts file entries (all other hostnames	webhost.mycompany.comidmhost2

C.1.3 Discovering Database Nodes

Database abstract hostnames are the ones used during Identity Management and Fusion Applications installation. Database abstract hostnames are the only ones that will be changed by the clone tool.

When the cloning scripts are run, the tool uses the entries on the tables (located in the Databases tab of the Discovery Workbook) to rewire all database connections. Database information (hostname, port, SID, Service Name) from the source environment is replaced with the destination entries provided, so it's important that the source information you enter on the Discovery Workbook match what's in your source environment.

C.1.3.1 OID Database

The OID Database abstract hostname (or multiples, in the case of RAC databases) is the one used during OID installation. On an existing environment it can be identified by inspecting the tnsnames.ora file located in $OID_INSTANCE/config.

C.1.3.2 Identity Management (IDM) Database

The Identity Management database abstract hostname (or multiples, in the case of RAC databases) is the one used during installation of Oracle Identity and Access Management (OIM/OAM), as well as Fusion Applications provisioning.

It can be obtained by inspecting the provisioning.rsp file, or checking the WLS Console for the IDMDomain data sources (all data sources) and Fusion Applications domains data sources (OWSM data sources only).

C.1.3.3 Fusion Applications (FA) Database

The Fusion Applications Database abstract hostname (or multiples, in the case of RAC databases) is the one used during Fusion Applications provisioning and can be obtained by inspecting the provisioning.rsp file.

It can be identified on an existing environment by inspecting the FA domain data sources (with the exception of the OWSM and BI data sources, which instead point at the IDM Database and BI server respectively).

These abstract hostnames should be added to the respective node's Abstract Hostname column in the Topology tab as well as the Source DB Instances row for each database type (OID, IDM, FA) in the Databases tab of the Discovery Workbook.