Bug 1525937 - cups-browsed doesn't detect printers automatically
Summary: cups-browsed doesn't detect printers automatically
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: cups-filters
Version: 29
Hardware: Unspecified
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Zdenek Dohnal
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1518415
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-12-14 13:24 UTC by Zdenek Dohnal
Modified: 2019-07-15 08:19 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1518415
Environment:
Last Closed: 2019-07-15 08:19:01 UTC


Attachments (Terms of Use)
Print dialog (21.20 KB, image/png)
2018-04-16 13:33 UTC, Attila
no flags Details
Print dialog LibreOffice wrong (104.62 KB, image/png)
2019-06-11 13:34 UTC, Attila
no flags Details
Print dialog LibreOffice right (87.11 KB, image/png)
2019-06-11 13:34 UTC, Attila
no flags Details


Links
System ID Priority Status Summary Last Updated
Github OpenPrinting cups-filters issues 10 None None None 2017-12-14 13:36:27 UTC

Description Zdenek Dohnal 2017-12-14 13:24:07 UTC
+++ 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.

Comment 1 Zdenek Dohnal 2017-12-14 13:36:28 UTC
Added upstream issue.

Comment 2 Jason Tibbitts 2017-12-16 21:59:52 UTC
So I just did a partial F27 rollout and realized that I had forgotten to properly test printing.  And indeed, with an F27 CUPS server, F26 machines see the exported printers fine but F27 machines do not.  I added BrowsePoll statements and "LocalQueueNamingRemoteCUPS RemoteName" as described in this ticket and things are working again, though it seems to take quite some time to fully populate the printer list, while F26 filled the list pretty much immediately.  (This network has about 30 printers.)

I don't have any issues with using either bare hostnames or FQDNs; I'm  assuming that was something of a digression and that the primary issue is the one described in the ticket topic.

The "new way" where the clients connect directly to the printers is... not workable for me.  I need centralized control, centralized access restrictions and would really love to have centralized accounting.  The printers are firewalled from the network in general, and in some cases aren't even on a network which is visible from the 200+ desktop machines.

So maybe for a small home network it's reasonable for all clients to connect to the printers directly, but surely that can't be made the only way of doing things.  Otherwise I don't know how you could possibly implement anything resembling an "enterprise" printing setup.  As far as I know there is no other remotely viable printing system for Linux (and none for Apple machines) so it would be pretty bad if this functionality went away.  So bad, in fact, that I really think that I must be missing the point.

Comment 3 Samuel Sieb 2018-03-02 22:13:17 UTC
I have the same setup at a school.  All the printers are on an isolated network with the server handling the printer queues.  I have upgraded very few computers to F27 yet, but now that I think about it, the one I upgraded recently did not see the printers and I had to add one manually.

Comment 4 Attila 2018-04-16 13:31:40 UTC
Hi,

I have added the statements "BrowsePoll fileserver" and "LocalQueueNamingRemoteCUPS RemoteName" to cups-browsed to be able to print and see all the remote printers on my Fedora 27 client.

When I want to print from LibreOffice I see unfortunately all the printers twice and one of them 3 times. The same from all KDE applications (based on Qt), see attachment. On Firefox and Thunderbird (based on Gtk) all the printers appear one time as expected. This is very chaotic and confusing.
Besides the print dialog from every application takes 3 to 4 seconds to appear. On Fedora 26 and before the print dialog was open immediately.

My first question is:
Is there a way to normalize the list of printers as it was on Fedora 26 and before?

My second question is:
Is there a way to accelerate the print dialog, so that it appears directly as it was on Fedora 26 and before?

Comment 5 Attila 2018-04-16 13:33:45 UTC
Created attachment 1422515 [details]
Print dialog

Comment 6 Zdenek Dohnal 2018-04-16 13:46:21 UTC
Hi Attila,

does command '$ lpstat -a' return duplicates of print queues as well? 

If doesn't, create other bugzilla on actual component, which shows duplicates.

If does, create other bugzilla on cups-filters component.

Comment 7 Attila 2018-04-16 14:00:10 UTC
'lpstat -a' doesn't return duplicates of print queues.
I am going to create a new bugzilla on "cups-filters".

