CN101211312A - 用于监控和管理客户端上的补丁的设备和方法 - Google Patents

Abstract

本发明涉及用于监控和管理客户端上的补丁的设备和方法，提供了一种用以评估补丁级别并在若干不同UNIX机器类型上应用补丁的自动化工具。该工具包括两个部分：服务器组件和客户端组件。服务器组件收集由客户端报告的数据，从数据库收集包括补丁数据的数据，下载供应商补丁并估计兼容性，并且向每个客户端发送将要根据需要而安装的补丁的列表。客户端组件收集机器数据并将其发送到服务器组件，从服务器组件接收将要安装的补丁的列表，并且下载和安装所列出的补丁。

Description

用于监控和管理客户端上的补丁的设备和方法

技术领域

本发明一般地涉及软件分析工具，并且更特别地涉及对用于洞察某些形式的软件故障的运行时分析工具的改进。

背景技术

在计算中，补丁是设计为更新或补救计算机程序所存在的问题的一小段软件。这包括修补漏洞，替换图形，以及改善可用性或性能。尽管其本意在于补救问题，但设计得不好的补丁有时可能会引入新的问题(又称软件退化(software regression))。

补丁管理是在特定的时间使用关于哪些补丁应当被应用到哪些系统的策略和计划的过程。

然而，没有用以确定很多UNIX机器是否已经被打上了符合兼容性标准的补丁的常用方法。也没有用以自动地对多个UNIX机器打上补丁的一组常用命令和工具。每个UNIX操作系统类型(Solaris，HP-UX，AIX，RedHat Linux，SuSE Linux)都具有用以估计补丁信息、补丁历史的不同方法和用以安装补丁的不同方法。这使得维持与安全标准的兼容性成为复杂和工作强度很大的任务并且需要针对每种机器类型的专门知识。

利用当前的技术，为UNIX系统打补丁是不具有兼容性且很容易出错的手工过程。图1图示了当前所使用的手工过程。在102处，释放新的APAR。APAR(授权程序分析报告)是对纠正缺陷的请求。在本申请中，APAR是一个补丁。在104处，确定APAR是否适用于该系统。如果APAR不适用于该系统，则在106处，关闭APAR。如果APAR适用于该系统，则在108处，搜索和下载APAR，在110处，安装APAR，并且在106处，关闭APAR。对打补丁进行监控和管理是很耗费时间的过程。

鉴于上述内容，需要通过提供一种用于监控和管理补丁过程的系统和方法来克服这些问题。

发明内容

本发明提供了一种用以确定机器是否打上了补丁并自动地根据需要应用补丁的常用框架。本发明提供了一种用以评估补丁级别并在若干不同UNIX机器类型上应用补丁的自动化工具。本发明提供了很多优点。使用这一自动化工具可以节省不必要的机器维护和重启成本。本发明针对用户的机器而遍历供应商的所有可能的兼容性补丁解决方案的列表，并确定用户的机器是否已经包含可使其一致的任何补丁。这一关键优化使得管理员不再需要对可能的成千上万个补丁描述进行全部搜索。或者更坏的情况是，关闭机器并且不必要地应用补丁。

此外，本发明节省了雇佣系统管理员来管理一组给定的UNIX机器的成本并控制资产兼容性。另外，本发明提供了一种集中式兼容性方法，其在自动地管理大量机器的同时，向组织中的多个角色提供补丁。本发明可以管理多种安全标准、机器类别和补丁安全级别，并且可以被定制为与现有的资产管理工具进行接口连接。本发明估计最合适的补丁以满足最低补丁要求，并且是将告知用户该用户的机器何时将无法保持兼容性的早期警告系统。该工具包括两个部分，即服务器组件和客户端组件。服务器收集由客户端机器报告的数据并将其存储在数据库中；从包括内部数据库和供应商网站在内的其它数据库收集补丁、机器数据和所有者数据；将供应商补丁下载到库区域(depot area)；并且估计兼容性并生成现在缺少的且将在以后应用的补丁以及满足要求的补丁的列表。针对每个机器计算总体兼容性判断。服务器向客户端发送将要根据需要而安装的补丁的列表。服务器从客户端接收安装状态，将其报告到网络上，并向用户发送邮件。客户端收集机器数据并将其发送到服务器；查询服务器以查看是否需要补丁，并接收补丁列表。客户端从APAR库下载补丁；并且安装补丁并将状态报告回服务器。

