Debian Bug report logs - #868728
cups requires do lpadmin configuration to share printers

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupre <anarcat@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: cups requires do lpadmin configuration to share printers

Date: Mon, 17 Jul 2017 20:56:48 -0400

Package: cups
Version: 2.2.1-8
Severity: normal

Hi!

When trying to share my printers with my roommates through the CUPS
web interface, I quickly found the "Share printers connected to this
system" button and clicked it. And lo and behold, other Linux (and
probably Mac, haven't tried) computers just see the printers and can
print to it. Great!

But when they do, they get this mysterious error message: "Filter
failed". Searching for that error message on the web is a dead end:
you end up with all sorts of errors with foomatic-db not being
configured properly and so on. This problem is remote-specific:
printing works fine on the local machine, just not from the remote
CUPS clients.

I have found this bug in the RedHat bugtracker that seems similar to
the situation I'm seeing here:

https://bugzilla.redhat.com/show_bug.cgi?id=1010580

This is another forum with the simple solution:

https://ubuntuforums.org/showthread.php?t=2254352

.. which is to run the following command, in a terminal:

   sudo lpadmin -p HP-LaserJet-p3015 -m raw

where "HP-LaserJet-p3015" is the printer name.

It seems to me a little odd that I would need to do this, as a user. I
would expect the graphical interface to do the right thing, or just
not offer the functionality at all. In the RH bugtracker, there's a
debate regarding whether this is an actual bug, as this seems to be
upstream's behavior of choice, but I fail to see how this is an
appropriate response... I am using what are mostly default
configurations here and didn't do anything special on the remote
computer.

It seems to me it would be essential to be able to share printers
through the GUI in Debian, out of the box. Having people go through
the commandline to workaround such an issue seems to defeat the whole
point of having that GUI in the first place.

Or did I miss something?

Thanks!

