18 Configuring Oracle Managed File Transfer in an Enterprise Deployment

The procedures explained in this chapter guide you through the process of adding Oracle Managed File Transfer to your enterprise deployment.

About Oracle Managed File Transfer

Oracle Managed File Transfer (MFT) provides a standards-based file gateway. It features design, deployment, and monitoring of file transfers by using a web-based design-time console that includes transfer prioritization, file encryption, scheduling, and embedded FTP and sFTP servers.

For more information about Oracle MFT, see Understanding Oracle Managed File Transfer in Using Oracle Managed File Transfer.

About Managed File Transfer in an Enterprise Deployment

Managed File Transfer runs in its own domain, separate from other components, such as Oracle SOA Suite, Oracle Service Bus, and Business Activity Monitoring. Typically, you create the domain and configure the Managed Servers for Managed File Transfer in a single configuration wizard session.

Managed File Transfer uses Oracle Web Services Manager (OWSM), and runs the OWSM services on the same servers as the Managed File Transfer applications.

Figure 18-1 illustrates the Managed File Transfer deployment topology.

For a description of the standard elements shown in the diagram, see Understanding the Typical Enterprise Deployment Topology Diagram.

For a description of the elements shown in the diagram, see Understanding the Primary Oracle SOA Suite Topology Diagrams.

Figure 18-1 Managed File Transfer Topology

Description of Figure 18-1 follows
Description of "Figure 18-1 Managed File Transfer Topology"

The Managed File Transfer domain can be configured on the same host as other FMW components. For this reason, Oracle recommends that you use a per host Node Manager configuration. In this configuration, a single Node Manager can control different domains on the same machine. See Configuring a Per Host Node Manager for an Enterprise Deployment.

Characteristics of the Managed File Transfer Domain

The following table lists some of the key characteristics of the domain that you are about to create. By reviewing and understanding these characteristics, you can better understand the purpose and context of the procedures used to configure the domain.

Many of these characteristics are described in more detail in Understanding a Typical Enterprise Deployment.

Characteristic of the Domain More Information

Uses a separate virtual IP (VIP) address for the Administration Server.

Configuration of the Administration Server and Managed Servers Domain Directories

Uses separate domain directories for the Administration Server and the Managed Servers in the domain.

Configuration of the Administration Server and Managed Servers Domain Directories

Uses Oracle Web Services Manager, which is deployed to the same servers as Managed File Transfer

Using Oracle Web Services Manager in the Application Tier

Uses the Load Balancer for routing SFTP requests from clients to MFT servers.

Configuring Oracle Load Balancer for SFTP Services

Uses a single Configuration Wizard session to configure the Infrastructure and Managed File Transfer software on the Managed File Transfer Managed Servers.

Creating the Managed File Transfer Domain for an Enterprise Deployment

Uses a per host Node Manager configuration.

About the Node Manager Configuration in a Typical Enterprise Deployment

Requires a separately installed LDAP-based authentication provider.

Understanding OPSS and Requests to the Authentication and Authorization Stores

Variables Used When Configuring Managed File Transfer

The procedures for installing and configuring Managed File Transfer reference use a series of variables that you can replace with the actual values used in your environment.

The following directory location variables are used in these procedures:

  • ORACLE_HOME

  • JAVA_HOME

  • NM_HOME

  • ASERVER_HOME

  • MSERVER_HOME

  • WEB_ORACLE_HOME

  • WEB_DOMAIN_HOME

See File System and Directory Variables Used in This Guide.

In addition, you reference the following virtual IP (VIP) address that are defined in Reserving the Required IP Addresses for an Enterprise Deployment:

  • ADMINVHN

Actions in this chapter are performed on the following host computers:

  • APPHOST1

  • APPHOST2

  • WEBHOST1

  • WEBHOST2

Note:

Note that for this chapter, APPHOST1 and APPHOST2 provide a more generic variable for the application tier hosts. This is because, depending upon the domain you are creating, the host name variable varies.

Synchronizing the System Clocks

Verify that the system clocks on each host computer are synchronized.

Oracle recommends the use of the Network Time Protocol (NTP). See Configuring a Host to Use an NTP (time) Server.

To verify the time synchronization, query the NTP service by running the chronyc -n tracking command on each host.

Sample output:


$chronyc -n tracking
Reference ID : A9FEA9FE (169.254.169.254)
Stratum : 3
Ref time (UTC) : Tue Jan 14 15:28:01 2025
System time : 0.000043127 seconds fast of NTP time
Last offset : +0.000034640 seconds
...

Prerequisites for Creating the Managed File Transfer Domain

Before you create the Managed File Transfer domain, ensure that your existing deployment meets the following prerequisites.

  • You must have a supported database to install the schemas used by the MFT domain.

  • Verify that you have installed a supported JDK.

  • You must have an existing Oracle home where you have installed the Oracle Fusion Middleware Infrastructure software binaries. This must be a dedicated Oracle home for the Managed File Transfer domain. The Oracle home is typically on shared storage and is available from MFTHOST1 and MFTHOST2. See Shared Storage Recommendations When Installing and Configuring an Enterprise Deployment.

    Note that you should not configure the Infrastructure domain, only install the Oracle Fusion Middleware Infrastructure software.

    To create the Infrastructure Oracle home, see Installing the Oracle Fusion Middleware Infrastructure on SOAHOST1.

  • Back up the installation. If you have not yet backed up the existing Fusion Middleware Home, Oracle recommends backing it up now.

    To back up the existing Fusion Middleware Home and domain, see Performing Backups and Recoveries in the SOA Enterprise Deployments.

  • If you have not done so already, verify that the system clocks on each host computer are synchronized. You can do this by running the date command as simultaneously as possible on the hosts in each cluster.

    Alternatively, there are third-party and open-source utilities that you can use for this purpose.

Installing the Software for an Enterprise Deployment

The procedure to install the software for an enterprise deployment is explained in this section.

Starting the Managed File Transfer Installer on MFTHOST1

To start the installation program:

  1. Log in to MFTHOST1.
  2. Go to the directory where you downloaded the installation program.
  3. Launch the installation program by invoking the java executable from the JDK directory on your system, as shown in the example below.
    JAVA_HOME/bin/java -jar Installer File Name

    Be sure to replace the JDK location in these examples with the actual JDK location on your system.

    Replace Installer File Name with the name of the actual installer file for your product listed in Identifying and Obtaining Software Distributions for an Enterprise Deployment.

When the installation program appears, you are ready to begin the installation.

Navigating the Installation Screens When Installing Managed File Transfer

The installation program displays a series of screens, in the order listed in the following table.

If you need additional help with any of the installation screens, click the screen name.

Screen Description

Welcome

This screen introduces you to the product installer.

Auto Updates

Use this screen to automatically search My Oracle Support for available patches or automatically search a local directory for patches that you have already downloaded for your organization.

Installation Location

Use this screen to specify the location of your Oracle home directory. This Oracle home should already contain Oracle Fusion Middleware Infrastructure.

For more information about Oracle Fusion Middleware directory structure, see Selecting Directories for Installation and Configuration in Planning an Installation of Oracle Fusion Middleware.

Prerequisite Checks

This screen verifies that your system meets the minimum necessary requirements.

If there are any warning or error messages, you can refer to one of the documents in the Roadmap for Verifying Your System Environment section in Installing and Configuring the Oracle Fusion Middleware Infrastructure.

Installation Summary

Use this screen to verify the installation options that you selected.

Click Install to begin the installation.

Installation Progress

This screen allows you to see the progress of the installation.

Click Next when the progress bar reaches 100% complete.

Installation Complete

Review the information on this screen, then click Finish to dismiss the installer.

Installing the Software on Other Host Computers

If you have configured a separate shared storage volume or partition for SOAHOST2, then you must also install the software on SOAHOST2. For more information, see Shared Storage Recommendations When Installing and Configuring an Enterprise Deployment.

Note that the location where you install the Oracle home (which contains the software binaries) varies, depending upon the host. To identify the proper location for your Oracle home directories, refer to the guidelines in File System and Directory Variables Used in This Guide.

Verifying the Installation

After you complete the installation, you can verify it by successfully completing the following tasks.

Reviewing the Installation Log Files

Review the contents of the installation log files to make sure that no problems were encountered. For a description of the log files and where to find them, see Understanding Installation Log Files in Installing Software with the Oracle Universal Installer.

Checking the Directory Structure for Managed File Transfer

The contents of your installation vary based on the options that you select during installation.

Use the ls --format=single-colum command to check the list of directory and sub-directories in the /u01/oracle/products/fmw directory:

ls --format=single-colum $ORACLE_HOME

bin
coherence
em
install
inventory
jlib
lib
mft
OPatch
opmn
oracle_common
oraInst.loc
osb
oui
soa
wlserver

For more information about the directory structure you should see after installation, see What are the Key Oracle Fusion Middleware Directories? in Understanding Oracle Fusion Middleware.

Creating the Managed File Transfer Database Schemas

Before you can configure an Managed File Transfer domain, you must install the required schemas in a certified database for use with this release of Oracle Fusion Middleware.

Starting the Repository Creation Utility (RCU)

To start the Repository Creation Utility (RCU):

  1. Navigate to the $ORACLE_HOME/oracle_common/bin directory on your system.
    cd $ORACLE_HOME/oracle_common/bin
  2. Make sure that the JAVA_HOME environment variable is set to the location of a certified JDK on your system. The location should be up to but not including the bin directory. For example, if your JDK is located in /u01/oracle/products/jdk:

    On UNIX operating systems:

    export JAVA_HOME=/u01/oracle/products/jdk
  3. Start RCU:

    On UNIX operating systems:

    ./rcu

    Note:

    If your database has Transparent Data Encryption (TDE) enabled, and you want to encrypt your tablespaces that are created by the RCU, provide the -encryptTablespace true option when you start RCU.

    This defaults the appropriate RCU GUI Encrypt Tablespace checkbox selection on the Map Tablespaces screen without further effort during the RCU execution. See Encrypting Tablespaces in Creating Schemas with the Repository Creation Utility.

Navigating the RCU Screens to Create the Managed File Transfer Schemas

Schema creation involves the following tasks:

Task 1   Introducing RCU

Click Next.

Task 2   Selecting a Method of Schema Creation

If you have the necessary permission and privileges to perform DBA activities on your database, select System Load and Product Load. This procedure assumes that you have the necessary privileges.

If you do not have the necessary permission or privileges to perform DBA activities in the database, you must select Prepare Scripts for System Load on this screen. This option generates a SQL script, which can be provided to your database administrator to create the required schema. See Understanding System Load and Product Load in Creating Schemas with the Repository Creation Utility.

