Patching Linux/Unix endpoints using JetPatch is pretty simple. This article explains how the process works in general and what are the involved components.
JetPatch can leverage different patch sources to patch your endpoints. Here are the three solutions
- Vendor - Official repositories that are updated and maintained by the vendor.
- 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
- JetPatch Unified 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.
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, and apt) 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.
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 or apt 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.