METHOD AND APPARATUS FOR POPULATING A SOFTWARE CATALOGUE WITH SOFTWARE KNOWLEDGE GATHERING

Abstract

A method and a corresponding apparatus for inventoring software products on a plurality of computer are proposed. The inventoring system aims at populating a software catalogue without the manual intervention of an administrator. The present invention reduces the cost of producing and maintaining a comprehensive knowledge base (the catalogue) which contains definitions of software products and the related signature. Information about software products and their related signature is obtained through a process which gathers information from a potentially very large collection of computers. Any occurence of a group of identical files across multiple computers is considered a reliable indicator that they belong to the installation footprint of a product.

Description

TECHNICAL FIELD

The present invention relates to the data processing field. More specifically, the present invention relates to a method of detecting the presence of software products on distributed data processing system. In particular the activity of knowledge gathering and signature generation is addressed by the present invention. The invention further relates to a computer program for performing the method, and to a product embodying the program. Moreover, the invention also relates to a corresponding apparatus.

BACKGROUND ART

Several system management software applications require the availability of a comprehensive knowledge base that contains information on software products, which may be currently installed and running on a plurality of data processing systems. For examplese license manager products like IBM Tivoli License Manager (ITLM) needs a knowledge base (i.e. a catalogue) to identify the products found on the managed systems and correctly metering and invoicing the use of such products. Another example can be configuration manager applications, e.g. IBM Tivoli Configuration Manager (ITCM) in particular the Inventory feature, or software deployment products. Normally this knowledge base is in the form of a catalogue which contains definitions of software products (e.g. product names and version) and the related signature. The software catalogue lists all the known products which can be found by on the managed systems; each product can be identified by one or more executable modules indicative of its running. As an example, in the case of a License Manager product, a licensing agent working in the background detects the executable modules that have been launched; the licensing agent then identifies the corresponding products through the software catalogue. The catalogue needs to be “populated” and this is normally a costly activity.

Several IT management solutions exist that perform the discovery of installed software for either inventory or licensing purposes. One form of software discovery that is particularly effective exploits a previously defined signature for each product that has to be discovered. The term signature means any type of information that can be consumed by a software discovery application to determine the presence of one or more instances of a software product on a given computer. A typical and particularly simple implementation of a signature is one that specifies the file-name and the file-size of a key application file. In this case, detecting a file with matching characteristics would cause the signature to be matched, thus indicating that the associated software product is installed. One advantage of a signature-based approach to software discovery is that the matching of a signature can be correlated by a management application to a precise definition (name, version, etc.) of the entity (software product) being discovered. A software inventory application which exploits signature-based discovery of installed software therefore has the need of accessing a comprehensive knowledge base of product and signature definitions. The challenge of this approach is to maintain its content up-to-date with respect to:

new software products being continuously made available;

maintenance updates to existing software products. The lack of an industry standard for representing software signatures, let alone of a common shared repository that all software vendors could populate with knowledge about their own published software, determined the need for vendors of IT management solutions to create proprietary implementations of such a product-signature knowledge base, hereafter referred to as “KB”. The value of the KB is directly proportional to the coverage and accuracy of its content, therefore the problem is how to guarantee coverage and accuracy at an affordable cost.

According to known methods normally employed to create product-signature information, one or more of the following actions is performed:

information is directly collected from the software producer (internal development department or independent software vendor);

a technical person who is experienced in the installation or use of a specific software product can manually produce accurate product and signature definitions for that product, or at least for a specific version;

a technical person who is experienced on the software installation and registration facilities available on one or more computing platforms can obtain product definitions by direct inspection of data maintained by the operating system on computers where those products have been installed, then it is possible to manually create signatures for these products based on OS registry values or installed files or both;

a technical person uses software tools that harvest information from a computer where the software is installed, in order to partially automate the activities described above.

All of the above methods have some drawbacks. The first two are only applicable to software products which are internally developed or to products for which in-depth knowledge is available. The other methods require visiting multiple computers where different versions or different maintenance levels of the same software product may be installed, as they may require different signatures. The cost of creating and maintaining the product-signature KB with the above methods are often prohibitive, which results in incomplete and obsolete content.

It is an object of the present invention to provide a method and a system which alleviates the above drawbacks.

SUMMARY OF THE INVENTION

