galiacheng / oracle-forms-reports-weblogic-on-azure

Create Highly Available Oracle Forms and Reports 12c clusters on Azure using Azure WebLogic VM offer.
Apache License 2.0
12 stars 5 forks source link
azure high-availability oracle-forms oracle-reports weblogic

Create Highly Available Oracle Forms and Reports clusters on Azure

This document guides you to create highly available Oracle Forms and Reports clusters on Azure VMs step by step, including:

You will get Forms and Reports running as the picture shows:

Oracle Forms and Reports Architecture

This sample does not cover high availability for Oracle Database, you can follow Oracle HA in Azure- Options to create Oracle Data Guard.

Azure Application Gateways are always deployed in a highly available fashion. You can scale up following Scaling Application Gateway v2.

See network and Availability Zone topology.

Network and Availability Zone Topology

Contents

Prerequisites

An Azure account with an active subscription. Create an account for free.

Provision Azure WebLogic Virtual Machine

Azure provides a series of Oracle WebLogic base images, it'll save your effort for Oracle tools installation. This sample will setup Oracle Forms and Reports based on the Azure WebLogic base image, follow the steps to provision a machine with JDK and WebLogic installed:

It will take 10min for the offer completed. After the deployment finishes, you will have a machine with JDK and WLS installed. Then you are able to install and configure Forms and Reports on the top of the machine.

Create Oracle Database

You are required to have a database to configure the JRF domain for Forms and Reports. This sample uses Oracle Database. Follow this document to create an Oracle database

If you are following the document to create Oracle database, write down the credentials to create domain schema, username and password should be: sys/OraPasswd1

Create Windows VM and set up XServer

Though you have Oracle WebLogic instance running now, to create Oracle Forms and Reports, you still need to install Oracle Forms and Reports. To simplify the interface, let's provision a Windows machine and leverage XServer to install required tools with graphical user interface.

Follow the steps to provision Windows VM and set up XServer.

Edit the security to allow access from your terminal.

After the Windows server is completed, RDP to the server.

Install Oracle Fusion Middleware Infrastructure

Download Oracle Fusion Middleware Infrastructure installer from https://www.oracle.com/webapps/redirect/signon?nexturl=https://download.oracle.com/otn/nt/middleware/12c/122140/fmw_12.2.1.4.0_infrastructure_Disk1_1of1.zip

Unzip the file and copy fmw_12.2.1.4.0_infrastructure.jar to adminVM. Make sure fmw_12.2.1.4.0_infrastructure.jar is copied to /u01/oracle/fmw_12.2.1.4.0_infrastructure.jar, owner of the file is oracle, you can set the ownership with command chown oracle:oracle /u01/oracle/fmw_12.2.1.4.0_infrastructure.jar.

Now let's use the XServer to install Oracle Fusion Middleware Infrastructure on adminVM.

Steps to install Oracle Fusion Middleware Infrastructure on adminVM:

Install Oracle Forms and Reports

Following the steps to install Oracle Forms and Reports:

Now you have Forms and Reports installed in the adminVM. Let's clone the machine for managed servers.

Clone machine for managed servers

You have Oracle Forms and Reports installed in the adminVM, you are able to reuse the installation by cloning adminVM for managed servers.

Follow the steps to clone adminVM, for high availability, let's create the disk and machine in different zones as the table shows:

Index Machine Name Disk Name Availability Zone
1 mspVM1 mspVM1_OS_Disk Zone 1
2 mspVM2 mspVM2_OS_Disk Zone 2
3 mspVM3 mspVM3_OS_Disk Zone 3

Create a snapshot from adminVM OS disk. If you have snapshot of adminVM, skip the following two steps:

Keep the snapshot, you will use it for scaling.

Create VMs for Forms and Reports replicas based on the snapshot:

  1. Create a disk from the snapshot.
  2. Create a VM with your expected name, e.g. mspVM1 on the disk. Make sure you are selecting the right availability zone, see above table.
  3. SSH to the machine, use root user and change the hostname.
    • Set hostname with hostnamectl set-hostname hostname. For example, set hostname mspVM1 with command hostnamectl set-hostname mspVM1
  4. Repeat step1-3 for mspVM2 or another new machine, make sure you have set correct hostname.

