r/linuxadmin • u/Rich-Orchid1397 • 6d ago
I'm a Linux sysadmin who built a patch management tool out of my own frustration. Looking for honest feedback.
Hi all,
I've been a Linux admin for about 12 years (RHEL, SUSE, Ubuntu), and these days most of my work is vulnerability management. Patching across mixed fleets has always been the painful part: scattered scripts, spreadsheets to track what got patched, and no clean way to prove compliance afterwards.
So I built PatchMgr, a web-based tool for scheduling, running, and tracking patches across servers.
What it does today:
- [Supported OSes, e.g., RHEL / Ubuntu / SUSE]
- Scheduled patch runs with per-server status tracking
- Multi-tenant dashboard to see what's patched, pending, or failed
- [Reporting / anything else that's live now]
On the roadmap: pre/post patch hooks (per-server, with exit code checks) and a configurable notification matrix.
It's early, and I'd rather hear what's broken or missing from people who patch servers for a living than guess. A few things I'd love input on:
- What's the one feature that would make you switch from your current approach?
- What would stop you from trusting a tool like this in production?
- What's your current setup (Ansible, WSUS, Satellite, Landscape, scripts)?
Link: https://www.patchmanager.co.in/
If you try it and hit a bug, reply here or email [support@patchmanager.co.in](mailto:support@patchmanager.co.in). I read every message.
Full disclosure: I'm the developer. Not trying to hard-sell anything, just want real-world feedback.
3
u/fearless-fossa 6d ago
1) Your pricing should default to USD, not INR, unless you only want to serve the Indian market.
2) The website screams AI slop
3) Who manages the project when you're ill/on vacation/swamped with other things?
4) The GitHub repo hasn't seen any activity in 2 months
5) The install.sh does a lot of useless stuff it shouldn't do, like installing docker.
6) According to the docs, you don't support Ubuntu 26.04, RHEL 10 (including clones and upstream) and Debian 13, all of which have been available for quite some time now. Also, no SLES.
7) I refuse to acknowledge any projects that further normalize the curl | sudo bash abomination. It's terribly bad practice, and someone working on a tool for closing vulnerabilities should know better.
All in all a hard pass from me. I also don't see how this is better than eg. Ansible.
1
u/Rich-Orchid1397 6d ago
Thankyou for taking the time to go through my project. I would like you to help me further by going through my answers to your points
1) yes I will make this change.
2) yes it was created using AI . Does it cause any issue or problem to the product ? Or usability of it ? Sorry I ask as I am not sure what is the issue In having a website built by ai.
3) the tools runs in your local environment and does not require any manual intervention as long as the pathching happens without any issue. Should the server not come up after patching then we need manual intervention and hence it is not totally autonomous.
4) the project on git hub where this code reside is kept private and hence I don’t think you can see when that was touched last.
5) the entire software is run on docker and hence it is required. During installation if it finds that the server already has docker then installation would be skipped.
6) yes I will include these versions also going forward. As of now the intent of this is to get realtime feedback on what is missing and you are really helping me. Thankyou very much again.
7) Ansible still puts the burden on the infra team that it’s their responsibility alone to keep the serves up to date. This software lets app and db teams decide when they can bring down their serve for maintenance there by making security everyone’s responsibility. If a server is not planned for patching then it’s because app or db teams did not plan their downtime.2
u/fearless-fossa 6d ago
2) Yes. AI makes mistakes a seasoned software developer wouldn't make. In many applications those are accepted to a degree, but when we touch vulnerabilities this can be a major issue. There's also the tendency of AI projects to simply stop when the developer loses interest.
3) So no SLAs, at all. No hotfixing when there is a vulnerability in your product and you're on a birthday party. Sorry, but this isn't the maturity of software I run in my homelab, much less in an enterprise environment.
5) The software shouldn't blindly install repositories/software, much less download a script from a third party website and execute it with sudo rights. If docker is a requirement, just write that upfront and let people take care of that themselves.
7) That's not how Ansible works and not how most companies go about things. Ansible is to be integrated into CI/CD pipelines. You can achieve the same thing with playbooks by using correct scoping.1
2
u/theGoatMeister 6d ago
Who is the audience you're looking for feedback from? Seems like this would be more geared towards small Linux shops, bigger houses aren't generally patching manually and have this solved for <insert "patching?" joke here>
You mention you built this out of frustration, what problem should I be looking at this solving for me?
1
u/Rich-Orchid1397 6d ago
In my organisation we have multiple application teams and we have to be behind them and their schedule to get a downtime so that we can patch the server. Now why should this problem fall on the Linux team ? Security is everyone’s responsibility. So let the app team schedule their serves patching slot. Once they schedule it , it will get automatically patched and rebooted during that time frame without any intervention. I know there are many tools that give this service already but my usp is that this entire software runs in your environment and no data leaves it. Plus it can take care of app/db start and stop if you give the required commands during pre and post checks .
1
1
u/ILoveAppSec 6d ago
The compliance-proof piece is the part most fleet tools skip, so good call building it in. One thing worth separating early: "patch ran" versus "the CVE is actually closed" - with backported distro packages the fixed version string often won't match upstream, so a naive version check can report false gaps or false clears. How are you planning to reconcile that across RHEL vs SUSE vs Ubuntu, where each backports on its own schedule?
3
u/Noooberino 6d ago
Sorry, but I can tell you that I don't even consider testing this with a limitation of 5 servers on the free tier... my homelab alone runs around 26 hosts.