How do automatic agent updates work?
If you have installed the package for real-time scanning, automatic updates will also apply to that package. If you don’t have it installed yet, you need to manually install it first - Patchman can’t automatically perform this installation for you, for security reasons.
The Patchman agent is capable of performing unattended automated updates. This saves you time and effort whenever we release a new version, and ensures that all your servers are always running the latest version with both the newest features and the latest bugfixes.
Configuring automatic updates
Disabling automatic updates
Automatic updates are switched on by default, and are available for agents with version 1.7.0-1 and higher.
If you do not wish to benefit from automatic updates, you can opt out through an option in the Portal. The option for controlling the automatic updates can be configured per server group. To disable automatic updates for a server group, navigate to "Server > Server groups", and then select the relevant server group in the list. Scroll down to "Miscellaneous settings" and deselect "Automatic updates".
Repository name modifications
By default we assume the repository is named "patchman", as will be the case if you use our installation script to install the repository on your system. If you decided to rename the repository definition, you can configure the alternative repository name by adding the following data to the file /etc/patchman/patchman.ini (create it if it does not yet exist):
[updates]
repository = patchman
Naturally, replace "patchman" with the appropriate value. Make sure to reload the daemon after modifying the file:
service patchman reload
Our update process will use the new repository name where appropriate.
Under the hood: steps in automatic updating
As a system administrator you may want to know how the updates are performed. In particular, you may be interested to know what checks we perform to ensure successful updates, what rollback procedures are involved if an update fails, and how the validity of each update is verified. This section lists all the steps the agent takes including some background information regarding the how and why for each step.
When building the updating procedure, our goal was to simulate the steps and checks involved in any manual update, and you'll notice that we're closely following the steps you might take if you manually performed an update of our software on your system. In particular, we made sure that we relied on the system package managers as much as possible (since that is what these systems were built for) which means we can delegate package signature validation and repository downloading to those proven tools. Additionally, we picked the steps involved in such a way that it will never update anything other than the patchman-client and patchman-client-realtime package, even if an update dependency requires it. If we ever update our dependencies, we will require a manual (attended) upgrade from you. All of this is done to ensure we don't modify anything on your systems that is not strictly required for purely updating our own software.
In the steps below, wherever actions are performed for the patchman-client package, they are repeated for the patchman-client-realtime package if (and only if) you have that installed.
CentOS/CloudLinux
Clean the cached metadata for the patchman repository to ensure issuing an install command will result in new metadata being downloaded from our repository
On CentOS 6 and 7:
CODEyum clean all --disablerepo="*" --enablerepo="patchman"
On CentOS 8:
CODEdnf clean all --disablerepo="*" --enablerepo="patchman"
Download the most recent version of the patchman-client package into the cache directory (and parse the associated filename). If no new version is available, stop the update procedure.
On CentOS 6 and 7:
CODEyum install -y --downloadonly --downloaddir=<patchman tmp dir> patchman-client
On CentOS 8
CODEdnf install -y --downloadonly --downloaddir=<patchman tmp dir> --verbose patchman-client
Determine the filename of the downloaded package using the filename from step 2.
Install the downloaded package using rpm. Since rpm is not able to download any potentially missing dependencies, this step will automatically fail if any unforeseen dependency problems arise.
CODErpm -U /<patchman tmp dir>/patchman-client-1.2.3-1.rpm
Parse the output from the rpm command to check whether the update succeeded.
If the update is successful, the agent will restart itself after completion of the update procedure, ensuring the server is running the newly installed version afterwards.
Debian/Ubuntu
Read the filename that contains our repository definition and the path to the cache directory. This means parsing Dir, Dir::Etc, Dir::Etc::sourceparts, Dir::Cache and Dir::Cache::archives from:
CODEapt-config dump
Update the cached metadata for only the patchman repository. This is done by telling apt to perform the update while thinking our repository is the only repository definition.
CODEapt-get update -o Dir::Etc::sourcelist="/etc/apt/sources.list.d/patchman.repo" -o Dir::Etc::sourceparts="-" -o APT::Get::List-Cleanup="0"
Check whether a new update for patchman-client is available by parsing the output from:
CODEapt-cache policy patchman-client
If a new update is available, download it (and parse the associated filename).
CODEapt-get -d install patchman-client
Determine the filename of the downloaded package using the cache directory and the filename from step 4.
Install the downloaded package using dpkg. Since dpkg is not able to download any potentially missing dependencies, this step will automatically fail if any unforeseen dependency problems arise.
CODEdpkg -i /var/cache/apt/archives/patchman-client_1.2.3-1.deb
Parse the output from the dpkg command to check whether the update succeeded.
If the update is successful, the agent will restart itself after completion of the update procedure, ensuring the server is running the newly installed version afterwards.
In step 3, we used apt-cache madison patchman-client
until version 1.14.0-1.