[cups] What is the preferd method to connect cups 1.7.5 to cups 1.3.9

[Johannes Meixner]

Hello Franz,

On Feb 26 18:08 Pförtsch, Franz wrote (excerpt):
> On wednesday I had the problem between my new central sles12 sp1
> cups 1.7.5 printserver to a sles11 sp4 cups 1.3.9 in the location.
>
> The central-server transfers the spool jobs from <local-queue>
> to the remote cups via the device-uri
> lpd://<remote-server>/<remote-queue>.

First and foremost I like to understand why you need to
forward print jobs from one cups server to another one.

As far as I understand it seems you run an application
"fooapp" on a client system "client".
That "fooapp" creates a print job on "client" and submits
it to a print queue "fwdq" on server "cups175".
On "cups175" the print job gets forwarded to another
print queue "finalq" on server "cups139".
>From "finalq" on server "cups139" the print job gets
finally sent to the real printer device where the
actual printout happens.

I do not understand the reason why there is the
intermediate print queue "fwdq" on server "cups175".

Why cannot the application "fooapp" on "client"
directly submit its print job to "finalq" on
server "cups139"?

To be able to reproduce your setup I need more
explicit information.

When you use lpd://<remote-server>/<remote-queue>
on your cups 1.7.5 printserver to send
jobs to your cups 1.3.9 printserver
it means remote-server must be the server name of your
cups 1.3.9 printserver and on your cups 1.3.9 printserver
the cups-lpd must be run as receiver of LPD print jobs.
Furthermore on the receiving cups 1.3.9 system there must
be a matching queue named "remote-queue" whereto the cups-lpd
on the receiving cups 1.3.9 system can forward the print job.

What I like to get to reproduce it is the lpadmin command that
one must run on the sending cups 1.7.5 system to create a queue
with such a lpd://<remote-server>/<remote-queue> deviceURI and
the cups-lpd configuration for the receiving cups 1.3.9 system
plus the lpadmin command that one must run on the receiving
cups 1.3.9 system to create the queue named "remote-queue".

Finally to reproduce it I need one original print job file
that you send from your sending cups 1.7.5 system so that I can
send the same kind of original print job data as you do.

FYI,
see "man cups-lpd":
--------------------------------------------------------------
PERFORMANCE
   cups-lpd performs well with small numbers of clients and
   printers. However, since a new process is created for
   each connection and since each process must query the
   printing system before each job submission, it does not
   scale to larger configurations. We highly recommend that
   large configurations use the native IPP support provided
   by CUPS instead.
--------------------------------------------------------------


> A lot of spooljobs where transfert. It was working for hours,
> suddenly the spooljobs get stucked in the <local-queue>.
> The status of the queue was processing and the spooljobs
> showed "Data file sent successfully."

Only with meaningful CUPS debug messages (i.e. with
"LogLevel debug") from about that time when the spooljobs
get stucked I see a chance to understand what went wrong.


> After this I tried several device uri's but nothing helped.
>
> On the end I created a new queue to park the spooljobs,
> because I do not want to loose data. we are in JIT-production.
> I moved the jobs to this queue, but this also did not help.
>
> In the end I removed the <local-queue> and created this new.
> When I started one of the spooljobs the cupd crashed
> with segfault without a coredump :-(

How did you remove the <local-queue> and created it anew?
By only using lpadmin commands or by editing files
in /etc/cups?


> Today I had the same problem with two Laserprinter
> (Kyocera FS-4000DN/Canon ADF C53xx).
> I solved this situation by modifiying the printer which
> startet the queue/canceling the printjob)

>From my point of view this does not match your above
description because above you described issues while
forwarding print jobs form cups 1.7.5 to cups 1.3.9
and now you describe issues with real printer devices.

I think I need more background information about your
overall setup, from the application that generates the
original print job that is forwarded and processes by
your various cups servers until the final printer-specific
data is sent to a real printer device where the actual
printout happens.


> There seems to be a syncing problem between printjob
> and printqueue.
>
> But I could no reproduce the situation by my self :-(

That is unfortunate news because it means that with
high probability also I cannot reproduce it.


> I opened a call at our supporter. The Service Request
> is #10994025138

I am already in contact with our supporters.


> But now again! What is the preferd connection between
> two cups-daemons?
>
> How should I couple two cups-servers?
> Is ipp better then lpd?

I assume because IPP is the native protocol that the cupsd
itself supports directly and LPD is only provided in a basic
way by the cups-lpd mini-server to provide some basic support
for legacy client systems, IPP should be preferred to let
two cupsds communicate with each other.

But on the other hand print job forwarding from one cups
server to another one is in general not recommended.

Depending on the exact setup it can lead to unexpected
behaviour, cf.
https://www.cups.org/str.php?L4766
and
https://www.cups.org/str.php?L4738

I assume those STRs do not describe your particular setup
but at least those STRs indicate that print job forwarding
from one cups server to another one can lead to issues.

Of course no setup - regardless how unusual it is - must
let the cupsd segfault.


Kind Regards
Johannes Meixner
-- 
SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard,
Graham Norton - HRB 21284 (AG Nuernberg)