[Pkg-cups-devel] Bug#429715: "Using Debian to print to a remote Debian CUPS server is dang hard"

[Kurt Pfeifle]

> Package: cupsys-client
> Version: 1.2.11-3
> Severity: important
> 
> My friend gave me the IPP URL of his printer.  Not knowing much about
> this newfangled protocol, I installed cupsys-client, thinking (based on
> the package description) it would be a cinch to access the printer.  It
> turned out to be an ordeal. 

Are you sure your friend had setup his CUPS in a way that allows remote
CUPS clients to use his printqueues?!?

Because by default, Debian will not setup CUPS to allow this. (And if
your friend *knew* what he did when telling you the printqueue URL, you
would not have needed to bugreport this....)

> I'm filing this bug as important even
> though nothing is necessarily (?) broken, because basic functionality is
> either missing or exceedingly difficult and frustrating to figure out.
> If this should be routed upstream, let me know, but I thought it would
> be best to start in the Debian BTS.
> 
> The URL was of the form
> 
>     ipp://192.168.0.10/printers/HPLJ1012
> 
> I started by looking in the lp and lpstat man pages, expecting to find a
> URL option. Nothing.

You are the client trying to access a remote service, right?

Therefor, you should first be sure that the remote service is accessible
for your client.

That means, read the man pages for "cupsd.conf" on your friend's print
server, and read the online documentation on

   http://192.168.0.10:631/help/overview.html
   http://192.168.0.10:631/help/ref-cupsd-conf.html

> Then I tried to find some documentation on what
> to do with the URL, what parts of it to pass to what options of
> lp/lpstat.  All I found was the IPP URL RFC, which isn't very accessible
> and is not helpful directly.

You can query a remote CUPS server to see if it is running:

  lpstat -h remote.cups.server -r

You can query a remote CUPS server for a list of its printers:

  lpstat -h remote.cups.server -p

You can query a remote CUPS server for its current jobs:

  lpstat -h remote.cups.server -o

You can query a remote CUPS server for its completed jobs:

  lpstat -h remote.cups.server -W completed -o

You can query a remote CUPS server for the totality of its info:

  lpstat -h remote.cups.server -t

> So I experimented. 

*MY* lpstat man page does also point me to go to

  http://localhost:631/help

for more documentation. Bad luck that you only had the client portion of
cupsys installed. Even if you had tried that URL, it would not have worked.
However,

  http://192.168.0.10:631/help/

should have worked....

> I started with the lpstat program.  Passing
> 192.168.0.10 to the -h option was fairly obvious.  Using the -r option,
> I was able to ping the server.  But using, say, -t returned several
> repetitions of "lpstat: Forbidden" and nothing else useful. 

Which most likely means your friend's "print server" was not set up to
be a print server....

> I figured
> maybe I had to query this printer specifically.  The first problem is I
> didn't know whether the name of the printer should be
> "/printers/HPLJ1012", "HPLJ1012", or something else. 

I think the man page is unequivocally:

   lpstat -h printserver -p printqueuename
   lpstat -h 192.168.0.10 -p HPLJ1012

But

   lpstat -h 192.168.0.10 -p

already should give the complete list of shared printers.

> I tried passing
> variations to -a, -p, and -v, but I always got "lpstat: Unknown
> destination \"HPLJ1012\"!".  So it seemed like the remote server didn't
> recognize the printer name.  But when I investigated further by running
> the command under strace, I found that the string HPLJ1012 was never
> even sent to the server!  In fact, the "Unknown destination" message was
> printed after failed attempts to read a file called lpoptions.  Why it
> needs to read a local file about a remote printer I have no idea. 

I have one: The Debian packagers in have set it up like that by default.
(I don't like a lot of their defaults either, but that's the way it is.
At least your system is supposedly more secure, if you can't print...)

> I
> looked at the lpoptions man page, but I didn't see anything that looked
> relevant.

You should have given the complete commandline you used. (I assume you
are not a newbie user, given that you handled to run "strace" and get
some meaningful result from that.)

If your commandline was missing the "-h remotehost" option, lpstat will
default to look for the local print server and try to access it via TCP
socket localhost:631 (or the unix domain socket, depending on your
configuration). And it will also first read /etc/cups/lpoptions and
/etc/cups/client.conf, and ~/.cups/client.conf, should these exist.

> At a loss, I turned my attention to lp, and finally I caught a break.  I
> passed HPLJ1012 to the -d option, gave a PDF file on the command line
> (although the man page says nothing about what format the file should be
> in, so that was a guess),

You can send ASCII or international text, PostScript, PDF or any image
format to a correctly configured CUPS system and you will get a printout.

> and got a printout.  Looking at the strace of
> the run, I found it curious that there were several "POST /" requests
> that all got "403 Forbidden" responses, before finally a "POST
> /printers/HPLJ1012" (hey--this program does know how to construct the
> URL, it just doesn't accept it!) 

It is not using an URL to assemble the job on the commandline. It just
the "-d printqueuename" option. However, in the error_log you may find
the URL (or the path part of it).

> succeeded.  I don't know whether this
> represents a misconfiguration of the server,

Most likely.

> or futility on the part of
> the client.  And even after this, I never figured out how to use lpstat
> to get job status, etc.

  lpstat -o printqueuename                 # if you ask local cupsd

  lpstat -h cupsserver -o printqueuename   # if you query a remote cupsd

> So in the end, I can at least print (though not query), but I still
> don't know how I was supposed to figure it out.  If I missed something,
> maybe it could be documented more prominently.

I rather think Debian should have sane, working default settings for

  (a) setting up CUPS as a print server
  (b) setting up CUPS for client systems

Because, you know, if "CUPS browsing" were set up correctly on server
and client, you would not even need to configure *anything*. And you
could select your printer in the KDE print dialog (or the Gnome one)
and have all print options at your finger tips *without* *even* *a*
*need* *to* *install* *a* *driver* *locally*.


I recommend to rename this bug report to "Using Debian to print to a
remote Debian CUPS server is dang hard".

-- 
Kurt Pfeifle
System & Network Printing Consultant ---- Linux/Unix/Windows/Samba/CUPS
Infotec Deutschland GmbH  .....................  Hedelfinger Strasse 58
A RICOH Company  ...........................  D-70327 Stuttgart/Germany