Executing screen command in Linux 8 gives error:
bash: screen: command not found
This is because: From Linux 8.x onwards screen has been deprecated and tmux has been introduced.
Execute Un-Interrupted Red Hat Linux 8 Sessions (Remotely in the Background) using TMUX (Replacement of screen utility In Earlier Linux Versions)

In the life of an Oracle EBS Apps DBA / Database Administrator, especially when a DBA comes into a situation that he has to connect/ssh to the client’s ERP’s Database or Application Server in order to run or manage a long-running task on a remote Linux server (e.g., a cloud VM or a physical server).

Example:
Particularly
* Database Backup
* Database optimization scripts or statistics collection jobs
* Tar backup of the Oracle ERP File System.
* Performing database migration from an old server to a new one. (The migration would indeed involve transferring large RMAN Backups which may be  Long running/time-consuming)

These critical operations needs around couple of hours to finish gracefully or otherwise since we ‘re working over SSH, and we risk losing the session or the connection due to network issues, system shutdowns, or even just a lost Wi-Fi signal we would obviously risk interrupting the entire process and might have to restart the same job from the begining.

So in order to double ensure that we go through seemlessly we offcourse need to run uninterrupted at any cost !.

In this post I am sharing very basic usage of tmux as how tmux can help save our critical jobs keep  running without any interruption:

This is a game-changer in environments where maintaining session continuity is crucial.

================

My Linux version is: 8.10

STEP 1:   INSTALL TMUX RPM PACKAGE ON LINUX 8
[root@ebstest Packages]# pwd
/media/rhel810-dvd/BaseOS/Packages
[root@ebstest Packages]# yum -y install tmux-2.7-3.el8.x86_64.rpm
Updating Subscription Management repositories.
Unable to read consumer identity
This system is not registered with an entitlement server. You can use subscription-manager to register.
Last metadata expiration check: 1:42:01 ago on Wed 26 Mar 2025 08:28:53 AM +03.
Dependencies resolved.
Package Architecture Version Repository SizeInstalling:
tmux x86_64 2.7-3.el8 @commandline 317 k
Transaction Summary

Install 1 Package
Total size: 317 k
Installed size: 726 k
Downloading Packages:
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Preparing : 1/1
Installing : tmux-2.7-3.el8.x86_64 1/1
Running scriptlet: tmux-2.7-3.el8.x86_64 1/1
Verifying : tmux-2.7-3.el8.x86_64 1/1
Installed products updated.
Installed:
tmux-2.7-3.el8.x86_64
Complete!
[root@ebstest Packages]#

=========================

We are going to start a session for our critical Database Backup Activity approximately requires around 3 hours of continuous and uninterrupted execution

STEP 2: START A NEW TMUX BACKGROUND SESSION

[appluat@ebstest ~]$ tmux new -s “database backup tmux seesion 1”

STEP 3: START TAR BACKUP OF DATA FILES IN TMUX BG SESSION

STEP 4 : TO TEMPORARY DISCONNECT FROM THIS TMUX SESSION WITHOUT STOPPING THE TAR BACKUP PROCESS AND KEEPING IT RUNNING
Hit —>   CTRL + B and then —> D ( without CTRL Key )
This will detach your session

OR

YOU MAY JUST DISCONNECT PUTTY TO SIMPLY SEE THE BENEFIT OF TMUX BACKGROUND SESSION

STEP 5 : CONNECT AGAIN TO YOUR SERVER AND CHECK EXISTING TMUX SESSIONS
[orauat@ebstest ~]$ tmux ls
database backup tmux seesion 1: 1 windows (created Wed Mar 26 12:06:24 2025) [88×14]
[orauat@ebstest ~]$
database backup tmux seesion 1

The above listed session is the same that we created

STEP 6: NOW CONNECT/RESUME TO YOUR SAME DATABASE TMUX SESSION

[appluat@ebstest ~]$ tmux attach -t “database backup tmux seesion 1”

RESULT:

OUR TAR BACKUP IS STILL INTACT IN OUR TMUX SESSION AND RUNNING NORMAL.

JAVA UPGRADE STEPS :

NOTE: JDK 7 has reached Sustaining Support at the end of July 2022. However with Oracle EBS only JDK 7 is certified and supported untill the time of posting this blog

