У нас есть машина с Windows Server 2003 R2, на которой запущена служба LPD в рамках реализации ERP. Я использую Nagios для мониторинга сети, и этот хост уже настроен. Теперь я пытаюсь настроить службу для мониторинга службы Windows LPD, которая работает на этом хосте, и убедиться, что ничего не остается в очереди слишком долго. я нашел http://exchange.nagios.org/directory/Plugins/Operating-Systems/Linux/check_lpstat/details но я чувствую, что схожу с ума, пытаясь его настроить!
Nagios работает на Ubuntu 10.04. Мне нужен был пакет с lpstat, поэтому я попробовал cups-client. lpstat -h [servername] только вернулся lpstat: transport endoint is not connected, и Google ничего не дал мне в сообщении об ошибке, кроме разреженных отчетов об ошибках для несвязанных ситуаций (в основном связанных с установкой), поэтому я попробовал lprng, который хотел, чтобы я сначала сгенерировал /etc/printcap, но меня не интересует ящик Nagios, предлагающий услуги печати, поэтому я тоже отказался от него. Я начал искать другой вариант и установил пакет lpr, надеясь использовать lpq команда, которую я видел в некоторых моих поисках Google. К сожалению, то, что я видел, должно быть, предназначалось для другой реализации, потому что она не принимала параметр -H (или что-то еще, что я мог видеть для указания удаленного хоста).
Очевидно, я здесь не вернусь. Я знаю, что могу просто telnet [servername] 515 и убедитесь, что я установил соединение, но это просто означает, что порт открыт, верно? Это может вернуть успех, но по-прежнему будет ошибка, связанная с удержанием очереди, верно? (серьезно, потому что, если я ошибаюсь по этим двум последним пунктам, я делаю это излишне сложным).
Вы правы, простое TCP-соединение не может достоверно сказать вам, что система работает.
lpstat попытается подключиться к IPP порт, я считаю, что служба LPD в Windows предоставляет только стандартный unix LPR на порт 515 (см. http://technet.microsoft.com/en-us/library/cc728404.aspx ).
Биржа NagiosExchange check_lpq здесь не лучшее решение. Возможно, вы сможете обойтись без использования check_grep как обертка вокруг lpq, вам либо понадобится lpq который будет подключаться напрямую к принтеру, или тот, который может подключаться через рабочий CUPS или lpr-ng.
Вероятно, это ваш лучший выбор: http://planet.pks.mpg.de/trac/site/browser/src/nagios/plugins/check_lpr.pl?rev=178&order=name
(щелкните ссылку «Исходный формат» под источником, чтобы загрузить только исходный текст). Вам понадобится рабочий Perl и Net::LPR модуль. Возможно, вам придется немного взломать его, особенно если вам нужно добавить логику для обнаружения зависших заданий. Я не могу сказать, что я много использовал его, но он отлично работал у меня с настоящими принтерами и lpd (lpr-ng), хотя я не использовал его с Windows / LPD.
$ perl check_lpr.pl -v -H hp1f01 -P Auto
OK - JetDirect lpd: no jobs queued on the port Auto
Вы также можете рассмотреть возможность использования check_nrpe и nrpe_nt (или аналогичный) с проверками служб / процессов в системе Windows, чтобы убедиться, что службы работают правильно; или какой-нибудь PowerShell для прямого запроса очереди печати (например, через WMI).