[6514] in Release_7.7_team
Re: Kerberized printing, the saga continues
daemon@ATHENA.MIT.EDU (Evan Broder)
Tue Nov 17 12:32:20 2009
MIME-Version: 1.0
In-Reply-To: <D10E68EE-5ADA-4B69-9EB2-A45BEFC2B246@mit.edu>
Date: Tue, 17 Nov 2009 12:32:11 -0500
Message-ID: <2706d8dd0911170932g28aac9d8u63f27b3c84e27259@mail.gmail.com>
From: Evan Broder <broder@MIT.EDU>
To: Jonathan Reed <jdreed@mit.edu>
Cc: "Mark W. Manley" <mmanley@mit.edu>, Stuart Peloquin <peloquin@mit.edu>,
Garry Zacheiss <zacheiss@mit.edu>,
"release-team@mit.edu" <release-team@mit.edu>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Flag: NO
X-Spam-Score: 0.00
Content-Transfer-Encoding: 8bit
Does printers.mit.edu require authentication for those queues? Would
it be possible either for the CUPS servers to bounce those jobs using
Kerberized lpr, or for the LPRng servers to be re-configured to
unconditionally accept jobs from the CUPS servers?
- Evan
On Tue, Nov 17, 2009 at 12:28 PM, Jonathan Reed <jdreed@mit.edu> wrote:
> (adding release-team to the CC)
>
> It sounds like our two primary options are:
> - Convert the printers to CUPS, which requires reconfiguration of client
> machines that are still using KLP/KLPR, and disables printing for Athena 9
> users
> - Educate users of Kerberized printers to continue using the "Print to LPR"
> functionality in GTK+ apps on Debathena.
>
> The former is undoubtedly the Right(tm) answer, but will probably increase
> the support burden on the RCCs and Helpdesk during the transition time. Is
> there any way we can get a list of hostnames/IP address that have submitted
> kerberized LPR jobs to those printers in, say, the past week? I'm hoping
> that if we go through the list, and eliminate those hostnames that belong to
> Athena workstations, we can get an idea of how many student machines would
> need reconfiguration.
>
> If do choose to go that route, can we do something intelligent such that
> anyone on an Athena 9 machine who tries to print to one of the queues in
> question gets an immediate error and/or gets e-mail sent to them saying
> "Your job didn't print, try again"?
>
> -Jon
>
> On Nov 17, 2009, at 12:03 PM, Mark W. Manley wrote:
>
>> Greetings,
>>
>> Since the switch yesterday to show the Ops-maintained CUPS systems to some
>> DebAthena workstations, I've noticed that jobs are building in the queues
>> for Kerberos-enabled printers, such as massave, ashdown, etc. It's more
>> than likely the result of people selecting these printers in the quick list
>> on the workstations, and continuing on their merry little way.
>>
>> The problem, as you can imagine, is what when our CUPS servers take the
>> job, they can't spool it onto the LPRng server since it's requiring the
>> Kerberos. As such, they're lingering in the queues until eventually
>> discarded or cancelled since they can't get there from here.
>>
>> So, the question becomes, what's the best way to handle this situation?
>> Some people recently decided to de-Kerberize their printers, like the waffle
>> printer. I still think that's the direction in which we should press
>> people. Others, unfortunately, recently insisted on this feature, no matter
>> how flaky. That leaves us in somewhat of a bind because DebAthena uses CUPS
>> for printing (which generates that nice pick list) and the Athena 9
>> workstations use LPRng.
>>
>> I propose, therefore, that we move these DORM Kerberized queues from LPRng
>> to CUPS soon. I'm still testing, but so far that's proven fairly reliable
>> in allowing the quick list to work again in DebAthena, as well as letting
>> people print on the command line using the CUPS client. What I still need
>> to test is making sure that clients can print to any of the CUPS servers and
>> having their server do The Right Thing [tm] in handling the job (the servers
>> bounce jobs between each other so that there is really one server to deliver
>> the job to each printer--one server to handle all the spooling). That kind
>> of testing shouldn't take long to do.
>>
>> The big change would be on users' desktops that hard-coded the older
>> server names like mulch. The LPRng servers don't speak IPP, much less
>> Kerberos-enabled IPP, so they'd be unable to bounce jobs to the CUPS servers
>> if Kerberos-enabled in any meaningful way, leading to the reverse of the
>> current situtation. It would also effectively de-support the LPRng client
>> on Athena 9 for Kerberos-enabled queues in favor of the CUPS client on
>> Athena 10.
>>
>> What are your thoughts on this change? I think it needs to happen at some
>> juncture, though I could be convinced that now is not the time.
>>
>> -MM
>
>