To Upgrade JDK : Via Oracle Java checker utility EJCPUC.sh to check recommendation of latest certified JAVA to deploy on your Target EBS Application Node

Download Latest certified java with EBS 12.2

Create Temporary Folder to upload Latest JDK on EBS App Server
mkdir -p /archive/Upg_Stuff/JDK_451/

ls -lrt
p37308812_170_451_Linux-x86-64.zip —-> 64 bit Java
p37308812_170_451_LINUX.zip —-> 32 bit Java

Extract both zip files one by one :
unzip p37308812_170_451_Linux-x86-64.zip
unzip p37308812_170_451_LINUX.zip

-rw-r–r–. 1 appluat dba 65789345 Dec 18 17:38 jdk-7u451-linux-x64.tar.gz
-rw-r–r–. 1 appluat dba 44697584 Dec 18 17:38 jdk-7u451-linux-x64.rpm
-rw-r–r–. 1 appluat dba 69117035 Dec 18 17:38 jdk-7u451-linux-i586.tar.gz
-rw-r–r–. 1 appluat dba 47324524 Dec 18 17:38 jdk-7u451-linux-i586.rpm

Remove rpm files or any other unwanted files that we do not plan to use :
rm -rf jdk-7u451-linux-x64.rpm
rm -rf jdk-7u451-linux-i586.rpm

[appluat@ebstest JDK_451]$ ls -lrt
-rw-r–r–. 1 appluat dba 65789345 Dec 18 17:38 jdk-7u451-linux-x64.tar.gz
-rw-r–r–. 1 appluat dba 69117035 Dec 18 17:38 jdk-7u451-linux-i586.tar.gz
-rw-r–r–. 1 appluat dba 110099293 Mar 25 09:48 p37308812_170_451_Linux-x86-64.zip
-rw-r–r–. 1 appluat dba 116029355 Mar 25 09:48 p37308812_170_451_LINUX.zip
[appluat@ebstest JDK_451]$

Extract further the extrcated tgz delivered by the zip files:
[appluat@ebstest JDK_451]$ tar -xzf jdk-7u451-linux-x64.tar.gz ( Extract 64 bit Java )

[appluat@ebstest JDK_451]$ ls -lrt
drwxr-xr-x. 7 appluat dba 4096 Dec 4 10:15 jdk1.7.0_451
-rw-r–r–. 1 appluat dba 65789345 Dec 18 17:38 jdk-7u451-linux-x64.tar.gz
-rw-r–r–. 1 appluat dba 69117035 Dec 18 17:38 jdk-7u451-linux-i586.tar.gz
-rw-r–r–. 1 appluat dba 110099293 Mar 25 09:48 p37308812_170_451_Linux-x86-64.zip
-rw-r–r–. 1 appluat dba 116029355 Mar 25 09:48 p37308812_170_451_LINUX.zip
[appluat@ebstest JDK_451]$
[appluat@ebstest JDK_451]$ mv jdk1.7.0_451 jdk64 ( Rename to required name of folder )
[appluat@ebstest JDK_451]$
[appluat@ebstest JDK_451]$ ls -lrt
total 442464
drwxr-xr-x. 7 appluat dba 4096 Dec 4 10:15 jdk64
-rw-r–r–. 1 appluat dba 65789345 Dec 18 17:38 jdk-7u451-linux-x64.tar.gz
-rw-r–r–. 1 appluat dba 69117035 Dec 18 17:38 jdk-7u451-linux-i586.tar.gz
-rw-r–r–. 1 appluat dba 110099293 Mar 25 09:48 p37308812_170_451_Linux-x86-64.zip
-rw-r–r–. 1 appluat dba 116029355 Mar 25 09:48 p37308812_170_451_LINUX.zip
[appluat@ebstest JDK_451]$