According to the present invention we provide a method of populating a software catalogue with software product identifiers corresponding to software products being discovered on a plurality of data processing systems, the method including the steps of: scanning the file systems of the plurality of data processing system for detecting the occurrence of sets of files, each of the sets being indicative of a product being installed on a data processing system; for each of the sets, determining a corresponding product signature, the signature being associated to a software product; storing the signature and an associated software product identifier on the software catalogue.

Another aspect of the present invention provides a method for inventoring software products across a plurality of data processing system.

A further aspect of the present invention provides a computer program for performing the above-described method.

A still further aspect of the invention provides a program product embodying this program.

Moreover, another aspect of the invention provides a corresponding apparatus for implementing the above method.

The novel features believed to be characteristic of this invention are set forth in the appended claims. The invention itself, however, as well as these and other related objects and advantages thereof, will be best understood by reference to the following detailed description to be read in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1a is a schematic block diagram of a data processing system in which the method of the invention is applicable;

FIG. 1b shows the functional blocks of a generic computer of the system;

FIG. 2 depicts the main components that can be used for practicing the method; and

FIG. 3 show a diagram describing the flow of activities relating to an illustrative implementation of the method.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT(S)

With reference in particular to FIG. 1a, a data processing system 100 with distributed architecture implementing a Software Inventory system, is depicted. The system 100 includes multiple endpoints 105, which are grouped into different sets. The endpoints 105 can be workstations, servers, laptops and more generally any kind of data processing system where a plurality of software products is installed. The endpoints 105 are connected to each other through a network 110 (for example, a LAN). The different sets of endpoints 105 communicate with a remote system management server 115 through a network 120 (for example, INTERNET-based); the system management server 115 implements a central repository where inventory data of the system 100 is collected and managed. As mentioned above, the present invention may be implemented in a license management system, but more generally in any system requiring an inventory activity, e.g. a software deployment system which needs to distribute fixes or enahncements to a plurality of workstation, after having inventored the current status of each workstation; another possible use is within a configuration management system.

As shown in FIG. 1b, a generic computer of the system (workstation, local server, or system management server) is denoted with 150. The computer 150 is formed by several units that are connected in parallel to a system bus 153. In detail, one or more microprocessors (μP) 156 control operation of the computer 150; a RAM 159 is directly used as a working memory by the microprocessors 156, and a ROM 162 stores basic code for a bootstrap of the computer 150. Peripheral units are clustered around a local bus 165 (by means of respective interfaces). Particularly, a mass memory consists of a hard-disk 168 and a drive 171 for reading CD-ROMs 174. Moreover, the computer 150 includes input devices 177 (for example, a keyboard and a mouse), and output devices 180 (for example, a monitor and a printer). A Network Interface Card (NIC) 183 is used to connect the computer 150 to the network. A bridge unit 186 interfaces the system bus 153 with the local bus 165. Each microprocessor 156 and the bridge unit 186 can operate as master agents requesting an access to the system bus 153 for transmitting information. An arbiter 189 manages the granting of the access with mutual exclusion to the system bus 153.

Similar considerations apply if the system has a different topology, or it is based on other networks. Alternatively, the computers have a different structure, include equivalent units, or consist of other data processing entities (such as PDAs, mobile phones, and the like). In any case, the solution of the invention is also suitable to be used in a system wherein the control of the workstations is decentralized, or even in a stand-alone computer.

Considering now FIG. 2, the main components that can be used to practice the method of a preferred embodiment of the invention are denoted as a whole with 200. The information (programs and data) is typically stored on the hard-disks of the different computers and loaded (at least partially) into the corresponding working memories when the programs are running.

A Systems Management Server 115 controls and executes management operations on several endpoints 105, connected by a communication network. The set of endpoints 105 includes servers, workstations, desktops or laptops, whose installed software is analyzed with the objective of enlarging the available base of product definitions and related signatures.

The Systems Management Server 115 controls management operations on a potentially large set of interconnected endpoints 105, thus avoiding the need of physically visiting each computer. This server and the underlying systems management infrastructure are used for performing a scanning operation on the managed computers with the goal of collecting raw data needed by the analysis application; and for moving data generated locally by the scanners to a central file-server 201, where these data can be stored on the server's file system. The scanning operation may be performed on all managed endpoints 105 or on a specific subset, the latter being possibly determined by their role (servers, workstations, desktops or laptops) or by the running operating system.

