0

We have a Windows Server 2003 R2 machine running an LPD service for us as part of an ERP implementation. I use Nagios to monitor the network and have this host set up already. I am now trying to set up a service to monitor the Windows LPD service which runs on this host and ensure nothing sits in the queue too long. I found http://exchange.nagios.org/directory/Plugins/Operating-Systems/Linux/check_lpstat/details but I feel like I am losing my mind trying to configure it!

Nagios runs on ubuntu 10.04. I needed a package with lpstat, so I tried cups-client. lpstat -h [servername] just returned lpstat: transport endoint is not connected, and google gave me nothing on the error message except sparse bug reports for unrelated situations (install related mainly) so I tried lprng, which wanted me to first generate /etc/printcap, but I am not interested in the Nagios box offering print services so I abandoned that too. I started looking for another option and installed the lpr package hoping to make use of the lpq command I had seen in some of my google searches. Unfortunately, what I had seen must have been for a different implementation because it wouldn't accept the -H option (or anything else I could see to specify a remote host).

Obviously I am not going down the right track here. I know I can just telnet [servername] 515 and make sure I make a connection, but that is just going to tell me the port is open, right? That could return success and still there be an error holding a queue, right? (seriously, because if I am assuming wrong on those last two counts then I am making this needlessly hard).

Chris O'Kelly
  • 296
  • 6
  • 19

1 Answers1

2

You are correct, a simple TCP connection isn't going to reliably tell you the system is operational.

lpstat will try to connect to the IPP port, I believe the LPD service on Windows provides just a standard unix lpr on port 515 (see http://technet.microsoft.com/en-us/library/cc728404.aspx ).

The NagiosExchange check_lpq isn't a good solution here. You might be able to get away with using check_grep as a wrapper around lpq, you'll either need an lpq that will connect directly to the printer, or one that can connect via a working CUPS or lpr-ng.

This is probably your best bet: http://planet.pks.mpg.de/trac/site/browser/src/nagios/plugins/check_lpr.pl?rev=178&order=name

(click the "Original format" link below the source to download just the source). You'll need a working perl and the Net::LPR module. You may need to hack it a bit, especially if you need to add logic to detect stuck jobs. I can't say I've used it heavily, but it has worked fine for me with real printers and lpd (lpr-ng), though I have not used it with Windows/LPD.

$ perl check_lpr.pl -v -H hp1f01 -P Auto
OK - JetDirect lpd: no jobs queued on the port Auto

You could also consider using check_nrpe and nrpe_nt (or similar) with service/process checks on the Windows system to make sure the services are running correctly; or some powershell to query the print queues directly (e.g. via WMI).

mr.spuratic
  • 3,430
  • 20
  • 14
  • Thanks very much for the help, I think the PS/WMI route is likely where I'll go, seeing as NSC++ is already installed on the host for general "is it turned on" monitoring. – Chris O'Kelly Mar 26 '13 at 05:11