-- System Information:
Debian Release: 9.0
  APT prefers stable
  APT policy: (500, 'stable'), (1, 'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cups depends on:
ii  cups-client            2.2.1-8
ii  cups-common            2.2.1-8
ii  cups-core-drivers      2.2.1-8
ii  cups-daemon            2.2.1-8
ii  cups-filters           1.11.6-3
ii  cups-ppdc              2.2.1-8
ii  cups-server-common     2.2.1-8
ii  debconf [debconf-2.0]  1.5.61
ii  ghostscript            9.20~dfsg-3.2
ii  libavahi-client3       0.6.32-2
ii  libavahi-common3       0.6.32-2
ii  libc-bin               2.24-11+deb9u1
ii  libc6                  2.24-11+deb9u1
ii  libcups2               2.2.1-8
ii  libcupscgi1            2.2.1-8
ii  libcupsimage2          2.2.1-8
ii  libcupsmime1           2.2.1-8
ii  libcupsppdc1           2.2.1-8
ii  libgcc1                1:6.3.0-18
ii  libstdc++6             6.3.0-18
ii  libusb-1.0-0           2:1.0.21-1
ii  poppler-utils          0.48.0-2
ii  procps                 2:3.3.12-3

Versions of packages cups recommends:
ii  avahi-daemon                     0.6.32-2
ii  colord                           1.3.3-2
ii  cups-filters [ghostscript-cups]  1.11.6-3
ii  printer-driver-gutenprint        5.2.11-1+b2

Versions of packages cups suggests:
ii  cups-bsd                                   2.2.1-8
pn  cups-pdf                                   <none>
ii  foomatic-db-compressed-ppds [foomatic-db]  20161201-1
ii  hplip                                      3.16.11+repack0-3
ii  printer-driver-hpcups                      3.16.11+repack0-3
pn  smbclient                                  <none>
ii  udev                                       232-25

-- debconf information:
  cupsys/backend: lpd, socket, usb, snmp, dnssd
  cupsys/raw-print: true

Message #10 received at 868728@bugs.debian.org (full text, mbox, reply):

From: Brian Potkin <claremont102@gmail.com>

To: Antoine Beaupre <anarcat@debian.org>, 868728@bugs.debian.org

Subject: Re: Bug#868728: cups requires do lpadmin configuration to share printers

Date: Tue, 18 Jul 2017 17:19:08 +0100

On Mon 17 Jul 2017 at 20:56:48 -0400, Antoine Beaupre wrote:

> Package: cups
> Version: 2.2.1-8
> Severity: normal
> 
> Hi!

Hello Antoine. Thank you for your report.
 
> When trying to share my printers with my roommates through the CUPS
> web interface, I quickly found the "Share printers connected to this
> system" button and clicked it. And lo and behold, other Linux (and
> probably Mac, haven't tried) computers just see the printers and can
> print to it. Great!

What do you mean by "just see the printers"? My understanding would be
that when you switch your server on, its printers simply appear in the
output of 'lpstat -a' (and in the printing dialogs of applications) on
client machines. This is achieved through the agency of cups-browsed and
does not involve the owners of these machines touching a single key on
the keyboard.  If they have done, they are probably going about it in
the wrong way. Close down your server and the printers disappear from
'lpstat -a'.
 
> But when they do, they get this mysterious error message: "Filter
> failed". Searching for that error message on the web is a dead end:
> you end up with all sorts of errors with foomatic-db not being
> configured properly and so on. This problem is remote-specific:
> printing works fine on the local machine, just not from the remote
> CUPS clients.

We would need an error_log from a client to get to the bottom of this.
The Printing section on wiki will guide you on this. Please compress
the file before sending it to the bug.

> I have found this bug in the RedHat bugtracker that seems similar to
> the situation I'm seeing here:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1010580
> 
> This is another forum with the simple solution:
> 
> https://ubuntuforums.org/showthread.php?t=2254352
> 
> .. which is to run the following command, in a terminal:
> 
>    sudo lpadmin -p HP-LaserJet-p3015 -m raw
> 
> where "HP-LaserJet-p3015" is the printer name.
> 
> It seems to me a little odd that I would need to do this, as a user. I
> would expect the graphical interface to do the right thing, or just
> not offer the functionality at all. In the RH bugtracker, there's a
> debate regarding whether this is an actual bug, as this seems to be
> upstream's behavior of choice, but I fail to see how this is an
> appropriate response... I am using what are mostly default
> configurations here and didn't do anything special on the remote
> computer.

cups-browsed does the right thing. The web interface does the right
thing too; a user who chose other than the raw "PPD" as an alternative
to using cups-browsed would be working against it.

> It seems to me it would be essential to be able to share printers
> through the GUI in Debian, out of the box. Having people go through
> the commandline to workaround such an issue seems to defeat the whole
> point of having that GUI in the first place.
> 
> Or did I miss something?

The Printer section's account of "Double Filtering" on the wiki? :)

Regards,

Brian.

Message #15 received at 868728@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@debian.org>

To: Brian Potkin <claremont102@gmail.com>, 868728@bugs.debian.org

Subject: Re: Bug#868728: cups requires do lpadmin configuration to share printers

Date: Tue, 18 Jul 2017 14:43:19 -0400

On 2017-07-18 17:19:08, Brian Potkin wrote:
> On Mon 17 Jul 2017 at 20:56:48 -0400, Antoine Beaupre wrote:
>
>> Package: cups
>> Version: 2.2.1-8
>> Severity: normal
>> 
>> Hi!
>
> Hello Antoine. Thank you for your report.
>  
>> When trying to share my printers with my roommates through the CUPS
>> web interface, I quickly found the "Share printers connected to this
>> system" button and clicked it. And lo and behold, other Linux (and
>> probably Mac, haven't tried) computers just see the printers and can
>> print to it. Great!
>
> What do you mean by "just see the printers"?

I mean that, when they choose the "Print..." menu in an application
(e.g. Firefox or Evince), the printer shows up in the printer selection
dialog.

> My understanding would be that when you switch your server on, its
> printers simply appear in the output of 'lpstat -a' (and in the
> printing dialogs of applications) on client machines.

I haven't tested the commandline version of this usage. I assume my
users are not proficient with the commandline and like to use the GUI
for things like printing... 

> This is achieved through the agency of cups-browsed and does not
> involve the owners of these machines touching a single key on the
> keyboard.  If they have done, they are probably going about it in the
> wrong way. Close down your server and the printers disappear from
> 'lpstat -a'.

Sure. The clients did not touch the keyboard: only the mouse. ;)

