RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1485502 - Rebase cups-browsed to latest version in upstream cups-filters
Summary: Rebase cups-browsed to latest version in upstream cups-filters
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: cups-filters
Version: 7.3
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Zdenek Dohnal
QA Contact: Petr Sklenar
Marie Hornickova
URL:
Whiteboard:
Depends On:
Blocks: 1420851 1534569 1630905 1630913 1663257
TreeView+ depends on / blocked
 
Reported: 2017-08-25 21:45 UTC by Bryan Mason
Modified: 2023-03-24 13:51 UTC (History)
9 users (show)

Fixed In Version: cups-filters-1.0.35-24.el7
Doc Type: Enhancement
Doc Text:
.`cups-filters` updated The `cups-filters` packages, distributed in version 1.0.35, have been updated to provide the following enhancements: * The `cups-browsed` daemon, which provides the functionality removed from CUPS since the version 1.5, has been rebased to version 1.13.4, excluding the support for CUPS temporary queues. * A new backend, `implicitclass`, has been introduced to support high availability and load balancing.
Clone Of:
Environment:
Last Closed: 2019-08-06 13:06:58 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2019:2220 0 None None None 2019-08-06 13:07:03 UTC

Description Bryan Mason 2017-08-25 21:45:36 UTC 
Description of problem:

    cups-browsed in RHEL 7.3 is very old and lacks many features
    such as high-availability and fail-over.

Version-Release number of selected component (if applicable):

    cups-filters-1.0.35-21.el7.x86_64

How reproducible:

    N/A

Steps to Reproduce:

    N/A

Actual results:

    N/A

Expected results:

    N/A

Additional info:

    High-availability and fail-over are key features of CUPS browsing.  This 
    currently does not work with cups-browsed and RHEL 6 CUPS/1.4.2.  
    I've verified that the upstream (Fedora 26) version of cups-browsed
    does high-availability and fail-over very nicely with RHEL 6.
Comment 20 Bryan Mason 2019-02-27 18:13:54 UTC 
Thanks!  I'll test it as soon as I can.  I'm doing some RHEL 8 cups-browsed HA testing, so it should dovetail nicely into that work.  I'll post results as soon as I have them.
Comment 22 Bryan Mason 2019-03-15 16:48:11 UTC 
I'm sorry for the delay in testing.  I finished some of the RHEL 8 tests, and I'll start my RHEL 7 testing today.  I've already got a couple of RHEL 8 systems set up, so it shouldn't be much work to set up a RHEL 7 client and see how it interoperates with the RHEL 8 systems.
Comment 24 Bryan Mason 2019-03-15 22:33:54 UTC 
I can confirm that adding:

    BrowsePoll rhel8b-master1
    BrowsePoll rhel8b-master2

with the following cups-filters package installed

    # rpm -q cups-filters
    cups-filters-1.0.35-23.el7.x86_64

does indeed result in the creation an implicit class when the hosts rhel8b-master{1,2} have print queues with the same name:

    # lpstat -t
    scheduler is running
    no system default destination
    device for raw-socket: implicitclass:raw-socket
    device for rdn: implicitclass:rdn
    raw-socket accepting requests since Fri 15 Mar 2019 03:26:03 PM PDT
    rdn accepting requests since Fri 15 Mar 2019 03:22:41 PM PDT
    printer raw-socket is idle.  enabled since Fri 15 Mar 2019 03:26:03 PM PDT
    printer rdn is idle.  enabled since Fri 15 Mar 2019 03:22:41 PM PDT

For what it's worth, I also had to add:

    CreateRemoteRawPrinterQueues Yes

because the queues on rhel8b-master{1,2} are raw queues.

I also tested to make sure that the print jobs did go through to the two master print servers as expected.

Next I need to test class creation without BrowsePoll.
Comment 25 Bryan Mason 2019-03-17 17:32:25 UTC 
If I run "cupsdisable raw-socket" on rhel8b-master1, all jobs are routed to rhel8b-master2, as expected.
Comment 26 Bryan Mason 2019-03-17 18:54:03 UTC 
I can also confirm that setting

  BrowseRemoteProtocols CUPS

on the RHEL 7 client while

  BrowseProtocols CUPS

is set on the master servers results in the queues being found on the client:

  [root@rhel76-client cups-filters]# lpstat -t
  scheduler is running
  no system default destination
  device for raw-devnull: implicitclass:raw-devnull
  device for raw-socket: implicitclass:raw-socket
  device for rdn: implicitclass:rdn
  raw-devnull accepting requests since Sun 17 Mar 2019 11:51:39 AM PDT
  raw-socket accepting requests since Sun 17 Mar 2019 11:51:39 AM PDT
  rdn accepting requests since Sun 17 Mar 2019 11:51:39 AM PDT
  printer raw-devnull is idle.  enabled since Sun 17 Mar 2019 11:51:39 AM PDT
  printer raw-socket is idle.  enabled since Sun 17 Mar 2019 11:51:39 AM PDT
  printer rdn is idle.  enabled since Sun 17 Mar 2019 11:51:39 AM PDT

Interestingly, all queues are created as implicitclass queues, even when there's only one printer in the class (raw-devnull only exists on one master print server).  That's a little different from the implicit class behavior in RHEL 6 (CUPS 1.4.2), but it is consistent with the behavior or cups-browsed in RHEL 8, so I assume that behavior is correct.
Comment 27 Zdenek Dohnal 2019-03-18 08:40:01 UTC 
(In reply to Bryan Mason from comment #26)
> I can also confirm that setting
> 
>   BrowseRemoteProtocols CUPS
> 
> on the RHEL 7 client while
> 
>   BrowseProtocols CUPS
> 
> is set on the master servers results in the queues being found on the client:
> 
>   [root@rhel76-client cups-filters]# lpstat -t
>   scheduler is running
>   no system default destination
>   device for raw-devnull: implicitclass:raw-devnull
>   device for raw-socket: implicitclass:raw-socket
>   device for rdn: implicitclass:rdn
>   raw-devnull accepting requests since Sun 17 Mar 2019 11:51:39 AM PDT
>   raw-socket accepting requests since Sun 17 Mar 2019 11:51:39 AM PDT
>   rdn accepting requests since Sun 17 Mar 2019 11:51:39 AM PDT
>   printer raw-devnull is idle.  enabled since Sun 17 Mar 2019 11:51:39 AM PDT
>   printer raw-socket is idle.  enabled since Sun 17 Mar 2019 11:51:39 AM PDT
>   printer rdn is idle.  enabled since Sun 17 Mar 2019 11:51:39 AM PDT

Thank you for all the testing, Bryan!

> 
> Interestingly, all queues are created as implicitclass queues, even when
> there's only one printer in the class (raw-devnull only exists on one master
> print server).  That's a little different from the implicit class behavior
> in RHEL 6 (CUPS 1.4.2), but it is consistent with the behavior or
> cups-browsed in RHEL 8, so I assume that behavior is correct.

cups-browsed started to mark all remote cups queues as implicitclass in auto-discovery since 1.12.0. It uses IPP backend only for real IPP printers (discovered by avahi+IPP2.0 min. requirement+PWG, Apple of PDF supported document format).
Comment 41 errata-xmlrpc 2019-08-06 13:06:58 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2019:2220
Note You need to log in before you can comment on or make changes to this bug.