Click Next.

Task 3   Providing Database Connection Details

Provide the database connection details for RCU to connect to your database.

  1. As Database Type, select Oracle Database enabled for edition-based redefinition.

    Note:

    Oracle Database enabled for edition-based redefinition (EBR) is recommended to support Zero Down Time upgrades. For more information, see https://www.oracle.com/database/technologies/high-availability/ebr.html.
  2. In the Host Name field, enter the SCAN address of the Oracle RAC Database.

  3. Enter the Port number of the RAC database scan listener, for example 1521.

  4. Enter the RAC Service Name of the database.

  5. Enter the User Name of a user that has permissions to create schemas and schema objects, for example SYS.

  6. Enter the Password of the user name that you provided in step 4.

  7. If you have selected the SYS user, ensure that you set the role to SYSDBA.

  8. Click Next to proceed, then click OK on the dialog window confirming that the connection to the database was successful.

Task 4   Specifying a Custom Prefix and Selecting Schemas

On this page, do the following:

  1. Choose Create new prefix, and then enter the prefix that you want to use for the Managed File Transfer schemas. A unique schema prefix is required because you are creating a new domain for Managed File Transfer.

  2. From the list of schemas, select the Managed File Transfer schema.

    The following dependent schemas are selected automatically:

    • Common Infrastructure Services

    • Oracle Enterprise Scheduler

    • Oracle Platform Security Services

    • User Messaging Service

    • Audit Services

    • Audit Services Append

    • Audit Services Viewer

    • Metadata Services

    • Weblogic Services

The custom prefix is used to logically group these schemas together for use in this domain only; you must create a unique set of schemas for each domain as schema sharing across domains is not supported.

Tip:

For more information about custom prefixes, see Understanding Custom Prefixes in Creating Schemas with the Repository Creation Utility.

For more information about how to organize your schemas in a multi-domain environment, see Planning Your Schema Creation in Creating Schemas with the Repository Creation Utility.

Click Next to proceed, then click OK on the dialog window confirming that prerequisite checking for schema creation was successful.

Task 5   Specifying Schema Passwords

Specify how you want to set the schema passwords on your database, then specify and confirm your passwords. Ensure that the complexity of the passwords meet the database security requirements before you continue. RCU proceeds at this point even if you do not meet the password polices. Hence, perform this check outside RCU itself.

Tip:

You must make a note of the passwords you set on this screen; you need them later on during the domain creation process.

Click Next.

Task 6   Verifying the Tablespaces for the Required Schemas

On the Map Tablespaces screen, review the information, and then click Next to accept the default values.

Click OK in the confirmation dialog box.

Task 7   Creating Schemas

Review the summary of the schemas to be loaded, and click Create to complete schema creation.

Note:

If failures occurred, review the listed log files to identify the root cause, resolve the defects, and then use RCU to drop and recreate the schemas before you continue.

Task 8   Reviewing Completion Summary and Completing RCU Execution

When you reach the Completion Summary screen, verify that all schema creations have been completed successfully, and then click Close to dismiss RCU.

Verifying Schema Access

Verify schema access by connecting to the database as the new schema users created by the RCU. Use SQL*Plus or another utility to connect, and provide the appropriate schema names and passwords entered in the RCU.

For example:

Note:

If the database is a plugable database (PDB), the apropriate tns alias that points to the PDB must be used in the sqlplus command.
sqlplus FMW1412_MFT/<mft_schema_password>

SQL*Plus: Release 23.0.0.0.0 - Production on Tue Jun 11 10:54:41 2024
Version 23.4.0.24.05

Copyright (c) 1982, 2024, Oracle. All rights reserved.

Last Successful login time: Tue Jun 11 2024 10:52:21 +00:00

Connected to:
Oracle Database 23ai EE Extreme Perf Release 23.0.0.0.0 - Production
Version 23.4.0.24.05

SQL>

Creating the Managed File Transfer Domain for an Enterprise Deployment

You create a separate Managed File Transfer domain by using the Fusion Middleware Configuration Wizard.

Starting the Configuration Wizard

Start the Configuration Wizard as the first step to create the MFT enterprise deployment domain.

To start the Configuration Wizard, navigate to the following directory and start the WebLogic Server Configuration Wizard.:


cd $ORACLE_HOME/oracle_common/common/bin
./config.sh

Navigating the Configuration Wizard Screens to Configure the MFT Domain

Follow the instructions in this section to create and configure the domain for MFT, with static clusters.

Domain creation and configuration includes the following tasks.

Task 1   Selecting the Domain Type and Domain Home Location

You must select a Domain home directory location, optimally outside the Oracle home directory.

Oracle recommends that you locate your Domain home in accordance with the directory structure in What Are the Key Oracle Fusion Middleware Directories? in Understanding Oracle Fusion Middleware, where the Domain home is located outside the Oracle home directory. This directory structure helps avoid issues when you need to upgrade or reinstall software.

To specify the Domain type and Domain home directory:

  1. On the Configuration Type screen, select Create a new domain.

  2. In the Domain Location field, specify your Domain home directory.

For more information about this screen, see Configuration Type in Creating WebLogic Domains Using the Configuration Wizard

Task 2   Selecting the Configuration Templates

On the Templates screen, make sure Create Domain Using Product Templates is selected, then select the following templates:

  • Oracle Managed File Transfer [mft]

    Selecting this template automatically selects the following dependencies:

    • Oracle Enterprise Manager

    • Oracle B2B Client

    • Oracle JRF

    • Oracle WSM Policy Manager

    • WebLogic Coherence Cluster Extension

For more information about the options on this screen, see Templates in Creating WebLogic Domains Using the Configuration Wizard.

Task 3   Configuring High Availability Options

This screen appears for the first time when you create a cluster that uses Automatic Service Migration or JDBC stores or both. After you select HA Options for a cluster, all subsequent clusters that are added to the domain by using the Configuration Wizard, automatically apply HA options (that is, the Configuration Wizard creates JDBC stores and configures ASM for them).

On the High Availability Options screen:

  • Select Enable Automatic Service Migration with Database Basis.

  • Set JTA Transaction Log Persistence to JDBC TLog Store.

  • Set JMS Server Persistence to JMS JDBC Store.

Note:

Oracle recommends that you use JDBC stores, which leverage the consistency, data protection, and high availability features of an Oracle database and makes resources available for all the servers in the cluster. So, the Configuration Wizard steps assume that the JDBC persistent stores are used along with Automatic Service Migration.

When you choose JDBC persistent stores, additional unused File Stores are automatically created but are not targeted to your clusters. Ignore these File Stores.

If, for any reason, you want to use Files Stores, you can retain the default values for TLOGs and JMS persistent store options in this screen and configure them in a shared location later. See Task 12, "Selecting Advanced Configuration". Shared location is required to resume JMS and JTA in a failover scenario.

You can also configure TLOGs and JMS persistent stores manually in a post step. For information about the differences between JDBC and Files Stores, and for specific instructions to configure them manually, see Using Persistent Stores for TLOGs and JMS in an Enterprise Deployment.

Click Next.

Task 4   Selecting the Application Home Location

On the Application Location screen, specify the value of the APPLICATION_HOME variable, as defined in File System and Directory Variables Used in This Guide.

For more information about the options on this screen, see Application Location in Creating WebLogic Domains Using the Configuration Wizard.

Task 5   Configuring the Administrator Account

On the Administrator Account screen, specify the user name and password for the default WebLogic Administrator account for the domain.

Make a note of the user name and password specified on this screen; you need these credentials later to boot and connect to the domain's Administration Server.

Task 6   Specifying the Domain Mode and JDK

On the Domain Mode and JDK screen:

  • Select Production in the Domain Mode field.

  • In the Enable or Disable Default Ports for You Domain field, use the default values provided for Production Mode:

    • Ensure that Enable Listen Ports (non-SSL Ports) is NOT checked.

    • Ensure that Enable SSL Listen Ports is checked.

    • Ensure that Enable Administration Port (SSL Port) is checked.

      Tip:

      More information about the options on this screen, including the differences between development mode and production mode, can be found in Domain Mode and JDK in Creating WebLogic Domains Using the Configuration Wizard.
  • Select Oracle Hotspot JDK in the JDK field.

    Note:

    Ensure that it points to the folder where you have installed the JDK. See Installing the JDK Software.
Task 7   Specifying the Database Configuration Type

On the Database Configuration Type screen:

  • Select RCU Data to activate the fields on this screen.

    The RCU Data option instructs the Configuration Wizard to connect to the database and Service Table (STB) schema to automatically retrieve schema information for the schemas needed to configure the domain.

  • Verify that the Vendor is Oracle and the Driver is *Oracle's Driver (Thin) for Service Connections; Versions: Any.

  • Verify that Connection Parameters is selected.

Note:

If you select Manual Configuration on this screen, you must manually fill in the parameters for your schema on the JDBC Component Schema screen.

After you select RCU Data, fill in the fields as shown in the following table:

Field Description

DBMS/Service

Enter the service name for the Oracle RAC database where you install the product schemas. For example:

soaedg.example.com

Be sure this is the common service name that is used to identify all the instances in the Oracle RAC database; do not use the host-specific service name.

Host Name

Enter the Single Client Access Name (SCAN) Address for the Oracle RAC database, which you entered in the Enterprise Deployment Workbook.

Port

Enter the port number on which the database listens. For example, 1521.

Schema Owner

Schema Password

Enter the user name and password to connect to the database's Service Table schema.

This is the schema user name and password that was specified for the Service Table component on the Schema Passwords screen in RCU. See Creating the Database Schemas.

The default user name is prefix_STB, where prefix is the custom prefix that you have defined in RCU.

Click Get RCU Configuration when you finished specifying the database connection information. The following output in the Connection Result Log indicates that the operating succeeded:

Connecting to the database server...OK
Retrieving schema data from database server...OK
Binding local schema components with retrieved data...OK

Successfully Done.

Click Next if the connection to the database is successful.

For more information about the RCU Data option, see Understanding the Service Table Schema in Creating Schemas with the Repository Creation Utility.

For more information about the other options on this screen, see Datasource Defaults in Creating WebLogic Domains Using the Configuration Wizard.

Task 8   Specifying JDBC Component Schema Information

Verify that the values on the JDBC Component Schema screen are correct for all schemas.

The schema table should be populated, because you selected Get RCU Data on the previous screen. As a result, the Configuration Wizard locates the database connection values for all the schemas required for this domain.

At this point, the values are configured to connect to a single-instance database. However, for an enterprise deployment, you should use a highly available Real Application Clusters (RAC) database, as described in Preparing the Database for an Enterprise Deployment.

