Directory

I was looking for a routing check. I found this here, expecting not much, but isn't it obviously a bit weird, that you use a program named 'tracert' instead of traceroute?

I could not find any information that on Unix systems there ever existed a tracert - tracert is imho a windows command, so the script won't work unmodified. Also, I can't see any 'Nagios Plugin Guidelines' applied to this little scriot.

Nevertheless good for learning approaches.

Hi,

I tested this plugin and it did not work correctly out of the box on the command line because it did output nothing at all (but web ui said "OK"). Looking into the code the problem was on line 140 where it says
my $TRAFFIC_FILE = "/usr/local/nagios/libexec/traffic/";

This directory did not exist on my system; this caused the plugin to output nothing. After adding this directory, it worked. Maybe add a test if directory exists and throw an error if not?

I miss two features though, whose availability would easily push this plugin to a five star plugin(!)
- error packet counter and corresponding warn/crit tresholds
- automatic port speed detection

These two are very important IMHO:
- error counter
If the error counters grows, you could be alarmed; thanks to performance data, you would even have some long time trending, being able to research when errors increased e.g.

- auto-detect port speed
If the network admin decides to change a port speed from 100M to 1G, the plugin settings for this specific port will become incorrect. Auto-detection could help here.

If you start the plugin with debug level 4 you can see that port speed detection _would_ already work. The command

/usr/lib/nagios/plugins/check_iftraffic64.pl -H 192.168.123.123 -C not-so-public -i 1 --debug 4

outputs (shortend):

OID's:
IfOperStatus: 1.3.6.1.2.1.2.2.1.8.1
IfSpeed: 1.3.6.1.2.1.31.1.1.1.15.1
IfSpeed32: 1.3.6.1.2.1.2.2.1.5.1
RESULTS:
Operational Status: 1
Interface Speed (64bit): 100 Mbits
Interface Speed (32bit): 100000000 bits

So there is already a port speed detection, but not used in any way - maybe it is unreliable?

Since I cannot re-review a plugin here, I will mark it with 5 stars, hoping the author might add these two features in the future.

Hi there,

I was using this plugin but it seems, lot of changes were made. When I started using it, it was called "check_ups_apc.pl" and version was "1.3".

I was having problems with UPS APC model 5000 in England, because they tended to report "onSmart Trim" - this is "output_status == 12" which was not covered in the old plugin, causing it to report "unknown state".

Now I was curious to see how much the new plugin has been improved, but afterwards I was wondering, why the variable "output_status" was removed completely.

So basically with this plugin, you cannot detect if the UPS is in "onSmartTrim" mode (trimming overvoltage).

It would be great if this state could be implemented in this plugin, since all APC support this feature - and it wouldn't hurt those who can't. On the other hand, this plugin is a great starting point for my own improvements.

Please let us know if you plan to improve this plugin and throw in another 2 cents ;-)

I must agree with user rrubel: considering a non initialized hot spare as a critical error is just plain wrong. So thanks go to user mtominsk for pointing out the lines of code that needed to be changed.

And just to be fair with all respect to the Nagios Plugin Developing Guideline: this check totally lacks a critical and a warning switch which would really make sense when monitoring temperatures.

So I really cannot consider this as a "good" nagios plugin, only average, because I cannnot define any limits. But it is still a good starting point for people who do not fear bash scripts.

Sadly, the author does not seem to be very active so be prepared to make your own changes to the script.

Successfully tested and used on Ubuntu 10.04.4 TLS with Nagios Core 3.2 and a Synology RS3412RPxs in Cluster-Mode.

This plugin is written in perl and when I executed it on the CLI, it worked like a charm!
But when I tried to run (the same query) through nagios, I got an error: (Service check did not exit properly)
The problem was with the nagios system account; I had to allow it, to use sudo. After modifying /etc/sudoers and nagios-commands.cfg it did the job.
Since there was no hint to do that, I have to substract 1 point for the style marks.

Tested with Nagios Core 3.2.0 on an Ubuntu 10.04 with a QNAP TS-809U.

Thank you for your achievement.

Hello,

I just tested this plugin and I have to say: this script does not what it should do (on Ubuntu 12.04)

I have a mountpoint, say /media/user/share which is defined in /etc/fstab. I ran the plugin as root and it said: "OK: all mounts were found (/media/user/share)".

Then I unmounted this share from the client,re-ran the plugin and it still claimed to be mounted: "OK: all mounts were found ( /media/user/share)".

Since Ubuntu is binary-compatibel to Debian I do really wonder why this script/plugin gives totaly wrong information (moreover, Ubuntu also uses /proc/mounts and /etc/fstab).

To put it in a nutshell: I can't blame Ubuntu for the wrong result of this plugin. I wonder how that can be, since it was updated some weeks ago :(

I will use /bin/bash -x to see if I can "debug" this script (maybe just a wrong loop logic) but consider this the reason for a low rating.

Without the bug I see on Ubuntu this would be a great plugin!

This review is considering the installation and documentation Nagios Core only.

This might be a great Add-On but I have to rate it as very poor because there is no such file set_bpi_perms.sh as mentioned in the INSTALL file.

I consider this really poor. As a work-around, it would have been nice to know what permissions/privileges are needed so one could do it manually.

Right now I'm only guessing (like chown nagios:www-data) and guessing is rarely good when reliably mapping business processes into Nagios.

If I get it running manually I might change the rating.