CUPS: end-user usability issues

Jon Kuroda jon at soda.csua.berkeley.edu
Thu Oct 21 15:48:07 PDT 2004


I have a similar problem to Georgi in our environment here.  We install
new systems with Fedora which uses CUPS as its native printing system,
but the central print spool server (over which we have no control aside
from getting new printers added) does not speak IPP, only Windows' native 
printing protocol and lpd via Services for Unix.  Some users expect
lpr/lpq/lpc/lprm/..., others expect lp/lpstat/cancel/..., but they 
both expect to be able to do mostly the same things with either set.

If the central spooling server spoke IPP, at least users could use
"lpstat -h central_server ..." to get queue information directly so
they could cancel jobs before they get to the printer or are stuck.

But we can't even offer that workaround since the print server does
not speak IPP and CUPS support for the lpd protocol seems (the docs
are very unclear on this) to be limited to accepting jobs over lpd
from clients that don't speak IPP.

So right now, if someone wants to see where their job is in relation
to others in the print queue for a printer or cancel a job, they have
to login to a solaris box, a box running BSD lpq, rlpq, or LPRng, or
a windows box.  I'm strongly considering ripping out at least CUPS'
versions of lpq, lpstat, lprm and cancel and replace them something
like the RLPR equivalents.

Yes, it's unrealistic for a user on a client system to expect lpq or
lpstat to return the status of the queues of every other print client
on the network.  Quite frankly, I think that is not only unrealistic,
but useless too.  In our setup (yes, there is only the one print server
that spools directly to the various networked printers), the only queue
that really matters is the one on the central print server -- what 
other clients have in their queues may be amusing information, but it's
not useful information until those jobs get into the last line leading
up to the printer(s)

Maybe it's a pain to do that in the failover/auto-discovery case, but
it's sure useful in the simpler cases.  

A side note from all the poring over docs in the past week trying to
get this all figured out is that the documentation for support of 
non-IPP protocols is pretty sparse.  I realize that there is a drive
from many areas towards an all IPP printing world and that support
for LPD is a second or third or non-priority, but knowing that certain
useful things are supported for the LPD backend would be really cool.

--Jon

In article <4177F8E7.40006 at easysw.com>, Michael Sweet  <mike at easysw.com> wrote:
>Georgi Kuzmanov wrote:
>> ...
>> the job got spooled.  With other printing systems (for example,
>> LPRng), it is enough to type:
>> 
>> lpq -Pljet1
>> 
>> but CUPS comes up with this misguiding message instead:
>> 
>> ljet1 is ready no entries
>> 
>> apparently because it just lists the jobs in the (empty) local queue.
>
>With LPRng, it actually talks to the remote server, since in this
>scenario you would have told it to send all jobs for ljet1 to the
>remote server (and only that server - no failover, no auto-discovery,
>etc.)
>
>With CUPS, each client has local queues which hold the job for that
>system; the local jobs are forwarded to a server for printing when
>that server is ready for them.  This method ensures that print files
>are not lost if a server goes down, and allows us to provide failsafe
>and load-balanced printing "for free".
>
>One side-effect of this architecture is that users won't see the
>server queue state, however even if we changed lpq/lpstat to query
>the remote server you still wouldn't have a true queue status since
>the server queue will not show all of the jobs that are queued on
>other clients at the same time!
>
>In short, we can't provide a live, global view of a shared queue
>because there is no central queue.  About all we could do is see
>that a remote job is printing and perhaps then query the server to
>see the ranking on the server (e.g. "spooled to server, 2nd job in
>server queue") for that job.  Similarly, if a remote printer is
>processing, we can (and do) show that it is printing job such-and-
>such, even if that job is not local.
>
>We do understand the desire for network-wide job tracking/status,
>and we are working on tools and changes that will support that in
>CUPS 1.2, however the core functionality provided by lpq/lpstat
>probably won't change because there is no central queue or
>respository of job information.
>
>> Problematic / inconsistent functionality 3 (removing jobs from a
>> queue)
> > ====================================================
> > Our user
>> has just five minutes to the next bus home and decides against
>> waiting for the two submitted jobs to print out but doesn't want to
>> waste print quota on print jobs that are likely to end up in a
>> recycle bin by the next morning.
>> 
>> Trying "lprm -Pljet1 -" (BSD-style "remove all my jobs from that
>> printer queue") keeps asking for the user's password, and, if that is
>
>The "lprm -Pprinter -" command uses the IPP_PURGE_JOBS operation,
>which is only available to adminstrative users.  You can pass job
>IDs on the command-line to cancel specific jobs, or pass none to
>cancel the current job.
>
>CUPS 1.2 will add a new IPP operation to cancel all jobs for a
>specific user without requiring admin privs (the IPP_PURGE_JOBS
>operation also removes the job history, which is why it is an
>admin operation)




More information about the cups mailing list