When there are module updates that are *not* security updates, Drupal update status sets a warning instead of a critical error. This makes sense - Drupal is not insecure, just out of date. No need to make this critical, right?
I've traced through what is coming back from the nagios_check_requirements() function, and it is returning a Nagios warning as well, however for some reason this is being treated as Critical in the Nagios service status page:
Test Site Drupal Requirements
CRITICAL 2011-03-13 20:23:07 0d 20h 16m 40s 4/4 ADMIN WARNING - Module and theme update status
The message from Drupal even says "ADMIN WARNING" yet it's coming through as critical - I'm not sure why this is, but I don't like it. Any ideas what the cause might be? Perhaps Drupal sending the wrong value? Are the constants out of date maybe?
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | 1091314-2-updated_nagios_error_levels.patch | 738 bytes | greg.harvey |
| #1 | 1091314.patch | 746 bytes | mig5 |
Comments
Comment #1
Anonymous (not verified) commentedIt seems the plugin return codes are wrong/out of date, at least for Nagios3.
See Plugin Return codes here: http://nagiosplug.sourceforge.net/developer-guidelines.html#AEN76
or here: http://nagios.sourceforge.net/docs/3_0/pluginapi.html
Patch attached.
Comment #2
greg.harveySlightly revised patch - the above was making drush make error out. This one makes drush make happy. =)
Comment #3
Anonymous (not verified) commentedThe patch was made with git diff, I think Drush Make has a bug in that it can't support a patch -p1. See #745224: Apply patches from git diff and git format-patch :)
Comment #4
greg.harveyOk, Khalid has very kindly made me co-maintainer so we can push this along a little. I'm setting this back to "needs work", because we're changing the expected Nagios codes. While this would be safe for new installs, we need to consider the possibility people are already running with modified Nagios codes to match the ones in the module. So, with that in mind, this patch needs to be a little more complex:
1. I need to roll some sort of beta release of the current Drupal 6 module (I think that's safe - we've verified it works fine)
2. This patch needs to *assume* people have set up Nagios to work with the old version and provide an upgrade path and a UI for mapping the codes (e.g. the errors need to be variables, not constants, there should be a UI for changing them and hook_update_N() needs to set the variables to the old values so there will be no interuption in service as a result of an upgrade, unless people have hacked the current module, in which case they're on their own!)
Edit: Obviously the patch needs re-rolling *after* the beta1 release, otherwise an upgrade path would be meaningless, so let's park this for a week or two.
It's a bit more work, but given the nature of the module and the sort of people most likely to be using it, we need to tread particularly carefully here. This needs to be rock solid. =)
Comment #5
greg.harveyAssigning to *me*.
Comment #6
greg.harveyBumping myself! *sigh*
Comment #7
greg.harveyHave moved the defined values to variables, created the upgrade path and set the defaults according to mig5's patch in #1 - still needs a UI, but the upgrade path means this can be safely committed and advanced users can massage the variables with drush:
Comment #8
greg.harveyFinally committed the last change, the admin UI. Yay!
Comment #9
greg.harveyActually, not closed - to be ported to D7.
Comment #10
greg.harveyCommitted to D7.
Comment #11
kalabarigi.aditya commentedHi Greg,
I am a quite new to this whole stuff, but I have to fix the simillar problem at work. Please could you tell me how to install the patch. I see a piece of code when I click on the patch, so how do I install it.
We keep getting the alerts on Nagios with the below error messages.
[1323189464] PASSIVE SERVICE CHECK: ;check_drupal;2;DRUPAL CRITICAL, ADMIN:CRITICAL=Module and theme update status (certificatelogin:NOT SECURE date:NOT CURRENT fckeditor:NOT CURRENT imce:NOT CURRENT pathauto:NOT CURRENT token:NOT CURRENT views:NOT CURRENT views_bulk_operations:NOT CURRENT), CRON:OK
Comment #12
greg.harveyJust update the module, the fix is in.
Comment #13
kalabarigi.aditya commentedGreg,
Thank you for looking into this. I understand the fix is to install the patch or update the module.
It will be great if you can tell me how. When you say module, did you mean the check_drupal module ?