“系统版本”和CUCM更新版本之间有什么关系？

Question

我正在编写代码，以验证从CUCM/CallManager检索的版本(例如7.1.5.34900-7)是否包含在特定修补程序/更新(例如7.1(5b)su6a)中找到的安全修复。考虑到这两个版本的格式不同，我很难找到足够的连接来构建我的逻辑。

我可以从CUCM检索到的版本之间是否存在严格的1到1的关系？“系统版本: 8.6.2.23900-10")以及公报中列出的版本(例如8.6.2SU3)？换句话说，会否有一个单一的“系统版本”会涉及多个"CUCM版本“，或相反的情况？在升级兼容性文档中，有一个将“系统版本”映射到"CUCM版本“的表，我一直在使用该表查找通信。

我读过这里，系统版本的格式是Major.Minor.Release.Build-InHouseBuild。本文还指出，对于非CUCM修补程序(即OS安全修补程序)，“构建”部分可以增加1,000。他们给出的例子(可能是真的，也可能不是真的)是6.1.2.2000和6.1.2.1112。声称后者包含CUCM补丁，而前者没有。当比较时，我是否需要忽略“千”数字？或者这不会发生在野生的CUCM安全更新？

Answer 1

思科做了一项出色的工作，掩盖了这些信息的某些原因。要回答你的具体问题：

1. 系统版本7.1.5.34900-7实际上是CUCM版本的7.1(5b)SU4。您需要下载系统版本7.1.5.35901-1或更高版本，以获得在CUCM版本7.1(5b)SU6a中找到的操作系统和应用程序修复。
2. 我不会说这两种格式之间总是存在1到1的关系(CUCM版本与系统版本)。然而，在我的经验中，当Cisco发布一个新的系统版本时，它们也会增加CUCM版本号。
3. 在较早版本的CUCM中，"OS补丁“和"CUCM补丁”之间的脱节程度要大得多，这将给您提供迈克尔·罗在您链接的页面中描述的差异。然而，最近几次(发布7.1天)，我从思科TAC收到的所有建议似乎表明，越多，越好，期间。

我遇到的唯一例外是未发布的“工程特殊”版本；通常只有TAC发布的特殊版本才能修复非常具体和不常见的bug。如果您使用的是“未发布的ES”版本，无论如何，您应该联系TAC以获得升级支持，因为可能存在与从该版本升级到正常的主线版本有关的无文档错误。

更长的答案是，我们可以利用你所链接的两个来源的信息来拼凑一张好图片。他们实际上是我的两个“去”地点来破解这些信息。

首先，根据您从罗迈克尔在加州大学角链接的页面，我们得到了思科如何构造CUCM/Unity /Presence/UCCX构建号的图片：

在每个子版本上，也有“版本号”。例如6.1.2.1000，6.1.2.2000等等。模数是最令人困惑的部分.一般来说，构建数量应该增加到1000，比如6.1.2.1000，6.1.2.2000等等。CUCM是建立在Linux操作系统上的。每当Cisco发布OS安全修补程序时，它们都会将版本号增加1000。这叫做PSIRT补丁。记住，CUCM是一个运行在Linux上的应用程序。OS修补程序不包含任何CUCM错误修复。任何错误修复都会出现在ES (工程专业)中。ES版本将由最后三位数(如6.1.2.1112)识别。

其次，从CUCM软件可编程序矩阵 PDF (来源于这里的思科支持文档)中，我们可以找到一个粗略的指南，说明什么是CUCM版本号与哪个系统版本号匹配。在我的经验中，这一直是一个准确的指南。

例如：

CUCM Version    |    System Version
-----------------------------------
9.1(1a)         |    9.1.1.20000-5
9.1(1)          |    9.1.1.10000-11
9.0(1)          |    9.0.1.10000-37
8.6(2a)SU3      |    8.6.2.23900-10
8.6(2a)SU2      |    8.6.2.22900-9