本发明的示例性方面设计为解决在此描述的一个或多个问题和/或未讨论的一个或多个其它问题。

附图说明

根据以下参考附图对本发明各方面的详细描述，本发明的这些和其它特征将变得更容易理解，附图描述了本发明的各实施例，其中：

图1是对现有技术的补丁管理方法的描述。

图2是对本发明的组件流程图的描述。

图3是对本发明的补丁过程图的描述。

应当注意，附图并不是按比例绘制的。附图仅仅旨在描述本发明的典型方面，因此不应当被视为对本发明范围的限制。在附图中，各图之间相同的标号代表相同的单元。

具体实施方式

除非另有说明，否则在此所用的术语“组”的意思是一个或多个(即至少一个)并且短语“任意解决方案”的意思是任意现在已知或以后开发的解决方案。此外，术语“数据存储器”(data store)的意思是任意类型的存储器、存储设备、存储系统等，其能够临时地或持久地存储电子数据，并且其能够被包括在用于计算机系统的存储装置和/或存储器的层级结构(在此统称为“存储器层级结构”)中。

该工具包括两个部分，即服务器组件和客户端组件。

服务器功能性概览

·服务器收集由客户端机器报告的数据并将其存储在数据库中(图2，步骤4)。

·服务器从包括内部数据库和供应商网站在内的其它数据库收集补丁、机器数据和所有者数据(图2，步骤1；图3，步骤312)。

·服务器将供应商补丁下载到库区域(图2，步骤2、2A；图3，步骤318)。

·服务器估计兼容性并生成现在缺少的且将在以后应用的补丁以及满足要求的补丁的列表。针对每个机器计算总体兼容性判断(图3，步骤324、326)。

·服务器提供web界面，以供用户规定如何更新他们的机器并得到通知(图2，方框212)。

·服务器向客户端发送将要根据需要而安装的补丁的列表(图2，步骤5；图3，步骤336)。

·服务器从客户端接收安装状态，将其报告到网络上，并向用户发送邮件(图2，步骤7、8；图3，步骤344、348)。

客户端功能性概览

·客户端收集机器数据并将其发送到服务器。这包括操作系统名称、版本、主机名称、IP地址、MAC地址、正常运行时间、补丁或补丁包名称、补丁版本以及安装日期(图2，步骤4；图3，步骤332、330)。

·客户端查询服务器以查看是否需要补丁，并接收补丁列表(图2，步骤5；图3，步骤338、340)。

·客户端从APAR库下载补丁(图2，步骤6；图3，步骤346)。

·客户端安装补丁并将状态报告回服务器(图2，步骤7；图3，步骤346)。

·这些任务作为安排好的日常事件而运行(图3，步骤312)。

图2示出了组件数据工作流程。来自GSSD 210的XML APAR列表将“获得兼容性所需的APAR”请求1传递给APARXML DB服务器web服务器206(“XML”即“可扩展标记语言”文件格式，包含APAR信息。“GSSD”即全局安全服务递送网站)。包括有本地APAR库208的APARXML DB服务器web服务器206将“获得兼容性所需的APAR”请求2和2a传递给供应商网站和APAR库214。来自其它数据库CEP和Labdb的机器元数据202将“获得元数据”请求3传递给APARXML DB服务器web服务器206。“CEP”即计算设备简档，是一种安全管理工具，而“Labdb”即Lab资产管理工具。客户端机器204将机器和APAR数据4传递给APARXML DB服务器web服务器206。客户端机器204将“针对我的APAR？”请求和“获得所需的APAR列表”命令5传递给APARXML DB服务器web服务器206。APARXML DB服务器web服务器206在6处将APAR下载并安装到客户端机器。客户端机器204在7处发送“APAR安装结果”和“获得供应商APAR元数据”。Web浏览器用户界面和电子邮件通知212将“针对机器的APAR安装控制和报告”8传递给APARXML DB服务器web服务器206。