In addition, Oracle recommends that you use an Active GridLink datasource for each of the component schemas. For more information about the advantages of using GridLink data sources to connect to a RAC database, see Database Considerations in the High Availability Guide.

To convert the data sources to GridLink:

  1. Select all the schemas by selecting the checkbox in the first header row of the schema table.

  2. Click Convert to GridLink and click Next.

Task 9   Providing the GridLink Oracle RAC Database Connection Details

On the GridLink Oracle RAC Component Schema screen, provide the information that is required to connect to the RAC database and component schemas, as shown in following table.

Element Description and Recommended Value

Service Name

Verify that the service name for the Oracle RAC database is the appropriate. For example, soaedg.example.com.

SCAN, Host Name, and Port

Select the SCAN check box.

In the Host Name field, enter the Single Client Access Name (SCAN) Address for the Oracle RAC database.

In the Port field, enter the SCAN listening port for the database (for example, 1521).

ONS Host and Port

These values are not required when you are using an Oracle 12c database or higher versions because the ONS list is automatically provided from the database to the driver.

Enable Fan

Verify that the Enable Fan check box is selected, so that the database can receive and process FAN events.

For more information about specifying the information on this screen, as well as information about how to identify the correct SCAN address, see Configuring Active GridLink Data Sources with Oracle RAC in the High Availability Guide.

You can also click Help to display a brief description of each field on the screen.

Task 10   Testing the JDBC Connections

A green check mark in the Status column indicates a successful test. If you encounter any issues, see the error message in the Connection Result Log section of the screen, fix the problem, then try to test the connection again.

By default, the schema password for each schema component is the password you specified while creating your schemas. If you want different passwords for different schema components, manually edit them in the previous screen (JDBC Component Schema) by entering the password you want in the Schema Password column, against each row. After you specify the passwords, select the check box that correspond to the schemas that you changed the password in and test the connection again.

For more information about the other options on this screen, see Test Component Schema in Creating WebLogic Domains Using the Configuration Wizard.

Task 11   Specifying the Keystore

Use the Keystore screen in the Configuration Wizard to specify details about the keystore to be used in the domain.

For a typical enterprise deployment, you can leave the default values. See Keystore in Creating WebLogic Domains Using the Configuration Wizard

Task 12   Selecting Advanced Configuration

To complete domain configuration for the topology, select the following options on the Advanced Configuration screen:

  • Administration Server

    This is required to properly configure the listen address of the Administration Server.

  • Node Manager

    This is required to configure Node Manager.

  • Topology

    This is required to add, delete, or modify the Settings for Server Templates, Managed Servers, Clusters, Virtual Targets, and Coherence.

Note:

  • If any of the above options are not available on the screen, then return to the Templates screen and ensure that you have selected the required templates for this topology.

  • JDBC stores are recommended and selected in Task 3, "Configuring High Availability Options" so there is no need to configure File Stores.

Task 13   Configuring the Administration Server Listen Address

On the Administration Server screen:

  1. In the Server Name field, retain the default value "AdminServer".

  2. In the Listen Address field, enter the virtual host name that corresponds to the VIP of the ADMINVHN that you procured in Procuring Resources for an Enterprise Deployment and enabled in Preparing the Host Computers for an Enterprise Deployment.

    For more information about the purpose of using the ADMINVHN virtual host, see Reserving the Required IP Addresses for an Enterprise Deployment.

  3. In the Configure Administration Server Ports section, perform the following steps:

    1. Leave the Enable Listen Port field unchecked. The Listen Port value will be disabled in grey.

    2. Ensure the Enable SSL Listen port field is checked.

    3. Leave the default value as 7002 in the SSL Listen Port field.

    4. Leave the default value as 9002 in the Administration Port.

  4. Leave the default value as Unspecified in the Server Group.

Task 14   Configuring Node Manager (Per Host)

Select Manual Node Manager Setup as the Node Manager type.

WARNING:

You can ignore the warning in the bottom pane. This guide provides the required steps for the Manual Node Manager configuration.

Tip:

For more information about the options on this screen, see Node Manager in Creating WebLogic Domains Using the Configuration Wizard.

For more information about per domain and per host Node Manager implementations, see About the Node Manager Configuration in a Typical Enterprise Deployment.

For information about Node Manager configurations, see Configuring Node Manager on Multiple Machines in Administering Node Manager for Oracle WebLogic Server.

Task 15   Configuring Managed Servers

Use the Managed Servers screen to create the Managed Servers that are required in the Managed File Transfer domain.

  1. Change the default server name to WLS_MFT1 in the Server name column.

  2. Click Add and repeat this process to create a second Managed Server named WLS_MFT2.

  3. Use the information in Table 18-1 to fill in the rest of the columns for each MFT Managed Server.

The Managed Server names suggested in this procedure (WLS_MFT1 and WLS_MFT2) are referenced throughout this document; if you choose different names then be sure to replace them as needed,

For more information about the options on this screen, see Managed Servers in Creating WebLogic Domains Using the Configuration Wizard.

Table 18-1 MFT Managed Server

Server Name Listen Address Enable Listen Port Listen Port Enable SSL Port SSL Listen Port Administration Port Server Groups

WLS_MFT1

MFTHOST1

Unchecked

Disabled

Checked

7010

9014

MFT-MGD-SVRS

WLS_MFT2

MFTHOST2

Unchecked

Disabled

Checked

7010

9014

MFT-MGD-SVRS

The selected server group ensures that the Managed File Transfer and Oracle Web Services Manager (OWSM) software is targeted to the Managed Server.

There is another server group called MFT-MGD-SVRS-ONLY that targets only MFT but not Oracle Web Services Manager (OWSM) to the server. This is typically used if you want to have Oracle Web Services Manager (OWSM) in a different server rather than with the MFT server.

The server groups target Fusion Middleware applications and services to one or more servers by mapping defined groups of application services to each defined server group. Any application services that are mapped to a given server group are automatically targeted to all servers that are assigned to that group. See Application Service Groups, Server Groups, and Application Service Mappings in Domain Template Reference.

Task 16   Configuring a Cluster

Use the Clusters screen to create a new cluster:

  1. Click the Add button.

  2. Specify MFT_Cluster in the Cluster Name field.

  3. Leave the Cluster Address field blank.

  4. Specify mft.example.com in the Frontend Host field.

  5. Specify 0 as the Frontend HTTP port and 443 as the Frontend HTTPS port.

For more information about the options on this screen, see Clusters in Creating WebLogic Domains Using the Configuration Wizard.

Task 17   Assigning Server Templates

Click Next.

Task 18   Configuring Dynamic Servers
Verify that all dynamic server options are disabled for clusters that are to remain as static clusters.
  1. Confirm that the Calculated Machine Names and Calculated Listen Port checkboxes on this screen are unchecked.

  2. Confirm that the Server Template and Dynamic Server Groups selections are Unspecified.

  3. Click Next.

Task 19   Assigning Managed Servers to the Cluster

Use the Assign Servers to Clusters screen to assign Managed Servers to the new cluster.

  1. In the Clusters pane, select the cluster to which you want to assign the servers; in this case, MFT_Cluster.

  2. In the Servers pane, assign WLS_MFT1 to MFT_Cluster by doing one of the following:

    • Click once on WLS_MFT1 to select it, then click on the right arrow to move it beneath the selected cluster (MFT_Cluster)) in the Clusters pane.

      or

    • Double-click on WLS_MFT1 to move it beneath the selected cluster (MFT_Cluster) in the clusters pane.

  3. Repeat these steps to assign the WLS_MFT2 Managed Server to MFT_Cluster.

For more information about the options on this screen, see Assign Servers to Clusters in Creating WebLogic Domains Using the Configuration Wizard.

Task 20   Configuring Coherence Clusters

Use the Coherence Clusters screen to configure the Coherence cluster that is automatically added to the domain.

In the Cluster Listen Port, enter 9991.

For Coherence licensing information, Oracle Coherence Products in Oracle Fusion Middleware Licensing Information User Manual.

Task 21   Creating Machines

Use the Machines screen to create five new machines in the domain. A machine is required in order for the Node Manager to be able to start and stop the servers.

  1. Select the Unix Machine tab.

  2. Click the Add button to create five new UNIX machines.

    Use the values in Table 18-2 to define the Name and Node Manager Listen Address of each machine.

  3. Verify the port in the Node Manager Listen Port field.

    The port number 5556, shown in this example, may be referenced by other examples in the documentation. Replace this port number with your own port number as needed.

    Note:

    If you are installing on a host where additional domains were already configured, and you have already configured a per host Node Manager, then the address and port configured in this screen must be for the existing per host Node Manager.

Table 18-2 Values to Use When Creating Unix Machines

Name Node Manager Listen Address Node Manager Type Node Manager Listen Port

MFTHOST1

The value of the MFTHOST1 host name variable or MFTHOST1 alias. For example, MFTHOST1.example.com.

SSL

5556

MFTHOST2

The value of the MFTHOST2 host name variable or MFTHOST2 alias. For example, MFTHOST2.example.com.

SSL

5556

ADMINHOST

Enter the value of the ADMINVHN variable.

SSL

5556

For more information about the options on this screen, see Machines in Creating WebLogic Domains Using the Configuration Wizard.

Task 22   Assigning Servers to Machines

Use the Assign Servers to Machines screen to assign the Administration Server and the two Managed Servers to the appropriate machine.

The Assign Servers to Machines screen is similar to the Assign Managed Servers to Clusters screen. Select the target machine in the Machines column, select the Managed Server in the left column, and click the right arrow to assign the server to the appropriate machine.

Assign the servers as follows:

  • Assign the AdminServer to the ADMINHOST machine.

  • Assign the WLS_MFT1 Managed Server to the MFTHOST1 machine.

  • Assign the WLS_MFT2 Managed Server to the MFTHOST2 machine.

For more information about the options on this screen, see Assign Servers to Machines in Creating WebLogic Domains Using the Configuration Wizard.

Task 23   Reviewing Your Configuration Specifications and Configuring the Domain

The Configuration Summary screen contains detailed configuration information for the domain that you are about to create. Review the details of each item on the screen and verify that the information is correct.

If you need to make any changes, you can go back to any previous screen either by using the Back button or by selecting the screen in the navigation pane.

Domain creation does not begin until you click Create.

In the Configuration Progress screen, click Next when it finishes.

For more information about the options on this screen, see Configuration Summary in Creating WebLogic Domains Using the Configuration Wizard.

Task 24   Writing Down Your Domain Home and Administration Server URL

The Configuration Success screen shows the following items about the domain you just configured:

  • Domain Location

  • Administration Server URL