Comment 8 Zdenek Dohnal 2018-04-16 14:04:07 UTC
(In reply to Zdenek Dohnal from comment #6)
> does command '$ lpstat -a' return duplicates of print queues as well? 
> 
> If doesn't, create other bugzilla on actual component, which shows
> duplicates.
> 
^^^
This is your outcome, please file a bug on GUI component like libreoffice or another.


> If does, create other bugzilla on cups-filters component.

Comment 9 Steve 2018-11-03 17:42:11 UTC
I see this bug in Fedora 29. No printers found.

$ lpstat -t
scheduler is running
no system default destination
lpstat: No destinations added.
lpstat: No destinations added.
lpstat: No destinations added.
lpstat: No destinations added.
$ lpstat -a
lpstat: No destinations added.
$

cups-2.2.8-5.fc29.x86_64
cups-filters-1.20.3-9.fc29.x86_64

Please change version to 29, since i can't do that!

Comment 10 Steve 2018-11-03 17:53:50 UTC
Installing and running system-config-printer does the job.

$ lpstat -t
scheduler is running
system default destination: Hewlett-Packard-HP-LaserJet-200-color-M251n
device for Hewlett-Packard-HP-LaserJet-200-color-M251n: hp:/net/HP_LaserJet_200_color_M251n?hostname=NPI6E41CB.local
Hewlett-Packard-HP-LaserJet-200-color-M251n accepting requests since Sat 03 Nov 2018 06:48:08 PM CET
printer Hewlett-Packard-HP-LaserJet-200-color-M251n is idle.  enabled since Sat 03 Nov 2018 06:48:08 PM CET
$ lpstat -a
Hewlett-Packard-HP-LaserJet-200-color-M251n accepting requests since Sat 03 Nov 2018 06:48:08 PM CET
$ 

system-config-printer-1.5.11-13.fc29.x86_64

Comment 11 Zdenek Dohnal 2019-06-10 07:59:41 UTC
Hi everyone,

can you confirm the issue is still there? Please notice that automatic print queue creation (without any change in cups-browsed.conf) works by design for following use cases:

- IPP printers in the same LAN if 'CreateIPPPrinterQueues All' is set - check if it is set in cups-browsed.conf (it does not have to be there, if you made changes in cups-browsed.conf - it won't get replaced by update, if config is changed...)
- CUPS remote queues from CUPS server (with CUPS around 2.x and newer) for network printers shared by dnssd

It does not work by design without BrowsePoll for:
- IPP printers and 'new' CUPS servers which are not in the same LAN 
- queues shared by legacy CUPS broadcast

It does not work at all for now:
- remote queues connected to usb printer

Comment 12 Zdenek Dohnal 2019-06-10 08:01:13 UTC
Plus you need to have cups-browsed service running.

Comment 13 Steve 2019-06-10 09:09:41 UTC
After removing the printer and starting cups-browsed (disabled by default?), the printer is added. So i would say this bug is fixed.

Comment 14 dag 2019-06-11 08:03:31 UTC
After a sleep resume cups-browserd will not pick up the printers any more without a restart of the service

Comment 15 Zdenek Dohnal 2019-06-11 08:46:47 UTC
It is different bug, https://bugzilla.redhat.com/show_bug.cgi?id=1541084 .

Comment 16 Attila 2019-06-11 13:30:09 UTC
Hi,

the file "cups-browsed.conf" i am using is the one provided by the rpm-package on Fedora 30. "CreateIPPPrinterQueues All" is set. The service cups-browsed is running. The computer is restarted.
Here the results of my test:

1. When I open "kwrite" the list of available printers is now OK. I can reopen the print dialog at any time and the list of available printers is OK.

2. When I open "LibreOffice writer" the list of available printers is sometimes OK (same as kwrite) and sometime wrong (I see the printer twice and more with different names). When I keep running LibreOffice and reopen the print dialog again I see the wrong list of printers. I reopen the print dialog for many times and sometimes it shows the worng list and sometimes the correct list.
I am wondering, how can this be? Is it a kind of "timing" or a "cache" problem an d sometimes the "cache" wins? I have no clue.

3. All of the clients are on Fedora 30. The files "cups-browsed.conf" and "cupsd.conf" are identical. Anyway it seems to work on some clients and on other not which means "kwrite" shows me always the correct list of printers on some clients and on other clients always the wrong list.

Any idea?

Comment 17 Attila 2019-06-11 13:34:03 UTC
Created attachment 1579381 [details]
Print dialog LibreOffice wrong

Comment 18 Attila 2019-06-11 13:34:46 UTC
Created attachment 1579382 [details]
Print dialog LibreOffice right

Comment 19 Attila 2019-07-15 06:39:34 UTC
Can someone please respond to this?

Comment 20 Zdenek Dohnal 2019-07-15 08:19:01 UTC
Attila,

you are adding an different issue into ticket on different problem. Please file the issue on specific app you have the problem with. My guess is that you can have new enough printer (2012 and younger) which is capable of IPP everywhere, so those duplicate queues are CUPS temporary queues.

Because there is no response about the problem of 'automatic print queue creation', I'm closing the issue.


Note You need to log in before you can comment on or make changes to this bug.