[Feature]: Update all, and reboot options
What is the installation method of your PatchMon server?
No response
What is the version of your PatchMon server?
v2.0.2
Briefly describe the feature
Add support for Update all and reboot manually and automatically
Detailed description
This is a cool project, but I am missing important features to update all devices and then reboot.
Why is this useful?
Right now I only use Patchmon to see pending updates. Then I use ansible to carry out these updates and reboot if needed. I would like to have all this function inside Patchmon
17 Comments
This feature add so much security risks to patchmon. If this feature is added to Patchmon, it can be disabled to reduce the attack surface.
Good morning\afternoon jbcr. I am curious too understand your thoughts a little further as I wander how this would be any different from any other patching system?
But maybe we need to break down if it is the "Patch All" part or the Reboot part you have a concern over.
What concerns me is the remote root access granted to a tool.
Many companies need to monitor systems and restrict privileges as much as possible.
Some companies even go so far as to use read-only file systems.
Features such as updating and rebooting must be capable of being disabled to allow PatchMon to function correctly on a read-only system or when running as a non-root user.
With these features disabled, PatchMon can list available updates but must exclude the hosts when it comes to actually applying them.
Thank @jbcr I agree that this should be controlled so we are on the same page with that.
+1 ;)
I agree on this feature.
Would help a lot.
Any progress in this regard?
Thank you for this very helpful tool!
This was also brought up in #828 and #764
This would be ideal as a tickbox in a patching policy, since there are servers I would be confident to restart without further checking and others that are critical or require carefully managed restarts.
Definitely!!
Now I have this wonderful tool I don't want to use a shell at this point.
Especially this could be done from my tablet.
SSH from my tablet will be a little tricky, due to the fact that we're using keyless SSH with short living certificates.
BR SMF
Hi this is not there yet its on the todo list along with per and post patch events.
Hopefully will be in a build not to far from this one as the discord team have also been asking for it there since the release of V2
It will be released in one of the next versions! 👍 it's in the roadmap
For Ubuntu you can use "apt-mark" to place a hold on a package and on Fedora "dnf versionlock" would achieve the same and installing updates via PatchMon does not overwrite this.
However being able to specify a reboot action after a successful update run would be really nice.
i too, would also like this (post update reboot)
I would (highly) support the Post-Update reboot option too 😊
Personally it's not very difficult to get the agent to also have a reboot command and wire it in the Ui however I feel like once within the next few releases we have PatchMon agent running as its own user with scoped permissions tested and cater for both sudo and non sudo environments - only then is it worth have features like pre/post commands and hooks like reboot if required.
It's very tempting for me to build this (and accept the Pull Request for this) but the security takes priority in this case. This way when we implement the secure way of having "allowed commands" list then we can easily see what the list of commands and tools it has access to such as wget, curl, /usr/local/bin/xyz and /etc/patchmon/scripts/stop_start_services.sh etc.
This way we can clearly see what the agent has permissions to execute as that user "patchmon_user" part of the group "patchmon_group" therefore when we want to allow a script or executable to be accessed by the patchmon agent then we will grant patchmon_group access to it.
Amongst this, it's twinned with giving instructions on setting up PatchMon in rootless mode and changing the installation scripts so that the containers are all ran with absolutely minimum permissions. We have had good progress so far with tightening the security over time through things like embedding the agent builds inside the container image as opposed to having a seperate docker volume that can be writable and other improvements with our CI/CD pipeline for releases.
So the question isn't about building the feature itself, but the drawback is my vision to sure security is to a maximum before we let the juicy features in.
Hope that helps with my understanding of it, open to feedback.
If we look at the way SolarWinds handles agent management, the agent itself runs under SYSTEM (runs as as service) - if you want to run any additional scripts or monitor specific applications, then you have to provide relevant credentials.
From their documentation - for Windows - "After the agent is installed, it runs as a Local System account and does not require administrative permissions to function."
for Linux - "After the agent is installed, it runs under dedicated swiagent account. Some actions require root access."
You also have an additional lever of role permissions at the user level within the platform itself. E.g. a regular user in PatchMon shouldn't be able to initiate a host reboot, but they may be able to authorise a patch run. Same for SSH access or anything else.
You essentially have a user restriction in the system itself, but then you also need to run anything else at the Agent level with an elevated access.
In the ideal scenario with PM and I think that's what is being worked on, is that the PM agent would run with a non root account, and then be elevated where required.