图3示出了补丁过程。过程300分为服务器侧302和客户端侧304。从服务器侧开始，在306处，服务器确定在GSSD处以XML数据文件发布了新APAR。在308处，服务器确定APAR是否是新的，如果APAR不是新的，则在310处，夜间工作结束。如果APAR是新的，则在312处，服务器在夜间下载APAR XML数据。在314处，服务器确定新APAR是否需要下载到本地存储装置。如果新APAR不需要下载到本地存储装置，则在322处，不采取任何措施。如果新APAR需要下载到本地存储装置，则在316处，服务器确定其是否是过时的APAR。如果新APAR不是过时的APAR，则在318处，服务器从不同供应商的网站下载APAR。如果新APAR是过时的APAR，则在320处，服务器使用mythology来确定新补丁。(下面将进一步讨论这一点。)

在客户端侧304上，在334处，新客户端遍历所安装的APARXML客户端软件段。在332处，客户端在本地运行脚本以收集补丁信息和系统配置，并且在330处，将所收集的补丁信息和系统配置发送到服务器处的配置数据库。在328处，服务器收集针对客户端的安全信息。在326处，服务器将来自XML文件的数据和来自客户端的数据进行比较，以确定需要安装哪个补丁。在324处，服务器确定客户端上是否缺少任何APAR，并且如果客户端上不缺少任何APAR，则在322处，不采取任何措施。如果客户端上缺少任何APAR，则在336处，服务器发送通知(每周一次)到客户端并更新列出所缺少的补丁和截止日期的网页。在338处，客户端检查其是否缺少任何APAR，并且如果其不缺少任何APAR，则过程在342结束。如果其缺少任何APAR，则在341处，服务器确定是否启用了自动安装，并且如果没有启动自动安装，则在344处，服务器通知用户并更新网络。如果启动了自动安装，则在346处，客户端下载并安装APAR。在348处，服务器从客户端确定安装是否成功，并且如果安装不成功，则服务器通知用户并更新网络。如果安装成功，则服务器确定APAR是否需要重启。如果APAR需要重启，则在346处，服务器通知用户并更新网络。如果APAR不需要重启，则在352处，服务器更新网络。

对实现方式的详细描述

步骤1：

系统的第一个要求是获得所需补丁或补丁包(称为APAR)的列表。这在图2步骤4和图3步骤306、308、312中示出。这一信息是从一组XML文件(一个文件针对一个平台)获得的，这些XML文件是从服务器下载的。对于某些平台，XML文件提供了补丁号。对于其它平台，XML文件提供了所需的补丁包名称和补丁包版本。APAR的严重性和APAR的发行日期也包括在XML文件中。这一信息被解析并输入到数据库中。

为了正确地确定哪些补丁满足特定要求，有必要收集关于补丁历史的数据。也就是说，主服务器必须知道已经发行的取代所需补丁的所有补丁以及其发行顺序。计算这一信息的方法针对每个平台而不同。

RedHat和SuSE具有补丁包版本编号方案，其中版本号被隔开，即首先用小短线(-)，然后用英文句号(.)，最后用字母(a-z)。使用这一层级结构来对版本号进行比较，版本号大于或等于所需版本的任何补丁包都满足要求。

AIX具有更简单的版本编号方案。版本号简单地被英文句号(.)隔开。使用这一细目分类来对版本号进行比较，同样，版本号大于或等于所需版本的任何补丁包都满足要求。

