October 2025 CPU patchset and CVE-2025-61882

Oracle emailed Security Alert CVE-2025-61882 out on Oct 5, 2025 and published Doc ID 3106344.1 (Security Alert CVE-2025-61882 Patch Availability Document for Oracle E-Business Suite) for it. The document first strongly recommends a set of patches 38501230, 38501349, 38501757 as hotfixes. Then, Oracle modified the document and recommended October 2025 CPU patch set or 6 hotfix patches 38507994, 38518258, 38523311, 38523302, and 38510732, 38501757.

I applied October 2025 CPU patch and found it includes all individual patches mentioned above. So, it is a good and clean way to fix CVE-2025-61882 vulnerabilities. Below are EBS patches I applied to my instances

38298685 12.2.0  Oct 2025 CPU

38261405 R12.FWK.C  Oracle Applications Framework

37450688 R12.OWF.C  Oracle Workflow

38180394 R12.FND.C  (prerequisite: OCT 2020 CPU: 31643029:12.2.0)

38510732 R12.XDO.C  BI Publisher (formerly XML Publisher)

Note ECPUC.sql only lists patches that are required or recommended by a CPU patch release but does NOT list prerequisites by each patch. For example, October 2025 CPU patch 38298685 requires R12.AD.C.DELTA.15 & R12.TXK.C.DELTA.15 (or higher) and so I had first to apply below two patches in instances that had AD and TXK Delta 14:

36119925 (R12.AD.C.DELTA.16) Built: JUL-16-2024

36117775 (R12.TXK.C.DELTA.16) Built: JUL-16-2024

Run new adgrants.sql as SYSDBA using 

SQL> @/path/to/adgrants.sql <APPS schema name>

$ adop phase=apply apply_mode=downtime patches=36119925,36303698,36989014,37988551 merge=yes patchtop=/path/to/Oct2025_CPU/AD workers=16 wait_on_failed_job=yes

$ adop phase=apply apply_mode=downtime patches=36117775,36641685,37500697 merge=yes patchtop=/path/to/Oct2025_CPU/TXK workers=16 wait_on_failed_job=yes

Detailed steps in applying patches in October 2025 CPU release are almost the same as in applying January 2025 patches.

To get the list of CVEs addressed by each CPU patchset, go to https://www.oracle.com/security-alerts and then click on the individual CPU release.

ADOP and adstrtal.sh may skip reading $HOME/.profile

When user applMgr on a primary node of RHEL8 runs ADOP to apply patches to slave/remote nodes or runs adstrtal.sh in allnodes mode to start EBS services on remote nodes, it does not read applMgr's .profile on remote nodes but get some OS settings from /etc/login.defs of the server instead. That makes some custom or important behaviors, such permission on file $CONTEXT_FILE or on files in $APPLCSF/out, inconsistent in a multi-node instance.

Two ways to avoid the problem:

1. Add line(s) to custom env file

$INST_TOP/appl/admin/custom$CONTEXT_NAME.env on remote nodes, e.g.

umask 0022

echo "this is for debug"

2. Comment out line(s), such as "# UMASK   077", in /etc/login.defs to force/make ADOP and adstrtal.sh get OS env settings from applMgr's .profile on remote nodes.

Similarly software tools, such as ftp & scp, also read OS env variables from file /etc/login.defs of server level. 

How to retrieve WebLogic password in R12.2

WebLogic is used as part of Oracle EBS R12.2. "weblogic" account is used to start EBS services and is used to log onto WebLogic Admin console (at hostname.domain.com:s_wls_adminport). Its password is encrypted and saved on the file system. Here are two steps I ran in my R12.2 environments to decrypt it.

1. Identify WebLogic Domain path and boot.properties file

$ echo $EBS_DOMAIN_HOME

$RUN_BASE/FMW_Home/user_projects/domains/EBS_domain

$ cd $EBS_DOMAIN_HOME/servers/AdminServer/security

$ ls 

boot.properties

$ more boot.properties

username={AES}mE0mATL4+Lv/gLcIuuuuuuuuu=

password={AES}2kGMi4fcZ7FwYXWIxxxxxxxxx=

2. Run wlst.sh to decrypt the password

$ cd $FMW_HOME/wlserver_10.3/common/bin

$ ls

commEnv.sh       config.sh  security    startDerby.sh   stopDerby.sh  upgrade.sh     wlsifconfig.sh

config_builder.sh  pack.sh    setPatchEnv.sh  startManagedWebLogic.sh  unpack.sh     wlscontrol.sh  wlst.sh

$ sh wlst.sh

CLASSPATH=/u01/app/... ......

Initializing WebLogic Scripting Tool (WLST) ...

Welcome to WebLogic Server Administration Scripting Shell

Type help() for help on available commands

wls:/offline> domain = '$EBS_DOMAIN_HOME'   # <= replace the env variable with the real path

wls:/offline> service = weblogic.security.internal.SerializedSystemIni.getEncryptionService(domain)

wls:/offline> encryption = weblogic.security.internal.encryption.ClearOrEncryptedService(service)

wls:/offline> print "Weblogic server password is: %s" %encryption.decrypt("{AES}2kGMi4fcZ7FwYXWIxxxxxxxxx=")

Weblogic server password is: webLogicPWD

wls:/offline> ^C

If you get Java error, most likely you entered a wrong path or a wrong encrypted password/string.

My WebLogic version is 10.3.6.0.210119. It can be found by two lines:

$ . $FMW_HOME/wlserver_10.3/server/bin/setWLSEnv.sh

... ...

Your environment has been set.

$  java weblogic.version

... ...

WebLogic Server 10.3.6.0.210119 PSU Patch for ...

... ...

If you want to change weblogic password, please read How to change weblogic password

RHEL7 to RHEL8 upgrade on EBS server

Oracle EBS did not support in-place OS upgrade until April 30, 2024 when they updated Oracle document 1330701.1 (Oracle E-Business Suite Installation and Upgrade Notes Release 12 (12.2) for Linux x86-64):

An in-place OS upgrade from Oracle Linux 7 to 8 using the Leapp utility is certified for Oracle E-Business Suite Release 12.2. While you were previously required to install Oracle Linux 8 on a separate target environment before cloning or re-mounting file systems to it, you can now choose to preserve your current Oracle Linux 7 environment and perform an in-place upgrade to Oracle Linux 8 using Leapp. You should review the Operating System upgrades using Leapp section below.

If server team allows the server name unchanged as we did in RHEL 5, 6, and 7 upgrades, it is an easy task for EBS Apps Admin to bring EBS up on the new RHEL 8 server. But, if server team has to change the server name (e.g. migrate the host to a cloud), we have to clone EBS apps to the new server and to make other areas (such as in network, F5, security/firewall, FTP/email, custom codes and PPM) also work with cloned EBS instances.

RHEL 8 in-place upgrade steps on our R12.2.10 servers:

1. Check current RHEL version

$ cat /etc/redhat-release

Red Hat Enterprise Linux Server release 7.9 (Maipo)

2. Apply two patches to EBS: 

- WebLogic patch 32931976. Download the .zip file to get patch file p31090393_1036_Linux-x86-64.zip (which has no relation with patch 31090393). Without this patch, users get a blank page without error message when viewing output or log of concurrent requests. Unzip the file to cache_dir folder and then use bsu.sh to apply EG54. 

$ cd $FMW_HOME/utils/bsu/

$ ./bsu.sh -prod_dir=$FMW_HOME/wlserver_10.3 -status=applied -verbose -view | egrep -i 'EG54'

- Patch 33471111. Follow special steps in Doc ID 13307011.1 to apply it by using folder prereq from p33471111_111190_Generic.zip to replace both $FMW_HOME/webtier/inventory/Scripts/prereq and $PATCH_BASE/FMW_Home/webtier/inventory/Scripts/prereq

3. Verify apps (login page & forms) works and back up all file systems.

4. Shutdown all EBS services.

5. Linux Admin upgrades RHEL to RHEL 8 by using Leapp.

6. Verify it is RHEL8 now

$ cat /etc/redhat-release

Red Hat Enterprise Linux release 8.10 (Ootpa)

- Kernel Settings: /etc/sysctl.conf

Restore sysctl.conf from the backup that was taken prior to the upgrade.

- Make sure to include the options parameter in the resolve.conf.

$ cat /etc/resolv.conf | grep -i options

options timeout:1 attempts:5 rotate

- If the /etc/sysconfig/networking/profiles/default/network file exists, remove it.

- Values in /etc/security/limits.conf

Restore /etc/security/limits.conf from the backup

- Make sure /etc/oraInst.loc has proper permission.

7. Verify all rpm packages required by Oracle doc 1330701.1 exist on the server. Use YUM to install them, such as

$ yum install libXp-devel-1.0.3-3.el8.i686

Some important packages installed on my servers:

$ rpm -qa | grep libXp

libXp-devel-1.0.3-3.el8.i686

libXp-1.0.3-3.el8.x86_64

libXp-1.0.3-3.el8.i686

libXp-devel-1.0.3-3.el8.x86_64

libXpm-3.5.12-11.el8.x86_64

$ rpm -qa | grep motif

motif-devel-2.3.4-20.el8.x86_64

motif-2.3.4-20.el8.x86_64

motif-devel-2.3.4-20.el8.i686

motif-2.3.4-20.el8.i686

Notes: opemmotif21 is not installed

$ rpm -qa | grep redhat-lsb

redhat-lsb-desktop-4.1-47.el8.x86_64

redhat-lsb-printing-4.1-47.el8.x86_64

redhat-lsb-submod-security-4.1-47.el8.x86_64

redhat-lsb-cxx-4.1-47.el8.x86_64

redhat-lsb-submod-multimedia-4.1-47.el8.x86_64

redhat-lsb-languages-4.1-47.el8.x86_64

redhat-lsb-core-4.1-47.el8.x86_64

redhat-lsb-4.1-47.el8.x86_64

$ rpm -qa | grep xorg-x11     (Optional?)

xorg-x11-fonts-misc-7.5-19.el8.noarch

xorg-x11-xbitmaps-1.1.1-13.el8.noarch

