Bug 1525937

+++ This bug was initially created as a clone of Bug #1518415 +++

Description of problem:
cups-browsed no longer works

Version-Release number of selected component (if applicable):
cups-2.2.4-6.fc27.x86_64
cups-filters-1.16.1-2.fc27.x86_64

How reproducible:
100%

Steps to Reproduce:
1.  Install Fedora 27
2.  Run lpstat -t  or system-config-printer
3.

Actual results:
No printers are listed

Expected results:
A list of printers on servers on the LAN

Additional info:
After installing F27 and ensuring cups-browsed is running, none of the
my printers that are available and advertised on other (F26) servers
can be seen.  If I reboot the client machine to F26, they are visible
and usable as they have always been before.

In the new F27 system, in the system-config-printer GUI I can still click thru  a bunch of steps to search for and find those network printers.  And then use them.  But that's tedious and much less useful than the previous totally automatic availability of all printers across the LAN.

--- Additional comment from Zdenek Dohnal on 2017-11-29 02:47:12 EST ---

Hi,

do you have CUPS service enabled and running? Do you have "BrowsePoll" option set to your servers in your /etc/cups/cups-browsed.conf on client ? Do you have 'LocalQueueNamingRemoteCUPS RemoteName' in /etc/cups/cups-browsed.conf , if you are using remote cups queues (because browsing remote cups queues is really old way to share printers, so there are other options to set to have it working old way)?

--- Additional comment from Dario Lesca on 2017-11-29 11:12:27 EST ---

Here, after update to F27 from F26, on my notebook I cannot see the printer shared from my home server.

