Managing Patch Jobs for Linux Assets
Patch Management allows you to deploy patch jobs on Linux assets. You can use a single job to deploy a single patch on multiple assets, multiple patches on a single asset, and multiple patches on multiple assets. You cannot target Windows and Linux assets in a single job. For security purposes, the Linux patches are downloaded manually and stored in a shared folder that must be accessible through a mounted directory on each server. This shared directory helps reduce the traffic, ensures file integrity, and is only exposed to selective servers. The patches are transferred to the repository only after successful assessment on the staging server. We recommend fetching the patch installation files directly from the vendor to assure authenticity and integrity.
Note:
- For Linux jobs, Patch Management does not fetch patches at run time. Before triggering a patch job, you need to create a Yum repository and make all the approved patches available in it. Yum provides all the dependencies required to deploy a patch, and it can automatically determine, fetch, and install all available dependent packages.
Linux distributions have online public repositories that include all approved patch files. Hence, the internet connection for these repositories works fine if it's configured according to the steps suggested by the patch vendor.
- The RHEL Extended Update Support (EUS) patches are supported for the RHEL 8.6 and 8.8 versions. These patches are also published in the patch catalog. You can deploy patches on your Linux assets from your EUS repository.
Supported Linux Versions
To know the supported Linux operating systems and the supported agent versions for them, refer to the Cloud Agent Platform Availability Matrix (PAM).
Note:
- You can apply only the latest Debian and Ubuntu patches. Ensure that the latest patches are available at:
- Qualys advisory as a security fix
- Debian and Ubuntu package repository
You cannot apply the intermediate patches because Debian and Ubuntu do not maintain history patches.
Consider this!
- Four out-of-the-box widgets are available exclusively for Linux patches. You can customize and add widgets based on your preferences.
- On the Assets tab for Linux, you cannot view the agent scan status based on the vulnerability scan. Agent scan date would be the date of the latest vulnerability scan on an asset.
- Superseded patches are not applicable for Linux.
- You cannot enable the opportunistic patch download to allow the Cloud Agent for Linux to download the required patches before a scheduled job run begins. The patches must be stored in a repository at a predefined location that is accessible to each asset.
- You can only create deployment jobs for Linux assets. Rollback jobs are not applicable for Linux assets.
- While creating a Linux deployment job, if you select an asset tag that includes Windows and Linux assets, only Linux assets will be added for the job.
- The job title for each job must be unique. You cannot have the same job title as a Windows job. For example, if a Windows job titled Security Patches is created, you cannot have a Linux job titled as Security Patches.
- If a deployment job contains multiple OS patches, then only the job assets with specific OS will have applicable patches installed. For example,
- A job that has a mixed set of patches that is both RHEL 6 and RHEL 7, but only RHEL6 assets, in this case, the status for RHEL 7 patches will be displayed as Skipped.
- A job that has RHEL 6 patches and also has RHEL 7 assets, in this case, no manifest will be sent and the status for the asset will be shown as Not Applicable.
Prerequisite
- You must install the Cloud Agent for Linux on each of your Linux assets before you can deploy patch jobs.
- Ensure that the patches that you want to install are available in the agent-side repository for the respective OS on the asset during the job execution. This configuration must be set up at the OS-specific setting and not specific for Patch Management.
About Zero-Touch Patch Jobs
All QQL-based recurring jobs are known as the Zero-Touch Patch jobs. All zero-touch patch jobs are denoted with the zero-touch icon 
The Zero-Touch Patch Job option allows you to create an automated job to proactively patch current and future Linux vulnerabilities.
