资讯专栏INFORMATION COLUMN

Weblogic补丁升级之坑坑洼洼

IT那活儿 / 1128人阅读
Weblogic补丁升级之坑坑洼洼
[
概述
]


虽然当前国内去IOE波涛汹涌,但不可否认OracleWeblogic当前市场还有有一定使用量。所以,weblogic依然是中间件运维的重要工作之一。然而Oracleweblogic已经连续三个季度(2019年10月~2020年7月)曝出CVSS风险为9.8的高危安全漏洞,漏洞修复是一轮接着一轮,轮的哥都要吐了,但没办法,活儿还是不能拉下。本文主要是针对weblogic漏洞修复,罗列一些在weblogic安全漏洞补丁更打过程中笔者遇到的一些问题以及解决方案或思路,希望对同样做补丁升级的兄弟们有所启示。


[
坑坑洼洼
]


问题1:

weblogic补丁升级后执行BSUCOMMAND查看不到补丁信息


该问题出现在weblogic11g正常更打完PSU补丁集后,最后使用./bsu.sh–view -status=applied -prod_dir=最后查看校验一下补丁版本信息时,结果却没返回有补丁信息:


此时莫慌张,并不是你补丁安装失败了。可以关注到红线部分,此处的weblogicPatch指定了一“DownloadDir:“ ,怀疑和这个设置有关。我们尝试继续使用bsu.sh查看补丁信息,这次咱们开启debug日志来验证想法:

 ./bsu.sh -view -verbose -status=applied -prod_dir=/data1/weblogic/wlserver_10.3 -log=bsu.log -log_priority=debug,日志会生成在脚本当前路径。


查看日志有如下报错:


问题原因:是我们习惯将补丁放到./utils/bsu/cache_dir解压更打,而此处weblogic指定了DownloadDir这个目录,所以才产生这个问题,读取不到补丁信息。

解决方法:1)将本次更打的patch-catalog_xxxxx.xml文件拷贝到上述目录下,重命名为patch-catalog.xml。

2)重新指定本次patch_download_dir目录-patch_download_dir=/data1/weblogic/utils/bsu/cache_dir

重新查看补丁信息,如下:


问题2:升级过程中抛出OOM异常

该问题新手在更打或卸载weblogic11g补丁过程中经常会遇到,报错如下“java.lang.OutOfMemoryError:Java heap space“


问题原因:卸载或更打补丁前,未设置合理的JVM大小,导致执行过程中JVM不足,内存溢出。


解决方法:修改bsu.sh,将如下设置修改为-Xms2048m –Xmx2048m,或者内存充足的情况下,设置为更大的值即可。


问题3:weblogic12C升级过程中OPatch版本问题

该问题常出现在weblogic12c版本补丁更打过程当中,报错信息很友好,直接给出了解决方案:


问题原因:TheOPatch version is not applicable for current OUI version.


解决方法:到OracleSupport下载patch6880880,更新OPatch,命令如下:

java-jar /6880880/opatch_generic.jar -silentoracle_home=

更新后,使用opatchversion,查看当前opatch信息如下:


问题4:拷贝安装的惹的祸

某系统某次weblogicPSU补丁升级完成后,该系统出现“ORA-01461:仅能绑定要插入 LONG列的 LONG值”报错,报错之前系统只做过weblogicPSU更打,于是第一时间回滚后,问题消失,确认问题由补丁升级引起。经排查,初步判定ORA-01461报错原因应该系数据库与客户端JDBC驱动不匹配所致。当晚升级人员在补丁升级后,应用启动日志记录的数据源与库建立连接使用的驱动版本为11.2.0.3.0,日志记录如下:


而在未升级补丁时,日志记录的驱动版本为12.1.0.2.0版本,如下:

继续核实发现,该系统weblogic产品针对jdbc驱动包ojdbc6.jar做了修改(修改后驱动为12.1.0.2.0版本),而当晚升级操作人员直接使用其他系统升级完成的weblogic拷贝安装至该系统主机,相当于将修改后的ojdbc6.jar驱动包还原了,因此驱动版本变成了11.2.0.3.0,导致问题的出现。