xorg-x11-server-utils-7.7-27.el8.x86_64

xorg-x11-apps-7.7-21.el8.x86_64            <= xclock

xorg-x11-utils-7.5-28.el8.x86_64

xorg-x11-proto-devel-2020.1-3.el8.noarch

xorg-x11-xauth-1.0.9-12.el8.x86_64

xorg-x11-font-utils-7.5-41.el8.x86_64

xorg-x11-xinit-1.3.4-18.el8.x86_64

$ rpm -qa | grep libXrender

libXrender-devel-0.9.10-7.el8.x86_64

libXrender-0.9.10-7.el8.x86_64

libXrender-0.9.10-7.el8.i686

8. Run AutoConfig 

9. Start all EBS  services

10. After RHEL8 upgrade, some ports may not be opened on the server. If Apache services start without error, but EBS login webpage does not load up on browsers, the port number may become not open for TCP or may be blocked by a firewall after OS upgrade. In a case, "wget https://sitename.domain.com:4470" returned "connected" on the Linux server itself but got "failed: No route to host." from any remote server. After I asked Linux Admin to fix the issue on port 4470, the login page https://sitename.domain.com:4470 works on browsers.

Please check my post on port or https://runcloud.io/blog/check-tcp-port-linux,

11. Listener issue in opening concurrent job log. 

It was also due to port problem. When trying to open concurrent request log, get message an error occurred while attempting to establish an Applications File Server connection with the node FNDFS_nodeName. There may be a network configuration problem, or the TNS listener on node FNDFS_nodeName may not be running. Please contact your system administrator.

"tnsping FNDFS_nodeName" should work and tell the listener port on the server where FNDFS_nodeName is an entry of tnsnames.ora file. Most likely, the listener port is blocked on the server.

12. SELinux may be enabled in RHEL8. Check file /etc/selinux/config. That may make ssh passwordless login fails. "-Z" option in "ls -alZ" command is available only when selinux is enabled.

13. Make sure applMgr account has the right umask value in $HOME/.profile. This is very important if other OS users need to view output file (in $APPLCSF) of concurrent jobs or to submit concurrent jobs from a shell script.

$ umask 0022

14. Kill switches

Minimum Security Baseline (MSB), also known as a Minimum Baseline Security Standard (MBSS), is a set of foundational security guidelines and requirements that organizations must meet to protect their information systems and data, ensuring a basic level of security. 

MSB says $HOME directories should be 700 permissions (drwx------.). If an EBS is installed under /u01/app ($HOME) directory, the proper permission on app is 750 (drwxr-x---.) and its owner is applMgr. In that case, Server Admin has to add a kill switch so that Chef will not remove those permissions. A Kill Switch is one line (such as cis_rhel8_01_02_03=false) added to a company custom file (usually, it is /etc/xxxxx.info) to prevent something is uninstalled or is removed by Chef.

