Oracle 19c RAC安装排雷：从INS-06006错误到RPM依赖的实战解决方案

1. 项目概述：一次典型的Oracle 19c RAC安装排雷实录

最近在给客户部署一套新的Oracle 19c RAC环境，本以为轻车熟路，没想到在安装Grid Infrastructure（GI）软件的第一步就栽了跟头，遇到了经典的“INS-06006”错误。这个错误提示“无法列出节点名”，看似简单，背后却牵扯到操作系统环境、软件包依赖和网络配置等一系列基础问题，尤其对于刚接触RAC或者在新版本操作系统上部署的朋友来说，很容易在这里卡住。更棘手的是，在解决这个问题的过程中，还连带暴露了“没找到rpm命令”以及一系列RPM包依赖的“连环坑”。今天，我就把这次踩坑和填坑的全过程，结合最新的CentOS/RHEL 7.9、Oracle Linux 8等环境，详细拆解一遍。无论你是正在部署19c RAC，还是未来可能遇到类似问题，这篇从实战中总结的排错指南，应该能帮你省下不少折腾的时间。

2. 问题深度解析：INS-06006错误的根源与表象

2.1 INS-06006错误的直接诱因

当你启动Oracle Grid Infrastructure安装向导（runInstaller），在“集群节点选择”环节，点击“添加”或直接下一步时，突然弹出一个错误对话框，核心信息就是“INS-06006: Passwordless SSH connectivity not set up between the following node(s)”。很多人的第一反应是去检查SSH互信，这没错，但这只是表象之一。实际上，INS-06006是一个比较笼统的错误码，它本质上是安装程序在尝试与远程节点通信并执行基础检查时失败了。失败的原因可能有好几个，SSH问题只是最常见的一种。

安装程序底层会调用ssh、scp等命令，并依赖/etc/hosts文件或DNS来解析节点名。如果节点名解析失败（比如主机名配置了域名，但/etc/hosts里只写了短名），或者SSH连接需要手动确认（首次连接时的known_hosts提示），甚至是目标节点上的bash环境变量有问题，都会触发这个错误。但根据我这次的经验以及近期社区的热议，在新版最小化安装的系统上，一个更隐蔽的根源是：目标节点上缺少必要的操作系统工具包，导致安装程序连最基本的“节点存在性验证”都无法完成。

2.2 隐藏的“元凶”：RPM命令缺失与包管理器环境

在排查SSH确认无误后，我通过查看安装日志（通常位于$ORACLE_BASE/cfgtoollogs下），发现了更具体的线索。日志显示，安装程序尝试在远程节点上执行rpm -q命令来查询某个基础包（如binutils）的版本时，返回了“命令未找到”或类似错误。这就是第二个热搜词“没找到rpm命令”的由来。

这听起来有点不可思议，rpm是Red Hat系Linux的基石，怎么会没有？但在以下两种场景中确实可能发生：

1. 极度精简的系统镜像：某些云平台或容器化的基础镜像为了追求极致小巧，可能只安装了dnf或yum（它们底层调用rpm），但没有将/usr/bin/rpm这个可执行文件包含在基础包rpm中？这听起来矛盾，实际上，rpm命令本身来自rpm这个包，而yum或dnf是另一个包。在最小安装时，有可能只安装了包管理器（dnf）的核心部分，而rpm命令行工具被意外省略（虽然罕见，但确有案例）。
2. 环境变量PATH被破坏：更常见的情况是，目标节点的PATH环境变量设置异常，导致安装程序通过SSH远程执行命令时，在/usr/bin或/bin目录下找不到rpm。这可能发生在自定义了全局环境变量的系统中。

一旦rpm命令无法执行，Oracle安装程序的一系列预检查就全部瘫痪了，因为它严重依赖rpm来验证系统包是否满足要求。于是，INS-06006就成了最终呈现给用户的结果。

2.3 连锁反应：操作系统RPM包依赖的深水区

解决了rpm命令问题，只是拿到了入场券。紧接着，你就会正式踏入Oracle RAC安装中最磨人的阶段：满足那一长串的操作系统RPM包依赖要求。Oracle 19c RAC对于Linux的包依赖要求非常严格，不仅要求包存在，还对最低版本有明确限制。这引出了搜索词中大量的“rpm 下载网站”、“openssh rpm”、“socat的rpm包”等需求。

对于CentOS/RHEL 7.9，主要依赖包括但不限于：binutils，compat-libcap1，compat-libstdc++-33，gcc，gcc-c++，glibc，glibc-devel，ksh，libaio，libaio-devel，libgcc，libstdc++，libstdc++-devel，libXi，libXtst，make，sysstat，elfutils-libelf-devel，fontconfig-devel，libXrender，libXrandr，libXinerama，libXcursor，libXau，libXft，libXpm，libXmu，libpng，libjpeg，libXaw，libX11，libXext，motif，openssh-clients等。其中ksh、compat-libstdc++-33、libX*系列图形包在最小化安装中很容易缺失。

