Patching Linux Devices
This page contains information specific to patching Linux devices.
Contentless approach to patching on Linux
Ivanti's patching solution for Linux differs from that used for Windows and macOS. It is important to understand how the contentless approach to Linux patching differs from the content-based approach to Windows and macOS patching because it results in patch data for the different operating systems appearing at different times in Ivanti's products.
For Windows and macOS, the patch content data is curated and tested by Ivanti before being released to the products for use. For full details of this process, see the Ivanti Community. This approach is required as these operating systems allow software to be installed from a variety of sources.
Linux has a different approach, where deploying and maintaining the installed software is controlled using a Package Manager connected to distribution-specific repositories. Ivanti’s patching products use the device's repository sources to populate the patch content that is required during the patch scan. This is the contentless approach and enables the products to be more flexible. It enables you to use third party and internal repositories without the need for Ivanti to update its own patch content. Additionally, as soon as updates are available from the repository they are available for installation without the need for a Patch Content update from Ivanti.
Initially, no Linux patch data appears in Neurons until a device has been scanned and the data for that device has been uploaded and processed. As more devices are scanned, any additional data is merged to provide a more complete picture.
Ivanti Neurons for Patch Management follows the convention in patching Linux devices by always updating to the latest package available in the repository, even if an earlier version is selected. Note that for some distributions this is actually the only option available, as earlier versions of a package are not available from the repository.
When using the original dnf package manager provided with Linux distributions derived from Red Hat Kernel versions 8.1 - 8.4, the dnf pre-deployment scan may generate false-positive notifications that do not appear in the post-deployment scan results. This was corrected by Red Hat in the package manager provided with version 8.5, and can also be corrected using the command sudo dnf update dnf.
Modules and versions
You can't always install the latest version of a package on a Linux device.
For Red Hat Linux and distributions derived from Red Hat, a device may have modules installed that have several streams, only one of which can be enabled on a device.
Consider the case where an advisory wants to update a package in one of these types of module.
If the new version of the package is for a specific stream that differs from the enabled stream on a device, then the updated package is incompatible and cannot be installed. As a result, a later version of a package for a module will be available than the version that can be installed on a device.
Similarly, it may appear that the latest package hasn't been installed because of module dependencies. For example, the module perl-DBD-SQLite appears to have several module updates for the perl-DBD-SQLite package:
- perl-DBD-SQLite-0:1.58-2.module+el8.1.0+2940+55ca6856.x86_64
- perl-DBD-SQLite-0:1.58-2.module+el8.1.0+2940+f62455ee.x86_64
- perl-DBD-SQLite-0:1.58-2.module+el8.2.0+4265+ff794501.x86_64
- perl-DBD-SQLite-0:1.58-2.module+el8.6.0+13408+461b4ab5.x86_64
However, each of these packages has a dependency on a specific perl stream. The first can be installed only when perl:5.24 is enabled, and the last only when perl:5.32 is enabled, so it may be that what appears to be the latest version of a package cannot be installed on a specific device.