U.S. patent application number 10/755113 was filed with the patent office on 2005-08-25 for patch application that enables the identification of patches for installation on a computer system in a reactive manner.
Invention is credited to Zweifel, Evan R..
Application Number | 20050188259 10/755113 |
Document ID | / |
Family ID | 34860716 |
Filed Date | 2005-08-25 |
United States Patent
Application |
20050188259 |
Kind Code |
A1 |
Zweifel, Evan R. |
August 25, 2005 |
Patch application that enables the identification of patches for
installation on a computer system in a reactive manner
Abstract
A system and/or method selects program patches for installation
into computer systems, where the patches are organized into patch
chains each having a root. The method includes obtaining a base
context identifier, searching for a patch in a context
corresponding to the base context identifier, obtaining a system
description, corresponding to a system where the system description
includes more than hardware version and operating system version
information, and filtering patches found in the search to remove
patches not applicable to the system.
Inventors: |
Zweifel, Evan R.; (Fort
Collins, CO) |
Correspondence
Address: |
HEWLETT PACKARD COMPANY
P O BOX 272400, 3404 E. HARMONY ROAD
INTELLECTUAL PROPERTY ADMINISTRATION
FORT COLLINS
CO
80527-2400
US
|
Family ID: |
34860716 |
Appl. No.: |
10/755113 |
Filed: |
January 9, 2004 |
Current U.S.
Class: |
714/23 |
Current CPC
Class: |
G06F 8/658 20180201 |
Class at
Publication: |
714/023 |
International
Class: |
G06F 011/00 |
Claims
1. A method of selecting program patches for installation into
computer systems, where the patches are organized into patch chains
each having a root, the method comprising the steps of: obtaining a
base context identifier; searching for a patch in a context
corresponding to the base context identifier; obtaining a system
description corresponding to a system, the system description
comprising more than hardware version and operating system version
information; and filtering patches found in the search to remove
patches not applicable to the system.
2. The method of claim 1, wherein obtaining a system description
corresponding to a system comprises obtaining a uniform resource
identifier (URI).
3. The method of claim 2, wherein the URI is used to obtain a
system description file.
4. The method of claim 3, wherein the system description file is
located in the memory of the system.
5. The method of claim 1, wherein filtering patches found in the
search to remove patches not applicable to the system comprises
checking the system description to determine if a patch or its
successors are installed on the system.
6. The method of claim 1, further comprising placing patches not
removed by filtering into a shopping cart.
7. A selection system for aiding in the selection of program
patches for installation into computer systems, where the patches
are organized into patch chains each having a root, the system
comprising: a patch search mechanism which searches for and finds
patches in a base context; a system identification mechanism which
obtains system information for a system; a patch chain examination
mechanism which examines patches identified by the search mechanism
and additional patches, if any, sharing the same patch chain as any
patch whose identifier is found by the search mechanism and
occupying a position on the shared patch chain between the position
of any patch whose identifier is found and the root of the shared
patch chain, the patch chain examination mechanism determines if
patches are already installed on the system based on the system
information obtained by the system identification mechanism; and a
patch presentation mechanism which presents one or more patches,
including patches whose identifiers are found by the search
mechanism and/or additional examined patches, said patches
presented being those that the examination mechanism determines are
not already installed on the system.
8. The system of claim 7, wherein the system identification
mechanism obtains a system description file having a list of
installed software, including installed patches.
9. The system of claim 7, wherein the system identification
mechanism uses a uniform resource identifier to store and retrieve
the system description file.
10. The system of claim 7, wherein the patch search mechanism
extracts a resource base context identifier and searches patches in
a corresponding base context.
11. The system of claim 7, further comprising a communication
interface which communicates with the system, the communication
including information for a search page, a patch details page, and
a shopping cart.
12. The system of claim 7, further comprising a patch download
mechanism which communicates selected patches to the system.
13. The system of claim 12, wherein patches are selected from a
shopping cart.
14. The system of claim 12, wherein the system information
comprises more information than hardware and operating system
version information.
15. A system for the selection of program patches for installation
into computer systems, where the patches are organized into patch
chains each having a root, the system comprising: means for
obtaining a base context identifier; means for searching for a
patch in a context corresponding to the base context identifier;
means for obtaining a system description corresponding to a system;
and means for filtering patches found in the search to remove
patches not applicable to the system.
16. The system of claim 15, wherein means for obtaining a system
description corresponding to a system comprises means for obtaining
a uniform resource identifier (URI).
17. The system of claim 16, wherein the URI is used to obtain a
system description file located on the system.
18. The system of claim 17, wherein the system description
comprises more information than information hardware and operating
system version information.
19. The system of claim 15, wherein means for filtering patches
found in the search to remove patches not applicable to the system
comprises means for checking the system description to determine if
a dependent patch or its successors are installed on the
system.
20. The system of claim 15, further comprising means for placing
patches not removed by filtering into a shopping cart.
Description
CROSS REFERENCE TO RELATED APPLICATION
[0001] Not applicable.
BACKGROUND OF THE INVENTION
[0002] 1. Field of the Invention
[0003] The present invention relates generally to techniques for
maintaining programming systems, and more particularly, to methods
for selecting which sets of program corrections or "patches" are
identified for installation in a reactive manner.
[0004] 2. Description of the Related Art
[0005] When an operating system, such as Hewlett-Packard's version
of UNIX "HP-UX," receives new program files that are to be added to
a given system, the files are delivered gathered into filesets
having names, such as FS1, FS2, and so on. These filesets are
installed on a given system by a process that unpacks and,
possibly, uncompresses the files and places them onto the hard disk
drive of that system. As in shown in FIG. 1, each fileset can
contain a small or large number of files. The FILESET FS1 is shown
containing the files FILE A, FILE B, . . . and FILE F. Likewise,
the FILESET FS2 is shown containing the files FILE J, FILE K, . . .
and FILE P. Of course, a fileset typically contains many more files
than this. Some of these files would be program files, some would
be data files, some would be graphic image and multimedia files,
depending upon the particular nature of the system and the
particular nature of the programming system being installed.
[0006] Patches, or corrected/updated sets of files, are also
delivered to a system as collections of filesets. In the HP-UX
system, it is customary that the filesets in a patch have the same
names as the installed filesets. A patch fileset contains updated
versions of some (possibly all) of the files in the system fileset
having the same name. A given patch PATCH_5 contains new features
and fixes or repairs for specific defects. Descriptions of the new
features and of the repaired defects are contained in a text file
that is maintained in a central database for each patch and that is
searchable for words and phrases. FIG. 2 illustrates an example
patches database. Accordingly, a systems administrator may search
through the patch text file database and locate patches that repair
particular defects or add particular features.
[0007] Over time, a first patch may be replaced by a second patch
which contains all the fixes and new features of the first patch
plus additional changes. These additional changes are called
incremental fixes. The new patch then SUPERSEDES the previous
patch. With reference to FIG. 4, the PATCH_4 at the root of the
patch tree 40 supersedes all of the three patches to the left in
this simple linear search tree. Historically, the first patch
created was PATCH_1. It was superceded by PATCH_2, which was later
superceded by PATCH_3, and that patch was later superceded by
PATCH_4 which now resides at the root of the patch tree 40.
[0008] In some situations, as illustrated in FIG. 3 at 30 and also
in FIG. 5 at 50, two or more patches will be replaced by a single
patch. Thus, PATCH_6 SUPERSEDES both the patches PATCH_5 and
PATCH_8. This is represented in the search tree by PATCH_6 forming
the root of a sub-tree having the two branches PATCH_5 and PATCH_8.
Referring now to FIG. 5, the same patch tree shown in FIG. 3 is
shown at a later point in time. At some point in time, a new patch
PATCH_9 was added which was not part of the original patch search
tree but which initially formed a single isolated patch search tree
having only one patch element. Then a new patch PATCH_7 was created
which combined all of the updates and changes contained in the
patches 5, 6, 8, and 9. Even later on, PATCH_7 was superceded by a
new patch PATCH_10, thus forming the patch tree 50 shown in FIG. 5.
The root patch in the patch tree 50 is the PATCH_10. That patch and
PATCH_7 form the trunk of this searchable patch tree, which then
branches into two branches, one containing PATCH_9 and another
containing PATCH_6; and the PATCH_6 branch of the tree then
branches again into the two patches PATCH_5 and PATCH_8. As can be
seen, a patch tree can become quite elaborate over time as many
patches are combined into a smaller number of newer patches. When
placed into a patch tree database, as shown in FIG. 2, a patch tree
can be searched in an automated manner.
[0009] Patch applications are designed to identify, analyze, and
deliver patches to customers. A patch is applicable to a system if
at least one of the filesets contained in the patch has already
been installed on the system and no successor to the patch is
already installed on the system. During the identification phase,
algorithms identify starting locations on patch chains and traverse
the chains, analyzing the attributes of the patches attempting to
identify the most appropriate patch for the customer.
[0010] Known reactive patch applications have utilized knowledge
about given computer systems. In patch terminology, reactive refers
to searching for a patch to fix a particular problem. However, such
applications have only used information regarding the hardware (HW)
version and the operation system (OS) version of the computer
system. As such, the patch application is forced to assume all
patches for the specified hardware version and operating system
version are applicable. The patch application is unable to
eliminate many non-applicable patches from the search space.
Indeed, when searching for patches using the patch application and
specifying only the HW and OS, the resulting list of patches may be
very large and may contain many patches which are not applicable.
Moreover, when performing dependency analysis for patches given
only the HW and OS, the patch application must assume that none of
the dependents are installed on the computer system. The term
"dependent" patches refers to a patch that requires the additional
installation of a different patch found on a separate patch tree. A
later patch includes a dependent patch within it. As a result, some
dependent patches included are unnecessary because they (or one of
their successors) are already be installed on the customer's
system.
SUMMARY OF THE INVENTION
[0011] Briefly summarized, an embodiment of the invention may be
found in a system and/or method which selects program patches for
installation into computer systems, where the patches are organized
into patch chains each having a root. The method includes obtaining
a base context identifier, searching for a patch in a context
corresponding to the base context identifier, obtaining a system
description, corresponding to a system where the system description
includes more than hardware version and operating system version
information, and filtering patches found in the search to remove
patches not applicable to the system.
BRIEF DESCRIPTION OF DRAWINGS
[0012] FIG. 1 presents the structure of a systems database that
indicates which files, which filesets, and which patches are
installed on each system.
[0013] FIG. 2 presents the structure of a patches database that
indicates what filesets each patch corrects and which files within
those filesets the patches repair or modify or both.
[0014] FIG. 3 presents the database structure of a patch tree
database showing the root patch for each patch tree, the filesets
that each patch tree modifies, and the non-root patches within the
branches of each patch tree.
[0015] FIG. 4 presents a simple linear patch tree.
[0016] FIG. 5 presents a more complex patch tree with several
branches.
[0017] FIG. 6 presents a set of four patch trees, two of which have
branches.
[0018] FIG. 7 presents a flow diagram depicting exemplary
operations for obtaining software patches in accordance with an
embodiment of the invention.
[0019] FIG. 8 presents an overview diagram of a patch application
system including a computer system having a system description file
and user interface displays for patch searches, patch details, and
a shopping cart in accordance with an embodiment of the
invention.
[0020] FIG. 9 presents a flow diagram depicting exemplary
operations for patch searching in accordance with an embodiment of
the invention.
[0021] FIG. 10 presents a flow diagram depicting exemplary
operations for patch searching in accordance with another
embodiment of the invention.
DETAILED DESCRIPTION
[0022] FIG. 7 illustrates exemplary operations performed in a
primary use model for obtaining software patches. Additional,
fewer, or different operations may be performed in various
processes for obtaining software patches, depending on the
embodiment. In an exemplary embodiment, the primary use model is
search centric and uses a shopping cart model. In an operation 72,
a user specifies a search context, such as the hardware and
operating system that the user has. In an operation 74, the user
selects a search method for finding patches. The search method can
be searching by a patch ID (identifier), searching by keyword, or
searching by browsing in the specific context, for example. A patch
application presents a list of patches matching the search
criteria. In an operation 76, the user can select a specific patch
for installation and correction of a problem on a computer system
and, in an operation 78, the user can view a document describing
details of the patch.
[0023] In an operation 79, either from a search results page, or
from a patch details page, the user can add a patch to a shopping
cart. The search results page, patch details page, and shopping
cart are depicted in FIG. 8. Each page can include a user interface
that presents information to the user. From the shopping cart page,
the user may take delivery of the patches by downloading the binary
files individually or en masse (in a variety of different formats).
Although a wide range of purchasing models can be employed in
different embodiments, the shopping cart model has the advantage of
being able to enforce certain patching rules. Example rules can
include a rule that two patches on the same patch chain cannot be
installed on a computer system, therefore cannot both appear in the
cart. Another rule can be that if a patch requires other patches
(dependencies), the dependent patches must also appear in the
shopping cart.
[0024] The search page, the patch details page, and the shopping
cart (FIG. 8) behave differently depending on context. For example,
in the search page, the context controls which patches are
searched. In the patch details page, the context controls which
related patches are displayed (the recommended and/or successors).
In the shopping cart, the context controls which dependent patches
are included in the cart for the user to download.
[0025] The context parameter for the search page, patch details
page, and shopping cart can be specified as a string of the form
"HW:OS" which is used as a key to locate information which is used
to control the behavior of these pages. This string is referred to
as the ContextID. Pages and requests that need to know the current
context can be passed the ContextID as a request parameter.
[0026] FIG. 8 illustrates a system 82 having a connection 84 to a
network 86 that is in communication with a patch repository 88. The
user communicates information about the system 82 to be patched by
uploading a system description file 89. The file 89 can be created
by executing a collector script. The collector script may be
obtained in a variety of ways, such as downloading it from the
patch repository 88. The system description file 89 contains a list
of attributes describing the system including, for example, the
hardware and operating system revisions, a list of the filesets
installed, and a list of the patches installed.
[0027] The system 82 presents the user with user interface pages,
including, for example, a search page 83, a patch details page 85,
and a shopping cart 87. Additional interfaces may also be included.
The search page 83 presents an interface where the user can search
for patches and review the found patches. The patch details page 85
presents an interface providing recommended and/or successor
patches and information about the patches. The shopping cart 87
presents an interface where the user can see selected patches to be
obtained and/or purchased. Some patches may require purchase,
whereas some patches may not. Use of the term "shopping cart"
refers to a model for selecting and obtaining patches. Purchase by
whatever means may or may not be a part of the shopping cart.
[0028] In an exemplary embodiment, the system description file 89
can be stored in a database accessible by the patch repository 88.
A patch application can use the system description file 89 to
provide patches that are available for use with the system 82. The
system description file 89 may contain a string that identifies the
system 82. This string may contain two components, a uniform
resource identifier (URI) and a resource base context ID. The URI
is a key which can be passed to a ResourceLocator object within the
patch application resulting in the extraction of the system
description file 89 from the database.
[0029] The resource base context ID is the normal ContextID
describing the hardware and operating system of the system
described by the system description file 89 as well as installed
programs and patches. The new string is referred to as a
ResourceContextID. The string can take the form of:
"URI{BaseContextID}". Pages expecting a ContextID parameter can be
generalized to allow the passing of a ResourceContextID.
[0030] FIG. 9 illustrates exemplary operations performed in patch
searching process. Additional, fewer, or different operations may
be performed in various patch searching processes, depending on the
embodiment. In an operation 92, a resource base context ID is
extracted from the ResourceContextID. As explained above, the
ResourceContextID may be located in a string contained in the
system description file. In an operation 94, a search is performed
in the corresponding base context. In an operation 96, the URI is
extracted for the system specified in the ResourceContextID. In an
operation 98, the system description is obtained using the
ResourceLocator and the URI. The search results are filtered in an
operation 99, removing any patches which are not applicable to the
system. The search results are presented to the user, allowing the
user to browse to the specifics of a patch or to add patches to the
shopping cart.
[0031] The existing patch details display page receives a contextID
to enable the computation of related patches (the recommended
successor and the latest patch of the chain). The ContextID may be
passed along from the patch details page when adding a patch to the
shopping cart. As discussed, the ContextID may be a
ResourceContextID. In this case, the computation of the related
patches uses the corresponding base context stored in the
ResourceContextID. If the ContextID is a ResourceContextID, then
the base context ID is extracted from the ResourceContextID. The
recommended and latest patches can be located using this base
context ID.
[0032] In an exemplary embodiment, the shopping cart is partitioned
into sections based on the ContextID. When adding a patch to the
cart, the appropriate ContextID must be provided. The patch is
added to the appropriate section and the dependencies for that
section are re-computed and added to that section. Each section is
preferably comprised of two parts: the patches which the user
explicitly requested, and the patches which are included as
dependencies of explicitly requested patches. This partitioning is
generalized to allow sections in the shopping cart corresponding to
ResourceContextIDs (and thus patches for a particular system).
Also, the processing of dependencies is generalized to minimize the
number of patches in the cart, by using the knowledge of the system
being manipulated.
[0033] FIG. 10 illustrates exemplary operations performed in a
patch processing process. Additional, fewer, or different
operations may be performed in various patch processing processes,
depending on the embodiment.
[0034] In an operation 1002, the URI is extracted for the system
specified in the ResourceContextID. In an operation 1004, the
system description is obtained using the ResourceLocator and the
URI. In an operation 1006, the list of the explicitly requested
patches for the section corresponding to the ResourceContextID is
set to a variable "X." In operations 1008 and 1010, the variables
Total and ProcessList are both set to X. In an operation 1012,
ProcessList is checked to see if it is empty. If it is empty, Total
is stored in the shopping cart in an operation 1014. If it is not
empty, an operation 1016 is performed in which the first element in
ProcessList is set to a variable "P".
[0035] After operation 1016, an operation 1018 is performed in
which P is removed from the ProcessList. In an operation 1020, the
variable DependentList is set to a list of all of the dependents of
P. In an operation 1022, the DependentList is checked to see if it
is not empty. If DependentList is empty, the procedure goes to
operation 1012. If DependentList is not empty, an operation 1024 is
performed in which the variable D is set to the first element in
the DependentList. Then, in an operation 1026, D is removed from
the DependentList. In an operation 1028, a check is made as to
whether, D or its successor is in Total. If D or its successor is
in Total, control passes to operation 1022. If D is not in Total,
an operation 1030 is performed in which a check is made as to
whether D or its successor is installed on the system. If D or its
successor is installed on the system, control returns to operation
1022. If D or its successor is not installed on the system, an
operation 1032 is performed in which R is set to the best successor
of D. In an operation 1034, R is added to Total and, in an
operation 1036, R is added to Process List. After operation 1036,
control returns to operation 1022.
[0036] Advantageously, generalizing ContextID to ResourceContextID,
allowing the inclusion of a key to specify a system to be patched,
and making modifications to a few pages provides for improved
patching models for computer systems.
[0037] While several embodiments of the invention have been
described, it is to be understood that modifications and changes
will occur to those skilled in the art to which the invention
pertains. Accordingly, the claims appended to this specification
are intended to define the invention precisely.
* * * * *