[appluat@ebstest JDK_451]$ tar -xzf jdk-7u451-linux-i586.tar.gz ( Extract 32 bit Java )
[appluat@ebstest JDK_451]$ ls -lrt
total 442464
drwxr-xr-x. 7 appluat dba 4096 Dec 4 10:15 jdk64
drwxr-xr-x. 7 appluat dba 4096 Dec 4 10:20 jdk1.7.0_451
-rw-r–r–. 1 appluat dba 65789345 Dec 18 17:38 jdk-7u451-linux-x64.tar.gz
-rw-r–r–. 1 appluat dba 44697584 Dec 18 17:38 jdk-7u451-linux-x64.rpm
-rw-r–r–. 1 appluat dba 69117035 Dec 18 17:38 jdk-7u451-linux-i586.tar.gz
-rw-r–r–. 1 appluat dba 47324524 Dec 18 17:38 jdk-7u451-linux-i586.rpm
-rw-r–r–. 1 appluat dba 110099293 Mar 25 09:48 p37308812_170_451_Linux-x86-64.zip
-rw-r–r–. 1 appluat dba 116029355 Mar 25 09:48 p37308812_170_451_LINUX.zip
[appluat@ebstest JDK_451]$
[appluat@ebstest JDK_451]$ mv jdk1.7.0_451 jdk32 ( Rename to required name of folder )
[appluat@ebstest JDK_451]$ ls -lrt
total 442460
drwxr-xr-x. 7 appluat dba 4096 Dec 4 10:15 jdk64
drwxr-xr-x. 7 appluat dba 4096 Dec 4 10:20 jdk32
-rw-r–r–. 1 appluat dba 65789345 Dec 18 17:38 jdk-7u451-linux-x64.tar.gz
-rw-r–r–. 1 appluat dba 44697584 Dec 18 17:38 jdk-7u451-linux-x64.rpm
-rw-r–r–. 1 appluat dba 69117035 Dec 18 17:38 jdk-7u451-linux-i586.tar.gz
-rw-r–r–. 1 appluat dba 47324524 Dec 18 17:38 jdk-7u451-linux-i586.rpm
-rw-r–r–. 1 appluat dba 110099293 Mar 25 09:48 p37308812_170_451_Linux-x86-64.zip
-rw-r–r–. 1 appluat dba 116029355 Mar 25 09:48 p37308812_170_451_LINUX.zip
[appluat@ebstest JDK_451]$

Navigate to COMMON_TOP/util
JDK 64 and 32 both should be here

cd /archive/8010_clone/ebiz/fs1/EBSapps/comn/util
rename the both the existing 32 and 64 bit JDK folders

mv jdk64 OFF_OLD_jdk64
mv jdk32 OFF_OLD_jdk32

cp -RH /archive/Upg_Stuff/JDK_451/jdk64 .
cp -RH /archive/Upg_Stuff/JDK_451/jdk32 .

Upgrade at FMW Webtier JDK 64
cd /archive/8010_clone/ebiz/fs1/FMW_Home/webtier
mv jdk OFF_OLD_jdk

cp -RH /archive/Upg_Stuff/JDK_451/jdk64 .
mv jdk64 jdk

Upgrade at FORMS 10.1.2 JDK ( Must be 32 bit only )

cd /archive/8010_clone/ebiz/fs1/EBSapps/10.1.2
mv jdk OFF_OLD_jdk

cp -RH /archive/Upg_Stuff/JDK_451/jdk32 .
mv jdk32 jdk

RELINK FORMS

cd $ORACLE_HOME/forms/lib
make -f ins_forms.mk sharedlib install

RELINK REPORTS
cd $ORACLE_HOME/reports/lib
make -f ins_reports.mk install

Run Autoconfig on Apps Tier
Make sure it is successfull

Verify 64 Bit Java Successfully deployed :
[appluat@ebstest JDK_451]$ $AFJVAPRG -version
java version “1.7.0_451”
Java(TM) SE Runtime Environment (build 1.7.0_451-b06)
Java HotSpot(TM) 64-Bit Server VM (build 24.451-b06, mixed mode)
[appluat@ebstest JDK_451]$

Verify 32 Bit Java Successfully deployed :
[appluat@ebstest JDK_451]$ cd $ORACLE_HOME
[appluat@ebstest 10.1.2]$ pwd
/archive/8010_clone/ebiz/fs1/EBSapps/10.1.2
[appluat@ebstest 10.1.2]$ cd jdk/bin
[appluat@ebstest bin]$ ./java -version
java version “1.7.0_451”
Java(TM) SE Runtime Environment (build 1.7.0_451-b06)
Java HotSpot(TM) Server VM (build 24.451-b06, mixed mode)
[appluat@ebstest bin]$
[appluat@ebstest bin]$

