Let us Patch Up with Patching - weblogic/soa suite

Patching is a confusing topic for beginners. In this post, I will try to explain different terminologies.

CPU – Short for Critical Patch Update. It comprises of security patches.  
PSU – Short for Patch Set Updates. It includes security and priority fixes.
Both patches are released quarterly on the Tuesday closest to the 17th day of the months of January, April, July and October. Both the patches are cumulative that means every patch includes fixes of the early patches. So, there is no need to apply earlier patches. Once a PSU has been applied on the system, the recommended method to apply all future CPU program security content is to apply future PSUs. In other words, once a PSU has been applied, it is not recommended to switch back to traditional N-apply patches. Reverting to CPU from PSU is complex and time consuming task and so it is not recommended.
One-Off: If Oracle finds critical vulnerability that can’t wait till next patch release, it releases One-Off Patch.
Error Correction Period: This is the period beyond which Oracle doesn’t release any fixes either PSU or CPU. There is different criteria for different product versions. Please refer to Oracle documentation for more details.
How to get current patch set level:
12c:
In WebLogic Server 12.1.2 and higher (that is, the versions which use OPatch rather than Smart Update), you need to use OPatch to query what patches (including what PSU) are installed. To do this, use the OPatch lsinventory command. 
For example: opatch lsinventory
11g:
In WebLogic Server versions prior to 12.1.2, you can determine what PSU and other one-off patches are applied to your environment by using the weblogic.version command. To do this, follow these steps:
i) Set the environment for your WLS installation by running the WL_HOME/server/bin/setWLSEnv (cmd or sh) script.
ii) Run the weblogic.version command. 
                                        or
i) cd $MW_HOME/utils/bsu/ 
ii) ./bsu.sh -view -status=applied -prod_dir=/app_base/PRDBTB/Middleware/wlserver_10.3/  -verbose -view
Note: In WLS 11g (10.3.4+) and 12.1.1, each PSU will conflict with any prior PSU in the series. To install a subsequent PSU, any existing PSU must first be uninstalled. This restriction is no longer applicable in WLS 12.1.2 and higher. In those versions, OPatch automatically rolls back the previous PSUs and there should be no requirement that customers manually roll back prior to installing the PSU. 
 References:
Oracle Doc id: 1306505.1

Comments

Post a Comment

Popular posts from this blog

HOW WE REDUCED SOA OSB PROVISIONING FROM 4 DAYS TO 4 HOURS

 In our organization, we’ve undertaken the task of upgrading both SOA and OSB from version 12.2.1.3 to 12.2.1.4. This involves an out-of-place migration approach, wherein we create a new environment and switch traffic during the cutover. As you know, this process typically requires several days we opt for manual provisioing. A very significant amount of automation work was previously accomplished for 12.2.1.3 by our predecessors. Despite these efforts, the process still used to take lot of time due to following factors: Bugs in existing automation. For example, SOA composite deployments is not stable which warrants lot of manual work Import of 10s of TLS Certificates into KSS Manual retiring and shutting down of services Monitoring setup Miscellaneous: Increasing Log file count, enabling GC logging, changing heap parameters, bash profile changes While our current automation initiatives have yielded substantial savings, we aimed to capitalize on this upgrade activity to enable end-t...
Read more

NOT ABLE TO START RABBITMQ CLUSTER: CANNOT DECLARE A QUEUE ‘~S’ ON NODE ‘~S’: ~255P

We have 7 node rabbitmq cluster and we are using sharding queues. We have shutdown all non prod rabbitmq nodes as part of VM patching. As it was non prod, we thought of shutting down all together instead of rolling patching. We couldn’t start the any of the rabbitmq post patching. All of nodes were failing to start with the below error: 2022-06-23 05:13:10.104845-07:00 [error] <0.647.0> “Cannot declare a queue ‘~s’ on node ‘~s’: ~255p”, 2022-06-23 05:13:10.104845-07:00 [error] <0.647.0> [“queue ‘sharding: shard.my.queue – rabbit@rabbit1’ in vhost ‘my_vhost'” This is a known issue in some old versions of rabbitmq. rabbitmq node fails to come up with above error. Work around for this is to disable sharding policy for the problematic sharding queue. It can be done either from command line or from rabbitmq admin page. It requires to connect a running node. But as all the nodes were down, we could not disable sharding policy. Luckily, rabbitmq allows disabling sharding pulgi...
Read more

SOA SUITE 12.2.1.4 INSTALLATION: GOT EXCEPTION WHEN AUTO CONFIGURING THE SCHEMA COMPONENT(S) WITH DATA OBTAINED FROM SHADOW TABLE

  We planned to do out of place upgrade from soa suite 12.2.1.3 to 12.2.1.4. As part of this, we planned to automate end to end provisioning. While executing domain configuration using ansible and python scripts, we got following error in domain creation step. Got exception when auto configuring the schema component(s) with data obtained from shadow table. Failed to build JDBC Connection object: com.oracle.cie.domain.script.jython.CommandExceptionHandler. exception. Quick internet search gave few solutions like deleting domain-registry.xml file, verifying dehydration store password supplied to script etc. But none of them helped. After trying several options, I thought I might have done some stupid error prior to domain creation step. To track down the issue, though of checking what getDatabaseDefaults actually doing. I tried to grep for the getDatabaseDefaults function call inside oracle home. But couldn’t find the source code for the python function. As a final resort, thought of...
Read more