[114] in athena10
Re: [RHE] Is Athena10 using LPRng, CUPS or both?
daemon@ATHENA.MIT.EDU (William Cattey)
Mon Mar 10 23:34:09 2008
In-Reply-To: <47D55331.8090909@mit.edu>
Mime-Version: 1.0 (Apple Message framework v753)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <88A3357C-AEC2-472E-B93B-20502C31D635@mit.edu>
Cc: Greg Hudson <ghudson@mit.edu>, rhe-release@mit.edu, sipb-cups@mit.edu,
athena10@mit.edu
Content-Transfer-Encoding: 7bit
From: William Cattey <wdc@MIT.EDU>
Date: Mon, 10 Mar 2008 23:33:21 -0400
To: Evan Broder <broder@mit.edu>
My understanding of the issues in adding Kerberos printing to CUPS is
incomplete at best.
The description that Evan gives about requiring a local keytab, or
dis-allowing local printers
is consistent with the amorphous "there are problems getting the
tickets from the end-user through to the printer with the CUPS
architecture," I'd heard.
I'd pretty much accepted that the way forward was to adopt CUPS and
abandon Kerberized printing. Sacrificing local printers, or
requiring a per-machine keytab
to get Kerberized printing back with CUPS seems like too high a price
to me.
-Bill
----
William Cattey
Linux Platform Coordinator
MIT Information Services & Technology
N42-040M, 617-253-0140, wdc@mit.edu
http://web.mit.edu/wdc/www/
On Mar 10, 2008, at 11:26 AM, Evan Broder wrote:
> Instead of using CUPS as a front end to LPRng, it might be better
> in the
> long run to setup a CUPS server as the primary print server, and
> having
> the LPRng queues dump into that. For old Athena machines, you could
> probably throw CUPS's lpr/lprm into a locker for managing jobs, or
> possibly even provide GUI options.
>
> The problem with the SIPB CUPS server (or any other server that just
> dumps jobs into LPRng) is that the server immediately dumps the job
> into
> LPRng's queue and it vanishes from CUPSland, so that you need the
> LPRng
> tools to manage your jobs.
>
> I also believe that there are some problems with the CUPS architecture
> that would make it extremely difficult to do Kerberized printing,
> although I'm not sure of the details yet. My understanding is that a
> CUPS client prints to a cupsd, which is usually running on localhost.
> The local cupsd may accept advertised printers from a global cupsd.
> You
> need to be running a local cupsd, though, so that printers can be
> added
> locally (like a USB printer or something). However, the local cupsd
> needs to have a keytab in order to accept forwarded credentials
> from the
> CUPS client in order to forward those credentials on to the global
> CUPS
> server.
>
> I might be wrong about this works. I hope I'm wrong, because it
> would be
> really nice to be able to have a CUPS-based infrastructure that
> supports
> Kerberized printing. Documentation on Kerberized CUPS is fairly scant,
> so it's hard to figure out exactly how things work. Right now, though,
> it looks like if you want Kerberized printing, you either disallow
> local
> printers or require a keytab on every machine.
>
> The sipb-cups project has requested an ipp/ keytab, and I've also
> requested one for my own machine so that we can experiment, so
> we'll get
> back to you on what we find out.
>
> - Evan
>
> Greg Hudson wrote:
>> On Sat, 2008-03-08 at 15:07 -0500, William Cattey wrote:
>>
>>> What is Athena10 planning to do?
>>>
>>
>> We don't have a firm plan yet.
>>
>> ops has expressed a willingness to make changes to the printing
>> infrastructure but I'm guessing they would need help for anything
>> serious. They are more amenable to less invasive changes, like
>> setting
>> up a CUPS server as a front end to the existing lpd printing queues.
>> SIPB's work in setting up a prototype CUPS front end is appreciated
>> here.
>>
>> Ideally I would like to get to a point where the Athena lprng sources
>> are no longer required at all. Corner cases like removing
>> printing jobs
>> may make that unfeasible for Athena 10. If we do have to build
>> it, we
>> will probably follow SWRT's lead and rename all of the commands to
>> mit-lp* to avoid conflicting with native printing packages.
>>
>> It is unclear how long authenticated printing will remain
>> important. My
>> understanding is that it is still in use with some private
>> printers but
>> no one in IS&T particularly wants to support it any more. CUPS
>> supposedly allows Kerberos-authenticated printing via IPP with
>> forwarded
>> tickets, but (1) we don't know if that really works, and (2) that
>> requires adding IPP printing queues alongside or in place of the lpd
>> printing queues, which is a more invasive change.
>>
>>
>>
> _______________________________________________
> Rhe-release mailing list
> Rhe-release@mit.edu
> http://mailman.mit.edu/mailman/listinfo/rhe-release