The data harvested from the selected computers stored in the file-system of the central file-server, from which the data can be accessed by the Analysis Application 203. Analysis Application 203 implements the data transformation and the analysis leading to the creation of new product definitions and related signatures.

The first step implemented by the Analysis Application 203 is to merge information from all scanned computers into an Analysis Database 205, in a normalized form that avoids redundancy (see Data Normalization). This information is the primary input to the analysis. In addition, this database holds the intermediate products of the analysis (footprint data) from which the application derives product definitions and signatures.

Once data are normalized, the application supports the identification of footprints (groups of files) that are representative of an installed instance of a software product (see Footprint Analysis). Each footprint needs to be correlated to a product definition which can be often derived automatically from harvested data or that can be generated by the application with input from the user. The last step implemented by the application is the generation of a product definition and a signature definition, from the available footprint data, in a format that can be stored in the Software Knowledge Base 207. A Software Knowledge Base 207 is a database holding a set of consolidated product definitions and signatures. The database can be initially empty or it can be populated with data created by a provider of software signatures. The new definitions produced by the analysis application are consolidated in this database.

Considering now FIG. 3, the logic flow of a knowledge gathering process according to an embodiment of the invention is represented with a method 300. The method begins at the black start circle 301. Continuing to block 303 data are gathered throughout the endpoints 105. Collected data are then normalized at step 305, while at step 307 a footprint analysis is performed. At step 309 it is checked whether a matching product definition already exists: if this is the case the footprint is correlated to such definition (step 311); if not a product definition is generated according to available information and user input (step 313). Finally at step 315 a signature definition is generated. We will now see in further details each of the above steps.

Data Gathering

The following data are gathered from a potentially very large collection of available computers by a distributed application that implements the following functions:

1. Scan the machine for basic operating-system data, producing:

a. a unique identifier of the computer

b. operating system type and version

c. hardware architecture

d. optional information to help locating the machine for a direct inspection, in case that would be needed for troubleshooting;

e. key named directories that may be needed on some operating systems to help include or exclude file-system directories

2. Scan the file-system—using appropriate filters—to record the following information on files that are candidate to be representative of a product's install footprint (e.g. executable files and libraries):

a. Path name

b. File name

c. File size

d. File checksum

3. Scan the operating system or installer specific registry for information about installed products, recording the following product information:

a. Product name

b. Product Version

c. Source (registry) type

4. Use the available registry information to establish a link between products definitions collected in step 3) and candidate representative files listed on step 2). This can be done by knowing the product's install location. Alternatively, the canonical platform registry on the most popular UNIX operating systems already provides means to determine which files belong to a given registered product.

5. On some operating systems applications may register information about themselves in the form of key-data pairs appearing in a tree-like structure where the name of a key is often application specific. These registry data are extremely valuable for a human to infer an appropriate product definition (name and version) once it is possible to correlate a set of data to a group of files that is in the footprint of an otherwise unknown product. Therefore, selected sub-trees of the registry are recorded which can be correlated to one file-system directory identified in the file-system scan of step 2) according to the following matching criteria:

a. A key exists in the same registry sub-tree that conforms to the format of a file-system path-name (e.g.: starts with “X:\”)

B. The value of the key, once variable substitution and other appropriate decoding is applied, matches the path-name of a file-system directory recorded in step 2)

Data Normalization

The data gathered from the target computers are processed by the analysis application which stores them in a relational database in a normalized form. The following advantages are obtained through the data normalization:

files are identified by their content (checksum and filesize) rather than their name, so that the analysis is not affected by the fact that some instances of a file may be renamed;

a single instance of the entity representing the file is stored in the database, regardless of the number of instances found across the scanned systems;