而对于Oracle Linux 8或RHEL 8，包名有部分变化，例如某些compat-lib*包被新的版本替代，并且需要关注libnsl等包。如果系统是ARM架构（如飞腾），搜索“麒麟v10 飞腾版 openssh-10.3p1 rpm 升级包”这类词条，说明在国产化替代环境中，寻找架构兼容的RPM包更是难上加难，官方仓库可能不提供，需要从可信的第三方或厂商处获取。

注意：切勿随意从不明网站下载RPM包！这可能导致系统被植入恶意软件或出现不兼容问题。应优先使用操作系统自带的官方仓库（如CentOS的Base、EPEL）、Oracle的ULN或Yum服务器，或像repo.mysql.com（用于mysql数据库rpm安装）这样的知名软件供应商仓库。

3. 系统性解决方案与实操步骤

3.1 第一阶段：诊断与修复基础通信环境

在开始安装之前，我们必须确保所有节点处于一个“可被安装程序正常探测”的状态。

步骤1：验证节点名解析（至关重要）这是导致INS-06006的高频原因。在所有集群节点上，检查/etc/hosts文件。必须确保每个节点的公有主机名（public hostname）、私有主机名（private hostname）和虚拟主机名（VIP hostname）都能被正确解析。

• 错误示例：在/etc/hosts里只写了192.168.1.10 rac1，但你的节点实际配置的主机名是rac1.example.com。
• 正确做法：在/etc/hosts中，为每个IP地址同时配置短名和全限定域名（FQDN）。例如：

  192.168.1.10 rac1 rac1.example.com 192.168.1.11 rac2 rac2.example.com 192.168.1.20 rac1-priv rac1-priv.example.com 192.168.1.21 rac2-priv rac2-priv.example.com 192.168.1.30 rac1-vip rac1-vip.example.com 192.168.1.31 rac2-vip rac2-vip.example.com

  使用hostname和hostname -f命令分别查看短名和FQDN，确保它们都能ping通。

步骤2：建立彻底的SSH互信不要仅仅满足于能免密登录。使用Oracle提供的sshUserSetup.sh脚本或手动建立互信时，务必包含所有类型的主机名（短名、FQDN、私有IP对应主机名）。

1. 在所有节点上为oracle和grid用户生成密钥：ssh-keygen -t rsa。
2. 将所有节点的公钥（id_rsa.pub）内容汇总，追加到每个节点每个用户的~/.ssh/authorized_keys文件中。
3. 执行彻底的连通性测试：ssh rac1 date，ssh rac1.example.com date，ssh rac1-priv date。确保每一个命令都不需要输入密码且没有首次连接提示。

步骤3：检查并修复rpm命令问题

1. 诊断：从一个节点SSH到另一个节点，直接执行which rpm和rpm --version。

   ssh rac2 'which rpm && rpm --version'

   如果返回/usr/bin/which: no rpm in (...)或bash: rpm: command not found，则证实了问题。
2. 修复：
   • 如果rpm包确实未安装（极罕见）：连接到该问题节点，使用yum或dnf安装它。因为yum本身可能依赖rpm，所以可能需要通过rpm命令从安装介质手动安装rpm包，形成“鸡生蛋”的循环。更实际的方法是，如果系统是克隆出来的，检查源镜像是否完整；如果是云主机，考虑重置或选择更标准的基础镜像。
   • 如果rpm存在但PATH问题：检查目标节点上/etc/profile、~/.bash_profile等文件，确保PATH变量包含了/usr/bin。一个稳妥的方法是在grid和oracle用户的~/.bash_profile中显式导出PATH：export PATH=$PATH:/usr/bin:/bin。然后务必通过SSH执行一个交互式命令来触发环境变量重新加载，例如：ssh rac2 'source ~/.bash_profile; which rpm'。

3.2 第二阶段：一站式解决RPM包依赖

解决了通信问题，我们就可以集中火力攻克包依赖。我推荐一个高效且可靠的方法，而不是手动一个个去找。

步骤1：使用Oracle官方预安装脚本（最推荐）Oracle提供了名为rpm的预安装检查脚本，但它更强大的功能是能生成一份缺失包的详细报告和修复脚本。

1. 从Oracle 19c Grid安装介质中，找到runcluvfy.sh脚本。但更直接的是使用gridSetup.sh的-executePrereqs参数。
2. 在任意节点，以grid用户身份运行：

   cd /path/to/grid_software ./gridSetup.sh -executePrereqs -silent -responseFile /path/to/response_file.rsp

   如果没有响应文件，可以临时运行检查（虽然可能会提示缺少响应文件，但有时会先进行一部分检查）。更好的方式是先运行集群验证工具：

   ./runcluvfy.sh stage -pre crsinst -n rac1,rac2 -verbose

3. 仔细阅读输出日志。它会明确列出每个节点上缺失的包、版本不满足的包。这是你解决问题的权威清单。

步骤2：配置本地Yum/DNF仓库并批量安装手动下载单个RPM包是下策。我们应该配置一个包含所有依赖的本地仓库。