Make sure You are able to Launch Java Applet successfully after this Java Upgrade

Via Oracle Java checked utility EJCPUC.sh check status of latest certified JAVA Upgraded on EBS Application Node

ERROR on perl txkCfgUtlfileDir.pl on getUtlFileDir when 19c EBS Database backup has been restored

[orauat@ebsdbuat dbs]$ su – orauat
Password:
[orauat@ebsdbuat ~]$ cat envPRECDB.env
. /do2/8010_uat_db/db/19.0.0/PRECDB_ebsdbuat.env
[orauat@ebsdbuat ~]$ . /do2/8010_uat_db/db/19.0.0/PREUPG_ebsdbuat.env
[orauat@ebsdbuat ~]$ cd /do2/8010_uat_db/db/19.0.0/appsutil/bin
[orauat@ebsdbuat bin]$

[orauat@ebsdbuat bin]$ perl txkCfgUtlfileDir.pl -contextfile=/do2/8010_uat_db/db/19.0.0/appsutil/PREUPG_ebsdbuat.xml -oraclehome=/do2/8010_uat_db/db/19.0.0 -outdir=/do2/8010_uat_db/db/19.0.0/appsutil/log -mode=getUtlFileDir
Enter the APPS Password:
Script Name : txkCfgUtlfileDir.pl
Script Version : 120.0.12020000.15
Started : Wed Feb 7 07:47:03 +03 2024
Log File : /do2/8010_uat_db/db/19.0.0/appsutil/log/TXK_UTIL_DIR_Wed_Feb_7_07_46_58_2024/txkCfgUtlfileDir.log
Context file: /do2/8010_uat_db/db/19.0.0/appsutil/PREUPG_ebsdbuat.xml exists.
Completed : Wed Feb 7 07:47:05 +03 2024
ERROR DESCRIPTION:
(FATAL ERROR
PROGRAM : (txkCfgUtlfileDir.pl)
TIME : Wed Feb 7 07:47:04 2024
FUNCTION: main::validateAppsSchemaCredentials [ Level 1 ]
ERRORMSG: Invalid APPS database user credentials.
)
ERRORCODE = 1 ERRORCODE_END

[orauat@ebsdbuat bin]$ exit
logout
[orauat@ebsdbuat dbs]$
[orauat@ebsdbuat dbs]$ lsnrctl status PRECDB
LSNRCTL for Linux: Version 19.0.0.0.0 – Production on 07-FEB-2024 07:47:30
Copyright (c) 1991, 2022, Oracle. All rights reserved.
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=ebsdbuat.srrco.org.sa)(PORT=1526)))

STATUS of the LISTENER

Alias PRECDB
Version TNSLSNR for Linux: Version 19.0.0.0.0 – Production
Start Date 06-FEB-2024 21:36:41
Uptime 0 days 10 hr. 10 min. 48 sec
Trace Level off
Security ON: Local OS Authentication
SNMP OFF
Listener Parameter File /do2/8010_uat_db/db/19.0.0/network/admin/listener.ora
Listener Log File /do2/8010_uat_db/db/19.0.0/log/diag/tnslsnr/ebsdbuat/precdb/alert/log.xml
Listening Endpoints Summary…
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=ebsdbuat.srrco.org.sa)(PORT=1526)))
The listener supports no services
The command completed successfully

[orauat@ebsdbuat dbs]$ ps -ef | grep tns
root 68 2 0 Feb06 ? 00:00:00 [netns]
orauat 96275 1 0 Feb06 ? 00:00:00 /do2/8010_uat_db/db/19.0.0/bin/tnslsnr PRECDB -inherit
orauat 116407 115254 0 07:49 pts/1 00:00:00 grep –color=auto tns
[orauat@ebsdbuat dbs]$
[orauat@ebsdbuat dbs]$
[orauat@ebsdbuat dbs]$ cd /do2/8010_uat_db/db/19.0.0/appsutil/scripts/PREUPG_ebsdbuat/
[orauat@ebsdbuat PREUPG_ebsdbuat]$ ./adcdblnctl.sh start PRECDB
Logfile: /do2/8010_uat_db/db/19.0.0/appsutil/log/PREUPG_ebsdbuat/adcdblnctl.txt
You are running adcdblnctl.sh version 120.0.12020000.4
Starting listener process PRECDB …
Listener PRECDB has already been started.
Waiting for service PREUPG to be available…
Waiting for service PREUPG to be available…
Waiting for service PREUPG to be available…

