I do agree and lean towards using golang to have an easy binary but there's a lot of work already in this space for managing instances. I have a similar ansible task running on AWX to check instance updates but have had a backlog task to actually move it to Prometheus so the notifications and information are sitting in Grafana.
- It's a compiled language and not in the upstream repos of my dist, meaning something that needs to be built separately (yeah no I'm not downloading any prebuilt binaries thank you). While not without tradeoffs, rewriting it in shell script or maybe Python (sticking to libs available in apt repos) would make it a much easier sell and reduce the number of considerations before introducing it.
- A package on a machine is either auto-updated via unattended-upgrades or done manually via [rebuilding an image/running a playbook/whatever] which I already need a process for anyway. One more way to do the same thing is just more operational complexity.
That being said, I could see the value in a multi-distribution (ie apt/rpm/apk/pacman) utility which will trigger an event and call a command (send a notification) when there are available but unapplied updates for known bugs or CVEs. Would need to be runnable on offline server (possible meaning a split in two parts?) and without need for overly demanding centralized coordination like opening ports on every server or introducnig RPC. Puck currently looks like it wants to take a more centralized and active role than what I'd be after, though.
Your approach my still be valuable to others even if it's not my cup, though! Hope you enjoy making it and that it's useful for yourself already :)
(BTW, the name doesn't suck; no need to be apologetic (:)
The fact that this tool is unnecessary due to other tools existing is a fair point though.
> unless you want to edit the code and don't know GoLang, except that's also a skill issue.
How about editing the code live in a production environment currently lacking a debugger, internet, or compiler when it doesn't behave 100% according to expectations? Even if you have the debugger and compiler available and are comfortable using them, it's a world of difference in convenience.
> The fact that this tool is unnecessary due to other tools existing is a fair point though.
I never said that and do not believe that. Many options for the same thing can be great, let a thousand update helpers bloom I say. I guess we disagree on everything today :p