问题原因:在没了解清楚当前系统weblogic是否做过一些特定修改下,直接拷贝安装。


解决方法:在大批量服务器进行weblogic补丁更新时,可能大家都采用过拷贝安装的方式:先打一台模板,后续直接打包weblogic产品目录拷贝解压安装到其他服务器上,以完成补丁跟新。正常情况下,如果weblogic产品内部相关包未被修改或替换,确保操作系统版本、安装目录、jdk路径及版本一致的情况下,这不失为一种有效的捷径,但是如果存在weblogic产品内部相关包未被修改或替换,那可能就会踩坑了。


问题5:补丁升级后weblogicserver启动异常

该问题常出现在weblogic产品安装用户与weblogicServer启动用户不一样的情况下,在weblogic补丁更打成功后,weblogicServer启动出现如下报错,找不到”main”方法:


问题原因:weblogic补丁更打后,weblogic产品某些子录下文件重新创建,导致WEBLOGIC_HOME下某些子目录缺少可写或可执行权限所知。


解决方法:确保weblogicserver启动用户对Weblogic_HOME下的所有子目录具有可写和可执行的权限。建议如果weblogic安装用户与weblogicdomain域部署用户不一致的情况下,更打完PSU补丁集后,请chmod–R 755 $Weblogic_HOME。


问题6:补丁升级后weblogicserver启动异常

首先说明下,该问题的出现于weblogic升级并无直接关系,是笔者在今年7月份的一次weblogic补丁升级后,遇到的一次问题。情况是老套路,升级后,应用启不起来了,应用侧一口咬定补丁升级所致,报错如下图:


说实话哥也是心虚的,我所知的确实只有我做了weblogic补丁更新,问题也是第一次遇到,趁晚上升级还有时间,赶紧到MOS上找找答案。事实证明,确实很多坑,别人都已经帮我们踩过了,找到类似的报错信息,


以上,原因1直接PASS了,原因2,可能存在config.xml或setEnv文件可能被改动或失效。顺着这个思路,找来了应用账号,直接去$DOMAIN_HOME/config下看了下config.xml文件,当晚应用侧对config.xml文件明显有改动,存在多个版本。如下截图:

后面就简单了,直接让应用先回滚config.xml文件,重启weblogicserver正常启动,问题证实与补丁升级无关。

问题原因:应用侧修改config.xml文件存在格式或内容错误,导致文件失效所致。


解决方案:碰到没见过的问题不要慌,先到官网找找资料,绝大部门的坑,别人已经替咱们踩过了。


问题7:补丁升级后weblogicserver启动异常

最后一个案例,本人暂时没有遇到,系Oracle原厂发出的一个预警,希望近期在更新PSU20200714朋友如果遇到了此问题,可以参考。


最近有客户遇到WLS打完最新PSU20200714补丁后,服务启动报错的问题。OracleACSOFM团队初步分析是由于升级完成后,SAX对是否支持解析XML文件中的外部DTD默认值做了改变(之前版本默认值为true,新版本默认值变为false)。


如果升级完成后启动服务遇到如下类似报错,则是由于该问题导致。

WARNING: Could not read file registry settings $DOMAIN_HOME/config/fmwconfig/servers//logging.xml; exception: oracle.core.ojdl.logging.LoggingConfigurationException: ODL-52050:

Could not process file $DOMAIN_HOME/config/fmwconfig/servers//logging.xml, XML parsing exception line 1, column 1.266): org.xml.sax.SAXParseException; lineNumber: 1;

columnNumber: 1266; The content of the item type "root" is incomplete, must match "(logging_configuration)".

目前的解决方案是在WebLogicserver的启动参数中增加 -Dweblogic.xml.jaxp.allow.externalDTD=true 规避这个问题(已经过测试确认)。

[
小结
]