(In reply to Zdenek Dohnal from comment #1)
> do you have CUPS service enabled and running?
Yes

> Do you have "BrowsePoll" option set to your servers
> in your /etc/cups/cups-browsed.conf on client ?
No. Before, all work fine without this setting.

> Do you have 'LocalQueueNamingRemoteCUPS RemoteName'
> in /etc/cups/cups-browsed.conf if you are using remote cups queues?
No. Before, all work fine without this setting.

> (because browsing remote cups queues is really old way to share printers,
> so there are other options to set to have it working old way)?
?
What is the new way to share printer, if "browsing remote cups queues is really old way to share printers" ?

Thanks
Dario

--- Additional comment from David A. De Graaf on 2017-11-29 11:49:47 EST ---

Yes, of course.  Both cups and cups-browsed are running.
As originally noted, remote printing does work, provided I "manually discover" the remote printer via a labyrinth of mouse clicks in system-config-printer.  But this is much less useful than the historical automatic discovery process, and a big regression.

The only change I've made in /etc/cups/cups-browsed.conf is this:

[root@datacer /etc/cups]
# diff cups-browsed.confSTD cups-browsed.conf
96a97,99
> BrowseAllow 192.168.2.0/24
> BrowseAllow 192.168.1.0/24
>

and, according to the comment in that file,
# If there are no "Browse..." lines at all, all servers are accepted.
those added lines are unnecessary and irrelevant.

In particular, I remain studiously ignorant of "BrowsePoll" and 'LocalQueueNamingRemoteCUPS RemoteName'.  I like the "really old way to share printers" because it's simple, reliable and easy to comprehend.  I'm even a big fan of the lpstat and lpadmin commands.

You say "there are other options to set to have it working old way", but I have NEVER had to make any other edits to /etc/cups/cups-browsed.conf.  Has something changed to require other edits?  Why?

Please make remote printing work again.

--- Additional comment from Zdenek Dohnal on 2017-11-29 12:21:37 EST ---

First, I'm sorry about my first comment can be interpreted rude. Thank you for reporting this issue. Would you mind telling me what OS is on your servers?
What you use (what I understand you use) is browsing remote cups queues, which CUPS and cups-filters upstream marked as deprecated. Comment from CUPS upstream:

"Keep in mind that support for non-local CUPS servers has been deprecated since 2.0 due to sandboxing and other security "features" preventing clients from accessing network printers directly - that's one of the reasons we added the new CUPS-Create-Local-Printer operation so that cupsd did all of the communications for you..."

So there is still support for it, but users will need to do some changes in configuration to make it work as in the past - in this certain case try to add BrowsePoll statement (I think that sentence you mentioned is for BrowseAllow/BrowseDeny statement) and LocalQueueNamingRemoteCUPS RemoteName. I have same configuration and it works fine.
The new way, in which upstreams would like to go as soon as possible, is clients communicating with printer itself, without print server. But it works only for printers nowadays, not for older models AFAIK. I marked as "old" because upstream marked it old.

--- Additional comment from David A. De Graaf on 2017-11-29 15:55:41 EST ---

Zdenek:
Your comment was NOT rude and I didn't interpret it so.
I am, however, frustrated by changes in what has always been one of
the best features of UNIX/Linux - super reliable printing - where the
model has always been:  a computer is responsible for managing a
printer, including queueing jobs, preparing the job format to meet the
printer's needs, etc.  Users would send files to the server's queue(s)
and expect the smart computer to figure out how to convert the file to
a printable form.  Users would NEVER send a file directly to a
printer.  That would be insane.

So when I hear you say "The new way, in which upstreams would like to
go as soon as possible, is clients communicating with printer itself,
without print server."  I wonder if "upstream" have completely lost
their minds.

Nevertheless, I want to make printing work again, ASAP, but have
failed.  After reading the *extremely* long-winded comments in
/etc/cups/cups-browsed.conf with great care, I conclude that only the
BrowsePoll and LocalQueueNamingRemoteCups directives are relevant.
I do not want to restrict or limit in any way the visibility of
printer queues on my LAN.  Almost all the comments in that file seem
to be aimed at selecting or restricting or limiting what's seen.

I have exactly two physical printers.  Each printer is connected to a
server which is currently running Fedora 26.  The client machine (that
can't connect) is running Fedora 27.  The main laser printer is
connected to and managed by datium.datix.lan.  On that computer I see:

[dad@datium ~]
$ lpstat -t
scheduler is running
system default destination: cl
device for avery: usb://Brother/HL-L8250CDN%20series?serial=U63776E4J134556
device for cl: usb://Brother/HL-L8250CDN%20series?serial=U63776E4J134556
device for cl2: usb://Brother/HL-L8250CDN%20series?serial=U63776E4J134556
device for hppsc: implicitclass:hppsc
device for legal: usb://Brother/HL-L8250CDN%20series?serial=U63776E4J134556
avery accepting requests since Tue Oct 31 13:58:43 2017
cl accepting requests since Wed Nov 29 14:44:59 2017
cl2 accepting requests since Mon Oct 23 13:41:29 2017
hppsc accepting requests since Sun Nov 26 11:16:11 2017
legal accepting requests since Mon Oct 23 13:41:29 2017
printer avery is idle.  enabled since Tue Oct 31 13:58:43 2017
printer cl is idle.  enabled since Wed Nov 29 14:44:59 2017
printer cl2 is idle.  enabled since Mon Oct 23 13:41:29 2017
printer hppsc is idle.  enabled since Sun Nov 26 11:16:11 2017
printer legal is idle.  enabled since Mon Oct 23 13:41:29 2017

So, there are five queues intended to utilize various capabilites,
with "cl" meaning color laser, and "cl2" meaning color laser duplex,
etc.

There's also an HP inkjet connected to datair.datix.lan with a queue
named "hppsc".

As I read the cups-browsed.conf file, these edits ought to be
sufficient:

[dad@datacer /etc/cups]
$ diff cups-browsed.confSTD cups-browsed.conf
281a282,283
> BrowsePoll datium.datix.lan
> BrowsePoll datair.datix.lan
364a367
> LocalQueueNamingRemoteCUPS RemoteName

That is, I want to BrowsePoll both servers; and I want whatever
print queue names that are found there, to be presented here.
Simple, eh?

But it doesn't work!
The client machine sees nothing.

What have I done wrong?  How have I misinterpreted the instructions?
Can you help me understand?

--- Additional comment from Zdenek Dohnal on 2017-11-30 04:15:01 EST ---

(In reply to David A. De Graaf from comment #5)
> Zdenek:
> Your comment was NOT rude and I didn't interpret it so.
> I am, however, frustrated by changes in what has always been one of
> the best features of UNIX/Linux - super reliable printing - where the
> model has always been:  a computer is responsible for managing a
> printer, including queueing jobs, preparing the job format to meet the
> printer's needs, etc.  Users would send files to the server's queue(s)
> and expect the smart computer to figure out how to convert the file to
> a printable form.  Users would NEVER send a file directly to a
> printer.  That would be insane.
I'm sorry, I didn't explain it thoroughly. To keep it simple, how it works in client/server CUPS configuration:
1. an app wants to print
2. app sends file to local CUPS - to specified print queue
3. local CUPS proceeds file through correct filters, depending on PPD file for printer, and gets bulk of data
4. this bulk is sent to print queue on server, where data is going through filters again
5. and finally sent to actual printer

How should it work in upstream's idea/and works for some printers:
1. an app wants to print
2. an app sends file to local CUPS print queue
3. local CUPS does all magic for you - discovering printer, processing file through filters and sending it to printer itself

Scanning works by default similar way, but it doesn't have local daemon by default. Scanning tools like scanimage, xsane or simple-scan communicate with scanner itself.

From your 'lpstat' command - Do I understand correctly that Brother printer is connected to server machine A by USB cable and HP Inkjet is connected server machine B by ethernet cable? And you want to see all printers on all machines - that means you want to see all printers on server machine A, on server machine B , on client machine and all other machines, which can be connected to LAN?

> What have I done wrong?  How have I misinterpreted the instructions?
> Can you help me understand?

Ok, we will need some logs and configs.
First would you mind setting cups debug level on all machines to debug? You can do it by setting "LogLevel debug" in /etc/cups/cupsd.conf and restarting CUPS service.
Second, would you mind setting cups-browsed to debug mode on all machines, where you want to see all printers in network? You can set it by adding '-d' option to line 'ExecStart=/usr/sbin/cups-browsed' in /usr/lib/systemd/system/cups-browsed.service, then run 'systemctl daemon-reload' and 'systemctl restart cups-browsed'.

Then please gather logs and configs from machines and attach them here:
1) from client machine
- please attach cups-browsed.conf, cupsd.conf
- please restart cups and cups-browsed at same time (please remember exact time, we will use it for journald - now for example 11:00) and please attach cups and cups-browsed logs since their restart - for example 'journalctl -u cups -u cups-browsed --since='11:00' > output_file'

2) from server machines
- please attach cupsd.conf, OPTIONALLY cups-browsed.conf, if you want to see machines from other server
- please attach logs gathered since you restarted services on client - that means 'journalctl -u cups -u cups-browsed --since='11:00' > output_file'

This way I can see what is your configuration and what actually happens, when cups-browsed should show your printers. If that doesn't help, we can try to analyze network traffic by wireshark and system calls by strace.

--- Additional comment from David A. De Graaf on 2017-11-30 13:05 EST ---

Zdenek:
I will produce the debug log files you requested soon.
But before I do, on the main server A, where my Brother laser printer
is connected by a USB cable, I took a look at what's already in the
journal, ie,
  journalctl -u cups -u cups-browsed --since='11:00' > /usr/tmp/cups.jrnl
and will attach that file here.

Perhaps it already contains a clue to the problem.

There are lines that repeat every 1 minute saying:

Nov 30 11:00:25 datium cupsd[904]: [Client 2142] Request from "192.168.2.105" using invalid Host: field "datium.datix.lan:631".

I assume these lines are generated by the "BrowsePoll datium.datix.lan"
from the client machine, datacer.datix.lan, which is at 192.168.2.105.

So why am I seeing " using invalid Host: field "datium.datix.lan:631"."?
datium.datix.lan is a perfectly valid host name - it is the main
server that should be Polled by the client machine, datacer.datix.lan.
If  "BrowsePoll datium.datix.lan"  is wrong for the client what, on
earth, would be right?  Baffling!

These lines repeat *every minute*, because there's no printing
activity at all.  Until 12:07:54, when I printed your Comment #6.
This set off an overwhelming deluge of data for just this little 1+
page print job - 411 lines of stuff.  Wow!  Imagine the disk space
consumed in /var/log/journal on a really busy system.  This is NOT
debugging output, it's just what journald saves by default.

--- Additional comment from David A. De Graaf on 2017-11-30 14:52 EST ---

Output on client for journalctl -u cups -u cups-browsed --since=14:00

--- Additional comment from David A. De Graaf on 2017-11-30 14:53 EST ---

F26 server debug output

--- Additional comment from David A. De Graaf on 2017-11-30 14:54:56 EST ---

I have turned on debug mode on both datium, the F26 server, and
datacer, the F27 client and will attach the respective journalctl
output files.


On the client the cups config files are only slightly changed and very
long, so I'll show only the diff's:

[root@datacer /etc/cups]
# ll cups-br* cupsd.conf*
-rw-r--r--  1 root root 26222 Nov 29 14:20 cups-browsed.conf
-rw-r--r--. 1 root root 26128 Nov  5 02:29 cups-browsed.confSTD
-rw-r-----  1 root root  6308 Nov 30 13:53 cupsd.conf
-rw-r-----  1 root lp    6291 Oct  4 10:20 cupsd.conf.default
-rw-r-----. 1 root lp    6291 Oct  4 10:20 cupsd.confSTD

[root@datacer /etc/cups]
# diff cups-browsed.confSTD cups-browsed.conf
281a282,283
> BrowsePoll datium.datix.lan
> BrowsePoll datair.datix.lan
364a367
> LocalQueueNamingRemoteCUPS RemoteName


[root@datacer /etc/cups]
# diff cupsd.confSTD cupsd.conf
9c9,10
< LogLevel warn
---
> # LogLevel warn
> LogLevel debug


On the server the cups config files are unchanged from the F26
distribution, so I won't display them here:
[root@datium /etc/cups]
# ll cups*conf
-rw-r--r-- 1 root root 18763 Sep  3 14:56 cups-browsed.conf
-rw-r----- 1 root lp    3034 Sep 30 15:30 cups-files.conf
-rw-r----- 1 root lp    4902 Nov 30 13:59 cupsd.conf

--- Additional comment from David A. De Graaf on 2017-11-30 16:32:23 EST ---

On a hunch, I changed the lines in /etc/cups/cups-browsed.conf from
  BrowsePoll datium.datix.lan
  BrowsePoll datair.datix.lan
to 
  BrowsePoll datium
  BrowsePoll datair

Now browsing works again.
Who knew?  What's wrong with the Fully Qualified Name?
This notation certainly doesn't agree with any hint in the file's comments.

Weird.
This change doesn't make any sense to me.  It's still a regression.

Thanks for your help, Zdenek.

--- Additional comment from Zdenek Dohnal on 2017-12-04 12:01:07 EST ---

David,

you're right, this is clearly issue - but IMO it seems like issue in CUPS in F26. I'll check it with F27 client machine and F26 server machine, but I think CUPS 'doesn't like' your .lan extension - it doesn't count as valid host.
Would you mind trying to set 'ServerAlias datium.datix.lan' in /etc/cups/cupsd.conf at datium machine and restarting CUPS? (and similar way at datair machine)

--- Additional comment from David A. De Graaf on 2017-12-08 14:21:31 EST ---

Yes, I would mind very much.  I will vehemently resist acquiescing to
rampant violations of ancient standards.  My server is named datium
and is a member of my local domain, datix.lan, because it is defined so,
and properly, in my local DNS tables.  The domain name is appended to 
name searches because of these entries in /etc/resolv.conf:

  $ cat /etc/resolv.conf
  # Generated by NetworkManager
  search datix.lan dino.lan
  nameserver 192.168.2.2

If the cups package chooses to ignore proper name lookup, then it is
more severely broken than I had imagined.

There is no rational justification to
"set 'ServerAlias datium.datix.lan' in /etc/cups/cupsd.conf at datium
machine".  That is already its valid and correct name.

--- Additional comment from David A. De Graaf on 2017-12-08 15:00:18 EST ---

OK, now we know what's needed to make cups-browsed work again as it
used to, up through Fedora 26.

Edit /etc/cups/browsed.conf to add these lines:

  BrowsePoll datium
  BrowsePoll datair

  LocalQueueNamingRemoteCUPS RemoteName

The BrowsePoll lines are needed to tell which machines have printers and
printer queues;  cups-browsed can no longer figure this out by itself.
Be sure to use just the basename, not the Fully Qualified Domain Name.

The LocalQueueNamingRemoteCUPS entry is required to suppress printer
queues such as cl or cl2 from being called cl_datium and cl2_datium.

This edit must be made on every single computer on the LAN, client or
server, that hopes to use the printers on the servers.  In addition,
every visitor to my house who connects to my LAN must be instructed
to do the same - which machines serve as printer spoolers, and how to
edit this (obscure) file.


This is insanely stupid!
What is the purpose of cups-browsed but to detect and make available all
the printers on the LAN - automatically.
Detection and connection.  That's what it's for.

Please fix this unreasonable newly stupid program.
Until it's fixed, please revert the cups system to the Fedora 26
version which works just fine. 
This is a serious reason to NOT convert to Fedora 27.

--- Additional comment from Zdenek Dohnal on 2017-12-11 04:32:31 EST ---

(In reply to David A. De Graaf from comment #14)
> The BrowsePoll lines are needed to tell which machines have printers and
> printer queues;  cups-browsed can no longer figure this out by itself.
> Be sure to use just the basename, not the Fully Qualified Domain Name.

IMO this is clearly bug - CUPS should take FQDN - I just wanted to confirm my theory that if you set 'ServerAlias datium.datix.lan' in /etc/cups/cupsd.conf, it should work. Because CUPS looks for hostnames with '.local', IPs and server aliases in CUPS' code (because they probably forgot about it). If 'ServerAlias' would work, I'll know it is functional workaround and report it to CUPS upstream with all info.

> 
> The LocalQueueNamingRemoteCUPS entry is required to suppress printer
> queues such as cl or cl2 from being called cl_datium and cl2_datium.

I can set this option (LocalQueueNamingRemoteCUPS) in cups-browsed.conf by default for now, it can make users more comfortable with upgrade. But as upstream says, they marked this way of sharing as deprecated, so you could try to connect to your network printer directly from any client devices.

About 'no need to set BrowsePoll==to be able to see printers from all servers' it logically seems like bug, I'll ask upstream about it. Actually I always use 'BrowsePoll' option, so I didn't encounter possibility that it works without BrowsePoll. When I remove 'BrowsePoll' line from /etc/cups/cups-browsed.conf, cups-browsed connects only on local CUPS (CUPS socket /var/run/cups/cups.sock:0), so local CUPS managed to get remote cups queues before F27 (if cups-browsed worked without 'BrowsePoll').

--- Additional comment from David A. De Graaf on 2017-12-11 16:26:18 EST ---

> IMO this is clearly bug - CUPS should take FQDN - I just wanted to confirm my theory that if you set 'ServerAlias datium.datix.lan' in /etc/cups/cupsd.conf, it should work.

I can confirm that browsing works with
  BrowsePoll datium
or
  BrowsePoll datium.local
but NOT with
  BrowsePoll datium.datix.lan

I'm sure my LAN is quite similar to many - I have about ten computers of which two have a printer attached.  The idea that because cups-browsed has lost the ability to detect and connect those printers to all the LAN machines, that I should have to edit each and every one instead, is abhorrent and repulsive.

Incidentally and gratuitously, I wasted an entire day of my life yesterday struggling to get Windows 7 (as a guest under kvm, of course) to be able to print to my Brother laser printer.  Although datium, which hosts it, knows everything it needs to know about how to prepare data for that printer, Windows insisted on having its own set of drivers, which were not built in to its database.  So I had to fetch them from Brother - all because of the braindead printing architecture that Microsoft has chosen.  This is CERTAINLY NOTHING that Linux should emulate.  But sadly, it appears that the upstream geniuses are doing just that.

Here's a design principle that I advocate:
Confine all detailed knowledge of a printer's idiosyncrasies to the computer that hosts and manages it.  NEVER require the multitude of other computers that might some day want to use the printer to know anything about it.