15. X11 is removed on RHEL8 unless an Exception (such as Archer exception. See https://www.archerirm.com) is filed, and a kill switch is added.

In RHEL8, folder lib under /usr/X11R6 may still exist, but /usr/X11R6/lib does not have any .so files or is empty. openmofit21 is replaced by another package in RHEL8. Without it, EBS Forms still works. If Forms Server failed to start with error FRM-92101, see Doc ID 3052209.1. Also check logs in $EBS_DOMAIN_HOME/servers/forms_server1/log/*.out

16. X-Windows is disabled in RHEL8 by default per Security Requirements as it does not meet the MSB as set in the CIS standards. An exception is needed to make X-Window (such xclock) work on laptop/PC.

17. Server tools in our RHEL8 servers are installed under /opt.

$ ls -d */

BESClient

Tivoli

tivoli

Symantec

appdynamics

chef

Tanium

splunkforwarder

CrowdStrike

Each of them is a folder. Use "ps -ef | grep chef" (e.g.) to check if the tool is running on the server.

How to check a port is open on the firewall

If the port used by a website is not open in the firewall of the web server, the webpage will not be accessible. "nc" can be used to verify if a network port is open and available on a server. Below result indicates port 7042 is open on server serverName.

$ nc -zv serverName 7042

Ncat: Version 7.92 ( https://nmap.org/ncat )

Ncat: Connected to 167.xx.xx.50:7042.

Ncat: 0 bytes sent, 0 bytes received in 0.01 seconds.

If nothing is listening on port 7042, "nc" gives a different result and does not tell if port is the problem. 

$ netstat -tuanp | grep 7042

(Not all processes could be identified, non-owned process info

will not be shown, you would have to be root to see it all.)

$ nc -zv serverName 7042      <= run it on another server

Ncat: Version 7.92 ( https://nmap.org/ncat )

Ncat: Connection refused.

So make sure the Apps service is working correctly and running before using "nc" to check port's status. When the port is used on the server,  "nc" message No route to host tells us that the port is blocked by firewall of the server. 

$ netstat -tuanp | grep 7043

(Not all processes could be identified, non-owned process info

will not be shown, you would have to be root to see it all.)

tcp6       0      0 167.xx.xx.50:7043       :::*                 LISTEN      2915615/java

tcp6       0      0 167.xx.xx.50:52210      167.xx.xx.50:7043       ESTABLISHED 2922169/java

$ nc -zv serverName 7043        <= run it on another server

Ncat: Version 7.92 ( https://nmap.org/ncat )

Ncat: No route to host.

wget may give similar failure message if WLS webservice is listening on port 7043:

$ wget serverName.domain.com:7043/console

... ...

Connection ... ... failed: No route to host

root is able to check and see the list of open ports on the firewall of the server:

$ echo $USER

applmgr

$ sudo su -       

[sudo] password for applmgr:        

Hostname:  serverName.domain.com   <= ONLY if sudo root is granted to applmgr

OS:  Red Hat Enterprise Linux release 8.10 (Ootpa)

Arch:  x86_64

[root@serverName ~]# cd /etc/firewalld

[root@serverName ~]# which firewall-cmd

/usr/bin/firewall-cmd

[root@serverName firewalld]# firewall-cmd --list-all

internal (active)

target: default

icmp-block-inversion: no

interfaces: ens192

sources:

services: cockpit dhcpv6-client mdns samba-client ssh

ports: ... 443/tcp 7042/tcp 7051/tcp 7052/tcp 8004/tcp 4484/tcp ... 757/udp 17430/udp ...

protocols:

forward: no

masquerade: no

forward-ports:

source-ports:

icmp-blocks:

rich rules:

[root@serverName firewalld]#

Troubleshooting case. In a multi-node EBS instance, ADOP fs_clone failed on 2nd node with message "The admin server for the patch file system is not running". I started WebLogic services in patch filesystem of Primary node serverName successfully:

$ sh adadminsrvctl.sh start forcepatchfs

... ...

adadminsrvctl.sh: exiting with status 0

... ...

$ grep s_wls_adminport $CONTEXT_FILE

<wls_adminport oa_var="s_wls_adminport" oa_type="PORT" base="7001" step="1" range="-1" label="WLS Admin Server Port">7043</wls_adminport>

But, the problem was console webpage serverName.domain.com:7043/console did not work and showed generic errors on browser. Too many Java errors and messages in WebLogic logfiles under folder $FMW_HOME/user_projects/domains/EBS_domain/servers/AdminServer/logs

made logs not useful as well. Finally, I found the root cause is port 7043 was not open on the server. After it was added to the firewall by Linux Admin, the WebLogic website became accessible from browsers and then fs_clone worked.

Apply EBS January 2025 CPU patches

The first and important step in applying EBS CPU patches is to identify which patches are required for each EBS components. After step 1 below, the patching steps are the same for recent CPU releases. I used my shell scripts to perform two key steps for January 2025 CPU, which make the patching process much quicker and more consistent across nodes and instances. Posts for previous CPU patchings, such as October 2024 CPU Patches, have more details.

1. Download patch files.

Oracle E-Business Suite Release 12.2 Critical Patch Update Availability Document (January 2025) (Doc ID 3061170.1) is the document for applying January 2025 CPU patches. Run checkers and read the CPU document to decide which patches are required. Then, download and save them to a shared location /path/to/Jan2025_CPU that will be used for all nodes and different instances (Dev, QA and Prod, etc). This folder is organized to 10 sub-folders for different components:

$ cd /path/to/Jan2025_CPU

$ ls -d *

EBS ECPUC EJCPUC ETCC FMW_Comm FMW_Ora JDK JRE WLS

- EBS  hold patches required by ECPUC.sql.  Warning: ECPUC.sql only lists patches that are required or recommended by a EBS CPU patch but does NOT list prerequisites for each patch.

We decided to apply only 3 patches because other modules are not used in our EBS instances.

$ cd EBS

$ ls -trd * | egrep -i '36560216|37078855|37237361'

p37237361_12.2.0_R12_LINUX.zip

p37078855_R12.ATG_PF.C_R12_GENERIC.zip

p36560216_R12.PO.D_R12_GENERIC.zip

36560216

37237361

37078855

Grant permission once for ADOP to create multiple sub-folders under backup folder:

$ chmod 666 36560216/backup

$ chmod 666 37237361/backup

$ chmod 666 37078855/backup

- ECPUC  hold ECPUC.sql (from patch p35583866) for checking which EBS patches are required.

$ grep '$Header' *.sql

REM $Header: ECPUC.sql 120.0.12020000.10 2025/03/06 10:04:57 spullach noship $

- EJCPUC  hold ejcpuc.sh from patch p37171025 

$ grep '$Header' ejcpuc.sh

rcs="$Header: ejcpuc.sh,v 1.3 2025/01/21 04:30:00 egravers Exp egravers $"

Run ejcpuc.sh to confirm JDK upgrade is needed:

$ ./ejcpuc.sh

###############################################################

Checking Apptier Java 7 for CPU 2025.01 on Platform Linux_x64 - need 1.7.0_451

2025-05-xx 11:41:30 EDT on node_name.domain.com

###############################################################

2025.01    action    Your Version   bitness   Java Location

----------  -------- ---------------- -------- ------------------

1.7.0_451 UPDATE 1.7.0_391 32-bit $RUN_BASE/EBSapps/10.1.2/jdk/bin/java

1.7.0_451 UPDATE 1.7.0_391 32-bit $RUN_BASE/EBSapps/comn/util/jdk32/bin/java

1.7.0_451 UPDATE 1.7.0_391 64-bit $RUN_BASE/EBSapps/comn/util/jdk64/bin/java1

1.7.0_451 UPDATE 1.7.0_391 64-bit $RUN_BASE/FMW_Home/webtier/jdk/bin/java

Follow 1530033.1 to update the JDK(s). Your application tier JDK 7 is lower than the 1.7.0_451 update released in CPU 2025.01.

- ETCC  hold ETCC scripts from patch p17537119

Make sure both EBS apps and database use the scripts from the same p17537119 release/download.

$ grep '$Header' *.sh

checkDBpatch.sh:# $Header: checkDBpatch.sh 120.133 2025/01/30 17:56:04 chrhill noship $

checkMTpatch.sh:# $Header: checkMTpatch.sh 120.0.12020000.70 2025/01/30 18:28:36 chrhill noship $

- FMW_Ora  holds patch files for Oracle Home of forms and report (if required).

No required patches by January 2025 CPU release for my instances.

Custom file ocm.rep (see run Opatch in silent) was copied here for patching script.

$ ls *.*

ocm.rsp

- FMW_Comm  holds patch files for Oracle Common. 3 patch files that required by ETCC

$ ls *.*

p33974106_111190_Generic.zip

p33960746_111190_Generic.zip

p34714760_111190_Generic.zip

33974106

33960746

34714760

apply_EBStechPatches.sh

In addition, one custom file was copied here: apply_EBStechPatches.sh (see script for applying technology patches)

- FMW_Web  holds patch files for IAS_ORACLE_HOME (or, $FMW_HOME/webtier).

No patch is required by January 2025 CPU release for my instances.

- JDK  holds files needed for JDK upgrades.

Since Java 7 is officially out of Oracle support, we have to follow Oracle EBS CPU documents (such as Doc ID 3061170.1) & go to Table 3: Security Patches for Technology Stack Components With a New Patch in This CPU. Then, get a link to Oracle Java SE:

Doc ID 3066051.1 (Oracle Critical Patch Update (CPU) Jan 2025 for Oracle Java SE) has a link (on the low end) to download JDK 7 Update 451 Restricted: Patch 37308812 for JDK 1.7.0_451.

p37308812_170_451_Linux-x86-64.zip

p37308812_170_451_LINUX.zip 

Then unzip them to get two JDK files:

jdk-7u451-linux-i586.tar.gz 

jdk-7u451-linux-x64.tar.gz

Also copy/modify the custom script here.

JDK_upgrade1_7_xxx.sh  (see script for updating JDK)

- JRE  holds files for JRE upgrade on the server.

Document ID 3066051.1 (Oracle Critical Patch Update (CPU) Jan 2025 for Oracle Java SE) also has a link for JRE 8 Update 441: Patch 37308802. Download  p37308802_180441_WINNT.zip (for Microsoft Windows 32-bit), and unzip to see two files:

jre-8u441-windows-i586.zip

jre-8u441-windows-i586.exe

- WLS  holds 3 WLS patch files required by ETCC and CPU Doc ID 3061170.1

13845626/p13845626_10360231017_Generic.zip

35476084/p35476084_1036_Linux-x86-64.zip

35586779/p35586779_1036_Generic.zip

2. Apply database patches

Run ETCC checker to find the required patches, and then apply them. Run ejcpuc.sh to make sure Java versions in database are up to date.

3. Backups

Back up apps filesystems. Optional: hold scheduled concurrent jobs if necessary & create a GRP in database.

4. Apply EBS patches (in downtime mode on my instances)

$ adop - status      <= It's better to make sure fs_clone worked successfully before.

$ vi /etc/oraInst.loc

$ stop app services   

Also, check passwordless ssh works in multi-nodes instance for ADOP working on allnodes mode.

$ cd /path/to/Jan2025_CPU/ECPUC

$ sqlplus apps/

SQL> @ECPUC.sql

$ adop phase=apply apply_mode=downtime patches=37237361 patchtop=/path/to/Jan2025_CPU/EBS

$ adop phase=apply apply_mode=downtime patches=37078855,36560216 patchtop=/path/to/Jan2025_CPU/EBS

After their successful completion, confirm January 2025 CPU was applied:

SQL> col CPU format a9

SQL> select max(CODELEVEL) "CPU" 

             from ad_trackable_entities where abbreviation in ('ebscpu');

CPU

----------

2025.01

$ perl $AD_TOP/bin/admkappsutil.pl

Starting the generation of appsutil.zip

Log file located at $INST_TOP/admin/log/MakeAppsUtil_11260913.log

output located at $INST_TOP/admin/out/appsutil.zip

MakeAppsUtil completed successfully.

$ cp -p $INST_TOP/admin/out/appsutil.zip $APPLPTMP

$ chmod 666 $APPLPTMP/appsutil.zip

DBA runs the below steps on database server.

$ cp /path/to/shared/utl_dir/appsutil.zip $ORACLE_HOME/

$ cd $ORACLE_HOME 

$ unzip -o appsutil.zip

Set env and then run autoconfig on the database server.

5. Apply technology patches (on each node)

Run the script to apply them

$ cd /path/to/Jan2025_CPU/FMW_Comm  # if the shell script resides there

$ ./apply_EBStechPatches.sh 'appsPWD'

6. Upgrade JDK (on each node)

A shell script makes it easy

$ cd /path/to/Jan2025_CPU/JDK   # if the shell script resides there

$ ./JDK_upgrade1_7_xxx.sh

Verify the result:

$ cd ../EJCPUC

$ ./ejcpuc.sh

7. Upgrade JRE

$ cd /path/to/Jan2025_CPU/JRE

$ cp jre-8u441-windows-i586.exe $COMMON_TOP/webapps/oacore/util/javaplugin/j2se18441.exe

$ cd $COMMON_TOP/webapps/oacore/util/javaplugin

$ $FND_TOP/bin/txkSetPlugin.sh 18441

Verify the result:

$ grep sun_plugin_ver $CONTEXT_FILE

$ grep s_forms_launch_method $CONTEXT_FILE

8. Run adadmin to sign JAR files (optional) and run antoconfig on each node.

Optional: verify the digital signature of a Jar file (and new timestamp):

$ jarsigner -verify -verbose -certs $AD_TOP/java/jar/adxlib.jar

$ ls -altr $JAVA_TOP/oracle/apps/fnd/jar

9. Start apps services.

10. Test EBS website.

 

11. adop phase=fs_clone

Script for applying EBS technology patches

A key step in applying EBS CPU patches is to decide which technology patches are required by both ETCC checker and quarterly CPU Release document for WebLogic and Oracle Homes of Fusion Middleware. After the list of required patches for each component is decided, I write a shell script to run the patching process and make it more consistent and much quicker cross nodes and different instances (Dev, QA, & Prod).

Pre-steps: place technology patch files to a location shared by many servers. For January 2025 CPU patches (Doc ID 3061170.1), 3 patches are needed and copied to each dedicated sub-folder WLS and FMW_Comm under location /path/to/Jan2025_CPU:

 

- FMW_Comm

Holds 3 Fusion Middleware patch files. Each .zip file is unzipped to its own sub-folder here.

$ cd /path/to/Jan2025_CPU/FMW_Comm

$ ls *.*

ocm.rsp

p33974106_111190_Generic.zip

p33960746_111190_Generic.zip

p34714760_111190_Generic.zip

Do unzip and chmod just one time.

$ unzip p33974106_111190_Generic.zip

$ unzip p33960746_111190_Generic.zip

$ unzip p34714760_111190_Generic.zip

Open READ permission for other OS accounts to run the script to patch instances on other servers: (Or, remove the sub-folder and then unzip the .zip file again before each opatch run.)

$ chmod -R +r 33974106

$ chmod -R +r 33960746

$ chmod -R +r 34714760

$ ls -l | egrep "^drw" |awk '{print $9}'

33974106

33960746

34714760

- WLS 

Holds 3 WLS patch zip files, and each file is saved in its own sub-folder:

13845626/p13845626_10360231017_Generic.zip

35476084/p35476084_1036_Linux-x86-64.zip

35586779/p35586779_1036_Generic.zip

- FMW_Ora

Only holds opatch response file ocm.rsp. No Forms & Reports patch is required by January 2025 CPU patches.

-FMW_Web

Empty. No IAS_ORACLE_HOME patch is required by January 2025 CPU patches.

============= script apply_EBStechPatches.sh ============

# apply tech patches for January 2025 EBS CPU technology patches. 

# it can be easily modified for other R12.2 EBS CPU releases.

# 1. Make sure same patches are required cross different nodes and instances!

# 2. Assume all patch files are saved in 4 sub-folders of a shared location: 

# FMW_Ora, FMW_Comm, FMW_Web, WLS

# 3. Assume ocm.rsp for for running opatch silently exists in folder $patchFileLoc/FMW_Ora

#

# Call the script, for example: ./apply_EBStechPatches.sh 'appsPWD$%^&_!'

#

###  Specify the path to the shared location where patch files are saved:

patchFileLoc=/path/to/Jan2025_CPU

# 

appsPWD=$1

if [ -z "$appsPWD" ]; then

 echo "ETCC needs password to run the script. Exit ..."

 exit 1

fi

runcount=`ps -ef | grep ${LOGNAME:0:7} | grep tnslsnr | wc -l`

if [ $runcount -gt 1 ]

then

 echo "EBS services may still running. Please stop them first. (count: $runcount)"

 exit 1

fi

## Optional

# echo "Run ETCC script:" 

# cd $patchFileLoc/ETCC

# echo $appsPWD | checkMTpatch.sh

echo "Apply WLS patches:"

if [ -f p*.zip ]; then   # if no .zip files in this folder, move to patch next ORACLE_HOME

 zipcount=`ls -al $patchFileLoc/WLS/*.zip | wc -l`

 echo "Apply $zipcount patch(es) to WebLogic..."

 echo $FMW_HOME

 cd $FMW_HOME/utils/bsu/cache_dir

 echo $PWD

 # assume all patch .zip files were copied to folder $patchFileLoc/WLS.

 #

 ### Because removal of conflict WLS patches may required, it is difficult to automate this part.

 ### Editing is needed for each CPU release! ###

 ### Below lines are for January 2025 CPU patching.

 cp -f $patchFileLoc/WLS/13845626/p13845626_10360231017_Generic.zip .

 cp -f $patchFileLoc/WLS/35476084/p35476084_1036_Linux-x86-64.zip .

 cp -f $patchFileLoc/WLS/35586779/p35586779_1036_Generic.zip .

 ls -altr

 unzip -o p35586779_1036_Generic.zip

 unzip -o p35476084_1036_Linux-x86-64.zip

 unzip -o p13845626_10360231017_Generic.zip

 cd ..

 echo $PWD

 ./bsu.sh -remove -patchlist=AMGE -prod_dir=$FMW_HOME/wlserver_10.3

 ./bsu.sh -remove -patchlist=P8S7 -prod_dir=$FMW_HOME/wlserver_10.3

 ./bsu.sh -install -patch_download_dir=$FMW_HOME/utils/bsu/cache_dir -patchlist=E7HI -prod_dir=$FMW_HOME/wlserver_10.3

 ./bsu.sh -install -patch_download_dir=$FMW_HOME/utils/bsu/cache_dir -patchlist=WY44 -prod_dir=$FMW_HOME/wlserver_10.3

 ./bsu.sh -remove -patchlist=CW7X -prod_dir=$FMW_HOME/wlserver_10.3

 ./bsu.sh -install -patch_download_dir=$FMW_HOME/utils/bsu/cache_dir -patchlist=KMHV -prod_dir=$FMW_HOME/wlserver_10.3

 ./bsu.sh -prod_dir=$FMW_HOME/wlserver_10.3 -status=applied -verbose -view | egrep -i 'KMHV|WY44|E7HI'

 ### stop editing ###

else

 echo "No zip files in this folder. No WLS patching is needed for this release."

fi

# Apply patches to 3 Oracle_HOMEs

# Assume ocm.rsp for opatch exists in folder $patchFileLoc/FMW_Ora

echo "Apply patches to Forms & Reports"

cd $patchFileLoc/FMW_Ora       # assume all ORACLE_HOME .zip files were unzipped in this folder.

foldercount=`find * -prune -type d | wc -l`

if [ $foldercount -gt 0 ]; then

 export ORACLE_HOME=$RUN_BASE/EBSapps/10.1.2

 export PATH=$ORACLE_HOME/OPatch:$PATH

 echo "apply $foldercount patch(es) to Oracle Home: $ORACLE_HOME"

 which opatch

 for x in `ls -l | egrep "^drw" |awk '{print $9}'`

 do

  echo "apply patch $x"

  cd $x

  opatch apply -silent -ocmrf $patchFileLoc/FMW_Ora/ocm.rsp

  cd ..

  opatch lsinventory | egrep -i "$x"

  echo

 done

else

 echo "No patch is needed"

fi

echo "Apply patches to ORACLE_WEBTIER:"

cd $patchFileLoc/FMW_Web      # assume all IAS_ORACLE_HOME .zip files were unzipped in this folder.

foldercount=`find * -prune -type d | wc -l`

if [ $foldercount -gt 0 ]; then

 export ORACLE_HOME=$IAS_ORACLE_HOME   # Or, $FMW_HOME/webtier

 export PATH=$ORACLE_HOME/OPatch:$PATH

 echo "apply $foldercount patch(es) to Oracle Home: $ORACLE_HOME"

 which opatch

 for x in `ls -l | egrep "^drw" |awk '{print $9}'`

 do

  echo "apply patch $x"

  cd $x

  opatch apply -silent -ocmrf $patchFileLoc/FMW_Ora/ocm.rsp

  cd ..

  opatch lsinventory | egrep -i "$x"

  echo

 done

else

 echo "No patch is needed"

fi

echo "Apply patches to ORACLE_COMMON:"

cd $patchFileLoc/FMW_Comm      # assume all ORACLE_COMMON .zip files were unzipped in this folder.

foldercount=`find * -prune -type d | wc -l`

if [ $foldercount -gt 0 ]; then

 export ORACLE_HOME=$FMW_HOME/oracle_common

 export PATH=$ORACLE_HOME/OPatch:$PATH

 echo "apply $foldercount patch(es) to Oracle Home: $ORACLE_HOME"

 which opatch

 for x in `ls -l | egrep "^drw" |awk '{print $9}'`

 do

  echo "apply patch $x"

  cd $x

  opatch apply -silent -ocmrf $patchFileLoc/FMW_Ora/ocm.rsp

  cd ..

  opatch lsinventory | egrep -i "$x"

 echo

 done

else

 echo "No patch is needed"

fi

echo "ETCC to confirm no more patches are needed:"

cd $patchFileLoc/ETCC

echo $appsPWD | checkMTpatch.sh

exit 0

============== End ================

Run opatch in silent mode in EBS R12.2

Sometimes, you want to apply patches to Oracle Home in a shell script. To do that, you do not want to run opatch interactively. Here is how to apply patches to an Oracle Home of Fusion Middleware in silent mode.

$ export ORACLE_HOME=$FMW_HOME/oracle_common

$ export PATH=$ORACLE_HOME/OPatch:$PATH

$ which opatch    <= make sure opatch is from oracle_common/OPatch

$ echo $ORACLE_HOME

$RUN_BASE/FMW_Home/oracle_common

First, run emocmrsp to create a response file ocm.rsp:

$ cd $ORACLE_HOME/OPatch/ocm/bin

$ ./emocmrsp

The ORACLE_HOME does not contain java.

The ORACLE_HOME does not contain a valid JDK/JRE.

Redefine JAVA_HOME to refer to a JDK/JRE 1.2.2 or greater.

It needs proper JAVA_HOME:

$ export JAVA_HOME=$FMW_HOME/webtier/jdk   <= I chose this 64-bit JDK

$ echo $JAVA_HOME

$RUN_BASE/FMW_Home/webtier/jdk

$ ./emocmrsp

OCM Installation Response Generator 10.3.7.0.0 - Production

Copyright (c) 2005, 2012, Oracle and/or its affiliates.  All rights reserved.

Provide your email address to be informed of security issues, install and

initiate Oracle Configuration Manager. Easier for you if you use your My

Oracle Support Email address/User Name.

Visit http://www.oracle.com/support/policies.html for details.

Email address/User Name:

You have not provided an email address for notification of security issues.

Do you wish to remain uninformed of security issues ([Y]es, [N]o) [N]:  Y

The OCM configuration response file (ocm.rsp) was successfully created.

$ ls -al

-rwxr-x---. 1 userID Group 9063 Jul 21  2022 emocmrsp

-rw-rw-r--. 1 userID Group oaa  622 May 1 13:08 ocm.rsp

File ocm.rsp is created in $ORACLE_HOME/OPatch/ocm/bin by emocmrsp. It is a binary file, and can be copied to a shared location /path/to/sharedLocation for patching in other nodes or instances. 

Now, apply a patch to Oracle Common home without answering any opatch questions. For example, apply patch 33974106.

$ ps -ef | grep $LOGNAME     <= make sure EBS services are shutdown

$ cd /path/to/33974106

$ opatch apply -silent -ocmrf /path/to/sharedLocation/ocm.rsp

Oracle Interim Patch Installer version 11.1.0.12.9

Copyright (c) 2025, Oracle Corporation.  All rights reserved.

Oracle Home       : $RUN_BASE/FMW_Home/oracle_common

Central Inventory : /u03/app/oraInventoryDEVEBS

from                     : $RUN_BASE/FMW_Home/oracle_common/oraInst.loc

OPatch version    : 11.1.0.12.9

OUI version         : 11.1.0.11.0

Log file location : $RUN_BASE/FMW_Home/oracle_common/cfgtoollogs/opatch/33974106_May_1_2025_13_02_04/apply2025-05-1_13-02-04PM_1.log

OPatch detects the Middleware Home as "$RUN_BASE/FMW_Home"

Applying interim patch '33974106' to OH '$RUN_BASE/FMW_Home/oracle_common'

Verifying environment and performing prerequisite checks...

All checks passed.

Please shutdown Oracle instances running out of this ORACLE_HOME on the local system.

(Oracle Home = '$RUN_BASE/FMW_Home/oracle_common')

Is the local system ready for patching? [y|n]

Y (auto-answered by -silent)

User Responded with: Y

Backing up files...

Patching component oracle.jrf.thirdparty.jee, 11.1.1.9.0...

Verifying the update...

Patch 33974106 successfully applied

Log file location: $RUN_BASE/FMW_Home/oracle_common/cfgtoollogs/opatch/33974106_May_1_2025_13_02_04/apply2025-05-1_13-02-04PM_1.log

OPatch succeeded.

Note if a patching asks more questions, the silent mode will fail, e.g.

... ...

applying interim patch '38059622' to OH '$FMW_HOME/oracle_common'

Patch [ 38059622 ] conflict with patch(es) [  33960746 ] in the Oracle Home.

To resolve patch conflicts please contact Oracle Support Services.

If you continue, patch(es) [  33960746 ] will be rolled back and the new Patch  [ 38059622 ] will be installed.

Do you want to proceed? [y|n]

N (auto-answered by -silent)

User Responded with: N

Log file location: $FMW_HOME/oracle_common/cfgtoollogs/opatch/38059622_xxxx_1.log

OPatch failed with error code 61

In that case, we have to apply it interactively.

Script for upgrading JDK in EBS R12.2

EBS R12.2 uses different Java Homes. Upgrade JDK 7 in EBS R12.2 has details on manually upgrading JDK used in R12.2. I wrote below shell script to upgrade JDK in 4 JDK locations used by EBS R12.2. It can complete the upgrading in minutes after correct JDK files are downloaded and saved. 

This script is mainly used as part of quarterly CPU patching (such as January 2025 CPU and October 2024 CPU). It is important to download the right files for JDK upgrade. Since Java 1.7  is out of Oracle support, we have to follow Oracle quarterly CPU release to find the right version that can be used by current EBS R12.2. For example, for January 2025 CPU patching, document 3066051.1 (Oracle Critical Patch Update (CPU) Jan 2025 for Oracle Java SE) provides link (on the low end) for downloading JDK 7 Update 451 Restricted: Patch 37308812 for JDK 1.7.0_451. 

The script assumes EBS apps services are shutdown and two JDK 1.7.0_451 files are saved to shared location /path/to/Jan2025_CPU/JDK: 

jdk-7u451-linux-x64.tar.gz

jdk-7u451-linux-i586.tar.gz

========== script JDK_upgrade1_7_xxx.sh ==========

# Upgrade JDKs in R12.2 by steps from Doc ID 1530033.1 

# (Using the Latest Java Update with Oracle E-Business Suite Release 12.2).

#

# currently Oracle quarterly CPU document gives a link (in Table 3?) for downloading the right JDK .gz files

# Specify 3 values:

# the location and file names for JDK 1.7.0_451  (downloaded from patch 37308812)

JDKfolder=/path/to/Jan2025_CPU/JDK

JDK_gz_file_64=jdk-7u451-linux-x64.tar.gz

JDK_gz_file_32=jdk-7u451-linux-i586.tar.gz

# Similarly, specify below values if upgrading JDK to JDK 7 Update 441 

# (downloaded from patch 37063192) as part of October 2024 CPU:

# JDKfolder=/path/to/Oct2024_CPU/JDK

# JDK_gz_file_64=jdk-7u441-linux-x64.tar.gz

# JDK_gz_file_32=jdk-7u441-linux-i586.tar.gz

DT=date +"%h_%Y"

curr=pwd

echo $curr

cd $JDKfolder

ls -al

echo ""

echo "Current JDK version:"

$ADJVAPRG -version

$AFJVAPRG -version

#--

echo "Backup two jdk folders at $COMMON_TOP/util"

cd $COMMON_TOP/util

tar -czf jdk64_BK_$DT.tar.gz jdk64  # without -v (to turn off output)

tar -czf jdk32_BK_$DT.tar.gz jdk32

rm -fr jdk64

rm -fr jdk32

cp -p $JDKfolder/*.tar.gz .

tar -xzf $JDK_gz_file_32      # Assume un-tar creates a new folder jdk1.7.0_XXX

mv jdk1.7* jdk32                   # if not, modify this line.

tar -xzf $JDK_gz_file_64      # Assume un-tar creates a new folder jdk1.7.0_XXX

mv jdk1.7* jdk64                 

ls -al jdk*

pwd

sleep 2

#--

echo "Backup the jdk64 folder at $FMW_HOME/webtier."

cd $FMW_HOME/webtier

tar -czf jdk64_BK_$DT.tar.gz jdk

rm -fr jdk

cp -p $JDKfolder/$JDK_gz_file_64 .

tar -xzf $JDK_gz_file_64

mv jdk1.7* jdk

ls -al jdk*

pwd

sleep 2

#--

echo "Backup the jdk32 folder at $ORACLE_HOME"

cd $ORACLE_HOME

tar -czf jdk32_BK_$DT.tar.gz jdk

rm -fr jdk

cp -p $JDKfolder/$JDK_gz_file_32 .

tar -xzf $JDK_gz_file_32

mv jdk1.7* jdk

ls -al jdk*

pwd

sleep 2

echo "New JDK version:"

$ADJVAPRG -version

$AFJVAPRG -version

echo "Compiling EBS Forms and Reports:"

cd $ORACLE_HOME/forms/lib

make -f ins_forms.mk sharedlib install

cd $ORACLE_HOME/reports/lib

make -f ins_reports.mk install

cd $curr

echo "Done"

============== End =================

After the script finished, run ejcpuc.sh from patch p37172035 to confirm the upgrades are successful. $RUN_BASE = /u01/app/EBSDEV/fs2, e.g.

# ./ejcpuc.sh

#############################################################

Checking Apptier Java 7 for CPU 2025.01 on Platform Linux_x64 - need 1.7.0_451

2025-0X-XX 11:43:27 EDT  on  server_name.domain.com

#############################################################

2025.01        action  Your Version    bitness Java Location

------------     -------    ---------------       --------    -----------------

1.7.0_451      OK      1.7.0_451       32-bit  $RUN_BASE/EBSapps/10.1.2/jdk/bin/java

1.7.0_451      OK      1.7.0_451       32-bit  $RUN_BASE/EBSapps/comn/util/jdk32/bin/java

1.7.0_451      OK      1.7.0_451       64-bit  $RUN_BASE/EBSapps/comn/util/jdk64/bin/java

1.7.0_451      OK      1.7.0_451       64-bit  $RUN_BASE/FMW_Home/webtier/jdk/bin/java

JVM & JDK version in Oracle database and EBS R12.2

A new utility, Oracle E-Business Suite Java Critical Patch Update Checker (EJCPUC, Patch 37171025), was released with the Oct 2024 CPU (Doc ID 3037725.1) to find the Java version of different components in Oracle products. It is a great tool to clean confusion. Patch 37171025 gets updated with the new release of quarterly CPU patches. EJCPUC Output on database server:

$ bash ejcpuc.sh

#######################################################

## Checking DB tier Java for CPU 2024.10 on Platform IBM_AIX

#######################################################

## Check Database Version

#######################################################

Your database version is 19.25.0.0.0

         ORACLE_HOME     $ORACLE_HOME

         ORACLE_SID          EBSDEV

         ORACLE_UNQNAME

## Check Java Version of OJVM, Database JDK and EBS's appsutil JRE

######################################################

 Latest Version  action  Your Version  bitness Java Location

 -------------- -------- ------------  ------- ---------------

 1.8.0_431       o)     _.__.101034000   64-bit   OJVM In database

 1.8.0_411                1.8.0_421             64-bit   $ORACLE_HOME/jdk/bin/java

 1.8.0_411        u)     1.8.0_271             64-bit   $ORACLE_HOME/appsutil/jre/bin/java

o) Apply the Database Release Update (DBRU) recommended by ETCC which will update the DB OJVM version to the latest

u) When the DB JDK version is updated to the latest - then follow section 3 of 1530033.1 to update this JRE

A SQL statement can verify the JDK version:

SQL> select dbms_java.get_jdk_version from dual.

GET_JDK_VERSION

----------------------------

1.8.0_411

OJVM, or Oracle Java Virtual Machine (JVM), is a component within the Oracle Database that allows user to run Java stored procedures and other Java modules directly within the database environment and without the need for external Java processes.

ejcpuc.sh can be executed on EBS application mid-tier to find the Java components version of EBS apps:

$ sh ejcpuc.sh

#########################################################

## Checking Apptier Java 7 for CPU 2024.10 on Platform Linux_x64 - need 1.7.0_441

#########################################################

 2024.10        action      Your Version    bitness  Java Location

 ------------   ------  ------------    ------- ---------------

 1.7.0_441      UPDATE   1.7.0_391    32-bit  $ORACLE_HOME/jdk/bin/java

 1.7.0_441      UPDATE   1.7.0_391    32-bit  $COMMON_TOP/util/jdk32/bin/java

 1.7.0_441      UPDATE   1.7.0_391    64-bit  $COMMON_TOP/util/jdk64/bin/java

 1.7.0_441      UPDATE   1.7.0_391    64-bit  $FMW_HOME/webtier/jdk/bin/java

Follow 1530033.1 to update the JDK(s). Your application tier JDK 7 is lower than the 1.7.0_441 update released in CPU 2024.10.

umask and default file permission in Linux

You can find the umask value after you login to your Linux account by typing "umask" on the command line:

$ umask

0077

The value on umask in a Linux server level is defined in file /etc/login.defs (or maybe in /etc/profile, /etc/bashrc or /etc/cshrc. Check with Linux Admin for a sure answer). Note contents of those files (and so umask value) may be changed in RHEL8 when OS got upgraded from RHEL7. Below is one on our REHL8 server:

$ more /etc/login.defs

MAIL_DIR                /var/spool/mail

PASS_MAX_DAYS   90

PASS_MIN_DAYS    7 

PASS_WARN_AGE  7

PASS_MIN_LEN     8

UID_MIN               1000

UID_MAX              60000

GID_MIN              1000

GID_MAX             60000

CREATE_HOME     yes

UMASK                  077

USERGROUPS_ENAB yes

ENCRYPT_METHOD   sha512

Under 0077, any file you created will have "-rw-------" permission, which means only yourself can read and write it.

$ touch test1.del

$ ls -al test1.del

-rw-------. 1 userID Group 0 Feb 02 13:25 test1.del

But you can set up your own umask in .profile for your account. Sometimes, it is necessary for other users to read or modify a file created by a service account or you want others to read your files. To change the default from server level, add one line to the account's .profile:

$ vi $HOME/.profile

umask u=rwx,g=rwx,o=rx

or

umask  0002

After re-login, umask will change to 0002 in the account. Then, any file created by that account will get "-rw-rw-r--" permission. 

$ umask

0002

$ touch test2.del

$ ls -al test2.del

-rw-rw-r--. 1 userID Group 0 Feb 02 13:55 test2.del

Now, other users can read it.

If you put "umask u=rwx,g=rwx,o=rwx" or "umask  0000" in .profile, any new file will get "-rw-rw-rw-" permission (666). 

$ vi $HOME/.profile

umask u=rwx,g=rwx,o=rwx

$ umask

0000

$ touch test3.del

$ ls -al test3.del

-rw-rw-rw-. 1 userID Group 0 Feb 02 15:55 test3.del

If you have "umask  0022" in the profile, new file will get permission "-rw-r--r--".

Note that "x" in the .profile only applies to new folder creation. Linux allows only manually to grant executable to a file.

Connect to a remote server using the private key credential

When a 3rd party tool, such as PPM (Project and Portfolio Management) and Venafi (ssl cert tool), needs to access Oracle EBS server to perform tasks, Oracle EBS server becomes a remote server for the 3rd party server. We usually have to share applmgr password to other teams. The bigger challenge is that when the password is changed periodically by security requirement on EBS server, 3rd party's process will fail. The good and efficient way is to provide them with the private key for them to log onto EBS server without entering the password. Steps to accomplish that on RHEL8 servers:

On Oracle EBS server ebs2d (local server):

1. Generate a pair of key files

$ hostname

ebs2d

$ echo $USER

applmgr

$ ssh-keygen -t rsa -b 2048 -f $HOME/.ssh/Venafi_id_rsa

Generating public/private rsa key pair.

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /u06/app/.ssh/Venafi_id_rsa.

Your public key has been saved in /u06/app/.ssh/Venafi_id_rsa.pub.

The key fingerprint is:

SHA256:3y1+M95Js+4k383juI/qSsxxxxxxx   applmgr@ebs2d.domain.com

The key's randomart image is:

+---[RSA 2048]----+

|      .   .                   |

|      ... ...                 |

+----[SHA256]-----+ 

$ cd .ssh

$ ls -alZ

-rw-------.  1 applmgr grp unconfined_u:object_r:unlabeled_t:s0 1843 Jun  4 20:27 Venfi_id_rsa

-rw-------.  1 applmgr grp unconfined_u:object_r:unlabeled_t:s0  409 Jun  4 20:27 Venafi_id_rsa.pub

-rw-------.  1 applmgr grp system_u:object_r:unlabeled_t:s0     3563 Jan 16 11:35 known_hosts

2. Make file authorized_keys as a copy of public key file Venafi_id_rsa.pub (or, add the key to file authorized_keys)

$ cat id_rsa.pub >> authorized_keys    # (if authorized_keys exists, back it up first)

$ chmod 600 authorized_keys       # <= right permission is important

3. Change the labels on file authorized_keys (when SELinux label is enabled in RHEL8 OS)

$ chcon -u system_u authorized_keys

$ chcon -t user_home_t authorized_keys

$ ls -alZ

-rw-------.  1 applmgr grp system_u:object_r:user_home_t:s0 409 Jun  4 20:29 authorized_keys

-rw-------.  1 applmgr grp unconfined_u:object_r:unlabeled_t:s0 1843 Jun  4 20:27 Venafi_id_rsa

-rw-------.  1 applmgr grp unconfined_u:object_r:unlabeled_t:s0  409 Jun  4 20:27 Venafi_id_rsa.pub

-rw-------.  1 applmgr grp system_u:object_r:unlabeled_t:s0     3563 Jan 16 11:35 known_hosts

$ echo $HOME

/u06/app

$ ls -ald /u06    # <= to make sure permission on folder app is not 777.

4. Copy private key Venafi_id_rsa to remote server venafi1p and name it meaningfully. Or, send file Venafi_id_rsa to other trusted teams if requested.

$ scp -p Venafi_id_rsa usrID@venafi1p:/path/to/applmgr_ebs2d_Venafi_key

Password:

Venafi_id_rsa                                                           100% 1843   903.2KB/s   00:00

NOTES: if get errors, such as " The ECDSA host key for venafi1p has changed, ...", run

$ ssh-keygen -R venafi1p

On remote server venafi1p (host of 3rd party tool):  

After received the private key applmgr_ebs2d_Venafi_key, other team can use ssh, scp or sftp to connect to Oracle EBS server ebs2d using the private key credential (i.e. without entering applmgr's password).

$ hostname 

venafi1p

$ echo $USER

usrID

$ cd /path/to

$ ls -alZ

-rw-------. 1 usr group unconfined_u:object_r:unlabeled_t:s0 1843 Jun  4 20:27 applmgr_ebs2d_PPM_key

$ ssh -i /path/to/applmgr_ebs2d_Venafi_key applmgr@ebs2d

Connected!

$ hostname

ebs2d

$ echo $USER

applmgr

The goal is reached: Venafi server can set up a process or a script (using sftp or scp) to send ssl certificate to EBS server ebs2d smoothly for periodical cert renewal.

My old post has more details on running ssh, sftp, scp between servers without a password.

Apply R12.2 October 2024 CPU patches

The document for October 2024 CPU patches is Doc ID 3037725.1 (Oracle E-Business Suite Release 12.2 Critical Patch Update Availability Document - October 2024). We have to follow it to apply this CPU patches.

1. First of all, specify a location for holding all patch files. All zip file shall be downloaded/saved in sub-folders of this location

$ patch_folder=/path/to/CPU_Patches/Oct2024

2. Run EJCPUC script on database server to check the Java versions. A new utility, Oracle E-Business Suite Java Critical Patch Update Checker (EJCPUC, Patch 37171025), was released with the Oct 2024 CPU. EJCPUC Output:

$ bash ejcpuc.sh

#############################################################

## Checking DB tier Java for CPU 2024.10 on Platform IBM_AIX

#############################################################

## Check Database Version

#############################################################

Your database version is 19.25.0.0.0

         ORACLE_HOME     $ORACLE_HOME

         ORACLE_SID          EBSDEV

         ORACLE_UNQNAME

## Check Java Version of OJVM, Database JDK and EBS's appsutil JRE

#############################################################

 Latest Version  action  Your Version  bitness Java Location

 -------------- -------- ------------  ------- ---------------

 1.8.0_431       o)    _.__.101034000   64-bit   OJVM In database

 1.8.0_411               1.8.0_421             64-bit   $ORACLE_HOME/jdk/bin/java

 1.8.0_411        u)   1.8.0_271             64-bit   $ORACLE_HOME/appsutil/jre/bin/java

o) Apply the Database Release Update (DBRU) recommended by ETCC which will update the DB OJVM version to the latest

u) When the DB JDK version is updated to the latest - then follow section 3 of 1530033.1 to update this JRE

3. Download ETCC (patch 17537119). Make sure both database and apps use the same release of ETCC

$ cd $patch_folder/ETCC

$ grep 120 *.sh

checkDBpatch.sh:# $Header: checkDBpatch.sh 120.127 2024/11/12 15:02:31 chrhill noship $

checkMTpatch.sh:# $Header: checkMTpatch.sh 120.0.12020000.68 2024/04/12 16:35:27 chrhill noship 

3. DBAs apply database patches (after EBS services are stopped) to the database and make sure all requirements are met. ETCC Output :

$ ./checkDBpatch.sh

 +==========================================+

 |    Copyright (c) 2005, 2024 Oracle and/or its affiliates.        |

 |                     All rights reserved.                                            |

 |             Oracle E-Business Suite Release 12.2                     |

 |          Database EBS Technology Codelevel Checker           |

 +==========================================+

Database environment not set, going to check for GridHome.

Oracle Grid Infrastructure not identified.

Database environment not set and no Grid home found, so context file must be specified.

Enter full path to database context file: $ORACLE_HOME/appsutil/<CONTEXT_NAME>.xml

Validating context file: $ORACLE_HOME/appsutil/<CONTEXT_NAME>.xml

Using context file from user input:

$ORACLE_HOME/appsutil/<CONTEXT_NAME>.xml

Starting Database EBS Technology Codelevel Checker, Version 120.127

Mon Nov 25 16:41:09 EST 2024

Log file for this session: $ORACLE_HOME/appsutil/etcc/log/checkDBpatch_45744600.log

Identifying database release.

Database release set to 19.25.0.0.

Multitenant identified.

 - Container database (CDB) identified via s_cdb_name is CEBSDEV

 - Pluggable database (PDB) identified via s_pdb_name is EBSDEV

Connecting to database.

Database connection successful.

Database EBSDEV is in READ WRITE mode.

Identifying APPS and APPLSYS schema names.

 - APPS schema:   APPS

 - APPLSYS schema: APPLSYS

Checking for existence DB-ETCC results table.

Table to store DB-ETCC results already exists in the database.

Bugfix file ./db/onprem/txk_R1220_DB_base_bugs.xml: 120.0.12020000.85

This file will be used for identifying missing bugfixes.

Mapping file ./db/onprem/txk_R1220_DB_mappings.xml: 120.0.12020000.61

This file will be used for mapping bugfixes to patches.

+---------------------------------------------------------------------------------------+

  Always use the latest version of ETCC available in patch 17537119,

  as new bugfixes will not be checked by older versions of the utility.

  You should apply the latest recommended RU, BP, or PSU as appropriate.

+---------------------------------------------------------------------------------------+

Identified database DST version: 32

Checking Bugfix XML file for tag 19.25.0.0_RU.

Obtained list of bugfixes to be applied and list to be rolled back.

Validating OPatch version:

The OPatch utility is version 12.2.0.1.44.

DB-ETCC is compatible with this OPatch version.

Checking for applied patch history:

Found patch history in the inventory.

Checking mapping XML file for tag 19.25.0.0.241015DBRU.

All the required one-off bugfixes are present in database ORACLE_HOME.

5. Proceed with Apps patches

- Back up Apps file systems

- Start Apps services to make sure EBS works after database patching. 

- Stop Apps services 

6. ECPUC script (from patch p35583866) to identify what EBS CPU patches and security fixes are needed.

$ cd $patch_folder/ECPUC

$ sqlplus apps/appsPWD

SQL> @ECPUC.sql

... ...

E-Business Suite Critical Patch Update Checker (ECPUC)

ECPUC.sql may be run on any EBS 12.2 environment to identify missing patches that are in the latest EBS CPU.

You can download the latest version of ECPUC via Patch 35583866.

Refer to the README.txt in Patch 35583866 for instructions for running ECPUC and information regarding the generated ECPUC.lst report.

The checker generates the report ECPUC_YYYY-MM-DD_HH24-MI.lst that lists recommended EBS CPU patches and security fixes for your environment per Table 1 'CPU Patches for Oracle E-Business Suite' and Table 2 'Additional Patches Required' documented in the quarterly EBS CPU MOS Note.

Each quarterly EBS CPU MOS Note ID is unique. Refer to My Oracle Support (MOS) Knowledge Document 2484000.1, 'Identifying the Latest Critical Patch Update for Oracle E-Business Suite Release 12' which includes a link to the current EBS CPU MOS document.

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

SECTION-1 ECPUC Version

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

EBS CPU Checker Version

-----------------------

                 2024.1

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

SECTION-2 Oracle E-Business Suite (EBS): Instance Information

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

***********************************************************

Instance Summary

***********************************************************

EBS Release EBS CPU Level

----------- -------------

12.2.10     2023.10

Instance Name    Database         Database Version

---------------- ---------------- ------------------

CEBSDEV           EBSDEV            19.25.0.0.0

ATG Product  Product Name                             Code Level

------------ ----------------------------------------------- ----------

ad           Applications DBA                                    C.14

txk         Oracle Applications Technology Stack     C.14

atg_pf    Oracle Applications Technology Family  C.9

fwk        Oracle Applications Framework               C.9

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

SECTION-3 Required EBS CPU and Security Fixes

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

The following output is a list of required patches and security fixes that are missing in your environment.

It is strongly recommended that you apply all of the listed patches as soon as possible.

If no patches (no rows) are listed then no additional action is required at this time as your environment includes all patches for this EBS CPU.

**********************************************************

The following patches are required for this EBS CPU

--------------------------------------------------------------

36944346:12.2.0

37078855:R12.ATG_PF.C

37078915:R12.SCM_PF.C

37120482:R12.CC_PF.C

35362524:R12.IGI.C

34979060:R12.MSC.C

33457157:R12.HXT.C

30448458:R12.HXT.C

8 rows selected.

7. Apply two EBS patches. After consulting with Developers and Business users, we will apply only first two patches because we do not use the EBS modules on the list.

36944346:12.2.0

37078855:R12.ATG_PF.C

Make sure all Apps services are down

$ ps -ef | grep $LOGNAME

$ vi /etc/oraInst.loc

$ adop -status

If FS_CLONE has not been run, run it. This will help to screen out errors in applying new patches.

$ adop phase=fs_clone 

-- Apply patch to multiple nodes

$ adop phase=apply apply_mode=downtime patches=36944346 patchtop=$patch_folder/Oct24_CPU

$ adop phase=apply apply_mode=downtime patches=37078855 patchtop=$patch_folder/Post

Run query to confirm Oct 2024 CPU in the instance. See Doc ID 2484000.1 (Identifying the Latest Critical Patch Update for Oracle E-Business Suite Release 12.2)

SQL> col CPU format a9

SQL> select max(CODELEVEL) "CPU" from ad_trackable_entities where abbreviation in ('ebscpu');

CPU

---------

2024.10

8. Run autoconfig on database server

$ perl $AD_TOP/bin/admkappsutil.pl

Starting the generation of appsutil.zip

Log file located at $INST_TOP/admin/log/MakeAppsUtil_11260913.log

output located at $INST_TOP/admin/out/appsutil.zip

MakeAppsUtil completed successfully.

$ cp -p $INST_TOP/admin/out/appsutil.zip $APPLPTMP

$ chmod 777 $APPLPTMP/appsutil.zip

DBA run the below steps on EBSDEV database.

1. cp /u04/shared/utl_dir/appsutil.zip $ORACLE_HOME/

2. cd $ORACLE_HOME; unzip -o appsutil.zip

3. Set env and then run autoconfig on the database.

9. Run ETCC

$ cd $patch_folder/ETCC

$ ./checkMTpatch.sh

... ...

Starting Application Tier EBS Technology Codelevel Checker, Version 120.0.12020000.68.

... ...

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

PATCH RECOMMENDATION SUMMARY

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

One or more products have bugfixes missing.

The default patch recommendations to install these missing bugfixes are:

-------------------------------------------------------------------------------

Oracle Fusion Middleware (FMW) - Oracle Common 11.1.1.9.0

-------------------------------------------------------------------------------

  Patch 34714760

    - Filename: p34714760_111190_Generic.zip

-------------------------------------------------------------------------------

WLS 10.3.6.0.231017

-------------------------------------------------------------------------------

  Patch 35476084 [SU Patch [KMHV]]

    - Filename: p35476084_1036_Linux-x86-64.zip

Apply the required patches and rerun this script.

+-----------------------------------------------------------------------------+

A consolidated zip file with the required application tier patches is

available on My Oracle Support via:

  Patch 36616672

10.  Apply WLS patches: KMHV, WY44

$ echo $APPL_TOP 

$ echo $ORACLE_HOME

$RUN_BASE/EBSapps/10.1.2

$ echo $FMW_HOME

$RUN_BASE/FMW_Home

$ cd $FMW_HOME/utils/bsu

-- Check if patch p13845626 was applied:

$ ./bsu.sh -prod_dir=$FMW_HOME/wlserver_10.3 -status=applied -verbose -view | egrep -i 'WY44'

Patch ID:            WY44

PatchContainer:    WY44.jar

$ cd $FMW_HOME/utils/bsu/cache_dir

$ cp -p $patch_folder/WLS/35476084/p35476084_1036_Linux-x86-64.zip .   # (KMHV)

$ cp -p $patch_folder/WLS/13845626/p13845626_10360231017_Generic.zip . 

# (WY44. Asked by Doc ID 3037725.1)

$ unzip p35476084_1036_Linux-x86-64.zip

Archive:  p35476084_1036_Linux-x86-64.zip

replace README.txt? [y]es, [n]o, [A]ll, [N]one, [r]ename: A

  inflating: README.txt

  inflating: patch-catalog_27986.xml

  inflating: KMHV.jar

$ cd ..

$ ./bsu.sh -install -patch_download_dir=$FMW_HOME/utils/bsu/cache_dir -patchlist=KMHV -prod_dir=$FMW_HOME/wlserver_10.3

Checking for conflicts..

Conflict(s) detected - resolve conflict condition and execute patch installation again

Conflict condition details follow:

Patch KMHV is mutually exclusive and cannot coexist with patch(es): CW7X

$ ./bsu.sh -remove -patchlist=CW7X -prod_dir=$FMW_HOME/wlserver_10.3

Checking for conflicts..

No conflict(s) detected

Removing Patch ID: CW7X..

Result: Success

$ ./bsu.sh -install -patch_download_dir=$FMW_HOME/utils/bsu/cache_dir -patchlist=KMHV -prod_dir=$FMW_HOME/wlserver_10.3

Checking for conflicts..

No conflict(s) detected

Installing Patch ID: KMHV..

Result: Success

$ ./bsu.sh -prod_dir=$FMW_HOME/wlserver_10.3 -status=applied -verbose -view | egrep -i 'KMHV'

Patch ID:          KMHV

PatchContainer:    KMHV.jar

-- if patch p13845626 was NOT applied:

$ ./bsu.sh -install -patch_download_dir=$FMW_HOME/utils/bsu/cache_dir -patchlist=WY44 -prod_dir=$FMW_HOME/wlserver_10.3

11. Apply patch 34714760 to Oracle Fusion Middleware (FMW) - Common

$ export ORACLE_HOME=$FMW_HOME/oracle_common

$ export PATH=$ORACLE_HOME/OPatch:$PATH

$ which opatch

$ cd /tmpshrs/ebsarupgradeTEMP/CPU_Patches/Oct2024/FMW_OHS_Orcl_Comn

$ ls -al

$ mv 34714760 34714760_Feb19

$ unzip p34714760_111190_Generic.zip

$ cd 34714760

$ opatch apply

... ...

Patching component oracle.jrf.opss, 11.1.1.9.0...

... ...

-- Check if 4 patches were applied

$ opatch lsinventory | egrep -i '34330735|33974106|33960746|34714760'

-- if patch 33960746 was not applied

$ cd /tmpshrs/ebsarupgradeTEMP/CPU_Patches/Oct2024/FMW_OHS_Orcl_Comn

$ unzip p33960746_111190_Generic.zip    (required by Doc ID 3037725.1)

$ cd 33960746

$ opatch apply

... ...

Patching component oracle.sysman.common, 10.2.0.5.6...

Patching component oracle.sysman.oms.core, 11.1.1.9.0...

Patching component oracle.sysman.plugin.ai.main.oms, 11.1.1.9.0...

... ...

Note: if a patch was applied previously, "opatch apply" again will give below message: 

$ opatch apply

Applying interim patch '33960746' to OH '$FMW_HOME/oracle_common'

Verifying environment and performing prerequisite checks...

The following patch(es) are duplicate patches with patches installed in the Oracle Home.

 [ 33960746]

You have already installed same patch(es) with same UPI(s) or same version(s).

These patch(es) will be skipped.

... ...

OPatch stopped on request.

 

$ opatch lsinventory | egrep -i '34330735|33974106|33960746|34714760'

Patch  33960746     : applied on Thu Dec 05 12:03:32 EST 2024

     33960746

Patch  34714760     : applied on Thu Dec 05 11:48:27 EST 2024

     34714760

Patch  33974106     : applied on Fri Nov 24 13:31:49 EST 2023

Patch  34330735     : applied on Wed Aug 17 21:59:30 EDT 2022

12. Run ETCC again

Start a new OS session to get the correct env, and make sure no more patches are needed.

$ cd $patch_folder/ETCC

$ ./checkMTpatch.sh

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

All required one-offs are confirmed as present.

Finished checking prerequisite patches for file edition: run.

13. Upgrade JDK

$ cd $patch_folder/EJCPUC

$ ls

ejcpuc.cmd  ejcpuc.sh  p37171025_R12_GENERIC.zip  Readme.txt

$ sh ejcpuc.sh

############################################################

## Checking Apptier Java 7 for CPU 2024.10 on Platform Linux_x64 - need 1.7.0_441

############################################################

 2024.10        action  Your Version    bitness Java Location

 ------------   ------  ------------    ------- ---------------

 1.7.0_441      UPDATE   1.7.0_391    32-bit  $ORACLE_HOME/jdk/bin/java

 1.7.0_441      UPDATE   1.7.0_391    32-bit  $COMMON_TOP/util/jdk32/bin/java

 1.7.0_441      UPDATE   1.7.0_391    64-bit  $COMMON_TOP/util/jdk64/bin/java

 1.7.0_441      UPDATE   1.7.0_391    64-bit  $FMW_HOME/webtier/jdk/bin/java

Follow 1530033.1 to update the JDK(s). Your application tier JDK 7 is lower than the 1.7.0_441 update released in CPU 2024.10.

$ cd $patch_folder/JDK_1_7_441

Assume 2 JDK files and my shell script for JDK upgrade exist in this folder:

$ ls

jdk-7u441-linux-i586.tar.gz

jdk-7u441-linux-x64.tar.gz

JDK_upgrade441.sh

$ ./JDK_upgrade441.sh

Verify:

$ cd $COMMON_TOP/util/

$ ls -al

$ cd $patch_folder/EJCPUC

$ sh ejcpuc.sh

###########################################################

## Checking Apptier Java 7 for CPU 2024.10 on Platform Linux_x64 - need 1.7.0_441

############################################################

 2024.10        action  Your Version    bitness Java Location

 ------------   ------  ------------    ------- ---------------

 1.7.0_441      OK      1.7.0_441       32-bit   $ORACLE_HOME/jdk/bin/java

 1.7.0_441      OK      1.7.0_441       32-bit   $COMMON_TOP/util/jdk32/bin/java

 1.7.0_441      OK      1.7.0_441       64-bit   $COMMON_TOP/util/jdk64/bin/java

 1.7.0_441      OK      1.7.0_441       64-bit   $FMW_HOME/webtier/jdk/bin/java

14. Upgrade JRE

$ cd $COMMON_TOP/webapps/oacore/util/javaplugin

# Assume below file is downloaded and unzipped in folder

# $patch_folder/JRE_8_431

# p37063177_180431_WINNT.zip

$ cp $patch_folder/JRE_8_431/jre-8u431-windows-i586.exe j2se18431.exe

$ ls -altr

$ $FND_TOP/bin/txkSetPlugin.sh 18431

$ grep sun_plugin_ver $CONTEXT_FILE

         <sun_plugin_ver oa_var="s_sun_plugin_ver">1.8.0_431</sun_plugin_ver>

$ grep s_forms_launch_method $CONTEXT_FILE

         <config_option type="techstack" oa_var="s_forms_launch_method">jws</config_option>

15. Finalize 

optional: Re-sign JAR files. It takes time: "Creating and signing every jar file can take about thirty minutes ..."

$ adadmin

option 1 => 4 => yes

$ autoconfig on all Apps nodes

Start all services

$ adop phase=fs_clone

=== script JDK_upgrade441.sh for upgrading JDK =====

$ more JDK_upgrade441.sh

# Oracle JDK 7 Update 441 Patch Patch 37063192

DT=`date +"%h_%Y"`

curr=`pwd`

echo $curr

JDKfolder=$patch_folder/Oct2024/JDK_1_7_441

# Assume two JDK files (from patch 37063192) are saved in the folder:

# jdk-7u441-linux-i586.tar.gz

# jdk-7u441-linux-x64.tar.gz

ls -al $JDKfolder

echo "Current JDK version:"

$ADJVAPRG -version

$AFJVAPRG -version

# --

echo "$COMMON_TOP/util"

cd $COMMON_TOP/util

tar -czf jdk64_BK_$DT.tar.gz jdk64  # do not use -v (to turn off output)

tar -czf jdk32_BK_$DT.tar.gz jdk32

rm -fr jdk64

rm -fr jdk32

cp -p $JDKfolder/*.tar.gz .

tar -xzf jdk-7u441-linux-i586.tar.gz

mv jdk1.7.0_441 jdk32

tar -xzf jdk-7u441-linux-x64.tar.gz

mv jdk1.7.0_441 jdk64

ls -al jdk*

pwd

sleep 5

# --

echo "$FMW_HOME/webtier"

cd $FMW_HOME/webtier

tar -czf jdk64_BK_$DT.tar.gz jdk

rm -fr jdk

cp -p $JDKfolder/jdk-7u441-linux-x64.tar.gz .

tar -xzf jdk-7u441-linux-x64.tar.gz

mv jdk1.7.0_441 jdk

ls -al jdk*

pwd

sleep 5

# --

echo "$ORACLE_HOME"

cd $ORACLE_HOME

tar -czf jdk32_BK_$DT.tar.gz jdk

rm -fr jdk

cp -p $JDKfolder/jdk-7u441-linux-i586.tar.gz .

tar -xzf jdk-7u441-linux-i586.tar.gz

mv jdk1.7.0_441 jdk

ls -al jdk*

pwd

sleep 5

echo "New JDK version:"

$ADJVAPRG -version

$AFJVAPRG -version

echo "Compiling:"

cd $ORACLE_HOME/forms/lib

make -f ins_forms.mk sharedlib install

cd $ORACLE_HOME/reports/lib

make -f ins_reports.mk install

cd $curr

echo "Done"

Script to check if a space partition is full

We can use "df" to check if a Linux server space is full or not. Script below will send an email out when when it reaches the threshold. 

#Script to check if a space partition is 80% full

threshold=80

shareLoc='/path/to/partition'       # such as the one for $APPLCSF of Oracle EBS

spacesize=`df -h | grep $shareLoc | awk '{print $5}' | tr -cd '[[:digit:]]'`

spacepercent=`df -h | grep /tmpshrs/ebsarupgradeTEMP | awk '{print $5}'`

freesize=`df -h | grep /tmpshrs/ebsarupgradeTEMP | awk '{print $4}'`

if [ $spacesize -gt $threshold ]; then

echo "$shareLoc is too large" | mailx -s "Warning: $shareLoc is ${spacepercent} full" email@address.com

echo "Email sent."

else

echo "$shareLoc has $freesize free. Used $spacepercent "

fi 

Finding concurrent programs that trace is enabled

EBS can enable trace on concurrent program level. Navigation: Concurrent => Program => Define. Enter "Short Name" (concurrent_program_name below) to check the checkbox field on Enable Trace.

After trace is enabled, the job may take more resources on database server. SQL statement to find all concurrent programs that trace is enabled. 

SQL> select fp.concurrent_program_name, fct.user_concurrent_program_name, fct.last_update_date, fct.last_updated_by, fu.description

 from applsys.fnd_concurrent_programs fp, applsys.fnd_concurrent_programs_tl fct, fnd_user fu

 where fp.concurrent_program_id = fct.concurrent_program_id

     and fct.last_updated_by = fu.user_id and enable_trace <> 'N'

  order by fct.last_update_date asc;

fnd_web_sec.change_password in R12.2

fnd_web_sec.change_password still works in R12.2.10. It is recommended to use it only in some special/urgent needs because it may (or may not) ignore the restrictions by EBS Profile options 'Signon%' (see Oracle Doc ID 1350776.1 on ORA-14552).

Before change the password for troubleshooting, verify if the EBS account is disabled/inactive or not:

SQL> SELECT fu.user_name, fu.description, fu.start_date, fu.end_date,

CASE

WHEN fu.end_date IS NOT NULL and fu.end_date < SYSDATE THEN 'Inactive' ELSE 'Active' END AS account_status

FROM fnd_user fu

WHERE fu.user_name = 'EBS_userID'

-- and fu.end_date IS NOT NULL

-- and fu.end_date < SYSDATE

ORDER BY fu.user_name;

If it is inactive, run below statement to enable it if needed. And then even try to retrieve the passowrd.

SQL> exec apps.fnd_user_pkg.enableuser('EBS_userID');

If it becomes necessary, below statement by APPS will change EBS_userID password:

SQL> SELECT fnd_web_sec.change_password('EBS_userID','newPwd4U') FROM dual;

FND_WEB_SEC.CHANGE_PASSWORD('EBS_USERID','NEWPWD4U')

-------------------------------------------------------------------------------------

Y

You can use below line to confirm a password:

SQL> select fnd_web_sec.validate_login('EBS_userID', 'newPwd4U') from dual;

FND_WEB_SEC.VALIDATE_LOGIN('EBS_USERID','NEWPWD4U')

--------------------------------------------------------------------------------

Y

SQL> select fnd_web_sec.validate_login('EBS_userID', 'myPWD_01') from dual;

FND_WEB_SEC.VALIDATE_LOGIN('EBS_USERID','MYPWD_01')

--------------------------------------------------------------------------------

N

SQL> select fnd_message.get from dual;

GET

--------------------------------------------------------------------------------

PASSWORD_INVALID

One day, EBS users cannot log onto EBS site. The login webpage shows up but does not allow any users in. Since there is no error on EBS apps side, we do not know it is a security/password problem or other problems.  I used below queries to show it is a database problem 

SQL> show user

USER is "APPS"

SQL> select HOST_NAME, INSTANCE_NAME from v$instance;

HOST_NAME   INSTANCE_NAME

------------------  -------------------------

ebsdb1q             CEBSQA

SQL> select fnd_web_sec.validate_login('EBS_userID', 'XXXXxxx') from dual;   

ERROR at line 1:

ORA-03113: end-of-file on communication channel

SQL> select sysdate from dual;

ERROR:

ORA-03114: not connected to ORACLE

NOTES 1: FND_WEB_SEC.validate_password( ) is aonther function.

SQL> select fnd_web_sec.validate_password('EBS_userID', 'newPwd4U') from dual;

FND_WEB_SEC.VALIDATE_PASSWORD('EBS_USERID','NEWPWD4U')

--------------------------------------------------------------------------------

N

SQL> select fnd_message.get from dual;

GET

--------------------------------------------------------------------------------

Must not reuse a recently used password. Please supply a different password.

NOTES 2: fnd_message.get can be used sometimes to get useful information. For example, after a Java load errored out in Sql*Plus, below line gives some details:

SQL> select fnd_message.get from dual;

GET

--------------------------------------------------------------------------------

Unable to load Java class oracle.apps.xxfnd.custom.security.PasswordValidation specified in profile option SIGNON_PASSWORD_CUSTOM.  Please verify that the class exists and that it implements the Java interface oracle.apps.fnd.security.PasswordValidation.