以上,是笔者或者同事在weblogic补丁更新过程中遇到的一些问题,以及记录下来的问题解决方案或思路,类似的问题还有很多,篇幅有限,未一一列举了。运维过程中,我们遇到的问题可能是千变万化,如何有效的去规避或者解决问题,我认为需要咱们做到以下几点:

  • 涉及操作,请制定合理的操作方案,并虚心提交公司老人或专家审核;

  • 正确的分析和理解错误日志,问题就解决一半了;

  • 有效的利用互联网资源,很多坑别人都已经替你踩过了;

  • 绝大部分问题相应产品官网均有详细的记录与解决方案,请善于查找官方资料;

  • 学会总结记录,相同的问题你不一定能记住准确的解决方案,好记性不如烂笔头;

  • 不要藏问题,请学会抛出问题,解决不了的提交专家或者至官网提交SR。

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/130176.html

相关文章

  • weblogic漏洞总结复现

    摘要:在当前页面抓包后修改内容,写入冰蝎脚本文件。添加的内容为实现反弹。影响范围相关漏洞有复现过程环境这里先使用扫描一下是否开启了服务。使用工具写入。 目录 简介Web...

    glumes 评论0 收藏0
  • 浅谈支撑起支付宝整个“11-11”的幕后功臣OceanBase数据库

    摘要:简介本文首发公众号一名打字员据悉,年的月份,蚂蚁金服已经宣布,蚂蚁金服及阿里巴巴自研的关系型数据库已经支撑起和淘宝的日常业务需求,成功替换了之前所采用的单机数据库如或者开源的。 简介 Tip:本文首发公众号【一名打字员】 据悉,17年的4月份,蚂蚁金服已经宣布,蚂蚁金服及阿里巴巴自研的关系型数据库OceanBase已经支撑起Tmall和淘宝的日常业务需求,成功替换了之前所采用的单机数据...

    Cristalven 评论0 收藏0
  • 浅谈支撑起支付宝整个“11-11”的幕后功臣OceanBase数据库

    摘要:简介本文首发公众号一名打字员据悉,年的月份,蚂蚁金服已经宣布,蚂蚁金服及阿里巴巴自研的关系型数据库已经支撑起和淘宝的日常业务需求,成功替换了之前所采用的单机数据库如或者开源的。 简介 Tip:本文首发公众号【一名打字员】 据悉,17年的4月份,蚂蚁金服已经宣布,蚂蚁金服及阿里巴巴自研的关系型数据库OceanBase已经支撑起Tmall和淘宝的日常业务需求,成功替换了之前所采用的单机数据...

    dinfer 评论0 收藏0
  • 浅谈支撑起支付宝整个“11-11”的幕后功臣OceanBase数据库

    摘要:简介本文首发公众号一名打字员据悉,年的月份,蚂蚁金服已经宣布,蚂蚁金服及阿里巴巴自研的关系型数据库已经支撑起和淘宝的日常业务需求,成功替换了之前所采用的单机数据库如或者开源的。 简介 Tip:本文首发公众号【一名打字员】 据悉,17年的4月份,蚂蚁金服已经宣布,蚂蚁金服及阿里巴巴自研的关系型数据库OceanBase已经支撑起Tmall和淘宝的日常业务需求,成功替换了之前所采用的单机数据...

    zhoutao 评论0 收藏0
  • Weblogic 管理控制台未授权远程命令执行漏洞(CVE-2020-14882,CVE-2020-

    摘要:将的动态功能和标准的安全性引入大型网络应用的开发集成部署和管理之中。使用这两个漏洞组成的利用链,可通过一个请求在远程服务器上以未授权的任意用户身份执行命令。这个漏洞的利用方式有两种,一是通过,二是通过。 一、软件介绍 WebLogic是美国Oracle公司出品的一个application s...

    zhongmeizhi 评论0 收藏0
  • 稳定高于一切的金融行业如何用容器?

    摘要:在谷歌不是这样,谷歌不会把特定的应用装在某台服务器上,业务应用和服务器的强绑定对于谷歌这种量级的数据中心的维护难度太高了。但是金融机构的数据中心规模不像谷歌这么大,所以能做到业务应用和硬件的强绑定。 复杂的基础IT架构是传统金融的现状,如何快速响应用户需求,加快新业务上线速度,缩短产品的迭代周期? 数人云在容器落地金融云的2年实践中,实现金融核心业务技术WebLogic、J2EE、Or...

    scola666 评论0 收藏0

发表评论

0条评论

IT那活儿

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<