calestyo / check_yum

check_yum is now maintained again by its original maintainer at https://github.com/HariSekhon/Nagios-Plugins/
17 stars 20 forks source link

Add check for time since last update #3

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 9 years ago
I have written a plugin to check when the last yum update was done. I ripped 
quite a bit of code out of your plugin to do this. I could host it myself, but 
I think it would make sense for it to be hosted with this plugin. 

I'm attaching the plugin, and if you like it then please add it to your 
repository under the same licence. If you don't want to put it in the same repo 
then please say so and I'll put it in its own repo. I'm also happy to do some 
rework (or for you to do some rework) if you think it needs it.

Original issue reported on code.google.com by ham...@aptivate.org on 17 May 2012 at 1:52

Attachments:

GoogleCodeExporter commented 9 years ago
For now I've put it up at https://github.com/aptivate/check_yum_last_update - 
feel free to grab it from there or ignore it.

Original comment by ham...@aptivate.org on 25 May 2012 at 7:44

GoogleCodeExporter commented 9 years ago
Hi.

1) check_yum is not my plugin,... I just took over maintenance more or less.

2) I'll have a look at the plugin.
Generally I'd say it would be better to keep the YUM related Nagios checks 
together (e.g. at this place), so inclusion seems to be a good idea.

But maybe one should go even further, and directly integrate your plugin into 
the existing check_yum.
I have not yet a strong opinion on whether this is a good idea or not.
What would you say?

Cheers,
Chris.

Original comment by calestyo@gmail.com on 16 Jun 2012 at 12:34

GoogleCodeExporter commented 9 years ago
The "nagios way" appears to be to have one check per script, and for the 
scripts to be self contained. The two scripts check quite different things, so 
I don't think it really makes sense to combine them into one script, despite 
them containing similar plumbing code.

So if you're happy with that approach then please copy the file from github and 
add it to your repo. I'll then change github to point to here.

Original comment by ham...@aptivate.org on 11 Jul 2012 at 8:33

GoogleCodeExporter commented 9 years ago

Original comment by calestyo@gmail.com on 27 Sep 2012 at 1:33

calestyo commented 8 years ago

I'm just cleaning up old issues and considered this one again.

First, I'm already in very-very-low maintenance mode of check_yum, adding another plugin would probably mean more work ;-)

Second, I wondered a bit, what the last update time actually gives? AFAIU this is the date of the last time any single (or more) packages have been upgraded, right?

What does that information really give? It may have been just one out of many packages that was upgraded, and thus that information doesn't really tell anything about how well the system in question is maintained or not.

So for now at least, I think it's better to keep this separated. Most people will be anyway used to your repo as the location for that plugin :)

tkoeck commented 4 years ago

"Second, I wondered a bit, what the last update time actually gives? AFAIU this is the date of the last time any single (or more) packages have been upgraded, right?"

In bigger older companies there are fixed update windows for production systems. Say every quarter of a year. That would be a great tool to have.

HariSekhon commented 4 years ago

@tkoeck The All Updates mode of the plugin would seem to cover this situation (btw the upstream maintained version is at https://github.com/harisekhon/nagios-plugins).

I don't know if yum actually stores a "last upgraded" timestamp anywhere, maybe in the rpm db or the last timestamp of the yum.log, but that is updated for any package install too. I think in more cases the All Updates mode is what you want.

tkoeck commented 4 years ago

In most cases I would like an activated 'auto update' on all servers and don't have to care about manual updates anymore but we all live in an imperfect world. ;)

HariSekhon commented 4 years ago

I toyed with that last decade, too risky for prod really.

Containerization rolling updates supercedes this.