You must make a note of both items as you need them later; the domain location is needed to access the scripts used to start the Administration Server.

Click Finish to dismiss the Configuration Wizard.

Download and Configure Weblogic Remote Console

This section describes how to download and configure the WebLogic Remote Console.

Note:

For the initial configuration steps required in this EDG, you will need access to the AdminServer listen address and administration port. Later on you will configure access from a frontend load balancer.

Perform the following steps to download and configure the WebLogic Remote Console:

  1. Uninstall any previous versions of the WebLogic Remote Console from your computer.
  2. Download the WebLogic Remote Console. Go to https://github.com/oracle/weblogic-remote-console/releases and download the installer from your operating system.
  3. Run the installer.
  4. Install the WebLogic Remote Console extension in the WebLogic Server domain. The WebLogic Remote Console extension provides additional functionality when using the WebLogic Remote Console to manage WebLogic domains.

    Note:

    This step is optional.
    1. Create a management-services-ext directory under the domain home.
    2. Download the latest WebLogic Remote Console extension, console-rest-ext-<version>.war, from https://github.com/oracle/weblogic-remote-console/releases and save it inside the management-services-ext directory you created in the previous step. If you have an earlier version of the extension already downloaded, delete it and replace it with the latest version.
    3. Reboot the Administration Server if it is already running.
  5. Launch the WebLogic Remote Console application.

    Example:

    ./weblogic-remote-console

    In the next steps you must connect to the EDG domain provider using initially the Admin Servers listen address.

Configuring SSL Certificates for the Domain

This section describes how to configure SSL certificates for the domain.

Creating Certificates and Certificate Stores for the WebLogic Domain

The Enterprise Deployment Guide provides steps to configure a domain that uses SSL listen addresses for all Weblogic Managed Servers, Weblogic Administration Server and Node Managers in the application tier. To achieve this the required certificates for all servers, machines and NM listen addresses must be created and pointed to from the domain and Node Manager configuration.

In Oracle FMW 14.1.2.0, Oracle WebLogic allows the usage of a per-domain Certificate Authority (CA). In this model, the CertGen and ImportPrivateKey utilities are enhanced to use the domain's secret key to encrypt the passphrases and store them in the domain's DemoCerts.props file. A self-signed Demo CA is automatically created for the domain and it is used for signing certificates for the SSL listen addresses used in the EDG. Although in a real production system, standard CAs should be used, the per-domain CA model implements an SSL system using domain specific CA that provides a higher degree of protection than non-ssl configurations. If you want to use your own custom certificates, see About Using Third Party SSL Certificates in the WebLogic and Oracle HTTP Servers in the Common Configuration and Management Tasks for an Enterprise Deployment chapter.

Oracle recommends using a shared storage location (protected with the appropriate snapshot or file backup tooling) where all the different certificates and stores can be found by the different servers. Perform the following steps to generate an Identity store and a Trust Store that can be used for enabling SSL listeners in a Weblogic Server using a per-domain CA:

  1. Download the generate_perdomainCACERTS.sh script in the maa github repo.

    https://github.com/oracle-samples/maa/blob/main/1412EDG/generate_perdomainCACERTS.sh

  2. Run the script with the following arguments:

    • WLS_DOMAIN_DIRECTORY: Directory hosting the Weblogic Domain that the Administration Server uses.
    • WL_HOME: The directory within the Oracle home where the Oracle WebLogic Server software binaries are stored. Typically /u01/oracle/products/fmw/wlserver.
    • KEYSTORE_HOME: Directory where appIdentity and appTrust stores will be created.
    • KEYPASS: Password used for the weblogic administration user (will be reused for certs and stores).

    Example:

    ./generate_perdomainCACERTS.sh $ASERVER_HOME $ORACLE_HOME/wlserver $KEYSTORE_HOME <keypass>

The script will traverse the WLS_DOMAIN_DIRECTORY/config/config.xml to find all the listen addresses used in the domain, generate certificates for all of them, create a Truststore with the domain CA and the WLS CertGenCA, and import certificates into a new Identity store. The aliases used in the import will be the same as the hostname used as listen address. Both the trust store and the identity store will be placed in the KEYSTORE_HOME directory.

Run the following command to verify if the "domainca" entry is there as a trustedCertEntry:

keytool -list -keystore $KEYSTORE_HOME/appTrustKeyStore.pkcs12

Run the following command to verify if there is a PrivateKeyEntry for each listen address (the values for ADMINVHN, SOAHOST1 and SOAHOST2):

keytool -list -keystore $KEYSTORE_HOME/appIdentityKeyStore.pkcs12

Adding Certificate Stores Location to the WebLogic Servers Start Scripts

Once the Identity and Trust Stores are created for the domain some Java properties must be added to the WebLogic start scripts. These properties are added to the file setUserOverridesLate.sh in $ASERVER_HOME/bin. Any customizations you add to this file are preserved during domain upgrade operations and are carried over to remote servers when using the pack and unpack commands.

  • If you created the Identity and Trust Stores with the script generate_perdomainCACERTS.sh, as explained in Creating Certificates and Certificate Stores for the WebLogic Domain, then the properties are automatically added to the file setUserOverridesLate.sh in $ASERVER_HOME/bin. Just verify that the file exists and that the EXTRA_JAVA_PROPERTIES have been added.

  • If you are using your own custom certificates, then manually create the file setUserOverridesLate.sh in $ASERVER_HOME/bin. Edit the file and add the variable EXTRA_JAVA_PROPERTIES to set the javax.net.ssl.trustStore and javax.net.ssl.trustStorePassword properties with the values used by your EDG system. For example:

    
    EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES}
     -Djavax.net.ssl.trustStore=/u01/oracle/config/keystores/appTrustKeyStore.pkcs12
     -Djavax.net.ssl.trustStorePassword=mypassword"
    export EXTRA_JAVA_PROPERTIES

Note:

The order of the extra java properties is relevant. In case that the same property is defined more than once, the later value is used. The custom values must be defined as in the example provided.

Update Server's Security Settings Using the Remote Console

Connecting to the Remote Console Using the Administration Server’s Virtual Hostname as Provider
The following procedure temporarily starts the Administration Server with the default start script so to enable you to perform these tasks. After you perform these tasks, you can stop this temporary session and use the Node Manager to start the Administration Server.

Note:

For this Remote Console initial access to the Administration Server, it is required that the machine that runs the Remote Console can resolve and connect to the Admin Server's Listen Address. This can be done by starting the Remote Console directly in the node where the Admin Server runs or creating a tunnel to this address from the node where the remote Console is executed.
  1. Using the following default start script to start the Administration Server:
    1. Change directory to the following directory:
      cd $ASERVER_HOME/bin
    2. Run the start script:
      ./startWebLogic.sh

      Monitor the terminal till the following message is displayed:

      <Server state changed to RUNNING>

      Also you must verify that the appropriate SSL listener is available, which can be confirmed with the a message like the following displayed in output:

      <Server> <BEA-002613> <Channel "DefaultSecure" is now listening on XXXX:7002 for protocols iiops, t3s, ldaps, https.>
  2. Create a new provider in the WebLogic Remote Console as follows:
    1. Download the domain's trust keystore to the host or laptop where you run the WebLogic Remote Console. For example, when using the per-domain CA steps in previous sections, this would be located at $KEYSTORE_HOME/appTrustKeyStore.pkcs12.
    2. Open the Remote Console and add the domain trust store to the remote console settings. Click File > Settings and enter the following values.
      1. Trust Store type - jks

      2. Trust Store Path - The path to the trust keystore file in the host where the Remote Console runs.

      3. Trust Store Key - Enter the password provided in the steps above for certificate creation.

      4. Check Disable HostName verification if you are using Demo certificates as described in the steps above.

    3. Using the Providers window in the Remote Console, create a new provider by selecting Add Admin Server Connection Provider.
      1. In the provider name, enter the name of mftedg_domain_asvip. This will identify the type of access.

      2. Enter the WebLogic Domain Administration username provided in the configuration wizard user name.

      3. Enter the password used for the domain creation.

      4. Use https protocol and the admin server listen address used in the configuration wizard as URL for access and specify port 9002.

        For example, https://ADMINVHN.example.com:9002.

      5. Check the Make Insecure Connection checkbox.

        Note:

        This provider should not be used once the front end and webtier are configured.

      The Remote Console Home Window for the domain will be displayed.

Updating the WebLogic Servers Security Settings
Perform the following steps to update the WebLogic Servers Security Settings and Administration Port:
  1. Access the Domain provider in the Remote Console and update the Administration Server and WebLogic Servers Security Settings:
    1. Click Edit Tree.
    2. Click Environment > Servers > AdminServer.
    3. Click Security tab.
    4. Change the keystores dropdown to Custom Identity and Custom Trust.
    5. In Custom Identity Keystore, enter the fully qualified path to the identity keystore as follows:
      KEYSTORE_HOME/appIdentityKeyStore.pkcs12

      Replace KEYSTORE_HOME with the value of the folder you use for storing keystore, as described in the Table 7-2.

    6. Set the Custom Identity Keystore Type to JKS.
    7. In Custom Identity Keystore Passphrase, enter the password Keystore_Password you provided in the certificate generation steps.
    8. In Custom Trust Keystore, enter the fully qualified path to the trust keystore.
      KEYSTORE_HOME/appTrustKeyStore.pkcs12

      Replace KEYSTORE_HOME with the value of the folder you use for storing keystore, as described in the Table 7-2.

    9. Set the Custom Trust Keystore Type to JKS.
    10. In Custom Trust Keystore Passphrase, enter the password you provided as the <keypass> in the certificate generation steps.
    11. Click Save.
    12. Under Security settings, navigate to SSL tab.
    13. In the Server Private Key Alias filed enter the alias provided in the certificate generation steps. If you used the certificate generation script this will be the same as the listen address used for the WLS server.
    14. In the Server Private Key Pass Phrase field, enter the password provided in the certificate generation steps. If you used the certificate generation script this will be the same as the keystore passphrase.
    15. Click Save.

      The cart on the top right part of the screen will show full with a yellow bag inside.

    16. Click the Cart icon on the top right and select Commit Changes.

    Repeat the above steps for each managed server in the domain changing the alias to match the alias used for the certificates.

  2. Return to the terminal window where you started the Administration Server with the start script.
  3. Press Ctrl+C to stop the Administration Server process.

    Wait for the Administration Server process to end and for the terminal command prompt to appear.

  4. Start the Administration Server again by using the following script:
    1. Change directory to the following directory:
      cd $ASERVER_HOME/bin
    2. Run the start script:
      ./startWebLogic.sh
    3. Monitor the output in the terminal till the following output is displayed.
      <Server state changed to RUNNING>

