Customizing the software catalog
The software catalog contains signatures that allow for identifying software installed on the computers in your infrastructure. It is updated by IBM on a regular basis. However, due to the number of software products that are available on the market, a product that you are using might not be included in the catalog. In this case, you can create a custom signature to ensure that the software is properly detected and reported. To get a better understanding of the software catalog concepts, check out the Software catalog overview guide.
Creating custom signatures
Before you start creating your own signatures, it might be worth checking the bigfix.me site. It’s a place where you can find various resources for BigFix, including custom signatures created by other members of the community. You can download such signatures and import them to your BigFix Inventory. For instructions how to export your custom signatures or import signatures downloaded from the signature community, click here. For best practices, see below.
If you decide to create custom signatures, follow a process that will allow you to ensure that the signatures are of high-quality. Start your work by identifying products that you expect to discover but are not reported or are missing from the software catalog. Next, organize your work to ensure that the most important products are given the highest priority. Then, determine what files or packages can be used to detect the software and report its usage. Finally, create the signatures. For detailed instructions, click here.
You can also use the Signature development checklist. You can tick off each point on the list as you go through the process to ensure that your signatures are effective and properly discover the software.
Sharing custom catalog content
The option to export and import custom signatures allows you for sharing custom catalog content between different instances of BigFix Inventory. You can also use it to import signatures downloaded from the signature community or export custom content that you want to contribute to the community. Because the function is not optimized for handling many entries at once, you are advised to import signatures in smaller parts.
- IBM catalog – the canonical software catalog that is imported directly to BigFix Inventory or through SwKBT
- Custom catalog – the catalog that contains custom signatures that you created by using the simple catalog management functionality available in BigFix Inventory. This is the catalog that you share between different instances of BigFix Inventory.
- Source catalog – the catalog from which you export custom signatures
- Target catalog – the catalog to which you import custom signatures from a different instance of BigFix Inventory
File and package signature
The simple catalog management functionality that is available in BigFix Inventory allows for creating one type of signatures. It combines a file (or files) and a package (or packages) and has the following constraints:
- Has up to 5 package rules and 5 file rules specified.
- Multiple signatures can be defined for a given software release
- A file that is used as a signature:
- Must have the file name specified. The name cannot be longer than 255 characters
- Must have a file extension that is gathered in the target instance of BigFix Inventory. By default, the following file extensions are gathered in 184.108.40.206: *.BIN, *.EAR, *.PL, *.SH, *.bin, *.com, *.ear, *.exe, *.ocx, *.pl, *.sh, *.sys
- Can have the size specified.
- Can have the version specified. If specified, the version cannot be longer than 255 characters
- A package that is used as a signature:
- Must have a name specified. The name cannot be longer than 1024 characters
- Name and version can include * at the end to match all values that start with the specified number. For example, version 1.2.* will match 1.2.0, 1.2.1, 220.127.116.11 etc.
- Can have the version and vendor specified. If specified, they cannot be longer than 255 characters
Import and export
You can export one or many signatures from one instance of BigFix Inventory and import them to another instance of BigFix Inventory. The whole import is done in a single transaction. If it fails, no changes are made to the database.
Explanation of the most common cases is provided below:
Case 1: One product is assigned to two different vendors
The software name must be unique and cannot be used with different vendors. If you have a product that is assigned to one vendor in the source catalog and to a different vendor in the target catalog, change the vendor in the XML file, and import this XML file into the catalog. The vendor name will be changed to the value in the XML file.
Note: If you have multiple XML files for the same software product in the exported ZIP, remove all but one of them, so that you only have 1 XML per software product in the ZIP you are importing.
Case 2: A file or package is used in a signature for a different product in the target catalog
The signature is added to the target catalog without any warning and the existing signature that is based on the same file or package rule is preserved. It is recommended to review the accuracy of discovery (even by randomly picking up endpoints for verification) and tune the signatures for best results.
For best practices concerning creation of software signatures, refer to the Customizing the software catalog guide.
Case 3: The target catalog contains a signature for a particular product
If the signatures are based on different rules and have different GUIDs, the signature is added to the target catalog. If the signatures are based on different rules but have the same GUID or do not have it at all, the signature from the source catalog overwrites the signature in the target catalog.
Case 4: The signature GUID is the same as the GUID of a signature in the IBM catalog
When the signature has a GUID that is the same as the GUID of a product that exists in the IBM catalog, the custom signature is assigned a new GUID and imported to the target instance of BigFix Inventory. If you import such a signature many times, it is assigned a new GUID during every import and added as a separate signature.
Case 5: The signature is based on a file extension that is not monitored in the target instance of BigFix Inventory
If the file extension is not monitored in the target instance of BigFix Inventory, the following error is written in the logs:
name=>["wrong file extension, the valid file extension is *.BIN, *.EAR, *.PL, *.SH, *.bin, *.com, *.ear, *.exe, *.pl, *.sh, *.sys”].
To solve the problem, you can extend the list of gathered extensions. However, this will extend the time of the import and increase the network traffic. Alternatively, you can try to find a different signature.
Validation and error reporting
Custom signatures that are imported from a different instance of BigFix Inventory are validated in the following two ways.
Validation of the XSD schema
If the imported signatures violate the XSD schema, error messages with detailed information about the cause of the problem are displayed. They are shown in the BigFix Inventory server local language, not the language that is specified in the web browser that you use for accessing BigFix Inventory.
Example: Signature import failed. The uploaded file does not appear to be a valid XML file. Signature.xml: Attribute ‘vendor’ must appear on element ‘software’
Validation of saving the signature
This type of validation is the same as in the case of signatures created manually on the Catalog Customizations panel. To get more information about saving problems, check the tema.log. If you want to monitor the failure log, display it in the console and export to a file, use the following command:
tail -n 0 -f ./wlp/usr/servers/server1/logs/tema.log | tee failure.log