Sun公司的补丁由6位数字后接小短线再后接2位修订号来标识。可以通过对修订号进行比较来简单地对具有相同的6位标识号的补丁进行比较。如果补丁标识号相同并且所安装的修订号大于所需修订号，则补丁满足要求。然而，存在如下情况，其中补丁被具有完全不同的6位标识号的另一补丁取代。在此情况下，由于不能仅仅基于补丁号来确定关系，因此该工具从Sun公司的补丁信息网站检索信息。当查找关于特定补丁的信息时，会提供关于补丁当前状态的信息(是有效的还是过时的)，并且如果补丁是过时的，则列出一致(in line)的下一个补丁。从所需补丁到最佳补丁的补丁链是简单地通过沿循Sun公司网站上的信息从一个补丁到下一个补丁而构造的。

HP公司(惠普公司)的补丁由一组4个字母后接一个下划线(-)再后接一个5位的数字来标识。由HP公司分配给补丁的补丁号不包含关于一个补丁取代另一个补丁的信息。所有这种信息必须从HP公司网站上收集。然而，与Sun公司不同的是，HP公司提供了关于过时补丁的信息。当在HP公司网站上请求关于补丁的信息时，会列出最佳补丁以及被这一补丁取代的一组补丁(不按照特定顺序排列)。没有关于哪些补丁落在最佳补丁与被查询的补丁之间的信息(这是所需的信息)。然而，可以使用以下算法来重新构造所需补丁与最佳补丁之间的补丁链。

预调节：

·机器上要求补丁p

·定义关于补丁x的函数S，其中S(x)等于被补丁x取代的补丁的集合。这一信息可在HP公司网站上获得。

·定义关于补丁x的函数B(x)，其中B(x)等于取代x的最佳补丁。这一信息可在HP公司网站上获得。

算法：

·令补丁b等于B(p)

·定义一个集合D＝S(p)+{p}。这些都是不会落在补丁p与补丁b之间的补丁。

·定义一个集合C＝S(b)-D。这是可能落在补丁p与补丁b之间的候选的集合。

·对于C中的所有c，令D＝D+{c}，其中S(c)不包含p。

·令C＝C-D。集合C现在仅包含落在补丁p与补丁b之间的补丁。现在必须确定这些补丁的顺序。

·对于C中的所有c，定义关联阵列A，其中A[c]＝S(c)-D。

·以A[c]中元素编号的升序对阵列A的索引进行排序，并将结果存储在有序集合R中。

后调节：

·从所需补丁到最佳补丁的补丁链等于：补丁p，后面按顺序接有集合R的元素，再后接补丁b。

某些按照要求是从Sun公司和HP公司的网站收集的。例如，某些补丁要求在安装之后重启，而另外一些补丁要求重新配置服务。这一信息还被捕获并存储在数据库中。

步骤2a

使用在步骤2中收集的信息，可以生成可能不需要安装在机器上的补丁或补丁包的列表。使用这一列表，可以自动地从供应商网站检索这些补丁并存储在本地补丁库中。在自动化安装期间，客户端可以从本地库中而不是供应商网站取回它们的补丁，这减少了外部因特网业务量费用。

步骤3

报告要求服务器能够将机器与它们的所有者相关联。服务器还需要知道每个机器的安全等级，以便确定要求哪些APAR以及这些APAR在机器上何时到期。这一信息是从已经存储了这一信息的另一数据库(CEP)收集的。

步骤4

客户端配置为每天都将它们的状态报告给服务器。每个机器运行用以收集关于该机器配置的信息的脚本。一些所收集的信息包括所安装的补丁或补丁包、操作系统、主机名称、IP地址、MAC地址以及正常运行时间。将这一信息以及机器上所存储的唯一客户端ID发送到服务器。如果该唯一客户端ID不存在，则服务器知道这是一个来报到的新机器，并且服务器向该客户端分配一个唯一ID。服务器用这一唯一ID来确定它是否应当利用它所接收到的信息来创建新记录或者它是否应当更新现有记录。

