好久没写东西，强迫自己水一个。最近有报道说黑客利用Weblogic Server的漏洞去挖矿，获得了至少611个门罗币（XMR），总价值达到了22.6万美元。第一反应是把自家的服务器打上补丁，打了patch后想看看有没有生效，才发现以前”java -weblogic.version”的方法不好使了。

放狗搜了一把，才知道从weblogic版本12.1.2.0.0后，因为使用opatch的方式统一管理补丁，所以查看PSU的方式也改变了。

依据Doc ID 1676652.1的方法如下：

cd $MW_HOME/OPatch
./opatch lsinventory

从Weblogic控制台可以看到当前的Weblogic版本：

Go to the Servers link
Customize this table
Check the WebLogic Version box and add it to the right side
Click Apply

一直习惯用Sublime里写代码，最近为了调试几个JET程序，想装个Netbeans 8.2,结果运行安装程序时，却出现一个奇怪的错误。

问题描述

启动Netbeans安装程序，第一个窗口出来后就闪退，在安装程序目录下生成一个名字为“hs_err_pidxxxx.log”的文件，提示有致命错误。信息如下：


#
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#


--------------- T H R E A D ---------------

Current thread (0x000000001921b800): JavaThread "Swing-Shell" daemon [_thread_in_native, id=6636, stack(0x000000001a1e0000,0x000000001a2e0000)]

siginfo: ExceptionCode=0xc0000005, reading address 0x0000000000000000


Registers:
RAX=0x0000000000000000, RBX=0x000000001a2df130, RCX=0x0000000000000000, RDX=0x0000000000cc8700
RSP=0x000000001a2df0d8, RBP=0x000000001a2df2c0, RSI=0x00000000000000e0, RDI=0x000000001921b9f8
R8 =0x0000000000cc8700, R9 =0x0000000000000000, R10=0x0000000000000000, R11=0x000000001a2dc2f0
R12=0x0000000000000000, R13=0x000000001a2df2e0, R14=0x000000001a2df2a8, R15=0x000000001921b800
RIP=0x0000000056926adf, EFLAGS=0x0000000000010246
......


然后安装程序自动退出。

解决方法

放狗搜了下，有人说是因为升级到最新版本的Win10所致。但经俺自己试验，其实系统上有God Folder导致，不管是God Folder是存在C盘还是桌面。把God Folder暂时挪至回收站，重新安装Netbeans，顺利完成。

把公司的内容管理系统全面迁移到Docker上重新部署，把备份的归档文件导入时发现报错没法导入，最后把自定义的元数据去掉后导入成功。但是原来利用文件类型的层级关系定义了很多子类型，都去掉的话很多查询的条件不能使用，积累的内容基本废了一半。

问题描述

尝试在WebCenter Content里更新内容元数据信息，但是每次更新都报Unable to update the content item information for ‘XXXX’. Unable to execute service method ‘validateCheckinData’. Null pointer is dereferenced.的错误。在Oracle Support上找原因，搜到的结果都不对。把自定义的表、视图、关系重建，把元数据删除重建，无数次的修改重启，就是不起作用。折腾了大半个月，差点发疯。

解决办法

今天下班没事又开始看，无意识的打开Oracle Support，以Unable to execute service method ‘validateCheckinData’为关键字搜索，没想到一下子跳出了Doc ID 2225215.1，说这是WebCenter Content 12c的一个bug，当用dDocType做为元数据层级关系的依据时，检入文件或更新时会报错。
按文档的指引下载了patch 23753742,打了补丁后在配置文件加上NoServerDependantFieldValidate=true，重启WebCenter Content服务，更新元数据，一切正常。
想起自己这个经历，心里只想骂他大爷的O记。

问题描述

因为Google把http的网站标记为不安全网站的关系，决定把本站点改为SSL的https方式。
安装好证书，修改了站点的Site和URL配置，重启站点后发现前端页面可以正常访问，但是wp-admin页面却一直显示重定向过多的错误，

ERR_TOO_MANY_REDIRECTS

解决方法

放狗搜了一番，从清cookies到修改wp-config.php都试过，但是还是不能奏效。就这样拖了两个星期，今天稍微空下来，决定把这个问题彻底解决。

在wp-config.php文件下增加了以下几行。

define('FORCE_SSL_ADMIN',true);
// in some setups HTTP_X_FORWARDED_PROTO might contain
// a comma-separated list e.g. http,https
// so check for https existence
if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false)
$_SERVER['HTTPS']='on';


重启后，发现站点不再报重定向过多的错了，但是又报OAuth的错（因为俺是用Google的OAuth验证登录）。登上Google的API Manager Console，把站点链接地址指向从http改到https，问题解决。

1.问题描述