>> But when they do, they get this mysterious error message: "Filter
>> failed". Searching for that error message on the web is a dead end:
>> you end up with all sorts of errors with foomatic-db not being
>> configured properly and so on. This problem is remote-specific:
>> printing works fine on the local machine, just not from the remote
>> CUPS clients.
>
> We would need an error_log from a client to get to the bottom of this.
> The Printing section on wiki will guide you on this. Please compress
> the file before sending it to the bug.

Understood, I'll see if i can find the time to send this.

Actually, looking at the "Printing" page on the wiki:

https://wiki.debian.org/Printing

I do not see exactly what you are refering to.

Or are you refering to this page:

https://wiki.debian.org/DissectingandDebuggingtheCUPSPrintingSystem

I must say the "Printing" page is a little confusing: there are too many
links there and it's hard to figure out what's what. A "troubleshooting"
section would be really helpful, for example. :)

>> I have found this bug in the RedHat bugtracker that seems similar to
>> the situation I'm seeing here:
>> 
>> https://bugzilla.redhat.com/show_bug.cgi?id=1010580
>> 
>> This is another forum with the simple solution:
>> 
>> https://ubuntuforums.org/showthread.php?t=2254352
>> 
>> .. which is to run the following command, in a terminal:
>> 
>>    sudo lpadmin -p HP-LaserJet-p3015 -m raw
>> 
>> where "HP-LaserJet-p3015" is the printer name.
>> 
>> It seems to me a little odd that I would need to do this, as a user. I
>> would expect the graphical interface to do the right thing, or just
>> not offer the functionality at all. In the RH bugtracker, there's a
>> debate regarding whether this is an actual bug, as this seems to be
>> upstream's behavior of choice, but I fail to see how this is an
>> appropriate response... I am using what are mostly default
>> configurations here and didn't do anything special on the remote
>> computer.
>
> cups-browsed does the right thing. The web interface does the right
> thing too; a user who chose other than the raw "PPD" as an alternative
> to using cups-browsed would be working against it.

The user, AFAIK, did not make any specific choice on the printer
configuration.

>> It seems to me it would be essential to be able to share printers
>> through the GUI in Debian, out of the box. Having people go through
>> the commandline to workaround such an issue seems to defeat the whole
>> point of having that GUI in the first place.
>> 
>> Or did I miss something?
>
> The Printer section's account of "Double Filtering" on the wiki? :)

I am not sure how I was expected to find this, but I did find this page
after doing a full text search for the "double filtering" quoted string:

https://wiki.debian.org/PrintQueuesCUPS#Double_Filtering

Reading that section just makes me more confused - while I am sure I
could spend the next 15 minutes trying to understand all the subtleties
of the CUPS internals, I fail to see how users are expected to learn
that stuff just to share printers over the network.

I don't understand the trade-offs here: why isn't "raw" processing
the default? What's the downside, if it allows automatic remote printing
configurations?

If I need to install cups-browsed on the client, why isn't that
installed by default?

It certainly seems to me that we expect way too much of our poor
users. I've been using Debian for over a decade, and I've been a DD for
years now, and I took my about 30 minutes to figure out how to make this
work. I consider myself lucky that I find the magic incantation at all,
and would be very surprised if a normal user would manage to fix this on
their own.

I guess one thing remains unclear to me: is remote printing automatic
configuration supposed to work without commandline intervention right
now? Or are we expected to switch the queue to raw mode on the server
when we want to share printers? It seemed to me this was the issue here,
but maybe that assumption is flawed...

Thanks for the clarifications and responses!

A.

-- 
When spider webs unite, they can tie up a lion.
                        - ethiopian proverb

Message #20 received at 868728@bugs.debian.org (full text, mbox, reply):

From: Brian Potkin <claremont102@gmail.com>

To: Antoine Beaupré <anarcat@debian.org>, 868728@bugs.debian.org

Cc: Brian Potkin <claremont102@gmail.com>

Subject: Re: Bug#868728: cups requires do lpadmin configuration to share printers

Date: Tue, 18 Jul 2017 23:17:10 +0100

On Tue 18 Jul 2017 at 14:43:19 -0400, Antoine Beaupré wrote:

> On 2017-07-18 17:19:08, Brian Potkin wrote:
> 
> https://wiki.debian.org/PrintQueuesCUPS#Double_Filtering
> 
> Reading that section just makes me more confused - while I am sure I
> could spend the next 15 minutes trying to understand all the subtleties
> of the CUPS internals, I fail to see how users are expected to learn
> that stuff just to share printers over the network.

Users are not sharing printers. You (and your server) are.

> I don't understand the trade-offs here: why isn't "raw" processing
> the default? What's the downside, if it allows automatic remote printing
> configurations?

The problem appears to be you have a client which isn't doing raw
processing. Sort them out,
 
> If I need to install cups-browsed on the client, why isn't that
> installed by default?

It is recommended by cups-daemon, so it is hard to avoid unless you
choose to. 
 
> It certainly seems to me that we expect way too much of our poor
> users. I've been using Debian for over a decade, and I've been a DD for
> years now, and I took my about 30 minutes to figure out how to make this
> work. I consider myself lucky that I find the magic incantation at all,
> and would be very surprised if a normal user would manage to fix this on
> their own.
> 
> I guess one thing remains unclear to me: is remote printing automatic
> configuration supposed to work without commandline intervention right
> now? Or are we expected to switch the queue to raw mode on the server
> when we want to share printers? It seemed to me this was the issue here,
> but maybe that assumption is flawed...

Remote printing works out of the box without commandline intervention.

-- 
Brian.

Message #25 received at 868728@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@debian.org>

To: Brian Potkin <claremont102@gmail.com>, 868728@bugs.debian.org

Cc: Brian Potkin <claremont102@gmail.com>

Subject: Re: Bug#868728: cups requires do lpadmin configuration to share printers

Date: Tue, 18 Jul 2017 18:44:55 -0400

On 2017-07-18 23:17:10, Brian Potkin wrote:
> On Tue 18 Jul 2017 at 14:43:19 -0400, Antoine Beaupré wrote:
>
>> On 2017-07-18 17:19:08, Brian Potkin wrote:
>> 
>> https://wiki.debian.org/PrintQueuesCUPS#Double_Filtering
>> 
>> Reading that section just makes me more confused - while I am sure I
>> could spend the next 15 minutes trying to understand all the subtleties
>> of the CUPS internals, I fail to see how users are expected to learn
>> that stuff just to share printers over the network.
>
> Users are not sharing printers. You (and your server) are.

I don't get this. I am not a user?

And I would argue this is not a "server": it's my workstation, to which
a printer is connected. I just want to share that printer.

>> I don't understand the trade-offs here: why isn't "raw" processing
>> the default? What's the downside, if it allows automatic remote printing
>> configurations?
>
> The problem appears to be you have a client which isn't doing raw
> processing. Sort them out,

Is that normal behavior? Or is this a symptom of some (possible
deliberate) misconfiguration on that client?

>> If I need to install cups-browsed on the client, why isn't that
>> installed by default?
>
> It is recommended by cups-daemon, so it is hard to avoid unless you
> choose to. 

Understood.

>> It certainly seems to me that we expect way too much of our poor
>> users. I've been using Debian for over a decade, and I've been a DD for
>> years now, and I took my about 30 minutes to figure out how to make this
>> work. I consider myself lucky that I find the magic incantation at all,
>> and would be very surprised if a normal user would manage to fix this on
>> their own.
>> 
>> I guess one thing remains unclear to me: is remote printing automatic
>> configuration supposed to work without commandline intervention right
>> now? Or are we expected to switch the queue to raw mode on the server
>> when we want to share printers? It seemed to me this was the issue here,
>> but maybe that assumption is flawed...
>
> Remote printing works out of the box without commandline intervention.

Thanks for the clarification,

a.

-- 
Wherever they's a fight so hungry people can eat, I'll be there.
Wherever they's a cop beatin' up a guy, I'll be there.
If Casy knowed, why, I'll be in the way guys yell when they're mad an'
I'll be in the way kids laugh when they're hungry an' they know
supper's ready. An' when our folks eat the stuff they raise an' live
in the house they build, why I'll be there.
                        - John Steinbeck, The Grapes of Wrath

Message #30 received at 868728@bugs.debian.org (full text, mbox, reply):