在服务器从客户端接收到状态报告之后，服务器重新计算机器上需要哪些APAR以及这些APAR何时到期。这是基于机器的操作系统、安全等级和体系结构来计算的。使用在步骤2期间收集的补丁信息，确定在机器上安装的任意补丁或补丁包是否满足所需的APAR。使用这一信息，服务器能够生成关于哪些APAR得到满足、它们何时得到满足以及被哪一补丁或补丁包满足的报告。服务器还能够生成现在缺少的且需要安装的APAR的列表。

步骤5

客户端还配置为每天都查询服务器并询问是否有任何应当自动安装的补丁。基于针对该特定机器的所缺少的APAR和用户的首选项(见步骤8)，服务器生成应当自动安装的补丁和补丁包的列表。然后，将这一列表发回客户端。

步骤6

给定应当自动安装的补丁和补丁包的列表，客户端自动地从服务器上的APAR库检索针对这些补丁和补丁包的文件。在检索到这些文件之后，客户端自动地安装每个所需补丁和补丁包。在整个过程中，客户端跟踪每个补丁和补丁包安装的状态。

步骤7

然后，将安装结果报告到服务器中。对于每个补丁和补丁包，客户端可以向服务器报告回下述内容：

·成功-补丁和补丁包安装成功

·失败-补丁和补丁包安装失败

·不适用-补丁和补丁包不适用于该系统

由于包括了每个状态的细节，因此所有者能够处理自动化安装中可能发生的任何问题。服务器记录安装状态并准备将要发送到机器所有者的报告。

步骤8

用户可以设置电子邮件首选项：

·向我发送关于每周状态报告的电子邮件

·当我的补丁还有不到15天就到期时，向我发送电子邮件

对于每个机器，机器所有者具有4个选项来表明在其机器上自动安装哪些内容：

·自动地安装所有缺少的补丁(即使对于这一安全等级来说并不需要这些补丁)

·自动地安装所有所需的补丁

·仅自动地安装我在界面上做了标记的那些补丁

·从不进行自动安装

从前述内容中可以看出，需要克服监控和管理补丁过程的问题，并且本发明的系统和方法解决了这些问题。

已经出于说明和描述的目的提出了对本发明各方面的前述描述。其并非旨在穷举或将本发明限制为所公开的精确形式，并且显然可以进行很多修改和变更。这些修改和变更对于本领域技术人员来说是很明显的，并且包括在由所述权利要求所限定的本发明范围内。

Claims (20)

1.一种用于系统中的工具，所述系统具有至少一个服务器、至少一个客户端、以及诸如内部数据库和供应商网站的数据库，所述数据库具有供应商补丁，所述工具用于监控并管理客户端上的补丁以确定客户端是否打上了补丁并自动地根据需要应用补丁，所述工具包括：

位于所述服务器上的服务器组件；以及

位于所述客户端上的客户端组件，

所述服务器组件收集由客户端报告的数据，从所述数据库收集包括补丁数据的数据，下载供应商补丁并估计兼容性，并且向每个客户端发送将要根据需要而安装的补丁的列表，

所述客户端组件收集机器数据并将其发送到服务器组件，从所述服务器组件接收将要安装的补丁的列表，并且下载和安装所列出的补丁。

2.根据权利要求1所述的工具，其中所述客户端组件查询所述服务器组件以查看是否需要补丁。

3.根据权利要求1所述的工具，其中所述数据库数据还包括机器数据和所有者数据。

4.根据权利要求1所述的工具，其中所述服务器组件将供应商补丁下载到库区域，并且所述客户端组件从库区域下载供应商补丁。

5.根据权利要求1所述的工具，其中所述客户端组件发送安装状态且所述服务器组件接收安装状态，并且所述服务器组件将安装状态报告到网络上并向用户发送具有安装状态的邮件。

6.根据权利要求1所述的工具，其中所述服务器组件估计最合适的补丁以满足最低补丁要求。

7.根据权利要求6所述的工具，其中所述服务器组件向用户提供关于该用户的机器何时将无法保持兼容性的早期警告。