CAUSE:
local_listener was not correct

SOLUTION:
alter system set local_listener=’hostname.domain:dbport’ scope=both;

ORA-28000, the account was unlocked in the primary database, but still locked in the Active Standby Database.

Situation:

The primary database is configured with Dataguard is returning an error ORA-28000, “the account is locked,” when the user tries to log in. 

The database administrator unlocked this user’s account in the primary database but still the user is unable to connect to the standby and receives the same error code, ORA-28000, for that specific user; nonetheless, the standby account status indicates that it is open.

Standby Situation:

SYS@DATABASE  > conn raheel/raheel123

ERROR:

ORA-28000: the account is locked

Warning: You are no longer connected to ORACLE.

SYS@DATABASE > select username,account_status from dba_users where username=’RAHEEL’;

USERNAME                      ACCOUNT_STATUS

——————————————————————————————

Raheel                               OPEN

SYS@DATABASE > @check_db

DbId Name      Log Mode     Open Mode            Database Role    Created             Resetlogs         Remote Archive

———– ——— ———— ——————– —————- ——————- ——————- ——————

603299473 RAHEEL   ARCHIVELOG   READ ONLY WITH APPLY PHYSICAL STANDBY 11/13/2019 20:16:17 11/13/2019 03:54:21 ENABLED

SOLUTION:
This is a result of the standby’s read-only access and inability to change any tables.  A user’s account is only locked in memory on the standby database when it has to be.

The database administrator, sysdba, is a privileged user who needs to log in to the standby and unlock the account.  The account is now unlocked in the standby database, as confirmed by the message ORA-28015 “Account unlocked, but the database is open for read-only access.”  After that, there are no more errors for the user to encounter when logging into the standby database.

Connect Standby Database and unlock the account:

SYS@DATABASE > ALTER USER RAHEEL ACCOUNT UNLOCK;

ALTER USER RAHEEL ACCOUNT UNLOCK;

ERROR at line 1:

ORA-28015: Account unlocked, but the database is open for read-only access

SYS@DATABASE > conn raheel/raheel123

Connected.

ISSUE:

/u01/ebs/fs1/EBSapps/10.1.2/bin/sqlplus: error while loading shared libraries: libnsl.so.1: cannot open shared object file: No such file or directory

While running adcfgclone appsTier single fs on EBS 12.2.10

FATAL ERROR

PROGRAM : (/u01/ebs/fs1/EBSapps/appl/fnd/12.0.0/patch/115/bin/txkManageDBConnectionPool.pl)

TIME : Sun Nov 10 15:26:51 2024

FUNCTION: main::validateAppsSchemaCredentials [ Level 1 ]

ERRORMSG: Invalid APPS database user credentials. No updates Performed

.end err out.

Result : FAILED

sqlplus: error while loading shared libraries: libnsl.so.1 txkManageDBConnectionPool.pl Invalid APPS database user credentials

Adcfgclone Fails With “sqlplus: error while loading shared libraries: libnsl.so.1: wrong ELF class: ELFCLASS64” (Doc ID 2963649.1)

CAUSE:

The output of the query below indicated that the Linux 8 RPM -> libnsl 64 bits was installed only instead of required 32 bit RPM

rpm -qa –qf “%{n}-%{v}-%{r}.%{arch}\n” | grep libnsl

libnsl-2.28-225.0.3.el8.x86_64

libnsl2-1.2.0-2.20180605git4a062cf.el8.x86_64

SOLUTION:

With a valid backup,Please execute the below

1) Install libnsl RPM with 32 bit

[root@ebs (clone)]$ 02:28:29 > rpm -ivh /media/dvd/BaseOS/Packages/libnsl-2.28-251.0.2.el8.i686.rpm

Verifying… ################################# [100%]

Preparing… ################################# [100%]