For the initial setup, make sure you have three machine ready to configure Forms and Reports: adminVM, mspVM1, mspVM2, and move on with next section.

For new replicas, make sure you have the new machine ready, and continue from Create Forms and Reports components.

Create schemas using RCU

You are required to create the schemas for the WebLogic domain.
The following steps leverage XServer and RCU to create schemas on the Oracle database created previously.

Configure Virtual IP for Admin Server

We will use a secondary virtual IP address for the Admin Server, rather than using the primary IP address of adminVM, which makes the Admin Server more flexible for backup and failover. To enable the secondary IP address, you are required to make changes to:

  1. Infrastructure: add a secondary IP to the Azure Network Interface of adminVM.
  2. Virtual Machine: add a local ethernet connection and restart networking service.
  3. Node manager: configure node manager to listen the new IP address and start the node manager with the IP address.
  4. Admin Server: configure Admin Server to listen the new IP address and restart Admin Server.

Make sure you have at least one available private IP address that hasn't been used by other machine, this sample use 10.0.0.16. You can find more information from this document.

Now you have added the IP address to the external network interface of adminVM, to connect adminVM with it, you still need to enable local ethernet connection on the machine.

You have to login to adminVM and configure the ethernet connection.

secondaryIP="10.0.0.16"
cd /etc/sysconfig/network-scripts
ls ifcfg-*
touch ifcfg-eth0:1
vi ifcfg-eth0:1

