Bug 118982
Summary: | CUPS client cannot connect to a secure SSL CUPS server | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 3 | Reporter: | Graham Leggett <minfrin> |
Component: | cups | Assignee: | Tim Waugh <twaugh> |
Status: | CLOSED ERRATA | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 3.0 | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-09-02 02:10:55 UTC | Type: | --- |
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: | 116727 |
Description
Graham Leggett
2004-03-23 16:16:37 UTC
Some more investigation: If an strace lpq is done, the following steps are evident: - The clients.conf file is opened and read. - An attempt is made to write a _non encrypted_ request to the server defined in clients.conf, when client.conf stipulates "encryption always". - The response comes back from the server: "HTTP/1.0 400 Bad Request" - lpq alternates between two responses: [minfrin@gatekeeper minfrin]$ lpq lpq: Unable to contact server! [minfrin@gatekeeper minfrin]$ lpq no entries In the case of "unable to contact server", it seems the initial write to the server fails immediately. In the case of "no entries", it seems this is what is returned if the server says "400 Bad Request". CUPS seems to alternate between one response and the other. This issue has been opened as STR #653 at http://www.cups.org. Any update on this bug? This is a showstopper for RHEL being deployed as a printserver. The latest version of CUPS as supplied www.cups.org is broken out the box on RHEL: [root@gatekeeper root]# service cups start cupsd: Child exited on signal 11! cups: unable to start scheduler. So: is there any hope for a secure RHEL printserver, or is RHEL a dead loss in this application? Direct link is: http://www.cups.org/str.php?L653 (Despite being on the CC field for it I've had no email from it. :-( ) Do you need a binary package set to test, or can you try the pseudo-patch from my comment to STR #653 yourself? FWIW, Fedora development will shortly have cups-1.1.20-8, which includes this patch. With cups-1.1.17-13.3.12, I'm still seeing: E [17/Aug/2004:22:43:34 -0400] EncryptClient: error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request E [17/Aug/2004:22:43:34 -0400] Bad request line "1.0"! in the error log. Am I just dumb with cups configuration? This seems to be due to STR #434: http://www.cups.org/str.php?L434 but I think it is comparatively harmless. The corresponding Red Hat Bugzilla report is bug #114999. It seems the latest fedora development version of cups-1.1.21-1.rc1.9 has a dependancy list a mile long, including the need to upgrade python. When will this patch be made available officially to RHEL3? An errata has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2004-228.html |