Re: CUPS upgrade from Lenny to Squeeze breaks encryption - HELP
- From: "John A. Sullivan III" <jsullivan@xxxxxxxxxxxxxxxxxxx>
- Date: Sat, 31 Jul 2010 11:47:33 -0400
On Thu, 2010-07-29 at 10:17 +0200, Florian Kulzer wrote:
On Thu, Jul 29, 2010 at 03:22:31 -0400, John A. Sullivan III wrote:
On Thu, 2010-07-29 at 06:41 +0000, Camaleón wrote:
On Thu, 29 Jul 2010 01:46:40 -0400, John A. Sullivan III wrote:Yes, that looks like it and there does not appear to be a patch or
Hello, all. We are in quite a pickle tonight - our CUPS printing is
complete broken after an upgrade. The cups error_log is filled with
"Bad request line "VCB" from 172.x.x.1!' Printers do not appear in
Gnome or OpenOffice and, even though they appear in KDE, they are
unavailable.
(...)
I remember a similar thread:
***
Help - CUPS printing stopped working
http://lists.debian.org/debian-user/2010/07/msg00844.html
***
So maybe you are hitting this bug?
***
cups: https interface has SSL error ("SSL received a record that exceeded
the maximum permissible length")
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=590610
workaround yet :(
Both the older thread and the bug report show that an SSL error is
encountered when an SSL connection to the CUPS web interface is
attempted on the standard, unencrypted CUPS port (631). As far as I
know, that is the normal behavior with 1.4.4. #590610 looks like
misunderstanding or a user configuration error to me. Your problem might
very well be a different issue.
In your case, I would:
- Use netstat on the cups server to check on which port it listens for
the SSL connections.
- Verify that the CUPS web interface works for an https connection to
that port (not necessarily 631), first from the server itself and then
from the client.
- Try to specify the SSL port explicitly in all server URLs configured
on the client.
- If that does not help, use tcpdump or strace -enetwork to see exactly
which connections on which ports the client is attempting when it
tries to print a document.
Note: I do not use encrypted CUPS connections myself, so the above
advice involves some guesswork. I don't know on which port(s) CUPS
printing (as opposed to the CUPS web interface) negotiates encrypted
connections. Maybe some changes of the procedure were introduced in the
newer CUPS version, so I would also have a look at the changelog with
that in mind.
Thanks very much. I thought the idea of user error very possible as I
am by no means a CUPS expert. In the past, we have used the same port
for encrypted and unencrypted traffic. So I tried to specify a
different port for SSL with SSLListen only to have CUPS not accept it
and issue an "unknown directive" error. After a bit of searching, I see
in the cups 1.2b1 release notes:
"The scheduler now automatically detects SSL/TLS clients without using
the SSLPort/SSLListen directives."
That was our previous experience anyway. So I am assuming this is a new
bug. Any other ideas? Thanks again - John
--
To UNSUBSCRIBE, email to debian-user-REQUEST@xxxxxxxxxxxxxxxx
with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx
Archive: 1280591253.3342.3.camel@localhost">http://lists.debian.org/1280591253.3342.3.camel@localhost
- References:
- CUPS upgrade from Lenny to Squeeze breaks encryption - HELP
- From: John A. Sullivan III
- Re: CUPS upgrade from Lenny to Squeeze breaks encryption - HELP
- From: Camaleón
- Re: CUPS upgrade from Lenny to Squeeze breaks encryption - HELP
- From: John A. Sullivan III
- Re: CUPS upgrade from Lenny to Squeeze breaks encryption - HELP
- From: Florian Kulzer
- CUPS upgrade from Lenny to Squeeze breaks encryption - HELP
- Prev by Date: Re: hypervisor choices on Debian Testing amd64
- Next by Date: Re: How is 'pppd' launched while starting
- Previous by thread: Re: CUPS upgrade from Lenny to Squeeze breaks encryption - HELP
- Next by thread: reportbug nscd did not find bugs on bugs.debian.org
- Index(es):
Relevant Pages
|