cat <<EOF >ifcfg-eth0:1
DEVICE=eth0:1
BOOTPROTO=static
ONBOOT=yes
IPADDR=${secondaryIP}
NETMASK=255.255.255.0
EOF
[root@adminVM1 network-scripts]# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.0.4  netmask 255.255.255.0  broadcast 10.0.0.255
        inet6 fe80::20d:3aff:fe8f:1fe7  prefixlen 64  scopeid 0x20<link>
        ether 00:0d:3a:8f:1f:e7  txqueuelen 1000  (Ethernet)
        RX packets 104754  bytes 69209518 (66.0 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 75892  bytes 19074850 (18.1 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0:0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.0.15  netmask 255.255.255.0  broadcast 10.0.0.255
        ether 00:0d:3a:8f:1f:e7  txqueuelen 1000  (Ethernet)

Configure Forms and Reports with a new domain

Create domain on adminVM

Now, the machine and database are ready, let's move on to create a new domain for Forms and Reports.

Now you are able to access admin console with http://adminserver-ip:7001/console, and Enterprise Manager with http://adminserver-ip:7001/em.

Create domain on managed machine

Now, you have Forms and Reports configured in adminVM, let's apply the domain on mspVM1 and mspVM2.

You can also follow the steps to apply domain to a new machine for new replicas.

Configure domain on managed machine:

  1. SSH to your machine, e.g login to mspVM1 with command ssh weblogic@mspVM1

  2. Use root user to set the ownership of domain package

    sudo su
    chown oracle:oracle /tmp/cluster.jar
  3. Use oracle user, sudo su - oracle

  4. Unpack the domain

    cd /u01/app/wls/install/oracle/middleware/oracle_home/oracle_common/common/bin
    bash unpack.sh -domain=/u02/domains/wlsd -template=/tmp/cluster.jar 
  5. Make sure the node manager listen address is correct by cat /u02/domains/wlsd/nodemanager/nodemanager.properties. The listen address should be private IP of the machine.

  6. Exit oracle user with command exit

  7. Use root user: sudo su

  8. Create service for node manager

    cat <<EOF >/etc/systemd/system/wls_nodemanager.service
    [Unit]
    Description=WebLogic nodemanager service
    After=network-online.target
    Wants=network-online.target
    [Service]
    Type=simple
    # Note that the following three parameters should be changed to the correct paths
    # on your own system
    WorkingDirectory="/u02/domains/wlsd"
    ExecStart="/u02/domains/wlsd/bin/startNodeManager.sh"
    ExecStop="/u02/domains/wlsd/bin/stopNodeManager.sh"
    User=oracle
    Group=oracle
    KillMode=process
    LimitNOFILE=65535
    Restart=always
    RestartSec=3
    [Install]
    WantedBy=multi-user.target
    EOF
  9. Start node manager

    sudo systemctl enable wls_nodemanager
    sudo systemctl daemon-reload
    sudo systemctl start wls_nodemanager

For initial setup, apply step 1-8 to mspVM2, and continue from Create and start Reports components. For new replicas, apply step 1-8 to your new machines, and continue from Create and start Reports tools for new replicas.

Create and start Reports components

Now, you have node manager running on adminVM, mspVM1, mspVM2, and Admin Server up in adminVM.
To successfully start Reports server, you must create and start the Reports components.

Let's create the ReportsToolsComponent using WLST.

Start Forms and Reports managed servers

Now, you have Reports tools components created and running, you are able to start the managed server and start the Reports In-process server.

Now you are able to start Reports in process server from browser.

Configure Forms and Reports as a Linux service

Now, you have the Forms and Reports running on your managed machines. To start them automactically when the machine is rebooted, you have to configure them as Linux service.

Please note that, as Forms and Reports are running on managed nodes, no change needed for adminVM.

Orders to start Forms and Reports:

The following WLST script is to start WLS_FORMS1, WLS_REPORTS1 on mspVM1.

Change the user name WLS_USER, password WLS_PSWD with your value, and ADMIN_SERVER_ADDRESS with the virtual IP address created in Configure Virtual IP for Admin Server, here is 10.0.0.16.

To create the script on mspVM2 and new replicas, change FORMS_SERVER_NAME, REPORTS_SERVER_NAME and MSPVM_ADDRESS with corresponding values.

Switch to oracle with sudo su - oracle and create script.

#weblogic admin account user name
WLS_USER=weblogic
#weblogic admin account password
WLS_PSWD=Secret123456
#virtual IP address of adminVM
ADMIN_SERVER_ADDRESS=10.0.0.16
#Froms server name
FORMS_SERVER_NAME=WLS_FORMS1
#Reports server name
REPORT_SERVER_NAME=WLS_REPORTS1
DOMAIN_HOME_PATH=/u02/domains/wlsd
INSTALL_PATH=/u01/app/wls/install
#private IP address of current machine
MSPVM_ADDRESS=10.0.0.6

cat <<EOF > $DOMAIN_HOME_PATH/startFormsReports.py 
import os, sys
connect('${WLS_USER}','${WLS_PSWD}','${ADMIN_SERVER_ADDRESS}:7001')
domainRuntime()
cd("/ServerLifeCycleRuntimes/${FORMS_SERVER_NAME}")
status=cmo.getState()
if status != "RUNNING":
  start('${FORMS_SERVER_NAME}','Server')
else:
  print 'Forms ${FORMS_SERVER_NAME} is already running'

cd("/ServerLifeCycleRuntimes/${REPORT_SERVER_NAME}")
status=cmo.getState()
if status != "RUNNING":
  start('${REPORT_SERVER_NAME}','Server')
else:
  print 'Reports ${REPORT_SERVER_NAME} is already running'

disconnect()
EOF

cat <<EOF >$DOMAIN_HOME_PATH/startFormsReports.sh
#!/bin/sh

${INSTALL_PATH}/oracle/middleware/oracle_home/oracle_common/common/bin/wlst.sh $DOMAIN_HOME_PATH/startFormsReports.py > /dev/null 2>&1 &

echo Wait for Reports server ready

code="404"
counter=1
while [[ "\${code}" != "200" && \${couter} -lt 300 ]]
do
  code=\$(curl -s -o /dev/null -w "%{http_code}" http://${MSPVM_ADDRESS}:9002/reports/)
  echo "http code: \${code}, counter: \${counter}"
  counter=\$((counter + 1))
  sleep 2
done

echo Start Reports In-process server
curl http://${MSPVM_ADDRESS}:9002/reports/rwservlet/startserver > /dev/null 2>&1 &
echo Done!
EOF

The following WLST script is to stop WLS_FORMS1, WLS_REPORTS1 on mspVM1.

Change the user name WLS_USER, password WLS_PSWD and ADMIN_SERVER_ADDRESS with the virtual IP address created in Configure Virtual IP for Admin Server, here is 10.0.0.16.

To create the script on mspVM2 and new replicas, change FORMS_SERVER_NAME and REPORTS_SERVER_NAME with corresponding values.

WLS_USER=weblogic
WLS_PSWD=Secret123456
ADMIN_SERVER_ADDRESS=10.0.0.16
FORMS_SERVER_NAME=WLS_FORMS1
REPORT_SERVER_NAME=WLS_REPORTS1
DOMAIN_HOME_PATH=/u02/domains/wlsd
INSTALL_PATH=/u01/app/wls/install

cat <<EOF > $DOMAIN_HOME_PATH/stopFormsReports.py 
import os, sys
connect('${WLS_USER}','${WLS_PSWD}','${ADMIN_SERVER_ADDRESS}:7001')
domainRuntime()
cd("/ServerLifeCycleRuntimes/${FORMS_SERVER_NAME}")
shutdown('${FORMS_SERVER_NAME}','Server')
cd("/ServerLifeCycleRuntimes/${REPORT_SERVER_NAME}")
shutdown('${REPORT_SERVER_NAME}','Server')

disconnect()
EOF

cat <<EOF >$DOMAIN_HOME_PATH/stopFormsReports.sh
#!/bin/sh

${INSTALL_PATH}/oracle/middleware/oracle_home/oracle_common/common/bin/wlst.sh $DOMAIN_HOME_PATH/stopFormsReports.py
sleep 2s
echo Done!
EOF

Now, switch to root user with command exit, create and enable the service.

DOMAIN_HOME_PATH=/u02/domains/wlsd
INSTALL_PATH=/u01/app/wls/install
cat <<EOF >/etc/systemd/system/ofmw.service
[Unit]
Description=Oracle Fusion Middleware Forms and Reports 12c
After=wls_nodemanager.service
Wants=wls_nodemanager.service
[Service]
Type=oneshot
RemainAfterExit=true
WorkingDirectory="/u02/domains/wlsd"
ExecStart="$DOMAIN_HOME_PATH/startFormsReports.sh"
ExecStop="$DOMAIN_HOME_PATH/stopFormsReports.sh"
User=oracle
Group=oracle
KillMode=process
LimitNOFILE=65535
[Install]
WantedBy=multi-user.target
EOF

Change file permission:

DOMAIN_HOME_PATH=/u02/domains/wlsd
chmod 750 $DOMAIN_HOME_PATH/startFormsReports.py
chmod 750 $DOMAIN_HOME_PATH/startFormsReports.sh
chmod 750 $DOMAIN_HOME_PATH/stopFormsReports.py
chmod 750 $DOMAIN_HOME_PATH/stopFormsReports.sh

Enable the service:

sudo systemctl enable ofmw.service
sudo systemctl daemon-reload
sudo systemctl start ofmw.service

Add Forms and Reports replicas

You are able to add Forms and Reports replicas by cloning machine and starting the corresponding components.

Create a new machine for new replicas

Clone adminVM following Clone machine for managed servers, let's name the new machine with mspVM3.

Create managed servers and Forms component

Firstly, you are required to create and start replated components. This sample leverages WLST offline mode to update the existing domain with new machine, new managed servers and new component, which requires restart on Admin Server to cause changes working.

This is an example to update the existing domain to start Forms and Reports on mspVM3, replace the machine name and component name with yours.

Use WLST to add new replicas:

Apply domain to the new machine

Now, you have finished updating the domain. Let's pack the domain and apply the domain to new machine.

Create and start Reports tools

To enable Reports in process server, you are required to create and start Reports Tools Component. Follow the steps to enable Reports Tools component for new Reports replicas.

Start servers

Forms and Reports system components on mspVM3 are ready, and node manager is up on mspVM3. Let's start the managed server from console portal.

Let's start Reports in process server from browser.

Note: if you have setup Applcation Gateway for load balancing, add the private IP of your new machine to backend pool. then the Applicatin Gateway is able to managed the traffic to the new replicas.

Configure Private Application Gateway

Create Application Gateway

This sample will use Azure Application Gateway as the top level load balancing of Forms cluster.

Follow the step to create the Application Gateway, you must enable Cookie-based affinity for Forms applciation. Make sure you are using a correct backend port, here is 9001.

Wait for the resources completed.

Configure Backend Pool

Configure Health Probe

After the health probe is completed without error, associate the http setting with the probe.

Check the backend health:

Then you should be able to access Forms using private IP of application gateway.

If you want to also manage the traffic to Reports cluster, you can add Path-based routing to /reports/rwservlet in the rule.

Enable Highly Available Administration Server

The high availability of applications in the Forms and Reports environment is realized by clustering. Managed servers in the cluster work together. The information about transactions is distributed cluster-wide. If a cluster member fails, another server takes over the tasks of the failed server and executes them. In this way, the applications are kept running without interruption.

The Admin Server is a single point of failure: if the server fails, the Domain is no longer administrable:

– Configuration changes cannot be performed

– The administration console is not available

The managed servers are still running and can continue to work, even if the Admin Server is not available, you can find Oracle Fusion Middleware High Availability Guide for more information.

This section enables high availability on Administration Server based on the virtual IP address you created previously in Configure Virtual IP for Admin Server, now you can use one of the approaches to achieve that:

  1. Moving of the configuration to the shared storage and setting up a backup host. The Administration Server on the active host owns the domain directory in shared storage. If the active host fails, the backup host takes over and restarts the Administration Server from the shared domain directory.
  2. Leveraging Azure Site Recovery Service. The application consistent snapshot feature of Azure Site Recovery ensures that the data is in usable state after the failover. The service enables customers to use Azure as a disaster recovery site on a pay-as-you-go model without having to invest in additional infrastructure.

The following table lists some difference between two approaches:

Difference Use a pre-defined backup machine Use Azure Site Recovery
Share domain configuration Yes.
Use Azure NFS File share.
No.
Auxiliary Azure Services Azure Automation Account for automation. Azure Site Recovery for Azure VM Zone to Zone recovery.
Azure Automation Account for automation.
Additional infrastructure Azure NFS File Share for shared domain configuration.
Azure Virtual Machine, Azure Network Interface and Azure Disk for backup host.
No.
RTO 3-9 min.
Need not shutdown the primary machine: 3-5 min.
Have to shutdown the primary machine: 8-9 min.
8-20 min.
Need not shutdown the primary machine: 8-12 min.
Have to shutdown the primary machine: 15-20 min.
Pros and Cons Pros:
1. Save time to provision a new machine.
Cons:
1. Domain configuration in NFS share may cause longer network latency and effect the performance of Admin Server.
2. Extra cost for the pre-defined machine.
Pros:
1. No additional infrastructure.
2. Leverage ASR to backup and protect the running machine.
Cons:
1. Takes longer to failover as it has to provison target resources. 2. Extra cost for ASR.

To move on, make sure you have enabled secondary IP for Admin Server, see Configure Virtual IP for Admin Server.

Use a pre-defined backup machine

To make sure the domain configuration is the same in both machines, this approach move the domain configuration to shared storage, this sample uses Azure File NFS share.

Create NFS share

Let's create an Azure Storage Account and NFS share from Azure Portal, you must select Premium sku to enable NFS share.

After the deployment finishes, you have enable the private access from your WebLogic machines to the storage account.

Let's create the NFS share.

After the NFS share deployment completes, you are able to mount it to adminVM.

Mount NFS share to adminVM

This sample saves the domain configuration in /u02. You will move all the data in this directory to NFS share. Before you move the data, you are required to back up the data in the directory and then create a mount point with directory /u02. To avoid conflict between the mounted file system and the OS disk, let's delete the directory before mounting the NFS share.

Now you have successfully moved domain configuration to NFS share. The next steps are created a backup machine from the snapshot of current adminVM.

Create and configure backup machine

Take a snapshot from adminVM OS disk. Note that do not use this snapshot to create managed machine for managed servers.

Create backup machine based on the snapshot:

Test failover

Now you have adminVM as the primary host and adminVMBak as backup host. Domain configuration are stored in NFS share, and share between both machines. Changes from Admin Server that runs on either machine are persisted to NFS share.

Before testing, let's start Admin Server by starting adminVM from Azure Portal. Make sure you are able to access Console portal or EM from browser.

Follow the steps to test failover manually:

  1. Stop adminVM.
  2. Remove secondary IP from adminVM: go to Azure Portal -> open adminVM -> select Settings -> select Networking -> open the network interface -> select Settings -> select IP Configurations -> remove ipconfig2 which was configured with virtual IP of Admin Server.
  3. Assign secondary IP to adminVMBak: go to Azure Portal -> open adminVMBak -> select Settings -> select Networking -> open the network interface -> select Settings -> select IP Configurations -> Add ipconfig2 with static IP address, here is 10.0.0.16.
  4. Start adminVMBak. Wait for Admin Server ready.

You should be able to access Admin Server and have the same domain configuration as that runs on adminVM.

You are able to automate assigning secondary IP using AssignIP-Workflow.ps1 in Automation Account. Follow Azure Automation Account to create Runbook and configure credentials. The script is using user managed identity, you must assign at least Contributor role to the user identity.

Use Azure Site Recovery

Azure Site Recovery will back up the disk of VM once you enable and protect the replica, you need not move the domain configuration to shared storage.

Enable Azure Site Recovery

Follow the step to enable ASR:

It takes about 1 hour for the resources ready. Once the deployment completes, you are able to find the replica from Recovery service vault.

Failover manually

ASR allows you to test failover in a seperated vnet. You are able to test failover to validate VM resource, but the Admin Server fails to access managed servers in a seperate vnet.

Follow the steps to start failover.

It takes about 15 min to complete the failover steps. You still need to assign the virtual IP address of Admin Server to the target machine:

You have to commit the failover after Admin Server is up: select Protected items -> Replicated istems -> adminVM -> commit.

Custom recovery plan

You are able to automate above steps with a custom recovery plan.

Before creating a custom plan, you're required to have an automation account in a different region:

Now you are ready to create a custom plan:

After the plan is completed, open the plan, you will find Customize button, hit that button and add a post action to group 1.

Steps to add post action to group 1:

Save the recovery plan. The plan is able to assign IP to target VM automatically.

Open the plan and click failover, the plan will provison and start target machine in the target resource group. You have to commit the failover after Admin Server is up: select the plan and click Commit.

Please note that, if you fail back from target machine to source machine, you have to assign IP maunaully, the plan will not trigger the post action for Re-protect.

Validate

Validate the Forms testing application.

Clean up

Delete the resource group from Azure portal.

Troubleshoot

  1. EM is slow

    Enable caching of FMW Discovery data.

    • Login EM
    • Select WebLogic domain -> System MBean Browser -> Application Defined MBeans -> emoms.props -> Server.admin -> Application.em -> Properties -> emoms-prop
    • Click Operations
    • Select setProperty
    • Set the following properties
      1. oracle.sysman.emas.discovery.wls.FMW_DISCOVERY_USE_CACHED_RESULTS=true
      2. oracle.sysman.emas.discovery.wls.FMW_DISCOVERY_MAX_CACHE_AGE=7200000
      3. oracle.sysman.emas.discovery.wls.FMW_DISCOVERY_MAX_WAIT_TIME=10000
    • Select WebLogic domain -> Refresh WebLogic domain.
  2. SSH WARNING: POSSIBLE DNS SPOOFING DETECTED!

    You may run into this error when connecting a machine using SSH, see the details:

    [oracle@adminVM1 bin]$ scp /tmp/cluster.jar weblogic@mspVM3:/tmp/cluster.jar
    @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
    @       WARNING: POSSIBLE DNS SPOOFING DETECTED!          @
    @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
    The ECDSA host key for mspvm3 has changed,
    and the key for the corresponding IP address 10.0.0.10
    is unknown. This could either mean that
    DNS SPOOFING is happening or the IP address for the host
    and its host key have changed at the same time.
    @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
    @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
    @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
    IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
    Someone could be eavesdropping on you right now (man-in-the-middle attack)!
    It is also possible that a host key has just been changed.
    The fingerprint for the ECDSA key sent by the remote host is
    SHA256:VEn4PQNWtIJhA337odSkzhPS1rIZ6oz0Bco6+ZNuvsk.
    Please contact your system administrator.
    Add correct host key in /u02/oracle/.ssh/known_hosts to get rid of this message.
    Offending ECDSA key in /u02/oracle/.ssh/known_hosts:2
    ECDSA host key for mspvm3 has changed and you have requested strict checking.
    Host key verification failed.
    lost connection

    Solution: remove ~/.ssh/knownhosts

  3. Reports failure: REP-50125: org.omg.CORBA.INTERNAL: vmcid: SUN minor code: 208 completed: No

    Error details:

    [2008/7/10 4:15:49:891] Info 56025 (RWServer:startServer): Reports Server is starting up
    [2008/7/10 4:15:50:274] Exception 50125 (org.omg.CORBA.INTERNAL: vmcid: SUN minor code: 208 completed: No
    at com.sun.corba.se.internal.corba.ORB.getLocalHostName(ORB.java:924)
    at com.sun.corba.se.internal.corba.ORB.checkApplicationPropertyDefaults(ORB.java:880)
    at com.sun.corba.se.internal.corba.ORB.set_parameters(ORB.java:457)
    at com.sun.corba.se.internal.POA.POAORB.set_parameters(POAORB.java:153)
    at com.sun.corba.se.internal.Interceptors.PIORB.set_parameters(PIORB.java:333)
    at org.omg.CORBA.ORB.init(ORB.java:337)
    at oracle.reports.utility.Utility.createORB(Utility.java:1902)
    at oracle.reports.server.RWServer.startServer(RWServer.java:764)
    at oracle.reports.server.RWServer.jniMain(RWServer.java:243)
    ): Internal error org.omg.CORBA.INTERNAL: vmcid: SUN minor code: 208 completed: No
    [2008/7/10 4:15:50:282] Info 50002 (RWServer:shutdown): Server is shutting down

    Root cause: incorret hostname and ip address.

    Solution: double check entries in /etc/hosts. See Oracle support doc.

  4. ERROR: Temporary directory /tmp does not have enough free space.

    -bash-4.2$ ./fmw_12.2.1.4.0_fr_linux64.bin
    ERROR: Temporary directory /tmp does not have enough free space. At least 3134 MB of free space are required.
    Please input another directory or [Exit]:
    

    Solution: specify a tmp folder

    sudo su - oracle
    # create a tmp folder
    mkdir /u01/oracle/tmp
    # export DISPLAY variable
    export DISPLAY=<yourWindowsVMVNetInternalIpAddress>:0.0
    # install again
    ./fmw_12.2.1.4.0_fr_linux64.bin -J-Djava.io.tmpdir=/u01/oracle/tmp
    
  5. How to copy files to WLS machine?

    You are able to use scp command to copy files to WLS machine, if you want to enable WLS proccess to access those files, make sure the copied files are owned by oracle.

    The following example copys files from local machine to mspVM1:

    scp mylibs.zip weblogic@<mspvm1-ip>:/home/weblogic/mylibs.zip

    Now, SSH to mspVM1 and unzip the files to /u01/oracle/mylibs.

    ssh weblogic@<mspvm1-ip>
    
    sudo su
    
    unzip /home/weblogic/mylibs.zip -d /u01/oracle/mylibs
    
    rm /home/weblogic/mylibs.zip

    Go to /u01/oracle/mylibs and valid the files. Set the file ownership:

    chown oracle:oracle /home/oracle/mylibs -R

    Now you are able to use oracle user to move to files to any place that owns by oracle.

    The following example is to move files to /u02/domains/wlsd/lib/

    mv -R /home/oracle/mylibs/* /u02/domains/wlsd/lib/

    To check the owner of files:

    ls -l /u02/domains/wlsd/lib/