Reference Manual
- About This Guide
- 1 Available Documentation
- 2 Feedback
- 3 Documentation Conventions
- 4 Special Uyuni Documentation Conventions
- 5 Overview and Navigation
- 6 Navigation
- 7 Systems
- 8 Autoinstallation
- 9 Salt
- 10 Images
- 11 Patches
- 12 Software
- 13 Audit
- 14 System Security via OpenSCAP
- 15 Configuration
- 16 Schedule
- 17 Users
- 18 Admin
- 19 Help
13 Audit
Select › to audit your managed systems.
13.1 CVE Audit #
The › › page will display a list of client systems with their patch status regarding a given CVE (Common Vulnerabilities and Exposures) number.
13.1.1 Normal Usage #
Proceed as follows if you want to verify that a client system has received a given CVE patch:
Make sure that the CVE data is up-to-date. For more information, see Section 13.1.3, “Maintaining CVE Data”.
Click › › to open the
CVE Auditpage.Input a 13-char CVE identifier in the
CVE Numberfield. The year setting will be automatically adjusted. Alternatively, set the year manually and add the last four digits.Optionally, uncheck the patch statuses you are not interested in.
Click
Audit systems.
Performing this procedure will result in a list of client systems, where each system comes with a Patch Status belonging to the given CVE identifier.
Possible statuses are:
Red - Affected, patches are available in channels that are not assignedThe system is affected by the vulnerability and Uyuni has one or more patches for it, but at this moment, the channels offering the patches are not assigned to the system.
Orange - Affected, at least one patch available in an assigned channelThe system is affected by the vulnerability, Uyuni has at least one patch for it in a channel that is directly assigned to the system.
Grey - Not affectedThe system does not have any packages installed that are patchable.
Green - PatchedA patch has already been installed.
In other words, it can mean the following:
More than one patch might be needed to fix a certain vulnerability.
The
Orange - state is displayed when Uyuni has at least one patch in an assigned channel.
This might mean that, after installing such a patch, others might be needed—users should double check the CVE Audit page after applying a patch to be sure that their systems are not affected anymore.
For a more precise definitions of these states, see Section 13.1.4, “Tips and Background Information”.
Note: Unknown CVE Number
If the CVE number is not known to Uyuni, an error message is displayed because Uyuni cannot collect and display any audit data.
For each system, the Next Action column contains suggestions on the steps to take to address the vulnerabilities.
Under these circumstances it is either sensible to install a certain patch or assign a new channel.
If applicable, a list of “candidate” channels or patches is displayed for your convenience.
You can also assign systems to a System Set for further batch processing.
13.1.2 API Usage #
An API method called audit.listSystemsByPatchStatus is available to run CVE audits from custom scripts.
Details on how to use it are available in the API guide.
13.1.3 Maintaining CVE Data #
To produce correct results, CVE Audit must periodically refresh the data needed for the search in the background. By default, the refresh is scheduled at 11:00 PM every night. It is recommended to run such a refresh right after the Uyuni installation to get proper results immediately instead of waiting until the next day.
In the Web interface, click › › .
Click the
cve-server-channels-defaultschedule link.Click the
cve-server-channels-bunchlink.Click the button.
After some minutes, refresh the page and check that the scheduled run status is
FINISHED.
A direct link is also available on the › › page (extra CVE data update).
13.1.4 Tips and Background Information #
Audit results are only correct if the assignment of channels to systems did not change since the last scheduled refresh (normally at 11:00 PM every night). If a CVE audit is needed and channels were assigned or unassigned to any system during the day, a manual run is recommended. For more information, see Section 13.1.3, “Maintaining CVE Data”.
Systems are called “affected”, “not affected” or “patched” not in an absolute sense, but based on information available to Uyuni. This implies that concepts such as “being affected by a vulnerability” have particular meanings in this context. The following definitions apply:
- System affected by a certain vulnerability
A system which has an installed package with version lower than the version of the same package in a relevant patch marked for the vulnerability.
- System not affected by a certain vulnerability
A system which has no installed package that is also in a relevant patch marked for the vulnerability.
- System patched for a certain vulnerability
A system which has an installed package with version equal to or greater than the version of the same package in a relevant patch marked for the vulnerability.
- Relevant patch
A patch known by Uyuni in a relevant channel.
- Relevant channel
A channel managed by Uyuni, which is either assigned to the system, the original of a cloned channel which is assigned to the system, a channel linked to a product which is installed on the system or a past or future service pack channel for the system.
A notable consequence of the above definitions is that results can be incorrect in cases of unmanaged channels, unmanaged packages, or non-compliant systems.
13.2 Subscription Matching #
To match subscriptions with your systems use the Subscription Matcher tool.
The Edit Virtual Host Managers link in the upper right corner will take you to the › › overview.
For more information about Virtual Host Managers, see Section 8.9, “Systems > Virtual Host Managers”.
It gathers information about systems, subscriptions and pinned matches (fixed customer defined subscriptions to systems mapping) as input and returns the best possible match according to the SUSE Terms and Conditions.
The Subscription Matcher (subscription-matcher) is also able to write CSV Reports.
The
Subscriptions Reportprovides subscriptions report data when usedThe
Unmatched Products Reportprovides information on products and their systems when a match to a subscription cannot be foundThe
Error Reportprovides a list of errors raised during the matching process
Selecting › › from the left navigation menu will provide you with an overview of all results generated by the Subscription Matcher.
Important: Subscription Matcher Accuracy
This tool’s goal is to help provide visual coverage on current subscription use and support reporting. The Subscription Matcher is excellent at matching systems and products registered with Uyuni, however any systems, products or environments which are not found in the database will remain unmatched. This tool is not intended to act as a replacement for auditing. Auditing should always take precedence over subscription matching.
13.2.1 › › › #
The Subscription Matching overview provides subscription part numbers, product descriptions, policies, matched total subscriptions used and remaining, and the start and end dates of subscriptions.
Figure 13.1: Subscription Matching Overview #
- Part Number
Identifier of a particular product
- Description
Name of a particular product
- Policy
Kind of the subscription of this product
- Matched/Total
Fully Matched. If the total amounts of a subscription are fully matched, the quantity column value is highlighted with a yellow warning triangle:
Susbscritions about to Expire. When a subscription will expire within less than 3 months, the record is highlighted.
Expired Subscriptions. If a subscription is expired, the record for it is faded.
- Start Date
Start date of the subscription
- End Date
End date of the subscription
13.2.2 Subscription Matcher Reports #
Uyuni automatically generates up-to-date nightly status reports by matching your SUSE subscriptions with all your registered systems.
These reports are stored in /var/lib/spacewalk/subscription-matcher and provided in CSV format.
These CSV files may be opened with a spreadsheet application such as LibreOffice Calc.
If you want to schedule these reports to be produced at different times, or at a certain frequency or schedule a one time completion you can perform this task by editing the Taskomatic settings for the gatherer-matcher located in the Web UI at › › › .
13.2.3 › › › #
Selecting the › › tab provides an overview of all systems the matcher could not find in the database or which were not registered with Uyuni.
The Unmatched Products overview contains product names and the number of systems which remain unmatched with known installed products.
Figure 13.2: Unmatched Products #
- Show System List
Select to open and display a list of all systems which were detected with an installed product but remain unmatched with a subscription.
13.2.4 › › › #
The subscription pinning feature allows a user to instruct the subscription matcher to favor matching a specific subscription with a given system or group of systems. This is achieved by creating pins. Each pin contains information about the preferred subscription-system match.
Note: Respecting Pins
In some cases the algorithm may determine that a specific pin cannot be respected, depending on the subscription’s availability and applicability rules, in this case it will be shown as not satisfied.
The pins table displays a list of all pins.
Items in the list contain the status of pins, which can be satisfied, not satisfied and pending next run.
A pin is
satisfiedif its system and subscription was matched in the last matcher run.A pin is
not satisfiedif its system and subscription was not matched in the last matcher run. This can happen, for example, if the pin violates terms and conditions for subscriptions.A pin is in the
pending next runstate when it needs a new matcher run to be taken into account. After the new run, the pin will become eithersatisfiedornot satisfied.
Click the button to open the Available Systems window.
You may filter systems by name and select a system for the matcher to pin manually.
Within the › button to raise priority for subscription use on the selected system.
13.2.5 › › › #
You can review all messages related to Subscription Matching from the › › › overview.
The following status messages can be displayed.
- Unknown Part Number
Unsupported part number detected
- Physical Guest
Physical system is reported as virtual guest, check hardware data
- Guest with Unknown Host
Virtual guest has unknown host, assuming it is a physical system
- Unknown CPU Count
System has an unknown number of sockets, assuming 16. You can try fixing this by scheduling hardware refresh for affected system.
13.3 OpenSCAP #
If you click › › › , an overview of the OpenSCAP Scans appears. SCAP (Security Content Automation Protocol) is a framework to maintain the security of enterprise systems. It mainly performs the following tasks:
Automatically verifying the availability of patches
Checking system security configuration settings
Examining systems for signs of compromise
For a description of the Web UI dialogs, see Section 14.5, “OpenSCAP Uyuni Web Interface”.
For instructions and tips on how to best use OpenSCAP with Uyuni, refer to Chapter 14, System Security via OpenSCAP. To learn more about OpenSCAP, see the project home page at http://open-scap.org.