1. 挂载操作系统ISO镜像：将CentOS/RHEL的完整安装ISO挂载到所有节点，例如/mnt/iso。
2. 创建本地仓库文件：

   # 在所有节点上操作 sudo mkdir -p /media/localrepo sudo mount -o loop /path/to/CentOS-7-x86_64-Everything.iso /media/localrepo # 创建repo文件 sudo cat > /etc/yum.repos.d/local.repo << EOF [local] name=Local Repository baseurl=file:///media/localrepo enabled=1 gpgcheck=0 EOF

3. 安装缺失的包组：根据runcluvfy输出的清单，使用yum groupinstall和单独安装结合。

   # 安装常用的开发工具和兼容库组 sudo yum groupinstall -y "Development Tools" sudo yum install -y compat-libstdc++-33 libaio-devel ksh elfutils-libelf-devel fontconfig-devel libXrender-devel libXrandr-devel libXinerama-devel libXcursor-devel libXtst-devel libXi-devel # 对于图形化安装（如果需要在服务器上运行OUI），还需要 sudo yum install -y xorg-x11-utils xorg-x11-xauth xorg-x11-server-utils

   针对compat-libcap1：这个包在CentOS 7的默认仓库中可能叫compat-libcap1，也可能需要从较旧的版本或EPEL仓库中寻找。如果找不到，有时可以忽略，因为更高版本的libcap可能已满足要求，但这需要根据具体错误判断。

步骤3：处理特殊包与架构适配对于像“麒麟v10 飞腾版”这样的ARM架构环境，通用仓库不适用。

1. 寻找可信源：联系操作系统厂商（麒麟软件），获取对应的ARM架构软件仓库源（.repo文件）或离线仓库包。
2. 手动编译：作为最后的手段，对于极少数在ARM仓库中也没有的包（如特定版本的compat-libstdc++-33），可以考虑在相同架构的机器上下载源码包（SRPM）进行编译。但这需要较强的技术能力。
3. 使用Oracle Linux：如果条件允许，在ARM服务器上直接安装Oracle Linux for ARM版本，其预配置的Unbreakable Linux Network (ULN)仓库能提供最好的兼容性。

实操心得：在开始安装Grid之前，我习惯在所有节点上手动执行一遍yum install oracle-database-preinstall-19c。这个RPM包是Oracle为单实例数据库提供的，但它会安装大量共通的依赖包（如binutils，gcc，libaio等），能为RAC安装扫清大约70%的包障碍。虽然它不包含RAC特定的高可用性包，但作为基础准备非常有效。

4. 安装过程中的问题排查与现场调试

即使准备工作万无一失，安装过程中仍可能遇到变数。掌握现场调试方法至关重要。

4.1 实时日志监控

不要只盯着安装程序的图形界面进度条。打开多个终端，实时跟踪关键日志：

• 全局安装日志：$ORACLE_BASE/cfgtoollogs/gridSetup/下的时间戳目录，查看gridSetupActions*.log。
• 特定操作日志：在安装的每个阶段，OUI会在/tmp下生成OraInstall*目录，里面的日志更详细。
• 集群验证日志：$GRID_HOME/cfgtoollogs/cluvfy/下的日志。

当出现错误时，第一时间去这些日志里搜索ERROR、CRS-、INS-等关键字。INS-06006的详细原因通常会在这些日志中暴露无遗，比如会显示它具体在执行哪个远程命令时失败。

4.2 手动模拟安装程序检查

如果你怀疑是某个特定检查点失败，可以手动模拟安装程序的行为。例如，针对节点通信：

# 以grid用户，从节点1执行，检查节点2 ssh rac2 "/usr/bin/rpm -q --queryformat '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' binutils" # 检查内核参数 ssh rac2 "sysctl -n kernel.sem" # 检查用户限制 ssh rac2 "ulimit -Hn && ulimit -Sn"

通过手动执行，你能立刻看到具体的错误输出，是“包未安装”还是“权限被拒绝”，抑或是“命令未找到”。

4.3 应对图形安装界面问题

如果因为缺少libX*包导致安装界面无法启动（与“chrome rpm安装包”搜索类似，都是GUI软件依赖），而你又在纯字符界面的服务器上，有两条路：

1. 安装必要的X11库：如上文所述，安装xorg-x11-xauth等包，然后通过SSH X11 Forwarding从本地有图形界面的电脑启动安装程序。使用ssh -X grid@rac1登录，再运行./gridSetup.sh。
2. 采用静默安装：这是生产环境最主流、最可靠的方式。先在一个测试环境通过图形界面生成响应文件（-saveResponseFile），然后仔细修改这个响应文件，最后在所有生产节点上使用-silent -responseFile参数进行安装。这完全避免了图形界面的依赖问题。

5. 常见问题速查与终极清单

以下是我将多次实战中遇到的问题浓缩成的速查表，你可以像查字典一样使用它：

最后再分享一个小技巧：在开始漫长的Grid安装之前，不妨先花点时间，在所有节点上运行Oracle的集群验证工具（CLUVFY）的完整预检查。虽然它可能报告一些警告（如时间同步偏差几秒），但对于错误（ERROR），必须一个不漏地解决。把它当作一次严格的“入学考试”，通过之后，正式的安装过程往往会顺利得多。毕竟，在RAC的世界里，前期一分的细致准备，能避免后期十分痛苦的排错。