Назад | Перейти на главную страницу

Некоторые отпечатки PostScript из SAP вызывают наводнение на сервере RPM

Эта ситуация может быть немного локализована, но корень проблемы означает, что это может происходить, пока вы передаете PostScript (и, возможно, другие типы заданий печати) через брандмауэр с контроль приложений или включена аналогичная функция (скажем, потому что у вас есть VPN-туннель к удаленному сайту).

Мы бегаем Brooks RPM на настольном компьютере, чтобы принимать задания печати PostScript с нашего сервера SAP. По сути, он применяет сценарий для преобразования входных данных (файла PostScript) в PDF, дает ему красивое имя и отправляет его на адрес электронной почты пользователя с предварительно отформатированной строкой темы для упрощения пересылки. Сервер SAP физически находится на нашем сайте. У меня есть пользователи SAP здесь и на удаленном сайте, к которому мы подключены через VPN-туннель (детали подключения не имеют значения).

Время от времени определенные документы отправляли на сервер бесконечно повторяющиеся задания на печать при печати. Симптомы были следующие:

Чтобы решить эту проблему, нам пришлось остановить службу очереди принтеров Windows, очистить% WINDIR% \ system32 \ spool \ PRINTERS и перезапустить службу очереди принтеров - только тогда повторяющиеся задания на печать останавливались. Мне показалось совершенно странным, что распечатки каждый раз будут иметь разное содержимое - я догадывался, что сервер SAP постоянно генерирует искаженные файлы PostScript в ответ на каждый отчет о сбое с сервера печати, но это было опровергнуто, когда мы проверили журнал спула принтера SAP. - для каждой попытки печати был зарегистрирован только один вывод. Исходя из моего (правда, отсутствующего) понимания буферизации печати, задания на печать не должны были иметь разный контент каждый раз, поскольку контент фактически не регенерировался.

Оказывается, я был наполовину прав - задания на печать были испорчены, но не SAP.

tl; dr version: это был SonicWALL App Control.

Парень, который написал сценарий, удаленный администратор сайта, мой босс и я сели за мой сайт, чтобы решить проблему. Нам удалось изолировать проблему от того, что происходит при передаче - образец файла PS в спуле сервера RPM был поврежден, но соответствующий файл PS на катушке принтера клиента был совершенно нормальным, когда мы преобразовали его в PDF. Более того, использование портативного компьютера администратора удаленного сайта (помните, он был с нами на моем сайте) для печати проблемного документа не вызвало флуда.

Мы запустили флуд с удаленной машины и снова проверили сеть - трафик выглядел совершенно нормально. Затем администратор удаленного сайта взглянул на несвязанный журнал и обнаружил, что что-то совершенно не так:

Оказывается, приложение SonicWALL App Control неправильно определяло трафик заданий печати как передачу файлов IM и прерывает соединение при обнаружении - это объясняет несогласованность содержимого заданий печати. Как только мы добавили наш сервер печати в белый список брандмауэра, проблема исчезла.

Сейчас это кажется очевидным, но задним числом 20/20.

Итак, вкратце: если у вас возникают проблемы с заданиями на печать, которые проходят через брандмауэр, проверьте, не улавливаются ли они какой-либо фильтрацией приложений.