Вложенная рекупсия (типа страшнее купса зверя нет!)

[dimbor]

Жил я тут поживал годами со своими серверами терминалов под старым системами. Организовывал клиентам ipp печать по цепочке из трех последовательных купс серверов. Можно крутить пальцем у висков и прочих неприличных мест, но там в схеме изначально их было пять! Исключение одного из них в свое время уже было победой. А давеча поднатужился и еще один убрал.

Пересчитываю: Начальный купс на далеком сервере кормится заданиями от приложений. К оконечному подключена железка. За компом со средним купсом сидит клиент с принтером ipp://<IP-оконечный>/printers/HP_LaserJet_P1006, к примеру. Порт среднего купса торчит на сервере. Серверный принтер выглядит так: ipp://127.0.0.1:6001/printers/HP_LaserJet_P1006.

С купсами версий по 2.1 включительно схема работала безупречно при полном комплекте дров на оконечной системе и соответствующем ppd на остальных. Работала и работала. Как работала - хз. Потому как эти купсы были вроде добрых огрызочных черных гномиков, которых нужно только правильно кормить.

С купсом 2.2.1, соответственно, схема сломалась. Иначе б не изливал тут гной. После начала разбирательств выяснилось, на оконечный купс с типом application/vnd.cups-pdf прилетает pjl, пытается пройти цепочку фильтров и ожидаемо абортируется. Средний купс не при делах: принимая задания любых типов, он принципиально не применяет фильтров и отправляет их как есть посредством backend/ipp.

Дело в начальном купсе, естественно. Этот гад применяет все фильтры из ppd, рожает унутре себя vnd.cups-postscript и зачем-то пускает renderer. А получившийся pjl отправляет под видом vnd.cups-pdf тем же backend/ipp. Причем такая штука - конфигурации у начального и среднего купсов идентичны. Отличаются только uri принтеров. Больше ничем кроме наличия в нем локалхоста причины начала чудес объяснить пока не могу.

Ситуевину я порешал, но вот метод мне сильно не понравился. Шаманство заключилось в замене в ppd начального купса значения *FoomaticRIPCommandLine на "cat". Теперича на конечный прилетает постскрипт с тем же типом vnd.cups-pdf. А он и говорит: "это ж postscript, печатаю". И печатает, собака.

Тут вам не здесь. Не хиханьки и не пляски с бубном. Ну не только они... В процессе перечитаны тонны бесовской англоязычной документации на купс, даже частью Programming Manual зацепило. Но так и не вкурил, на основе каких критериев купс принимает решение о запуске рендерера. А найденные ответы на вопросы в этом вашем интернете по большей части сводятся к "Запустите lpadmin -o тру-ля-ля=офигеть. Не получилось? Обновите. Запустите..." Ну не захардкожено оно там? Может подскажет кто, хоть что еще почитать?

[serzh-z]

Могу лишь посочувствовать. Каждый раз, когда хочется подключить дома принтер, приходится с самого начала разбираться в архитектуре печати Linux, а через полгода все забывается. Помню, что foomatic, кажется, решал много задач по матчингу (он устанавливает свой эдакий типа демультиплексор, который может быть и не только в foomatic) входного формата и рендера. На их же сайте находил понятные схемы об архитектуре.

[Bizdelnick]

Может подскажет кто, хоть что еще почитать?

Исходники…

[dimbor]

Могу лишь посочувствовать. Каждый раз, когда хочется подключить дома принтер, приходится с самого начала разбираться в архитектуре печати Linux, а через полгода все забывается. :)

Ага, точно. Я в таких случаях пишу длинные вонючие посты на форуме. Потом их же читаю, и деменция временно отворачивается ;)

Помню, что foomatic, кажется, решал много задач по матчингу (он устанавливает свой эдакий типа демультиплексор, который может быть и не только в foomatic) входного формата и рендера. На их же сайте находил понятные схемы об архитектуре.

И правда, спасибо. Благодаря вам осознаю очевидное, в логах написанное. Гадит походу не купс, а foomatic-rip. Его и буду ковырять.

Может подскажет кто, хоть что еще почитать?

Исходники…

Этого и боялся. Потом встанет непосильная задача их развидеть...