BEST PRACTICE: The security and performance principles of minimization and avoiding un-necessary resource contention prescribe that it is best to deploy OUDSM on a separate host from the OUD host(s). And if OUDSM does need to co-exist on the same host as OUD, it is best for OUDSM to have its own middleware home and JDK so that the OUDSM software can be updated independently of OUD.
Update Java Development Kit
JDK is the foundation of OUD and OUDSM and thus is one of the most important components to keep up-to-date. The supported JDK long term support release (LTS) versions for OUD 14c are 21 and 17. I generally prefer to use the most recent JDK LTS release available. Therefore, I'll focus on JDK 21. The latest versions of JDK 21 are available from Oracle at
Oracle Java Downloads. One of the interesting things about the JDK 21 download is that the download file names are the same over time. That makes download automation easier. For example, to determine on x64 Linux systems, I use a script similar to the following to check to see if the latest JDK 21 version is newer than the version that I have installed.
In this example, the current JDK used for OUD is located in /u01/sw/oud_jdk. I create a temporary directory to store the downloaded and extracted JDK version. Once the new JDK is extracted, I check to see if the version is newer than the current JDK version and if so, return a message that says "JDK Version ... is newer".
jdir='oud_jdk'
swdir=/u01/sw
cver=$(${swdir}/${jdir}/bin/java -version 2>&1 |grep "^java version"|cut -d'"' -f2|sed -e "s/^21\.//g")
mkdir ${swdir}/ckjdk.tmp
curl -kso ${swdir}/ckjdk.tmp/jdk21.tgz https://download.oracle.com/java/21/latest/jdk-21_linux-x64_bin.tar.gz
tar -xzof ${swdir}/ckjdk.tmp/jdk21.tgz -C ${swdir}/ckjdk.tmp
nver=$(${swdir}/ckjdk.tmp/*/bin/java -version 2>&1 |grep "^java version"|cut -d'"' -f2|sed -e "s/^21\.//g")
if [ $(echo "${cver} - ${nver}" |bc) != '0' ];then echo "This JDK Version 21.${nver} is newer";fi
BEST PRACTICE: Before moving on to the procedure for updating the JDK, it is important to note that one best practice in this example is to use a generic name for the JDK path like /u01/sw/oud_jdk rather than the default path name /u01/sw/jdk-21.0.10 before installing and setting up OUD or OUDSM instances. That will greatly simplify updating the JDK as well as upgrading OUD in the future.
Roll JDK Forward
If the version available from Oracle is newer, then I use the following procedure to update OUD. Note that similarly with OUDSM, you just stop OUDSM, update the JDK and start OUDSM back up.
1. Stop the existing OUD instances with stop-ds including Replication Gateway, Proxy and OUD Storage.
/u01/mw_oud14c/replgw1/OUD/bin/stop-ds
/u01/mw_oud14c/proxy1/OUD/bin/stop-ds
/u01/mw_oud14c/oud1/OUD/bin/stop-ds
/u01/mw_oud14c/asinst_1/OUD/bin/stop-ds
2. Confirm that no lingering processes processes are referencing the JDK. If the OUDSM is running using this JDK, you will want to shut that down as well.
ps -ef|grep /u01/sw/${jdir}
If there are any processes still running with the existing JDK, gracefully stop those processes before proceeding to replace the JDK.
3. Re-locate the existing JDK making note of the resulting JDK badkup date (<YYYYMMDDHHMMSS>).
now=$(date +'%Y%m%d%H%M%S')
mv ${swdir}/${jdir} ${swdir}/${jdir}.${now}
ls -ald ${swdir}/${jdir}.${now}
4. Move the new JDK version into place.
mv ${swdir}/ckjdk.tmp/jdk-21* /u01/sw/${jdir}
rm -fr ${swdir}/ckjdk.tmp
5. Start the OUD instances back up with start-ds.
/u01/mw_oud14c/asinst_1/OUD/bin/start-ds
/u01/mw_oud14c/oud1/OUD/bin/start-ds
/u01/mw_oud14c/proxy1/OUD/bin/start-ds
/u01/mw_oud14c/replgw1/OUD/bin/start-ds
Roll JDK Back
If for any reason the new JDK does not work, you will want to roll back. The beauty of this best practice method of managing the JDK version is that it is effortless and efficient to roll back to the previous version. Here is the procedure for rolling the JDK back to the previous version.
1. Stop the existing OUD instances with stop-ds including Replication Gateway, Proxy and OUD Storage.
/u01/mw_oud14c/replgw1/OUD/bin/stop-ds
/u01/mw_oud14c/proxy1/OUD/bin/stop-ds
/u01/mw_oud14c/oud1/OUD/bin/stop-ds
/u01/mw_oud14c/asinst_1/OUD/bin/stop-ds
2. Confirm that no lingering processes are referencing the JDK
jdir='oud_jdk'
ps -ef|grep /u01/sw/${jdir}
If there are any processes still running with the existing JDK, gracefully stop those processes before proceeding to replace the JDK.
3. Re-locate the existing JDK to a folder name ending with .failed to indicate that for whatever reason, that version was incompatible so that you will know which one to troubleshoot in a lower environment.
now=$(date +'%Y%m%d%H%M%S')
mv ${swdir}/${jdir} ${swdir}/${jdir}.${now}.failed
4. Restore the backup JDK (<YYYYMMDDHHMMSS>) back into place
mv ${swdir}/${jdir}.<YYYYMMDDHHMMSS> ${jdir}
5. Start the OUD instances back up with start-ds.
/u01/mw_oud14c/asinst_1/OUD/bin/start-ds
/u01/mw_oud14c/oud1/OUD/bin/start-ds
/u01/mw_oud14c/proxy1/OUD/bin/start-ds
/u01/mw_oud14c/replgw1/OUD/bin/start-ds
Update Oracle Unified Directory
Here is the procedure that I use for applying patches to OUD including bundle patches.
Roll OUD Forward
1. Determine the current OUD release version and patch bundle installed with "start-ds --version". In most cases, the release version will be 14.1.2.1.<date> where the date represents the most recent patch bundle installed. In the following sample, output, the patch bundle installed was the January 2nd, 2025 patch bundle (251202).
/u01/mw_oud14c/oud1/OUD/bin/start-ds --version
Oracle Unified Directory 14.1.2.1.251202
Build 20251202172439Z
2. In addition to getting the OUD version, store the current list of patches in an output file that you can reference when determining if a patch needs to be applied or not.
export JAVA_HOME=/u01/sw/jdk
export ORACLE_HOME=/u01/mw_oud14c
$ORACLE_HOME/OPatch/opatch lsinventory > /u01/oud_lsinventory.txt
Oracle Unified Directory 14.1.2.1.251202
Build 20251202172439Z
BEST PRACTICE: Note that some OUD patches require an updated version of OPatch to be installed before the OUD patch can be applied. Therefore, it is a best practice to go ahead and download the latest OPatch version (
https://updates.oracle.com/download/28186730.html) in addition to the OUD patch(es).
3. Before applying any patches, stop the OUD instance(s) and make a backup of the middleware home so that you have a roll back path in case the patch fails or the update(s) introduce unexpected problems. OUD instance types may include OUD storage, OUD proxy, or OUD replication gateway depending on your deployment.
/u01/mw_oud14c/replgw1/OUD/bin/stop-ds
/u01/mw_oud14c/proxy1/OUD/bin/stop-ds
/u01/mw_oud14c/oud1/OUD/bin/stop-ds
/u01/mw_oud14c/asinst_1/OUD/bin/stop-ds
4. Confirm that no lingering processes processes are referencing the JDK. If the OUDSM is running using this JDK, you will want to shut that down as well.
jdir='oud_jdk'
ps -ef|grep /u01/sw/${jdir}
If there are any processes still running with the existing JDK, gracefully stop those processes before proceeding to backup the OUD middleware home.
5. Backup the OUD middleware home. Make note of the backup date (<backup_date>) in case you need to roll back to this backup.
now=$(date +'%Y%m%d%H%M%S')
cd /u01
tar -czf mw_oud14c.${now}.tgz mw_oud14c
BEST PRACTICE: Make sure that the backup file destination has sufficient storage for the OUD middleware home backup. You may need to store the backup file (mw_oud14c.<date>.tgz) in a different filesystem if the OUD home is large enough that the backup would fill up the filesystem. You can determine the size consumed by the middleware home with the du command. For example: "du -hs /u01/mw_oud14c"
Compare that size to the amount of free space on the filesystem on which the middleware home resides with the df command. For example: "df -h /u01/mw_oud14c"
Using the example commands, we see from the output that the middleware home (/u01/mw_oud14c) is 717M and the available storage on the filesystem is 132GB, which is more than enough to hold the backup of the middleware home.
du -hs /u01/mw_oud14c
717M /u01/mw_oud14c
df -h /u01/mw_oud14c
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/ocivolume-root 189G 58G 132G 31% /
6. Apply the OPatch update. The application of the OPatch update is different than normal OUD patches. The following procedure illustrates how to apply the OPatch update. In this example, the downloaded OPatch update file from Oracle Support (
https://support.oracle.com) is
p28186730_1394224_Generic.zip. Use the patch file name that you download in place of this file name in the following example.
jdir='oud_jdk'
export JAVA_HOME=/u01/sw/${jdir}
export ORACLE_HOME=/u01/mw_oud14c
mkdir /u01/sw/opatch
unzip -qd /u01/sw/opatch -ou /u01/bits/opatch/p28186730_1394224_Generic.zip
$JAVA_HOME/bin/java -jar /u01/sw/opatch/6880880/opatch_generic.jar -silent oracle_home=$ORACLE_HOME
7. Apply each of the patch to the OUD 14c middleware home. To apply the OUD patch, use the opatch command. Set the requisite environment variables (JAVA_HOME and ORACLE_HOME), extract patch, cd into the patch number directory and then apply with the opatch command. Once the application of the patch is complete, the last line of the opatch command output should be some variation of "OPatch succeeded" or "Patch ... successfully applied" If this is not the case, review the output from the opatch command to see if there are any dependencies to be satisfied or issues to resolve. Resolve these and then apply the opatch until success is attained. If you can not resolve the issue, open an Oracle Support Request to obtain assistance from support to troubleshoot and resolve the issue.
Here is an automated procedure to iterate through all of the patches in /u01/bits/oud14c.
jdir='oud_jdk'
export JAVA_HOME=/u01/sw/${jdir}
export ORACLE_HOME=/u01/mw_oud14c
mkdir /u01/sw/oud14c
cd /u01/bits/oud14c
for p in p*
do patch=$(echo ${p}|cut -d'p' -f2|cut -d'_' -f1)
unzip -qod /u01/sw/oud14c /u01/bits/oud14c/${p}
cd /u01/sw/oud14c/${patch}
$ORACLE_HOME/OPatch/opatch apply -silent
done
8. Once the patch(es) have been successfully applied, then start the OUD instances back up, which may include OUD storage, OUD proxy, or OUD replication gateway depending on your deployment.
/u01/mw_oud14c/asinst_1/OUD/bin/start-ds
/u01/mw_oud14c/oud1/OUD/bin/start-ds
/u01/mw_oud14c/proxy1/OUD/bin/start-ds
/u01/mw_oud14c/replgw1/OUD/bin/start-ds
Roll OUD Back
If there are any issues with the application of the opatch or OUD updates, you may need to roll back to the previous state. This fortunately, is easy because you made a backup of the middleware home. Here is the roll back procedure.
1. Stop OUD
/u01/mw_oud14c/replgw1/OUD/bin/stop-ds
/u01/mw_oud14c/proxy1/OUD/bin/stop-ds
/u01/mw_oud14c/oud1/OUD/bin/stop-ds
/u01/mw_oud14c/asinst_1/OUD/bin/stop-ds
2. Confirm that no lingering processes processes are referencing the OUD JDK. If the OUDSM is running using this JDK, you will want to shut that down as well.
jdir='oud_jdk'
ps -ef|grep /u01/sw/${jdir}
If there are any processes still running with the existing JDK, gracefully stop those processes before proceeding to restore the OUD middleware home.
3. Re-locate the existing OUD middleware home
now=$(date +'%Y%m%d%H%M%S')
mv /u01/mw_oud14c /u01/mw_oud14c.${now}
4. Restore the previous OUD middleware home.
cd /u01
tar -xzf /u01/mw_oud14c.<backup_date>.tgz
5. Start OUD back up
/u01/mw_oud14c/asinst_1/OUD/bin/start-ds
/u01/mw_oud14c/oud1/OUD/bin/start-ds
/u01/mw_oud14c/proxy1/OUD/bin/start-ds
/u01/mw_oud14c/replgw1/OUD/bin/start-ds
Update Oracle Unified Directory Services Manager
Oracle Unified Directory Services Manager (OUDSM) is composed of the combination of the JDK, Oracle Unified Directory (OUD), Fusion Middleware (FMW) Infrastructure (a.k.a. WebLogic) and the Application Developer Framework (ADF) content.
BEST PRACTICE: It is best practice to install OUDSM in its own middleware home on its own host that is separate and independent of the hosts where OUD instances are running. The reasons for this separation include the following:
- Maintain independent JDK versions from other products. Note that if you are co-locating the OUD instances on the same host, use a different JDK path like /u01/sw/oudsm_jdk instead of /u01/sw/jdk referenced earlier in this post.
- Maintain independent OUD patch applications from other products
- Avoid resource contention with other products
- Preserve the security best practice of minimization by only installing and running what is minimally necessary to run the desired service or software
JDK Update
Apply the same JDK update procedures documented above. However, note that if OUDSM and OUD are on the same host, the JDK best practice is to have a separate JDK directory for OUDSM from other products on the same host. For example, consider using /u01/sw/oud_jdk for OUD and /u01/sw/oudsm_jdk for OUDSM. If the JDK update presents any problem with starting or running OUDSM, roll back the JDK with the "Roll JDK Back" procedure documented in the "Update Java Development Kit" section of this blog post.
OUD Patches
The procedure for applying the OUD patch to OUDSM middleware home (Example: /u01/mw_oudsm14c) is identical to those cited earlier with the exception of using the OUDSM middleware home directory and OUDSM specific JDK path (Example: /u01/mw_oudsm14c and /u01/sw/oudsm_jdk) that that are separate and independent of the OUD middleware home and JDK path (Example: /u01/mw_oud14c and /u01/sw_oud). Therefore, follow those procedures for applying the OUD patch to the OUDSM middleware home. Similarly to the JDK, if you need to roll back to the previous JDK version, use the "Roll OUD Back" but for the OUDSM middleware home (/u01/mw_oudsm14c).
FMW Patches
In addition to the OUD patches, OUDSM has several of its own FMW Infrastructure (a.k.a. WebLogic or WLS) patches to apply as well.
SPECIAL NOTE: If you are installing OUDSM for the first time, you may need to open a support request to obtain the password for the Oracle Application Development Framework (ADF) one off patch 37376076 (
https://updates.oracle.com/download/37376076.html) that isis required to run OUDSM 14c.
Roll OUDSM Forward
1. Before applying any patches, stop the OUDSM and make a backup of the middleware home so that you have a roll back path in case the patch fails or introduces unexpected problems.
/u01/mw_oudsm14c/domains/oudsm/bin/stopWebLogic.sh
ps -ef|grep -i weblogic.NodeManager|grep -v grep|awk '{ print $2 }'|xargs -n1 kill -9
2. Backup the OUDSM middleware home. Make note of the backup date (<backup_date>) in case you need to roll back to this backup.
now=$(date +'%Y%m%d%H%M%S')
cd /u01
tar -czf mw_oudsm14c_fmw.${now}.tgz mw_oudsm14c
BEST PRACTICE: Make sure that the backup file destination has sufficient storage for the OUDSM middleware home backup. You may need to store the backup file (mw_oudsm14c_fmw.<date>.tgz) in a different filesystem if the OUDSM home is large enough that the backup would fill up the filesystem. You can determine the size consumed by the middleware home with the du command. For example: "du -hs /u01/mw_oudsm14c"
Compare that size to the amount of free space on the filesystem on which the middleware home resides with the df command. For example: "df -h /u01/mw_oudsm14c"
Using the example commands, we see from the sample command output that the middleware home (/u01/mw_oudsm14c) is 3.5G and the available storage on the filesystem is 126GB, which is more than enough to hold the backup of the middleware home.
du -hs /u01/mw_oudsm14c
3.5G /u01/mw_oudsm14c
df -h /u01/mw_oudsm14c
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/ocivolume-root 189G 64G 126G 34% /
3. Apply the current OPatch update. The application of the OPatch update is different than normal OUD patches. The following procedure illustrates how to apply the OPatch update. In this example, the downloaded OPatch update file is
p28186730_1394224_Generic.zip from Oracle Support (
https://support.oracle.com). Use the patch file name that you download in place of this file name in the following example.
jdir='oudsm_jdk'
export JAVA_HOME=/u01/sw/${jdir}
export ORACLE_HOME=/u01/mw_oudsm14c
mkdir /u01/sw/opatch
unzip -qd /u01/sw/opatch -ou /u01/bits/opatch/p28186730_1394224_Generic.zip
$JAVA_HOME/bin/java -jar /u01/sw/opatch/6880880/opatch_generic.jar -silent oracle_home=$ORACLE_HOME
4. Apply OUD 14c and OUDSM 14c patches to the OUDSM middleware home (/u01/mw_oudsm14c).
To apply a patch, use the opatch command. Set the requisite environment variables (JAVA_HOME and ORACLE_HOME), extract patch, cd into the patch number directory and then apply with the opatch command. Once the application of the patch is complete, the last line of the opatch command output should be some variation of "OPatch succeeded" or "Patch ... successfully applied" If this is not the case, review the output from the opatch command to see if there are any dependencies to be satisfied or issues to resolve. Resolve these and then apply the opatch until success is attained. If you can not resolve the issue, open an Oracle Support Request to obtain assistance from support to troubleshoot and resolve the issue.
Here is an automated procedure to iterate through all of the patches in /u01/bits/oudsm14c.
jdir='oudsm_jdk'
export JAVA_HOME=/u01/sw/${jdir}
export ORACLE_HOME=/u01/mw_oudsm14c
mkdir /u01/sw/oudsm14c
cd /u01/bits/oudsm14c
for p in p*
do patch=$(echo ${p}|cut -d'p' -f2|cut -d'_' -f1)
unzip -qod /u01/sw/oudsm14c /u01/bits/oudsm14c/${p}
cd /u01/sw/oudsm14c/${patch}
$ORACLE_HOME/OPatch/opatch apply -silent
done
5. Once the patch(es) have been successfully applied, then start OUDSM back up.
now=$(date +'%Y%m%d%H%M%S')
/u01/mw_oudsm14c/domains/oudsm/bin/startWebLogic.sh > /u01/logs/wl-${now}.log 2>&1 &
# Wait until WebLogic completes starting up signified by seeing "in RUNNING mode" in the wl-${now}.log file.
# Start Node Manager
/u01/mw_oudsm14c/domains/oudsm/bin/startNodeManager.sh > /u01/logs/nm-${now}.log 2>&1 &
Roll OUDSM Back
If there are any issues with the application of the opatch or WLS updates, you may need to roll back to the previous state. This fortunately, is easy enough because you made a backup of the middleware home. Here is the roll back procedure.
1. Stop OUDSM
/u01/mw_oudsm14c/domains/oudsm/bin/stopWebLogic.sh
ps -ef|grep -i weblogic.NodeManager|grep -v grep|awk '{ print $2 }'|xargs -n1 kill -9
2. Re-locate the existing OUDSM middleware home
now=$(date +'%Y%m%d%H%M%S')
mv /u01/mw_oudsm14c /u01/mw_oudsm14c.${now}
3. Restore the previous OUDSM middleware home.
cd /u01
tar -xzf /u01/mw_oudsm14c_fmw.<backup_date>.tgz
4. Start OUDSM back up
now=$(date +'%Y%m%d%H%M%S')
/u01/mw_oudsm14c/domains/oudsm/bin/startWebLogic.sh > /u01/logs/wl-${now}.log 2>&1 &
# Wait until WebLogic completes starting up signified by seeing "in RUNNING mode" in the wl-${now}.log file.
# Start Node Manager
/u01/mw_oudsm14c/domains/oudsm/bin/startNodeManager.sh > /u01/logs/nm-${now}.log 2>&1 &
Qualify Functional And Performance Tests
Once the updates are complete, run through a battery of functional and performance tests to ensure that OUD and OUDSM are functioning properly. In addition, if appropriate, perform load generation testing to confirm that OUD is performing as well as it did before the application of patches.
Clean Up
Once qualification testing is complete and sufficient time has passed that you feel confident that you will not need to roll back the updates, then you can remove the backup files created during the update process. Typical retention of these backup files in my experience is 1-2 weeks.
I hope you find this beneficial and insightful.
Blessings!