Updating / installing…

1:libnsl-2.28-251.0.2.el8 ################################# [100%]

[root@ebs (clone)]$ 02:28:44 >

After installing 32 bit RPM adcfgclone appsTier ran successfully.

Verify whether your Primary Oracle Database is in sync with the Standby Database in a Data Guard configuration.

Solution:

To ensure synchronization, you need to check the Managed Recovery Process (MRP) and query relevant views that provide real-time status and logs. Below are the key SQL queries that help you confirm synchronization.

1. Check the Managed Standby Recovery Process (MRP)

Run the following query to check the status of the MRP process on the standby database:

SELECT thread#, sequence#, process, client_process, status, blocks 
FROM v$managed_standby;

• THREAD# – Identifies the thread number.
• SEQUENCE# – Displays the current sequence number being processed.
• PROCESS – Indicates the type of process running.
• CLIENT_PROCESS – Shows the client process (e.g., ARCH for archive or MRP for managed recovery).
• STATUS – Current status of the process (e.g., ACTIVE or WAITING).
• BLOCKS – Number of blocks being processed.

2. Check for Errors in Data Guard Status

Run this query to look for any critical errors (severity: Error or Fatal) in the Data Guard status log:

SELECT gvi.thread#, timestamp, message 
FROM gv$dataguard_status gvds, gv$instance gvi 
WHERE gvds.inst_id = gvi.inst_id 
AND severity IN ('Error', 'Fatal') 
ORDER BY timestamp, thread#;

This query will help you identify potential issues that could disrupt synchronization between the primary and standby databases.

3. Compare Last Received and Applied Archive Logs

Use this query to compare the last archive log received and applied on the standby:

SELECT ARCH.THREAD# "Thread", 
       ARCH.SEQUENCE# "Last Sequence Received", 
       APPL.SEQUENCE# "Last Sequence Applied", 
       (ARCH.SEQUENCE# - APPL.SEQUENCE#) "Difference" 
FROM (SELECT THREAD#, SEQUENCE# 
      FROM V$ARCHIVED_LOG 
      WHERE (THREAD#, FIRST_TIME) IN 
            (SELECT THREAD#, MAX(FIRST_TIME) 
             FROM V$ARCHIVED_LOG 
             GROUP BY THREAD#)) ARCH, 
     (SELECT THREAD#, SEQUENCE# 
      FROM V$LOG_HISTORY 
      WHERE (THREAD#, FIRST_TIME) IN 
            (SELECT THREAD#, MAX(FIRST_TIME) 
             FROM V$LOG_HISTORY 
             GROUP BY THREAD#)) APPL 
WHERE ARCH.THREAD# = APPL.THREAD#;

• Last Sequence Received – The most recent archive log received by the standby.
• Last Sequence Applied – The most recent archive log applied on the standby.
• Difference – Shows the gap (if any) between the received and applied sequence numbers.

If the Difference is 0 (zero), your standby database is fully synchronized with the primary. Any positive value indicates lag that may require attention.

ISSUE:

I had to renew my customer’s EBS SSL certificate as it was about to expire soon
Since the EBS 12.2.7 wallet had the ability to open wallet in GUI mode , I tried to open wallet BUT was Not able to open it facing the below error.

! The new version of wallet I guess does not allow to perform this activity through OWM GUI.

owm &

Java HotSpot(TM) Server VM warning: You have loaded library /oracle/PROD/fs1/EBSapps/10.1.2/lib/libowm2.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It’s highly recommended that you fix the library with ‘execstack -c ‘, or link it with ‘-z noexecstack’.

SOLUTION:

In order to resolve the issue, do the following:
export PATH=$FMW_HOME/webtier/bin:$FMW_HOME/oracle_common/bin:$PATH

Run:

owm &

it works now.

Removed the expired certificates

Imported all fresh Trusted and User Certififcates.

Command to displayed the wallet to validate the certificate chain:
$FMW_HOME/oracle_common/bin/orapki wallet display -wallet .

[applprod@erpprod Apache]$ $FMW_HOME/oracle_common/bin/orapki wallet display -wallet .
Oracle PKI Tool : Version 11.1.1.9.0
Copyright (c) 2004, 2015, Oracle and/or its affiliates. All rights reserved.

Requested Certificates:
User Certificates:
Subject: CN=*****.gov.sa,O=****** ***,L=Riyadh,C=SA
Trusted Certificates:
Subject: CN=SSL.com TLS RSA Root CA 2022,O=SSL Corporation,C=US
Subject: CN=Entrust OV TLS Issuing RSA CA 1,O=SSL Corporation,C=US
Subject: CN=SSL.com EV Root Certification Authority RSA R2,O=SSL Corporation,L=Houst on,ST=Texas,C=US
[applprod@erpprod Apache]$

ERROR:

When we click on the home button on landing page after login on java applet we are facing this issue.
” You have encountered an unexpected error. Please contact the system administrator for assistance. “

when we click on ” click here for exception details “

SOLUTION: Compile jsps

1. If you are login to EBS, do a clean logout.
2. Stop the application.
3. After complete stop of application check the following processes to confirm that the application is completely stopped.
   ps -ef | grep PALIB
   ps -ef | grep FND
   ps -ef | grep OPP
   ps -ef | grep frmweb
4. After that,
   COMMAND:
   cd $FND_TOP/patch/115/bin
5. COMMAND:
   perl -x ojspCompile.pl –compile –flush -p 2

Once the compilation is done, restart the EBS Services.

Issue would be resolved.

ISSUE:

While migrating one of my client’s Core Oracle Database from an on-premises environment to Google Cloud VM Instance. I encountered an issue while transferring files via SCP from the source Linux server to the target and was unable to connect to Google Cloud VM’s Linux terminal with password using SSH?

ERROR:

[oraprd@core-db-prd ~]$ scp abc oradev@155.199.299.187:/u01/core_db/db/
The authenticity of host ‘155.199.299.187 (155.199.299.187)’ can’t be established.
ECDSA key fingerprint is SHA256:weCNN1YK6jubMLYRfRs2QVhJ5wPNZc7G8SWp/J+0tJ0.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added ‘155.199.299.187’ (ECDSA) to the list of known hosts.
oraprd@155.199.299.187: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
lost connection
[oraprd@core-db-prd ~]$

SOLUTION:

Steps to Transfer a Folder or File Between GCP VMs

1. Enable Password Authentication on the Target DR Server
   • Open the SSH configuration file:
     vi /etc/ssh/sshd_config
   • Update the following line:
     From: PasswordAuthentication no
     To: PasswordAuthentication yes
   • Restart the SSH service:
     systemctl restart sshd
   • Verify the SSH service status:
     systemctl status sshd
2. Transfer Files
   • Use a secure copy command (scp) to transfer the folder or file from the source (Prod Server) to the target (DR Server). You will be prompted to enter the password.
3. Revert Password Authentication Setting on the Target DR Server
   • Edit the SSH configuration file again:
     vi /etc/ssh/sshd_config
   • Change the line back:
     From: PasswordAuthentication yes
     To: PasswordAuthentication no
   • Restart the SSH service:
     systemctl restart sshd
   • Verify the SSH service status:
     systemctl status sshd

IMPORTANT ! : Always ensure you revert the PasswordAuthentication setting after the transfer to maintain server security.

ISSUE:

While running perl adcfgclone.pl dbTechStack, Cloning EBS integerated 19c Database TechStack Fails on supported OS Check with Red Hat Linux 8.10

CAUSE:

19c does not contain Pre-req checks specific to Oracle Linux 8 / Red Hat Linux 8.10
Silent Installer will fail with below Error,as there are no Pre-req checks specific to Linux 8.

SHOW STOPPER ERROR:

[WARNING] [INS-08101] Unexpected error while executing the action at state:’supportedOSCheck’
CAUSE: No additional information available.
ACTION: Contact Oracle Support Services or refer to the software manual.
SUMMARY:
– java.lang.NullPointerException

SOLUTION:

Hence,there is a need to direct the Installer to assume the installed OS to be OL 7 & perform related checks.
Therefore,the below Variable needs to be set,prior to launching Installer-

export CV_ASSUME_DISTID=OEL7.8

NOTE: As per Oracle Pre-req check file for OL/RHEL 8 is provided by 19c PSU 19.6 + but I faced this same issue in 19.22 still !