From: Brian Potkin <claremont102@gmail.com>

To: Antoine Beaupré <anarcat@debian.org>, 868728@bugs.debian.org

Cc: Brian Potkin <claremont102@gmail.com>

Subject: Re: Bug#868728: cups requires do lpadmin configuration to share printers

Date: Wed, 19 Jul 2017 00:23:32 +0100

On Tue 18 Jul 2017 at 18:44:55 -0400, Antoine Beaupré wrote:

> On 2017-07-18 23:17:10, Brian Potkin wrote:
> > On Tue 18 Jul 2017 at 14:43:19 -0400, Antoine Beaupré wrote:
> >
> >> On 2017-07-18 17:19:08, Brian Potkin wrote:
> >> 
> >> https://wiki.debian.org/PrintQueuesCUPS#Double_Filtering
> >> 
> >> Reading that section just makes me more confused - while I am sure I
> >> could spend the next 15 minutes trying to understand all the subtleties
> >> of the CUPS internals, I fail to see how users are expected to learn
> >> that stuff just to share printers over the network.
> >
> > Users are not sharing printers. You (and your server) are.
> 
> I don't get this. I am not a user?

Yes and no. From the point of view of the command 'lp -d ... job' issued
directly on the server you are the user. When the command is issued from
another machine on the network you (the administrator) are not a user.

When you (as administrator) advertise your printers you are said to
share them. Users use your shared printers - they do not cause them to
be shared. Your generosity is in serving up these printers.
 
> And I would argue this is not a "server": it's my workstation, to which
> a printer is connected. I just want to share that printer.

That makes your machine a server, Switch your machine off. How happy
will your users be? Argue your way out of the complaints you will get. :)

> >> I don't understand the trade-offs here: why isn't "raw" processing
> >> the default? What's the downside, if it allows automatic remote printing
> >> configurations?
> >
> > The problem appears to be you have a client which isn't doing raw
> > processing. Sort them out,
> 
> Is that normal behavior? Or is this a symptom of some (possible
> deliberate) misconfiguration on that client?

Just a normal misconfiguration. Tell them not to do double filtering.
It's evil and completely unnecessary.

-- 
Brian.

Message #35 received at 868728@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@debian.org>

To: Brian Potkin <claremont102@gmail.com>, 868728@bugs.debian.org

Cc: Brian Potkin <claremont102@gmail.com>

Subject: Re: Bug#868728: cups requires do lpadmin configuration to share printers

Date: Tue, 18 Jul 2017 19:33:09 -0400

On 2017-07-19 00:23:32, Brian Potkin wrote:
> Just a normal misconfiguration. Tell them not to do double filtering.
> It's evil and completely unnecessary.

I guess this is the root of the problem. I don't even know how they/I
did that in the first place.

I wouldn't even know how to undo the `lpadmin raw` thing i did to
workaround the problem in the first place.

A.

-- 
The Net treats censorship as damage and routes around it.
                         - John Gilmore

Message #40 received at 868728-done@bugs.debian.org (full text, mbox, reply):

From: Brian Potkin <claremont102@gmail.com>

To: 868728-done@bugs.debian.org

Subject: Re: Bug#868728: cups requires do lpadmin configuration to share printers

Date: Wed, 19 Jul 2017 15:27:09 +0100

On Tue 18 Jul 2017 at 19:33:09 -0400, Antoine Beaupré wrote:

> On 2017-07-19 00:23:32, Brian Potkin wrote:
> > Just a normal misconfiguration. Tell them not to do double filtering.
> > It's evil and completely unnecessary.
> 
> I guess this is the root of the problem. I don't even know how they/I
> did that in the first place.
> 
> I wouldn't even know how to undo the `lpadmin raw` thing i did to
> workaround the problem in the first place.

Assuming cups-browsed installed and stopped a non-empty output to
'lpstat -a' might jog your memory as to the queue name. Delete with
'lpadmin -x ....' or use the web interface.

Actually, if the client prints only from GTK applications (Firefox,
Evince etc) you can dispense with cups-browsed and the cups daemon
because the applications will display your printers without any
outside aid.

I do not think we have a cups bug here. So, if you are satisfied, I
will close the report.

Cheers,

Brian.

Send a report that this bug log contains spam.