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. You must make the patches available in a Yum repository before triggering a patch job. We recommend creating a shared directory to hold all approved patch files that you must mount on all Yum-based Linux assets. This enables you to scale without caching, and proxying and is a more secure approach. It works without exposing your server assets beyond firewalls or tunnels, and it also ensures approved patch rollouts only when you put the patch files in the repository.
Supported Versions
- RHEL 6, 7, and 8
- CentOS 6 and 7
- Oracle Linux 6, 7, and 8
- Amazon Linux and Amazon Linux 2
- Ubuntu Linux 18, 20, and 21
- Debian 9, 10, and 11
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 i.e. 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.
