Linux/Unix Solution Overview

Patching Linux/Unix endpoints using JetPatch is pretty simple. This article explains how the process works in general and what are the involved components. 

Patch Source 

JetPatch can leverage different patch sources to patch your endpoints. Here are the three solutions

• JetPatch Unified Linux Repository solution - A single server with a Docker image that contains containers for local mirror repositories of various Linux/Unix-based operating systems, flavors, and versions. Learn more here.
• Local Repository - locally managed repositories that contain binaries and the meta-data of the packages. This solution is recommended for example when there is no internet connectivity in your environment. Learn more about local repositories
• Vendor - Official repositories that are updated and maintained by the vendor.  
• Note for AIX - it is dependent on a NIM server (see overview)
• Note for Solaris 
  • Solaris 10 repo (uses /var/sadm/install_data/rec_patchset_version to track installed patchsets)
  • Solaris 11 repo (uses pkg, similar to YUM)

How does it work?

Deploy the Connector 

JetPatch agent (the Connector) should be deployed on the endpoint. The connector will enable live status of the endpoint and will help you ensure your compliance level at all times. 

Collect Endpoint Updates

After the agent is installed, the “Collect endpoint Updates” built-in system task will run which leverages the built-in capabilities (yum, zypper, apt, etc) on the endpoint.  The execution results, which includes data on already installed updates and needed updates, will be written into /var/cache/JetPatch/scan_result.txt

In the first run of the script, a scheduling job is created on the endpoint to scan the updates automatically without JetPatch. Learn more on the endpoint scan mechanism 

The built-in system task checks the patch distribution on the endpoint -  Which patches are already installed, what are the patches that are missing (needed patches), and detects if patches have failed. Depending on the operating system, JetPatch will correlate the data which derives from the endpoint with an external Patch source to match the advisories and packages. 

Download Patches outside the Maintenance Schedule timeframe 

As part of the “Collect endpoint Updates” JetPatch can download all the needed patches to the endpoint. This option is disabled by default. If you would like to enable and save crucial time during your maintenance window, follow the instructions in this article.

Patch installation 

Assuming there is an active remediation plan on the endpoint, JetPatch will install the patches during the assigned maintenance Schedules. 

JetPatch installs the packages using the “execute patch installation” task which uses yum, zypper, apt, etc on the different Linux/Unix distributions. JetPatch retrieves the binaries from the repositories (either local or the official vendor repositories) and installs the packages on the endpoints. 

There are two possible installation methods:

• One by one (default)  - Each installation is a separate command. This method takes a long time but if one of the patches failed to succeed it will not affect all other operations. 
• Bulk install - collect all the needed updates and install all the patches in a single command line (batch). This is the faster way to install but keep in mind that if one of the patches fails the entire operation would fail as well.

Please note: If an installation of a patch fails (i.e packages were not installed properly for some reason), the operating system itself will rollback and will revert the transaction. If the process was in bulk - all patches will be reverted. If the rollback is One-by-One, it will revert the patch installation (of the patch that failed). The successful operations of One-by-One will remain the same.  

Removing  patches (rollback) 

It is possible to rollback the patches that were previously installed by JetPatch. The installation transaction ID is stored and when a rollback is required, the patch will be removed. 

Please note, if the previous package version does not exist in the repository, the patch operation will fail.