Configuring KSS with Per-domain CA

For consistency purposes and to use a common CA all across the domain artifacts you may want to use the per-domain CA for KSS (store used by OPSS and other components in the WebLogic Infrastructure/JRF Domain.

Perform the following steps to import the domain CA certificate in the KSS trusted store:

  1. Download the import-domainca-into-kss.sh script in the maa github repo https://github.com/oracle-samples/maa/blob/main/1412EDG/import-domainca-into-kss.sh.
  2. Edit the script and customize the following variables according to your environment:

    DOMAIN_HOME: Path to the WebLogic domain (ASERVER_HOME in this guide). For example, /u01/oracle/config/domains/mftedg_domain.

    MW_HOME: The path to the FMW home. For example, /u01/oracle/products/fmw.

    ADMINVHN: Administration Server’s listen address. For example, adminvhn.example.com.

    ADMINPORT: Administration Server’s listen port. For example, 9002.

    DOMAINUSER: Name of the administrator user for the WLS domain. For example, soaedgadmin.

    TRUSTSTOREFILE: Location of the truststore used to connect though SSL to the Admin Server. For example, /u01/oracle/config/keystores/appTrustKeyStore.pkcs12.

  3. Run the script with the following arguments:
    • DOMAINPASS: WLS domain administrator user’s password

    • KEYPASS: Password for the truststore.

    Example

    ./import-domainca-into-kss.sh adminpassword123 truststorepassword123

    The script imports the per Domain CA certificate into KSS and assigns it to jps.

    You can verify that the update was successful by inspecting the jps configuration files.

    grep domainca $ASERVER_HOME/config/fmwconfig/jps-config.xml

    The result of the command must be similar to the following example:

    <property name="ca.key.alias" value="domainca-new-24-05-07-16-44-52"/>
  4. Restart the Admin Server.
    If Admin Server was started with the script, perform the following steps:
    1. Press Ctrl+C to stop the Administration Server process.
    2. Go to directory $ASERVER_HOME/bin and run the following command:
      ./startWebLogic.sh

Configuring a Per Host Node Manager for an Enterprise Deployment

For specific enterprise deployments, Oracle recommends that you configure a per-host Node Manager, as opposed to the default per-domain Node Manager.

For more information about the advantages of a per host Node Manager, see About the Node Manager Configuration in a Typical Enterprise Deployment.

Creating a Per Host Node Manager Configuration

The step in configuring a per-host Node Manager is to create a configuration directory and two new node manager configuration files. You must also edit the default startNodeManager.sh file.

To create a per-host Node Manager configuration, perform the following tasks, first on MFTHOST1, and then on MFTHOST2:

  1. Log in to MFTHOST1 and create a directory for the Node Manager configuration files :

    For example:

    mkdir -p /u02/oracle/config/nodemanager

    Note that this directory should be on a local disk, because it is specific to the host. This directory location is known as the Node Manager home, and it is identified by the NM_HOME directory variable in examples in this guide.

  2. Change directory to the Node Manager home directory:
    cd $NM_HOME
  3. Create a new text file called nodemanager.properties and add the values shown Example: Contents of the nodemanager.properties Filein to this new file.

    You must repeat similar configuration for the Node Managers in the other node of the domain (MFTHOST2, use the pertaining certificate alias).

    Use the pertaining identity alias for the node that you are configuring. For example, soahost1.example.com in MFTHOST1 and soahost2.example.com in MFTHOST2.

    For more information about the properties that you can add to the nodemanager.properties file, see Node Manager Properties in Administering Node Manager for Oracle WebLogic Server.

    In the nodemanager.properties file, you enable crash recovery for servers as a part of this configuration. See Node Manager and System Crash Recovery in Administering Node Manager for Oracle WebLogic Server.

    Example: Contents of the nodemanager.properties File

    DomainsFile=/u02/oracle/config/nodemanager/nodemanager.domains
    LogLimit=0
    PropertiesVersion=14.1.2.0.0
    AuthenticationEnabled=true
    NodeManagerHome=/u02/oracle/config/nodemanager
    #Include the specific JDK home
    JavaHome=/u01/oracle/products/jdk
    LogLevel=INFO
    DomainsFileEnabled=true
    StartScriptName=startWebLogic.sh
    #Leave blank for listening on ANY
    ListenAddress=
    NativeVersionEnabled=true
    ListenPort=5556
    LogToStderr=true
    SecureListener=true
    LogCount=1
    StopScriptEnabled=false
    QuitEnabled=false
    LogAppend=true
    StateCheckInterval=500
    CrashRecoveryEnabled=true
    StartScriptEnabled=true
    LogFile=/u02/oracle/config/nodemanager/nodemanager.log
    LogFormatter=weblogic.nodemanager.server.LogFormatter
    ListenBacklog=50
    KeyStores=CustomIdentityAndCustomTrust 
    CustomIdentityAlias=soahost1.example.com
    CustomIdentityKeyStoreFileName=/u01/oracle/config/keystores/appIdentityKeyStore.pkcs12
    CustomIdentityKeyStorePassPhrase=password
    CustomIdentityPrivateKeyPassPhrase=password

    Notice the values for CustomIdentityAlias. If you used the generate_perdomainCACERTS.sh script, this is the hostname used as listen address in the configuration wizard for the Node Manager Machine. If you created the certificates one by one, this would be the alias that you assigned to the certificate import for MFTHOST1. You must also provide the location of the IdentityStore generated in the previous steps and the password for the same.

  4. Locate the startNodeManager.sh file in the following directory:
    $WL_HOME/server/bin
  5. Copy the startNodeManager.sh file to the Node Manager home directory.
    cp $WL_HOME/server/bin/startNodeManager.sh $NM_HOME
  6. Edit the new startNodeManager.sh file and add the NODEMGR_HOME property as follows:
    NODEMGR_HOME="NM_HOME"

    In this example, replace NM_HOME with the actual path to the Node Manager home.

  7. Locate the stopNodeManager.sh script in the WL_HOME/server/bin directory. Copy it to the Node Manager home directory. Edit the copied file and edit the NODEMGR_HOME property pointing to the node manager home (as it has been done for the startNodemanager.sh file):
    NODEMGR_HOME="NM_HOME"

    In this example, replace NM_HOME with the actual path to the Node Manager home.

  8. Create another new file in the Node Manager home directory, called nodemanager.domains.

    The nodemanager.domains file provides additional security by restricting Node Manager client access to the domains listed in this file.

  9. Perform steps 1 through 8 on MFTHOST2.
  10. Add the following entries to the new nodemanager.domains files:

    On MFTHOST1, add values for both the Administration Server domain home and the Managed Servers domain home:

    mftedg_domain=MSERVER_HOME;ASERVER_HOME

    Note:

    The path that is mentioned first (MSERVER_HOME) is considered as the primaryDomainPath and Managed Servers are run from this location.

    On MFTHOST2, add the value for the Managed Servers domain home only:

    mftedg_domain=MSERVER_HOME

    In these examples, replace ASERVER_HOME and MSERVER_HOME with the values of the respective variables, as described in File System and Directory Variables Used in This Guide.

Starting the Node Manager on MFTHOST1

After you manually set up the Node Manager to use a per-host Node Manager configuration, you can start the Node Manager on MFTHOST1, by using the startNodeManager.sh script.
To start the Node Manager on MFTHOST1:
  1. Change directory to the Node Manager home directory:
    cd $NM_HOME
  2. Run the following command to start the Node Manager and send the output of the command to an output file, rather than to the current terminal shell:
    nohup ./startNodeManager.sh > ./nodemanager.out 2>&1 &
  3. Monitor the the nodemanager.out file; make sure the NodeManager starts successfully. The output should eventually contain the following strings:
    
    <INFO> <Upgrade> <Encrypting NodeManager property: CustomIdentityKeyStorePassPhrase> 
    <INFO> <Upgrade> <Encrypting NodeManager property: CustomIdentityPrivateKeyPassPhrase>
    <Upgrade> <Saving upgraded NodeManager properties to '/u02/oracle/config/nodemanager/nodemanager.properties'>
    <INFO> <Loading domains file: /u02/oracle/config/nodemanager/nodemanager.domains>
    <INFO> <Loading identity key store: FileName=/u01/oracle/config/keystores/appIdentityKeyStore.pkcs12, Type=pkcs12, PassPhraseUsed=true>
    <INFO> <Loaded NodeManager configuration properties from '/u02/oracle/config/nodemanager/nodemanager.properties'>
    <INFO> <14.1.2.0.0>
    <INFO> <Server Implementation Class: weblogic.nodemanager.server.NMServer$ClassicServer.>
    <INFO> <Secure socket listener started on port 5556>

    You must check that the plain text used for passwords in nodemanager.properties has now been encrypted:

    
    [oracle@soalonhost1 keystores]$ cat /u02/oracle/config/nodemanager/nodemanager.properties 
    #Tue Feb 06 11:53:10 GMT 2024
    #Mon Feb 05 17:24:30 GMT 2024
    DomainsFile=/u02/oracle/config/nodemanager/nodemanager.domains
    LogLimit=0
    PropertiesVersion=14.1.2.0.0
    AuthenticationEnabled=true
    NodeManagerHome=/u02/oracle/config/nodemanager
    #Include the specific JDK home
    JavaHome=/u01/oracle/products/jdk
    LogLevel=INFO
    DomainsFileEnabled=true
    StartScriptName=startWebLogic.sh
    #Leave blank for listening on ANY
    ListenAddress=
    NativeVersionEnabled=true
    ListenPort=5556
    LogToStderr=true
    SecureListener=true
    LogCount=1
    StopScriptEnabled=false
    QuitEnabled=false
    LogAppend=true
    StateCheckInterval=500
    CrashRecoveryEnabled=true
    StartScriptEnabled=true
    LogFile=/u02/oracle/config/nodemanager/nodemanager.log
    LogFormatter=weblogic.nodemanager.server.LogFormatter
    ListenBacklog=50
    KeyStores=CustomIdentityAndCustomTrust 
    CustomIdentityAlias=soahost1.example.com
    CustomIdentityKeyStoreFileName=/u01/oracle/config/keystores/appIdentityKeyStore.pkcs12
    CustomIdentityKeyStorePassPhrase={AES256}EMvPrOCRfN7fyv3d8JcEnttTLyneG9Su+UVK5DGEmqmqDwLkpLz9nQFZ+fL1Bidc
    CustomIdentityPrivateKeyPassPhrase={AES256}O5cEJD8WVYP3aRLp9KAbFZ3CGLyxmmIWFX1YzVfJvPpl1dc5RbMksAcsBLquKcWW
    

Configuring the Node Manager Credentials

Perform the following steps to set the Node Manager credentials using the Remote Console:
  1. Access the Domain provider in the Remote Console.
  2. Click Edit Tree.
  3. Click Environment > Domain> Security.
  4. Check the Show Advanced Fields field.
  5. Set Node Manager Username to the same as the Weblogic Administrator, since this username will be used in other tasks mentioned in this guide.
  6. Change the NM password. Ensure the Node Manager password is set to the same as the Weblogic Administrator since this password will be used in other tasks mentioned in this guide.
  7. Click Save. The cart on the top right part of the screen will show full with a yellow bag inside.
  8. Click the Cart Icon on the top right and select Commit Changes.

Enrolling the Domain with NM

Perform the following steps in a new terminal window to enroll the domain with Node manager.

Note:

You will be unable to connect to the Node Manager and use it to start the servers in the domain without performing this step.
  1. Change directory to the following directory:
    cd $ORACLE_COMMON_HOME/common/bin
  2. Start the WebLogic Server Scripting Tool (WLST). In order to use the certificates created for the appropriate SSL handshake, the location of the stores and password of the same need to be provided to WLST. Use the following command or add these in a script that can be easily invoked:
    
    export WLST_PROPERTIES="-Dweblogic.security.TrustKeyStore=CustomTrust -Dweblogic.security.CustomTrustKeyStoreFileName=/u01/oracle/config/keystores/appTrustKeyStore.pkcs12 -Dweblogic.security.CustomTrustKeyStorePassPhrase=storepassword"
    ./wlst.sh 

    Note:

    You must avoid including the password in the script.
  3. Connect to the Administration Server by using the following WLST command:
    connect('admin_user','admin_password','admin_url')

    For example:

    connect('weblogic','<password>','t3s://ADMINVHN:9002')
  4. Use the nmEnroll command to enable the Node Manager to manage servers in a specified WebLogic domain.
    nmEnroll('ASERVER_HOME')

    For example:

    nmEnroll('/u01/oracle/config/domains/mftedg_domain')
  5. Generate startup properties for the Admin Server using the following WLST command:
    nmGenBootStartupProps('AdminServer')

    The startup.properties file is created in the following directory:

    $ASERVER_HOME/servers/AdminServer/data/nodemanager/

    Note:

    This step is optional and must be performed only if you want to customize any startup properties for the Administration Server.

Adding Truststore Configuration to Node Manager

It is required to add the corresponding truststore configuration for Node Manager communication with the different WebLogic Server listeners. To do this, edit Node Manager's start script startNodeManager.sh located at $NM_HOME and add the variable JAVA_OPTIONS to set the javax.net.ssl.trustStore and javax.net.ssl.trustStorePassword properties with the values used by your EDG system. For example:

export JAVA_OPTIONS="${JAVA_OPTIONS} -Djavax.net.ssl.trustStore=/u01/oracle/config/keystores/appTrustKeyStore.pkcs12 -Djavax.net.ssl.trustStorePassword=mypassword"

Note:

If you have used the generate_perdomainCACERTS.sh script to generate certificates and stores, the trustStorePassword is the password provided as "KEYPASS" parameter to the script.

Configuring the Domain Directories and Starting the Servers on MFTHOST1

After the domain is created and the node manager is configured, you can then configure the additional domain directories and start the Administration Server and the Managed Servers on MFTHOST1.

Disabling the Derby Database

Before you create the Managed Server directory and start the Managed Servers, disable the embedded Derby database, which is a file-based database, packaged with Oracle WebLogic Server. The Derby database is used primarily for development environments. As a result, you must disable it when you configure a production-ready enterprise deployment environment; otherwise, the Derby database process start automatically when you start the Managed Servers.
To disable the Derby database:
  1. Navigate to the following directory in the Oracle home.
    cd $WL_HOME/common/derby/lib
  2. Rename the Derber library jar file:
    mv derby.jar disable_derby.jar
  3. Complete steps 1 through 2 on each ORACLE_HOME for MFTHOST1 and MFTHOST2 if they use separate shared file systems.

Starting the Administration Server Using the Node Manager

After you have configured the domain and configured the Node Manager, you can start the Administration Server by using the Node Manager. In an enterprise deployment, the Node Manager is used to start and stop the Administration Server and all the Managed Servers in the domain.

To start the Administration Server by using the Node Manager:

  1. Ensure that the Administration Server is stopped.
  2. Start the WebLogic Scripting Tool (WLST):
    
    export WLST_PROPERTIES="
    -Dweblogic.security.TrustKeyStore=CustomTrust
    -Dweblogic.security.CustomTrustKeyStoreFileName=/u01/oracle/config/keystores/appTrustKeyStore.pkcs12
    -Dweblogic.security.CustomTrustKeyStorePassPhrase=password"
    cd $ORACLE_COMMON_HOME/common/bin
    ./wlst.sh

    Note:

    The weblogic.security.SSL.ignoreHostnameVerification=true is required when using Demo certificates as the ones provided my the generateCertifcates scripts. In an environment with formal CA and certificates, this flag should not be used.
  3. Connect to Node Manager by using the Node Manager credentials:
    nmConnect('nodemanager_username','nodemanager_password','ADMINVHN','5556','domain_name','ASERVER_HOME','SSL')

    Replace ADMINVHN and ASERVER_HOME with the values of the respective variables.

    Note:

    This user name and password are used only to authenticate connections between Node Manager and clients. They are independent of the server administrator ID and password and are stored in the nm_password.properties file located in the following directory:

    ASERVER_HOME/config/nodemanager
  4. Start the Administration Server:
    nmStart('AdminServer')

    Note:

    When you start the Administration Server, it attempts to connect to Oracle Web Services Manager for WebServices policies. It is expected that the WSM-PM Managed Servers are not yet started, and so, the following message appears in the Administration Server log:

    <Warning><oracle.wsm.resources.policymanager>
    <WSM-02141><Unable to connect to the policy access service due to Oracle WSM policy manager host server being down.>
  5. Exit WLST:
    exit()

Validating the Administration Server

Before you proceed with the configuration steps, validate that the Administration Server has started successfully by making sure that you have access to the Oracle WebLogic Remote Console and Oracle Enterprise Manager Fusion Middleware Control; both of these are installed and configured on the Administration Servers.

To navigate to Fusion Middleware Control, enter the following URL, and log in with the Oracle WebLogic Server administrator credentials:

https://ADMINVHN:9002/em

You should be able to connect to the Admin Server from the Remote Console as before.

Creating a Separate Domain Directory for Managed Servers on MFTHOST1

When you initially create the domain for enterprise deployment, the domain directory resides on a shared disk. This default domain directory is used to run the Administration Server. You can now create a copy of the domain on the local storage for both MFTHOST1 and MFTHOST2. The domain directory on the local (or private) storage is used to run the Managed Servers.

Placing the MSERVER_HOME on local storage is recommended to eliminate the potential contention and overhead cause by servers writing logs to shared storage. It is also faster to load classes and jars need from the domain directory, so any tmp directory or cache data that the Managed Servers use from the domain directory is processed quicker.

As described in Preparing the File System for an Enterprise Deployment, the path to the Administration Server domain home is represented by the ASERVER_HOME variable, and the path to the Managed Server domain home is represented by the MSERVER_HOME variable.

To create the Managed Server domain directory:

  1. Log in to MFTHOST1 and run the pack command to create a template as follows:
    cd $ORACLE_COMMON_HOME/common/bin
     
    ./pack.sh -managed=true 
              -domain=ASERVER_HOME 
              -template=complete_path/mftdomaintemplate.jar 
              -template_name=create_domain_template
    

    In this example:

    • Replace ASERVER_HOME with the actual path to the domain directory that you created on the shared storage device.

    • Replace complete_path with the complete path to the location where you want to create the domain template jar file. You need to reference this location when you copy or unpack the domain template jar file.

    • mftdomaintemplate is a sample name for the jar file that you are creating, which contains the domain configuration files.

    • mft_domain_template is the name assigned to the domain template file.

  2. Make a note of the location of the template jar file that you created with the pack command.

    Tip:

    For more information about the pack and unpack commands, see Overview of the Pack and Unpack Commands in Creating Templates and Domains Using the Pack and Unpack Commands.

  3. If you haven't already, create the recommended directory structure for the Managed Server domain on the MFTHOST1 local storage device.
  4. Run the unpack command to unpack the template in the domain directory onto the local storage, as follows:
    cd $ORACLE_COMMON_HOME/common/bin
    
    ./unpack.sh -domain=MSERVER_HOME \
                -overwrite_domain=true \
                -template=complete_path/mftdomaintemplate.jar \ 
                -log_priority=DEBUG \
                -log=/tmp/unpack.log \
                -app_dir=APPLICATION_HOME 

    Note:

    The -overwrite_domain option in the unpack command allows unpacking a managed server template into an existing domain and existing applications directories. For any file that is overwritten, a backup copy of the original is created. If any modifications had been applied to the start scripts and ear files in the managed server domain directory, they must be restored after this unpack operation.

    Additionally, to customize server startup parameters that apply to all servers in a domain, you can create a file called setUserOverridesLate.sh and configure it to, for example, add custom libraries to the WebLogic Server classpath, specify additional java command-line options for running the servers, or specify additional environment variables. Any customizations you add to this file are preserved during domain upgrade operations, and are carried over to remote servers when you use the pack and unpack commands.

    In this example:

    • Replace MSERVER_HOME with the complete path to the domain home to be created on the local storage disk. This is the location where the copy of the domain is unpacked.

    • Replace complete_path with the complete path to the location where you created or copied the template jar file.

    • mftdomaintemplate.jar is the name of the template jar file that you created when you ran the pack command to pack up the domain on the shared storage device.

    • Replace APPLICATION_HOME with the complete path to the applications directory for the domain on shared storage.

    Tip:

    For more information about the pack and unpack commands, see Overview of the Pack and Unpack Commands in Creating Templates and Domains Using the Pack and Unpack Commands.

  5. Change directory to the newly created Managed Server directory and verify that the domain configuration files were copied to the correct location on the MFTHOST1 local storage device.

Starting and Validating the WLS_MFT1 Managed Server on MFTHOST1

After you have configured Node Manager and created the Managed Server domain directory, you can use Oracle Enterprise Manager Fusion Middleware Control to start the WLS_MFT1 Managed Server on MFTHOST1.

  1. Enter the following URL into a browser to display the Fusion Middleware Control login screen:
    https://ADMINVHN:9002/em

    In this example:

  2. Log in to Fusion Middleware Control by using the Administration Server credentials.
  3. Select the Servers pane to view the Managed Servers in the domain.
  4. Select only the WLS_MFT1 Managed Server, and then click Control > Start on the tool bar.
  5. To verify that the Managed Server is working correctly, open your browser and enter the following URLs:
    https://MFTHOST1:7010/wsm-pm/
    https://MFTHOST1:7010/mftconsole/

    Note:

    • To validate the server URLs, disable (set to blank) the front-end host until you have completed the configuration for Oracle HTTP Server. If you do not disable the front-end host, all requests fail because they are redirected to the front-end address.

    Enter the domain admin user name and password when prompted.

Configuring Web Services Manager

This section describes how to configure Web Services Manager.

Updating WebServices Domain Configuration

  1. Log into the Fusion Middleware Control by using the administrator’s account.
  2. In the Weblogic Domain drop down menu, select WebServices > WSM Domain Configuration.
  3. Click Policies Access tab.
  4. Select the Auto Discover and Use SSL Only check boxes.
  5. In the SSL Setup section, select Oneway.
  6. In KeyStore Type, select JKS (Java Key Store).

    Note:

    You must select JKS if you are using the certificates and stores created in previous steps.

  7. In the Truststore Path enter the location of the truststore used in previous sections as follows:
    /u01/oracle/config/keystores/appTrustKeyStore.pkcs12
  8. In the Key field, enter a name to uniquely identify the password used for the truststore.
  9. In the password field, enter the password used for the truststore in previous sections (same as domain admin).
  10. Click Apply.

Bootstrapping WSM

In a new terminal window, perform the following steps to bootstrap WSMPM.

Note:

If this task is not performed, the WSMPM does not work properly .
  1. Change directory to the following directory as follows:
    cd $ORACLE_COMMON_HOME/common/bin
  2. Start the WebLogic Server Scripting Tool (WLST). To use the certificates created for the appropriate SSL handshake, the location of the stores and password of the same need to be provided to WLST. Use the following command or add these in a script that can be easily invoked (avoid including the password in the script):
    
    export WLST_PROPERTIES="-Dweblogic.security.TrustKeyStore=CustomTrust
    -Dweblogic.security.CustomTrustKeyStoreFileName=/u01/oracle/config/keystores/appTrustKeyStore.pkcs12
    -Dweblogic.security.CustomTrustKeyStorePassPhrase=storepassword"
    ./wlst.sh
  3. Connect to the Administration Server by using the following WLST command:
    connect('admin_user','admin_password','admin_url')

    For example:

    connect('weblogic','<password>','t3s://ADMINVHN:9002')
  4. Use the setWSMBootstrapConfig to enable WSM pm.url.
    setWSMBootstrapConfig('domain_name','domainpath','ConfigManager','pm.url','auto-ssl')

    For example:

    setWSMBootstrapConfig('mftedg_domain','/u01/oracle/config/domains/mftedg_domain','ConfigManager','pm.url','auto-ssl')

    Check that the appropriate entry is created in the $ASERVER_HOME/config/fmwconfig/wsm-config.xml for the domain. For example:

    
    cat /u01/oracle/config/domains/mftedg_domain/config/fmwconfig/wsm-config.xml
    <?xml version="1.0" encoding="UTF-8"?>
    <orares:properties xmlns:orares="http://xmlns.oracle.com/wsm/resources" xmlns:wsp15="http://www.w3.org/ns/ws-policy" xmlns:orawsp="http://schemas.oracle.com/ws/2006/01/policy" orares:type="CONFIGURATION" orares:resource="/">
       <orares:property orares:category="ConfigManager" orares:name="pm.url">
          <orares:value>auto-ssl</orares:value>
       </orares:property>
    </orares:properties>

Propagating the Domain and Starting the Servers on MFTHOST2

After you start and validate the Administration Server and WLS_MFT1 Managed Server on MFTHOST1, you can then perform the following tasks on MFTHOST2.

Unpacking the Domain Configuration on MFTHOST2

Now that you have the Administration Server and the first WLS_WSM1 Managed Server running on MFTHOST1, you can configure the domain on MFTHOST2.

  1. Log in to MFTHOST2.
  2. If you haven't already, create the recommended directory structure for the Managed Server domain on the MFTHOST2 storage device.
  3. Make sure that the mftedgdomaintemplate.jar file is accessible to MFTHOST2.
    For example, if you are using a separate shared storage volume or partition for MFTHOST2, then copy the template to the volume or partition mounted to MFTHOST2.
  4. Run the unpack command to unpack the template in the domain directory onto the local storage, as follows:
    cd $ORACLE_COMMON_HOME/common/bin
    
    ./unpack.sh -domain=MSERVER_HOME \
                -overwrite_domain=true \
                -template=/complete_path/mftdomaintemplate.jar \ 
                -log_priority=DEBUG \
                -log=/tmp/unpack.log \
                -app_dir=APPLICATION_HOME
    

    In this example:

    • Replace MSERVER_HOME with the complete path to the domain home to be created on the local storage disk. This is the location where the copy of the domain is unpacked.

    • Replace full_path with the complete path and file name of the domain template jar file that you created when you ran the pack command to pack up the domain on the shared storage device.

    • Replace APPLICATION_HOME with the complete path to the Application directory for the domain on shared storage. For more information about the variables, see File System and Directory Variables Used in This Guide.

    Tip:

    For more information about the pack and unpack commands, see Overview of the Pack and Unpack Commands in Creating Templates and Domains Using the Pack and Unpack Commands.

  5. Change directory to the newly created MSERVER_HOME directory and verify that the domain configuration files were copied to the correct location on the MFTHOST2 local storage device.

Starting the Node Manager on MFTHOST2

After you manually set up the Node Manager to use a per host Node Manager configuration, you can start the Node Manager by using the following commands on MFTHOST2:
  1. Change directory to the Node Manager home directory:
    cd $NM_HOME
  2. Run the following command to start the Node Manager and send the output of the command to an output file, rather than to the current terminal shell:
    nohup ./startNodeManager.sh > nodemanager.out 2>&1 &

Starting and Validating the WLS_MFT2 Managed Server on MFTHOST2

Use the procedure that is explained in Starting and Validating the WLS_MFT1 Managed Server on MFTHOST1 to start and validate the WLS_MFT2 Managed Server on MFTHOST2.

Modifying the Upload and Stage Directories to an Absolute Path

After you configure the domain and unpack it to the Managed Server domain directories on all the hosts, verify and update the upload and stage directories for Managed Servers in the new clusters. See Modifying the Upload and Stage Directories to an Absolute Path in an Enterprise Deployment.

Configuring the Web Tier for the Extended Domain

Configure the web server instances on the web tier so that the instances route to the proper clusters in the SOA domain.

Setting Frontend Addresses and WebLogic Plugin for the MFT Cluster and the Administration Server

As a security best practice oracle recommends setting a frontend address for the Administration Server and the MFT cluster. In the initial domain creation steps, since OHS and the frontend Load Balancer may have not been configured yet, the frontend setting is avoided to allow verifications using the individual server addresses. However, at this point and before configuring OHS (and the frontend load balancer, if not done yet) it is required to add the pertaining addresses.

  1. To set the front end for the Administration Server, use the WebLogic Remote Console as follows:
    1. Click Edit Tree.
    2. Click Environment>Servers>AdminServer.
    3. Select the Protocols Tab and then select the HTTP tab.
    4. As Frontend Host, enter the front end LBR address that is used to access Enterprise management and the Remote Console (admin.example.com in the example used in this guide).
    5. Leave the Frontend HTTP port set to 0.
    6. Enter the LBR’s admin listener port (445) as Frontend HTTPS port.
    7. Click Save.
    8. Click the car icon at the top right to commit the changes.
  2. The frontend of the MFT Cluster is configured during the domain creation. To verify the front end for the MFT Cluster, use the Remote Console as follows:
    1. Click Edit Tree.
    2. Click Environment>Clusters>MFT_Cluster.
    3. Select the HTTP tab.
    4. Verify that the value of the frontend name (for example, mft.example.com) is set as the Frontend Host.
    5. Verify that the Frontend HTTP port set to 0.
    6. Verify that the Frontend HTTPS port set to the appropriate value used by the LBR listener to access to MFT (443).
    7. In case of any change, click Save.
    8. Click the car icon at the top right to commit the changes.
    9. Click Save.
    10. Click the car icon at the top right to commit the changes.
  3. Enable the proxy plugin for the domain using the WebLogic Remote Console as follows:
    1. Click Edit Tree.
    2. Click Environment>Domains.
    3. Select Web Application tab.
    4. Click the Welogic Plugin Enable button.
    5. Click Save.
    6. Click the car icon at the top right to commit the changes.

    These changes requires a restart of the AdminServer and the MFT_Cluster to be effective (a notification appears in the WebLogic Remote Console about restart being required).

Configuring Oracle HTTP Server for Managed File Transfer

Follow the steps described in Configuring Oracle HTTP Server for an Enterprise Deployment for installing and configuring the OHS servers.

The only difference for MFT is that, instead of creating the soainternal_vh.conf file, you must create mft_vh.conf file with the following content, to route the requests to the MFT Cluster.

Ensure that you edit the file with the appropriate values for Listen, ServerName, VirtualHost, SSLWallet and Location directives:

File mft_vh.conf:

###################################################################
# Oracle HTTP Server mod_ossl configuration file: ssl.conf        #
###################################################################

# The Listen directive below has a comment preceding it that is used
# by tooling which updates the configuration.  Do not delete the comment.
#[Listen] OHS_SSL_PORT
Listen ohshost1.example.com:4443



##
## SSL Virtual Host Context
##
#[VirtualHost] OHS_SSL_VH
<VirtualHost ohshost1.example.com:4443>
ServerName mft.example.com:443
  <IfModule ossl_module>
   #  SSL Engine Switch:
   #  Enable/Disable SSL for this virtual host.
   SSLEngine on

   #  Client Authentication (Type):
   #  Client certificate verification type and depth.  Types are
   #  none, optional and require.
   SSLVerifyClient None

   #  SSL Protocol Support:
   #  Configure usable SSL/TLS protocol versions.
   SSLProtocol TLSv1.2 TLSv1.3
   
   # Option to prefer the server's cipher preference order 
   SSLHonorCipherOrder on

   #  SSL Cipher Suite:
   #  List the ciphers that the client is permitted to negotiate.
   SSLCipherSuite TLS_AES_128_GCM_SHA256,TLS_AES_256_GCM_SHA384,TLS_CHACHA20_POLY1305_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
   
   #Path to the wallet
   #SSLWallet "${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/instances/${COMPONENT_NAME}/keystores/default"
   SSLWallet "/u02/oracle/config/keystores/orapki/orapki-vh-WEBHOST1"
        
   <FilesMatch "\.(cgi|shtml|phtml|php)$">
      SSLOptions +StdEnvVars
   </FilesMatch>

   <Directory "${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/instances/${COMPONENT_NAME}/cgi-bin">
      SSLOptions +StdEnvVars
   </Directory>

   BrowserMatch "MSIE [2-5]" \
         nokeepalive ssl-unclean-shutdown \
         downgrade-1.0 force-response-1.0

   # Add the following directive to add HSTS
   <IfModule mod_headers.c>
   Header always set Strict-Transport-Security "max-age=63072000; preload; includeSubDomains"
   </IfModule>


  <Location /wsm-pm>
    WLSRequest ON
    WebLogicCluster MFTHOST1:7010,MFTHOST2:7010
  </Location>
<Location /mftconsole>
    WLSRequest ON
    WebLogicCluster MFTHOST1:7010,MFTHOST2:7010
</Location>

  </IfModule>

</VirtualHost>

Validating the Managed File Transfer URLs Through the Load Balancer

This section describes how to validate the configuration of Oracle HTTP Server and to verify that the hardware load balancer routes requests through the OHS instances to the application tier.

  1. Verify that the server status is reported as Running in the WebLogic Remote Console. If the server is shown as Starting or Resuming, wait for the server status to change to Started. If another status (such as Admin or Failed) is reported, check the server output log files for errors.
  2. Verify that you can access the following URL:
    https://admin.example.com:445/em
    https://mft.example.com:443/mftconsole

Configuring and Enabling the SSH-FTP Service for Managed File Transfer

The Oracle Managed File Transfer enterprise deployment topology is based on the Secure File Transfer Protocol (SFTP) for file transfer. SFTP is a separate protocol, packaged with SSH and designed to work similar to FTP, but over a secure connection.

SFTP allows you to limit the number of ports used for file transfer connections. It is preferable to FTP because of its underlying security features and ability to use a standard SSH connection.

Generating the Required SSH Keys

To enable SFTP, you must generate SSH keys. This procedure needs to be done only once on one of the Managed Servers, because Managed File Transfer shares the same SFTP key for all the servers in the cluster.

Without a valid private key, SSH-FTP server fails to start. To comply with security best practices, you should always use a password-protected private key. Perform the following steps to create the SSH key and configure it for the SFTP embedded servers:

  1. Log into MFTHOST1 and run the ssh-keygen command to generate a key.

    Example

    ssh-keygen \-t rsa \-b 2048 -m pem

    ssh-keygen is a standard Unix and Linux command. For more information , see your Operating System documentation.

    1. Enter the location for the file in which to save the key.
    2. Enter a passphrase to protect the key.
    Make a note of this information as you need it later.
  2. Import the key into the Managed File Transfer keystore:
    1. Make sure that the Managed File Transfer Managed Servers are up and running.
    2. Change directory to the following location:
      cd $ORACLE_COMMON_HOME/common/bin
    3. Start the WebLogic Server Scripting Tool (WLST):
      
      export WLST_PROPERTIES="-Dweblogic.security.TrustKeyStore=CustomTrust
      -Dweblogic.security.CustomTrustKeyStoreFileName=/u01/oracle/config/keystores/appTrustKeyStore.pkcs12
      -Dweblogic.security.CustomTrustKeyStorePassPhrase=password"
      ./wlst.sh
    4. Connect to the Administration Port of the first Managed Server, by using the following command syntax:
      connect('admin_user','admin_password','server_url')

      Example

      connect('weblogic','<password>','t3s://MFTHOST1:9014')
    5. Run the following WLST command to import the key:
      importCSFKey('SSH', 'PRIVATE', 'alias', 'pvt_key_file_path')

      Replace alias with the a name that you can use to identify the Managed Server.

      Replace pvt_key_file_path with the name and directory location of the key that you generated earlier in this procedure. See importCSFKey in WLST Command Reference for SOA Suite

  3. After you successfully import the SSH key, enable SSH-FTP and select the private key alias:
    1. Connect to the Managed File Transfer console at the following URL, by using the domain administration user and password:
      https://mft.example.com/mftconsole
    2. Navigate to the Administration tab, and then Keystore Management.
    3. In the SSH Keystore section, enter the passphrase you used in Step 1 to protect the key in the Private Key Password field.
    4. Save the changes that you just made.
    5. Select the Administration tab, and in the navigation tree, expand Embedded Servers.
    6. On the SFTP tab, select Enabled.
    7. Select the private key alias you created earlier in this procedure from the Host Key Alias drop-down menu.
    8. Leave the Authentication Type to Password.
    9. Save your changes.
    10. Click Start to start the SSH-FTP service.

Configuring the SFTP Ports

Before you can use the Secure File Transfer Protocol (SFTP) for Oracle Managed File Transfer, you must configure the SFTP Ports.

  1. Connect to the Managed File Transfer console, by using the domain admin user name and password:
    https://mft.example.com/mftconsole
  2. Select the Administration tab.
  3. In the left navigation pane, expand Embedded Servers.
  4. Click Ports.
  5. Enter 7022 as the Configured Port for the Managed File Transfer servers SFTP services.
  6. Click Save.
  7. Select all and click Restart to restart the server instances.

Configuring Oracle Load Balancer for SFTP Services

As described in the Configuring Virtual Hosts on the Hardware Load Balancer, the Managed File Transfer requires a TCP virtual server in the load balancer for the Secure File Transfer Protocol (SFTP), in addition to the virtual server for HTTPS. This TCP virtual server directly routes the SFTP requests to the SFTP embedded servers that run on the Managed File Transfer Managed Servers. For consistency, the port used in the hardware load balancer and in the SFTP servers is the same (7022). Ensure you have created the appropriate resources (services, pools, and so on) in your load balancer for this virtual server to allow acces to the SFTP through the load balancer.

Additional SFTP Configuration Steps for Managed File Transfer

There are several additional configuration steps that you should perform when you use SFTP with Managed File Transfer.

  1. Connect to the Managed File Transfer console at the following URL:
    https://mft.example.com/mftconsole
  2. Select Administration, and then in the navigation tree, select Embedded Servers.
    1. Update the Root Directory so that it points to a shared storage.

      Example

      ORACLE_RUNTIME/mftedg_domain/MFT_Cluster/ftp_root
    2. Click Save.
  3. Select Administration, and then in the navigation tree, select Server Properties.
  4. Update the High Availability Properties:
    1. Update the payload and callout directories so that they point to a shared storage location that can be accessed by the different servers in the cluster.

      Example

      ORACLE_RUNTIME/mftedg_domain/MFT_Cluster/storage

      ORACLE_RUNTIME/mftedg_domain/MFT_Cluster/callouts

    2. Set the Control Directory to a shared location.

      Example

      ORACLE_RUNTIME/mftedg_domain/MFT_Cluster/control_dir

      The Control Directory is the directory path that the Managed File Transfer File and FTP adapters use to handle high availability use cases. This field is required if the MFT is running in HA environment. You must set it to a shared location if multiple Oracle WebLogic Server instances run in a cluster.
    3. Verify the values in the following fields.
      • Verify that the value for Inbound Datasource is set to jdbc/MFTDataSource.

      • Verify that the value for Outbound Datasource is set to jdbc/MFTDataSource.

    4. Save the changes that you made so far.
    5. In the Navigation tree, expand Advanced Delivery Properties.

      The Advanced Delivery Properties capture the Internal Address and External Address (IP addresses) and the FTP, FTPS, and SFTP ports that the load balancer uses.

      Use these settings when Oracle Managed File Transfer sends a payload as an FTP or SFTP reference. If the values are set, they are used to construct the FTP reference (FTP/SFTP host address and ports).

      If Managed File Transfer is running behind internal and external proxies, then the Internal and External IP addresses are required.

      • Internal Address: Leave this field blank, unless you use an internal load balancer for SFTP. The default enterprise deployment uses an external load balancer, but not an internal load balancer.

      • External Address: Enter the address that is used as the entry point for your SFT requests through the external load balancer.

        For example, enter sftp.example.com as the address and 7022 as SFTP port.

    6. Save the changes you made and exit the console.
  5. Restart the WLS_MFT Managed servers.
  6. Use any standard SFTP client application to verify that you can use SFTP to access the Managed File Transfer servers.

    Example

    sftp -o "Port 7022" weblogic@MFTHOST1
    Connecting to MFTHOST1 ... 
    Password authentication 
    Password:
    sftp>
  7. Use any standard SFTP client application to verify that you can use SFTP to access the Managed File Transfer servers through the load balancer.

    Example

    sftp -o "Port 7022" weblogic@mft.example.com
    Connecting to mft.example.com ... 
    Password authentication 
    Password:
    sftp>

Creating a New LDAP Authenticator and Provisioning Users for Managed File Transfer

When you configure an Oracle Fusion Middleware domain, the domain is configured by default to use the WebLogic Server authentication provider (DefaultAuthenticator). However, for an enterprise deployment, Oracle recommends that you use a dedicated, centralized LDAP-compliant authentication provider.

This procedure is required for each new Oracle Fusion Middleware domain. For an Oracle Managed File Transfer domain, you can perform the following tasks:
  1. Review Creating a New LDAP Authenticator and Provisioning Enterprise Deployment Users and Group to understand the required concepts and to create the new LDAP Authenticator.
  2. When you provision the users and groups, use the following user and group names for Managed File Transfer administration authentication:
    Administrative user: weblogic_mft
    Administrative group: MFT Administrators
  3. Assign product-specific administration role to the group by logging in to Oracle Enterprise Manager Fusion Middleware Control. See Configuring Roles for Administration of an Enterprise Deployment.

Replacing Connect Strings with the Appropriate TNS Alias

Oracle recommends using TNS Alias in the connection strings used by FMW components instead of repeating long JDBC strings across multiple connections pools.

For more information about how to use TNS alias in your Datasources, see Using TNS Alias in Connect Strings in the Common Configuration and Management Tasks for an Enterprise Deployment chapter.

Backing Up the Configuration

It is an Oracle best practices recommendation to create a backup after you successfully extended a domain or at another logical point. Create a backup after you verify that the installation so far is successful. This is a quick backup for the express purpose of immediate restoration in case of problems in later steps.

The backup destination is the local disk. You can discard this backup when the enterprise deployment setup is complete. After the enterprise deployment setup is complete, you can initiate the regular deployment-specific Backup and Recovery process.

For information about backing up your configuration, see Performing Backups and Recoveries for an Enterprise Deployment.