8.一种用于在系统中操作的方法，所述系统具有至少一个服务器、至少一个客户端、以及诸如内部数据库和供应商网站的数据库，所述数据库具有供应商补丁，所述方法用于监控并管理客户端上的补丁以确定客户端是否打上了补丁并自动地根据需要应用补丁，所述方法包括步骤：

在服务器处：

收集由客户端报告的数据；

从所述数据库收集包括补丁数据的数据；

下载供应商补丁并估计兼容性；并且

向每个客户端发送将要根据需要而安装的补丁的列表；

在每个客户端处：

收集机器数据并将其发送到服务器；

从所述服务器接收将要安装的补丁的列表；并且

下载和安装所列出的补丁。

9.根据权利要求8所述的方法，还包括在每个客户端处查询所述服务器以查看是否需要补丁的步骤。

10.根据权利要求8所述的方法，其中所述数据库数据还包括机器数据和所有者数据。

11.根据权利要求8所述的方法，还包括在所述服务器处将供应商补丁下载到库区域的步骤，以及在所述客户端处从库区域下载供应商补丁的步骤。

12.根据权利要求8所述的方法，还包括在所述客户端处向所述服务器发送安装状态的步骤，在所述服务器处接收所发送的安装状态的步骤，以及在所述服务器处将该安装状态报告到网络上并从所述服务器向用户发送具有安装状态的电子邮件的步骤。

13.根据权利要求8所述的方法，还包括在所述服务器处估计最合适的补丁以满足最低补丁要求的步骤。

14.根据权利要求13所述的方法，还包括在所述服务器处向用户提供关于该用户的机器何时将无法保持兼容性的早期警告的步骤。

15.一种算法，用于在接收到客户端所需补丁后估计最合适的补丁以满足供应商的最低补丁要求，所述算法包括步骤：

收集供应商已经发行的取代所需补丁的所有补丁的列表以及其发行顺序；

确定所需补丁是有效的还是过时的；

如果该补丁是过时的，则检查一致的下一个补丁；以及

检查从所需补丁到最佳补丁的补丁链是否是简单地通过沿循网站上的信息从一个补丁到下一个补丁而构造的。

16.根据权利要求15所述的算法，其中所述供应商是Sun微系统公司。

17.一种算法，用于在接收到客户端所需补丁后估计最合适的补丁以满足供应商的最低补丁要求，所述算法包括步骤：

收集供应商已经发行的取代所需补丁的所有补丁的列表以及其发行顺序；

确定所需补丁是有效的还是过时的；

如果该补丁是过时的，则检查一致的下一个补丁；以及

确定从所需补丁到最佳补丁的补丁链。

18.根据权利要求17所述的算法，其中所述确定从所需补丁到最佳补丁的补丁链是根据以下算法来完成的：

获得所需补丁(“补丁p”)；

接收所查询的补丁(“补丁x”)；

获得被补丁x取代的补丁的集合(“S(x)”)；

确定取代x的最佳补丁(“B(x)”)；

定义补丁b等于B(p)；

确定不会落在补丁p与补丁b之间的补丁(集合D＝S(p)+{p)；

确定可能落在补丁p与补丁b之间的候选的集合(集合C＝S(b)-D)；

对于C中的所有c，定义D＝D+{c}，其中S(c)不包含p；

定义C＝C-D，其中集合C现在仅包含落在p与b之间的补丁；

对于C中的所有补丁c，定义关联阵列A，其中A[c]＝S(c)-D；

以A[c]中元素编号的升序对阵列A的索引进行排序，并将结果存储在有序集合R中，

其中从所需补丁到最佳补丁的补丁链等于：补丁p，后面按顺序接有集合R的元素，再后接补丁b。

19.根据权利要求18所述的算法，其中所述供应商是惠普公司。

20.根据权利要求19所述的算法，还包括获得关于所需补丁是否要求在安装之后重启或者所需补丁是否要求重新配置服务的信息的步骤。

Images