把WebCenter Content从11g升级到12c，用归档程序把原有的文件迁移到新版本，文件ID使用与原来相同的自动编号规则，当签入新文件时，系统总是报 “Content Server Request Failed Content item ‘TF_XXX’ was not successfully checked in. The content ID ‘TF_48509’ is not unique.”。

查看Content Server日志，错误信息如下：

An error has occurred. The stack trace below shows more information.

!csUserEventMessage,jeetqiu,139.159.32.66!$!csUnableToCheckIn,TF_007207!csCheckinIDNotUnique2,TF_007207
intradoc.common.ServiceException: !csUnableToCheckIn,TF_007207!csCheckinIDNotUnique2,TF_007207
*ScriptStack CHECKIN_NEW_SUB
3:doScriptableAction,dDocName=3:doSubService,dDocName=CHECKIN_NEW_SUB,dDocName=3:makeNewRevClass,dDocName=
at intradoc.server.ServiceRequestImplementor.buildServiceException(ServiceRequestImplementor.java:2259)…

2.解决方法

第一时间上Oracle Support找相关的答案，Doc ID 446390.1和Doc ID 1320842.1都有相关的描述，不过都是修改counters表的RevClassID来达到目的。照着文章修改了RevClassID，但不知道是WebCenter Coneent 12C的机制更新还是什么原因，修改后并没有起作用。

后来无意中在一个链接看到Doc ID 1395583.1 How WebCenter Content 11g Uses Sequences to Uniquely Identify Content，从中知道IdcSeqRevClassID是管自动生成序号的，于是找到当前最大序号。
Select MAX(dDocName) from revisions
再修改IdcSeqRevClassID的起始值至最大序号+1，重新回到content系统，签入新文件，一切正常。

1.问题描述

Ubuntu 16.04 Server LTS升级内核时，每次都跑出来“W: mdadm: /etc/mdadm/mdadm.conf defines no arrays”的提示。明明没有用RAID,查了mdadm.conf也有没有任何相关的配置。虽然不影响使用，但是强迫症患者还是觉得很不爽。

2.解决办法

先删除mdadm.conf文件

# rm /etc/mdadm/mdadm.conf

再用update-initramfs命令，自动生成新的mdadm.conf文件。

# update-initramfs -u

天下太平。

1.问题描述

对于俺这种升级强迫症患者，Ubuntu的/boot分区接近100%是常见的事。日前发现公司一台测试服务器又提示/boot空间快满。习惯性的想删除内核文件释放空间，运行命令，结果与自己期望相悖，系统报空间不，没法删除旧内核文件。
# sudo apt-get remove linux-image-4.4.0-28-generic
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
linux-headers-4.4.0-24 linux-headers-4.4.0-24-generic linux-headers-4.4.0-28 linux-headers-4.4.0-28-generic linux-headers-4.4.0-31 linux-headers-4.4.0-31-generic
linux-image-4.4.0-31-generic linux-image-extra-4.4.0-31-generic
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
linux-image-4.4.0-28-generic linux-image-extra-4.4.0-28-generic
0 upgraded, 0 newly installed, 2 to remove and 89 not upgraded.
3 not fully installed or removed.
After this operation, 218 MB disk space will be freed.
Do you want to continue? [Y/n] y
(Reading database ... 217969 files and directories currently installed.)
Removing linux-image-extra-4.4.0-28-generic (4.4.0-28.47) ...
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.4.0-28-generic /boot/vmlinuz-4.4.0-28-generic
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 4.4.0-28-generic /boot/vmlinuz-4.4.0-28-generic
update-initramfs: Generating /boot/initrd.img-4.4.0-28-generic

gzip: stdout: No space left on device
E: mkinitramfs failure cpio 141 gzip 1
update-initramfs: failed for /boot/initrd.img-4.4.0-28-generic with 1.
run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
dpkg: error processing package linux-image-extra-4.4.0-28-generic (–remove):
subprocess installed post-removal script returned error exit status 1
Removing linux-image-4.4.0-28-generic (4.4.0-28.47) …
Examining /etc/kernel/postrm.d .
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 4.4.0-28-generic /boot/vmlinuz-4.4.0-28-generic
update-initramfs: Deleting /boot/initrd.img-4.4.0-28-generic
run-parts: executing /etc/kernel/postrm.d/zz-update-grub 4.4.0-28-generic /boot/vmlinuz-4.4.0-28-generic
Generating grub configuration file …
Found linux image: /boot/vmlinuz-4.4.0-63-generic
Found initrd image: /boot/initrd.img-4.4.0-63-generic
Found linux image: /boot/vmlinuz-4.4.0-59-generic
Found initrd image: /boot/initrd.img-4.4.0-59-generic
Found linux image: /boot/vmlinuz-4.4.0-38-generic
Found initrd image: /boot/initrd.img-4.4.0-38-generic
Found linux image: /boot/vmlinuz-4.4.0-31-generic
Found initrd image: /boot/initrd.img-4.4.0-31-generic
Found memtest86+ image: /memtest86+.elf
Found memtest86+ image: /memtest86+.bin
done
Errors were encountered while processing:
linux-image-extra-4.4.0-28-generic
E: Sub-process /usr/bin/dpkg returned an error code (1)

