[6513] in Release_7.7_team
Re: Kerberized printing, the saga continues
daemon@ATHENA.MIT.EDU (Jonathan Reed)
Tue Nov 17 12:29:04 2009
Cc: Stuart Peloquin <peloquin@mit.edu>, Garry Zacheiss <zacheiss@mit.edu>,
"release-team@mit.edu" <release-team@mit.edu>
Message-Id: <D10E68EE-5ADA-4B69-9EB2-A45BEFC2B246@mit.edu>
From: Jonathan Reed <jdreed@MIT.EDU>
To: "Mark W. Manley" <mmanley@mit.edu>
In-Reply-To: <alpine.DEB.2.00.0911171150410.23746@green-arrow.mit.edu>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Tue, 17 Nov 2009 12:28:55 -0500
X-Spam-Flag: NO
X-Spam-Score: 0.00
(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
