[Feature]: Pre and post actions for patching

We use PatchMon 2.1.3 for a Proxmox/PBS-backed Linux fleet and already operate this pattern through an external gate: a user submits an exact patch run for approval; a controller-side pre-action creates and verifies a Proxmox/PBS backup; only after that succeeds is that exact run approved. After patching, an optional reboot and post-action verify the boot ID, required services and HTTP endpoints, then wait for a fresh PatchMon agent report. A failed or expired backup or failed health check must block/fail the run, while the backup reference and hook result belong in the PatchMon audit trail.

For safe native support, hooks should be reusable allowlisted templates, selectable per host/group/policy; support target-side and controller/server-side execution; keep scoped secrets server-side; provide timeout plus blocking/warning semantics and redacted logs; receive immutable run/host/package context; remain idempotent and retry-safe; and preserve the existing approval boundary. A synchronous webhook/external-workflow hook would also work and could integrate Proxmox/PBS, Ansible/AWX/Semaphore and similar systems without giving every guest infrastructure credentials.

Use case: configurable post-patch commands

It would be very useful to have an optional post-patch command/script that can be configured per host or patch policy and executed after a successful patch run.

For example, I have a Pi-hole host managed by PatchMon. After PatchMon runs patch_all and the system packages have been updated successfully, I would like PatchMon to execute:

pihole -up

Ideally, the post-patch command should:

• run only after a successful patch operation
• be configurable per host and/or patch policy
• show stdout/stderr in the same PatchMon patch output
• support a configurable timeout
• allow defining whether a command failure should mark the patch run as failed or only generate a warning
• preferably support an allowlist of permitted commands/scripts for security

This would be useful not only for Pi-hole, but also for other applications that have their own update mechanism or require a post-update action.

In my case, having pihole -up executed as part of the same PatchMon patch run would be much cleaner than maintaining a separate systemd watcher on the host.

Thanks for considering this feature!

I support that. It should also be possible to choose whether the hooks should run on the target system or the Patchmon server.

For example, we need a way to trigger a snapshot of the VM in Proxmox before every patch run. To avoid having every VM require access to the Proxmox API, we’d ideally like to run the hook from the Patchmon host.

Thanks for this.

I’m going to merge this into pre and post patching feature requests

It should always be done through sudo in my opinion. Sudo rights can be used also using in combination with the NOPASSWORD setting in /etc/sudoers.
And yes, sudo is the same as if you're executing it as root user.

I agree on this feature, for like executing some scripts or doing before or after patching process work. Possibly configurable through a template or per-server pre/post action.

@EiTiFuzzi Hi, thanks for raising. Are you able to close the duplicate please? You should be able to.

Duplicate marked and closed

@EiTiFuzzi Hi, thanks for raising. Are you able to close the duplicate please? You should be able to.

duplicated

Running the agent without root rights is a good idea. But, if the agent user can get the root right with sudo for any command, is it the same as run on root user?

Hi Iby, thanks for your great work with patchmon. A tool I ever looked for. simple chance to keep a bench of servers up to date. I will wait for the new features...

Thanks a lot

Yes - this I also mentioned yesterday however I want to add this upon next few releases.

So far every command done by the agent is hard coded to avoid ambiguous commands being ran.

So I do want to make sure the agent runs as non-root as default before implementing pre and post script.

The other thing is that I have to work out the best way to handle the sudoers file to allow certain commands that run via the agent to be auto-elevated to root upon execution.

So in short, implementation of pre-post scripts is easy however right now it’s not secure way of doing it as the agent runs as root.

Once I give this part of it some time and dedicated attention and testing I will implement pre/post options.

Glad you’re playing with 1.5.0, i’ll be pushing a new update soon which handles notifications logic differently with delayed notifications which will wait for x amount of time before proceeding with notifications.