☰

无需修补/安装即可确定本地 AIX 存储库的完整操作系统级别（包括构建日期）

tag-icon • tag-icon aix
无需修补/安装即可确定本地 AIX 存储库的完整操作系统级别（包括构建日期）

在我们的环境中，只有一台 AIX 服务器被允许通过防火墙访问互联网。在这台服务器上，我使用 suma 下载我们环境中所有基础级别、技术级别和服务包的所有修复程序；每天都会进行此操作。每月一次，我将每个基础级别的所有修复程序复制到一个文件夹中，并创建inutoc几个冻结的存储库，可用于修补我们所有的 AIX 服务器。这样，我们就可以确保所有服务器都处于相同的操作系统级别。我们称之为“每月补丁集”。

我们有一个 CSV 文件，其中列出了所有 UNIX/Linux 操作系统版本的每个“月度补丁集”的所有内核版本。我们的修补/验证脚本会使用该 CSV 文件。对于 Linux/Solaris，我发现了一些“技巧”，可以从存储库文件本身确定内核版本，但在 AIX 上，如果不实际用它修补服务器，我就无法确定操作系统级别。修补后，我可以运行“oslevel -s”来确定操作系统级别，但为时已晚，因为我们的修补脚本在开始实际修补之前使用/需要操作系统级别。

有人知道实现此目的的技巧吗？到目前为止，我已尝试了以下方法：

  • 我们的存储库文件夹包含许多 *.bff 文件，它们是二进制文件，因此在这些文件中我找不到 oslevel
  • *.bff 文件名大部分是“U”，后面跟着一些数字和“.bff”（因此不能用于确定操作系统级别）。但有些文件名实际上确实包含（部分）操作系统级别。例如：7200-01-06.bff 7200-02-01-1732.bff 7200-02-06.bff 7200-03-06.bff 7200-03.bff 7200-04-01.bff 7200-04-02.bff 7200-04-03.bff 7200-04.bff 7200-05-01.bff 7200-05-02.bff 7200-05.bff。但是，正如您所见，从最新的操作系统级别来看，文件名中缺少“构建日期”部分。
  • 我们使用install_all_updates -Y -d <path_to_repo>命令进行修补。我尝试使用install_all_updates -p -d <path_to_repo>，希望它会在输出中的某个地方可见，但事实并非如此。
  • 我也尝试过installp -[lL] -d <path_to_repo>，但是那里的 oslevel 也不可见。

我希望有人能帮助我。

编辑如下（作为对@Jeff Schaller 的回答的回应）

感谢你的帮助。

它非常接近匹配，但恐怕不完全匹配......

--> installp -L -d /nim/export/repos/AIX/AIX7200_OS-Vendor_Repo_20200511 | grep :bos\.rte\.install: | sort -t: -k17n | tail -1 | awk -F: '{print $3, $17}'
7.2.4.2 1937
root@servername /nim/export
--> oslevel -s
7200-04-01-1939
root@servername /nim/export

但不确定为什么...有什么想法吗？

更多详情：

--> installp -L -d /nim/export/repos/AIX/AIX7200_OS-Vendor_Repo_20200511 | grep 1937 | wc -l
     613
root@servername /nim/export
--> installp -L -d /nim/export/repos/AIX/AIX7200_OS-Vendor_Repo_20200511 | grep 1939 | wc -l
       0
root@servername /nim/export
-->

所以我认为一定安装了某个软件包，其构建日期为 1939，导致 'oslevel-s' 显示该构建日期。因此我运行以下命令来查找此软件包：

--> lslpp -Lc all | awk -F':' '{print $2" "$3" "$18}' | grep 1937 | wc -l
     288
root@servername /nim/export/repos/AIX/AIX7200_OS-Vendor_Repo_20200511
--> lslpp -Lc all | awk -F':' '{print $2" "$3" "$18}' | grep 1939 | wc -l
       0
root@servername /nim/export/repos/AIX/AIX7200_OS-Vendor_Repo_20200511
--> oslevel -s
7200-04-01-1939
root@servername /nim/export/repos/AIX/AIX7200_OS-Vendor_Repo_20200511
-->

正如你所见，我无法找到这个包... :(

编辑 #2 如下（作为对 @Jeff Schaller 的评论的回应）

root@servername /
--> instfix -ic | grep 7200-04 | grep :-:
root@servername /

恐怕那什么也没发生。

另外，我不确定您说的“... 服务器比预期的 oslevel 低级...”到底是什么意思。难道不是相反的吗？'oslevel -s' 返回 1939 年作为构建日期，而所有软件包都表明构建日期应为 1937 年。那么，这难道不是“高级”吗？

答案1

一个可能有用的步骤是使用bffcreate命令将这些 bff 文件名转换为基于包的文件名。类似于bffcreate -c -d /path/to/repo。

不过，要回答这个问题，一旦你运行inutoc要创建 .toc 文件，你可以询问installp以冒号分隔的输出形式列出该 repo 的 TOC 文件的内容，其中包括字段 17 中的构建日期。bos.rte.install 包将属于具有最新构建日期的包，因此您可以搜索该包并提取其 VRMF（版本、发布、修改、修复）和构建日期：

sudo installp -L -d /path/to/repo | grep :bos\.rte\.install: | sort -t: -k17n | tail -1 | awk -F: '{print $3, $17}'

这将输出该存储库中 bos.rte.install 包的最新版本的 VRMF 和构建日期。awk如果您只对其中一个字段感兴趣，请调整打印语句。版本号采用 YYww 格式（2 位数年份，2 位数年份周数）。bos.rte.install 的 VRMF 将与 的输出大致对应oslevel；您或许可以依赖前三个字段来匹配oslevel -r输出；例如，7.2.4.6 的 VRMF 与 7200-04 的 oslevel 相关，7.2.4.2 的 VRMF 也是如此 - 初始的 7.2 给出“7200”部分，而 4 给出“-04”部分。

答案2

最后，这是我实现的解决方案（它确实为我提供了正确的完整操作系统级别）：

创建仓库

  1. 将所有包作为 *.bff 复制到 ${REPO_SNAPSHOT_PATH} 中
  2. 重新创建.toc 文件：rm -f "${REPO_SNAPSHOT_PATH}.toc" 2>&1 ; cd "${REPO_SNAPSHOT_PATH}" ; inutoc .
  3. 清理仓库：/usr/lib/instl/lppmgr -rubxVd "${REPO_SNAPSHOT_PATH}"
  4. 将 bff 文件重命名为可理解的包名称：bffcreate -c -d "${REPO_SNAPSHOT_PATH}"
  5. 再次重新创建.toc 文件：rm -f "${REPO_SNAPSHOT_PATH}.toc" 2>&1 ; cd "${REPO_SNAPSHOT_PATH}" ; inutoc .

了解完整的操作系统级别

  1. 从 repo 创建 LPP 源：nim -o define -t lpp_source -a server=master -a location="${REPO_SNAPSHOT_PATH}" "${LPP_SOURCE_NAME}"
  2. 从此 LPP 源创建 Spot：nim -o define -t spot -a source="${LPP_SOURCE_NAME}" -a server=master -a location="${SPOT_PATH}" "${SPOT_NAME}"
  3. 从此 Spot 获取完整的 oslevel：FULL_OSLEVEL="$(lsnim -l ${SPOT_NAME} 2>/dev/null | awk '$1=="oslevel_s" {print $3}')"

相关内容