Bug 1485502
Summary: | Rebase cups-browsed to latest version in upstream cups-filters | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Bryan Mason <bmason> |
Component: | cups-filters | Assignee: | Zdenek Dohnal <zdohnal> |
Status: | CLOSED ERRATA | QA Contact: | Petr Sklenar <psklenar> |
Severity: | high | Docs Contact: | Marie Hornickova <mdolezel> |
Priority: | high | ||
Version: | 7.3 | CC: | apmukher, bmason, lkuprova, mdolezel, mkolaja, ovasik, psklenar, thozza, zdohnal |
Target Milestone: | rc | Keywords: | FutureFeature, Patch, Rebase, Regression |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
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.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2019-08-06 13:06:58 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 1420851, 1534569, 1630905, 1630913, 1663257 |
Description
Bryan Mason
2017-08-25 21:45:36 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. 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. 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. If I run "cupsdisable raw-socket" on rhel8b-master1, all jobs are routed to rhel8b-master2, as expected. 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. (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). 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 |