2.解决方法

运行以下命令先清除空间，确认/boot分区已有足够空余。
# sudo apt-get clean
# df -h


再用以下命令确定现在所用内核及已安装内核文件，清除不需要的内核文件。


# uname -a
# dpkg --get-selections|grep linux-image
# sudo apt-get remove linux-image-4.4.0-28-generic


计划把公司应用后台的数据库服务也统一迁移到docker上，因此起了在docker上部署Oracle数据库的念头。记得以前在docker hub上看到过现成的数据库image，上去一搜，发现不是版本太低就是说被O记要求删除。既然是这样，那O记官方有没以支持呢？放狗一搜，发现O记官方在github上有专门的docker images项目，包含了Java、数据库、应用等等的镜像生成文件。就算是自己生成镜像文件，这些资料也对写Dockerfile很有参考价值。

在github上下载Oracle数据库的docker文件，在OTN下载好Oracle Database 12C的安装包，把zip文件置于OracleDatabase/dockerfiles/12.0.0.2目录下，然后开始Oracle数据库docker的无脑安装 。

1.运行dockerfiles下的buildDockerImage.sh命令

从Oracle Linux的slim-7版本生成数据库镜像文件，该命令支持生成Oracle数据库企业版、标准版和XE版本。俺使用的是企业版。


# ./buildDockerImage.sh -v 12.1.0.2 -e -i


该脚本命令参数说明如下：

-v: version to build
Choose one of: 11.2.0.2 12.1.0.2
-e: creates image based on 'Enterprise Edition'
-s: creates image based on 'Standard Edition 2'
-x: creates image based on 'Express Edition'
-i: ignores the MD5 checksums


开始配置环境，复制安装文件，静默安装数据库，最后生成镜像。大概需要10来分钟时间。

注：在生成数据库镜像前，请特别留意Docker的存储驱动配置必须btrfs或overlay2，如果使用aufs在生成过程中会出现各种问题，俺还特意在github上特意开了issue讨论这个问题。

2.在docker容器中运行Oracle数据库


docker run --name \
-p :1521 -p :5500 \
-e ORACLE_SID= \
-e ORACLE_PDB= \
-e ORACLE_CHARACTERSET= \
-v [:]/opt/oracle/oradata \
oracle/database:12.1.0.2-ee

Parameters:
–name: The name of the container (default: auto generated)
-p: The port mapping of the host port to the container port.
Two ports are exposed: 1521 (Oracle Listener), 5500 (OEM Express)
-e ORACLE_SID: The Oracle Database SID that should be used (default: ORCLCDB)
-e ORACLE_PDB: The Oracle Database PDB name that should be used (default: ORCLPDB1)
-e ORACLE_CHARACTERSET:
The character set to use when creating the database (default: AL32UTF8)
-v The data volume to use for the database.
Has to be owned by the Unix user “oracle” or set appropriately.
If omitted the database will not be persisted over container recreation.

1.问题描述

Docker安装后默认的Storage Driver是AUFS，把存储驱动改成overlay2后，系统重启发现Docker daemon无法启动，查看状态提示是docker目录存在多个有效驱动，要求指定存储驱动。Error starting daemon: error initializing graphdriver: /data/docker contains several valid graphdrivers: aufs, overlay; Please cleanup or explicitly…

尝试删除Docker目录的aufs目录，结果提示rm: cannot remove ‘aufs’: Device or resource busy

2.原因

查找挂载目录，发现 cat /proc/mounts | grep "docker"，发现原来是aufs目录被挂载。

3.解决方法

卸载该目录， umount /var/lib/docker/aufs，问题解决。

懒癌发作，直到春节假期才下定决心把公司的基础架构都迁移到Docker上，随之而来的是一大堆应用重新部署及系统重构的工作。公司大量的应用是基于Oracle数据库构建，所以安装Oracle Database变成了首要任务。虽然安装配置数据库是小菜一碟，但是习惯了登录OTN网站下载安装文件然后照步骤安装，在Linux环境下碰到的第一个问题是在Console的环境下没有浏览器，而下载Oracle 数据库安装文件需要登录OTN网站并同意Oracle的License协议方能下载。

虽然可能利用cookies export这些工具来实现，但是习惯了使用最简单的方法解决问题，直接利用Firefox浏览器可以达到这个目的。在工作计算机上用Firefox登录OTN网站，同意协议后点击下载你所需的数据库安装文件，当下载开始后点击暂停下载，然后在下载任务上右键，选择复制下载链接。

然后登录到Linux终端，用Wget加上复制的链接就可以实现在Linux终端下载OTN文件。