folders are identified by their content (the files satisfying the scanner's filtering criteria that are contained in that folder). Therefore, a folder entity stored in the database represents a unique aggregation of content (files). The basic identifier of a folder is therefore a digest of the contained files. The digest is computed by applying a digest algorithm (e.g. MD5) to a string whose content is a concatenation of tokens, namely one token for each file. The algorithm chosen should guarantee a negligible probability for the occurrences of “collisions”. Each token consists of an expression of the form “(<file-checksum>,<file-size>)”, where “<file-checksum>” and “<file-size>” are the file's checksum and size, respectively. In order to make the computed digest insensitive to any casual way of listing the folder's files, the set of all tokens is sorted and the token insertion into the final string is done according to the position of each token in the sorted set.

pathname information is not stored as part of the folder entity, but rather as a property of the associations between the folder and each computer where one or more instances of a folder with the same content has been found.

products whose name, version and source (the type of registry from where the product definition has been harvested) are equal, are likewise treated as the same entity and stored once in the database.

All relationships derived from the raw data are maintained in the database, namely:

• • file-folder
  • product-file
  • folder-computer
  • product-computer
    Footprint Analysis

The data produced after data normalization are analyzed to identify groups of files that repeats themselves identically on multiple computers, regardless of the path-names of each file and of their parent directories, which may be different on each computer. These groups of files are hereafter referred to as footprints. The footprint identification can be totally automated, yet the application may allow the users to preview information through a graphical user interface, and exert some degree of control over the process.

The footprint identification process is implemented through the following steps:

files stored in the Analysis database are put in a list sorted by decreasing number of occurrences;

the list is scanned from the top until a file is found which does not have an associated footprint (initially no footprint exists) and that has not been marked for exclusion (initially, no file is marked for exclusion). Hereafter this file is referred to as the ‘source’ file.

the ‘source’ file is used to create a footprint in which that file would be included; the list of folders containing the file is analyzed and a set is created of all files contained in each one of the above folders (this set of course includes the ‘source’ file). This set, represents the set intersection of all folders where the ‘source’ file has been found.

the analysis application may allow the user to preview the set of folders whose intersection determines the generated footprint, in case there is the likelihood of some ‘spurious’ data. For example: an isolated copy of the ‘source’ file may be accidentally found outside of the product's install tree, in which case it could be possible to determine that the containing folder should be ignored when computing the intersection.

files belonging to the set intersection of folders containging the ‘source’ file are guaranteed by the process of not being part of an existing footprint, therefore they become the content of a new footprint that is stored in the Analysis Database;

files that do not belong to any footprint, and yet occur in some folder as ‘companions’ of a file which is part of some footprint, are marked for exclusion in the rest of the process and will not become part of any footprint. The above process of footprint identification terminates when each file is either associated to a footprint or is marked for exclusion.

A further step which can help the visualization of a product's installation tree composed of multiple folders can be performed by the analysis application by establishing a parent-child relationship among any pair of footprints A and B when each instance of the folders whose intersection defines the footprint A is found to be in the parent-child relationship with a corresponding instance of a folder related to the definition of the footprint B. By this approach it is possible to construct a tree structure of footprints evidently related to the installation tree of a single product.

Footprint Correlation to One Harvested Product Definition

In order to possibly associate a footprint to a product definition, it is sufficient that the latter could be harvested on even a single computer and that it was possible to associate the footprint with that product on that computer. This is especially powerful on UNIX environments where the product may have been installed in a canonical form (including registration) on only a few computers while it may have been simply cloned on the production environment with loss of the registry information. Therefore, for groups of files that satisfy the above condition, a definition of the product is immediately available and can be presented to the user for review and acceptance.

Computer Aided Creation of a Product Definition

This step is needed for the computer aided creation of product definitions that can be associated to groups which were not automatically correlated to one harvested product definition, as in the previous step. The computer aid tool guides the user to find the elements of a product's definition (name, version) by navigating the additional registry information collected in step 5) of the data gathering process. The navigation is restricted to registry sub-trees that were correlated to the files according to the criteria described in step 5) of the data gathering process, namely by matching some key value with the file path-names.

Signature Definition

A signature definition can be generated automatically based on the available information. Alternatively, computer-aided generation can be chosen to let the user exert control on the characteristics of the signature like, for example:

Selection of a single file, among the many included in a file-group, that is to be used for the signature definition.

In general, the capability of a discovery engine to handle complex signatures makes it possible to fully leverage the collected information to create a signature that is both selective and robust (e.g. with respect to software updates).

In this way, it's is possible to obtain robust Sw signatures to be used for SW discovery. A so obtained signature, is needed either because no SW signature was available before, or because the former known SW signature does not work. This latter case can happen, for instance, because a SW product have been deployed in a custom manner without executing its regular installation process (e.g. SW binaries were unpackaged from a customer assembled bundle, which did not contain the expected signature).

As an additional feature, in some circumstances, a reliability score could be assigned to each footprint, based on several parameters (e.g. the number of occurrences, or the size of the footprint). In the same way the association between a signature and a software product identifier could be assigned a reliability indicator, and a decision of whether to automatically assign the signature to such product could be made dependent on such indicator: if the indicator does not reach a minimum thresholds, the intervention of an administrator could be invoked.

Similar considerations apply if the programs and data are structured in a different manner, if other modules or functions are provided, or if the information is stored in equivalent memory structures.

Similar considerations apply if the method includes equivalent or additional steps.

Alternatively, for example different methods of obtaining the information on the inspected endpoints can be used, depending also on the operating system on which the system is installed.

Although the invention has been described above with a certain degree of particularity with reference to preferred embodiment(s) thereof, it should be understood that various changes in the form and details as well as other embodiments are possible. Particularly, it is expressly intended that all combinations of those elements and/or method steps that substantially perform the same function in the same way to achieve the same results are within the scope of the invention.

In any case, the method of the invention can be used for inventoring any kind of software products (such as video games, multimedia works, and the like.

In addition, the programs can be distributed on any other computer readable medium (such as one or more DVDs); alternatively, the programs are pre-loaded onto the hard-disks, are transmitted to the computers, are broadcast, or more generally are provided in any other form directly loadable into the working memories of the computers.

Moreover, it will be apparent to those skilled in the art that the additional features providing further advantages are not essential for carrying out the invention, and may be omitted or replaced with different features.

In any case, the method according to the present invention is also suitable to be carried out with a hardware structure (for example, integrated in a chip of semiconductor material), or with a combination of software and hardware.

Naturally, in order to satisfy local and specific requirements, a person skilled in the art may apply to the solution described above many modifications and alterations all of which, however, are included within the scope of protection of the invention as defined by the following claims.

Claims

1. A method of populating a software catalogue with software product identifiers corresponding to software products being discovered on a plurality of data processing systems, the method including the steps of:

scanning the file systems of the plurality of data processing system for detecting the occurrence of sets of files, each of the sets being indicative of a product being installed on a data processing system;

for each of the sets, determining a corresponding product signature, the signature being associated to a software product;

storing the signature and an associated software product identifier on the software catalogue.

2. The method of claim 1, wherein the scanning activity is limited to executable files or to executable files and libraries.

3. The method of claim 1 wherein the signature includes a file identifier associated to one of the files of the corresponding set of files.

4. The method of claim 1, wherein the signature includes registry information derived from at least one of the files of the corresponding set of files.

5. The method of claim 1, wherein the scanning and detecting activity includes the steps of:

identifying a plurality of executable files on the plurality of data processing systems;

creating a list containing the plurality of identified executable files;

selecting at least one file on the list;

for each selected file creating a footprint set including the files which occur in all the folder containing the source file.

6. The method of claim 6 further including the step of:

sorting the list according to the number of occurrences of each file;

starting from the file with the highest occurrence selecting one file on the list until the list has been scanned, and for each selected file:

creating a footprint set including the files which occur in all the folder containing the selected file;

deleting from the sorted list all the files included in the footprint.

7. The method of claim 1 wherein the association of the signature with a software product identifier is based on information extracted by the files included in the corresponding set of files.

8. The method of claim 1, wherein the method is used for inventoring software products, across a plurality of data processing system, using the method of any preceding claim.

9. A computer program in a computer readable medium for populating a software catalogue with software product identifiers corresponding to software products being discovered on a plurality of data processing systems, comprising:

instructions for scanning the file systems of the plurality of data processing system for detecting the occurrence of sets of files, each of the sets being indicative of a product being installed on a data processing system;

instructions for each of the sets, determining a corresponding product signature the signature being associated to a software product;

instructions for storing the signature and an associated software product identifier on the software catalogue.

10. A system

for populating a software catalogue with software product identifiers corresponding to software products being discovered on a plurality of data processing systems, comprising:

means for scanning the file systems of the plurality of data processing system for detecting the occurrence of sets of files, each of the sets being indicative of a product being installed on a data processing system;

means for each of the sets, determining a corresponding product signature, the signature being associated to a software product;

means for storing the signature and an associated software product identifier on the software catalogue.