[113] in athena10
Re: Is Athena10 using LPRng, CUPS or both?
daemon@ATHENA.MIT.EDU (Evan Broder)
Mon Mar 10 11:26:57 2008
Message-ID: <47D55331.8090909@mit.edu>
Date: Mon, 10 Mar 2008 11:26:41 -0400
From: Evan Broder <broder@MIT.EDU>
MIME-Version: 1.0
To: Greg Hudson <ghudson@mit.edu>
CC: William Cattey <wdc@mit.edu>, athena10@mit.edu, rhe-release@mit.edu,
sipb-cups@mit.edu
In-Reply-To: <1205161702.5860.8.camel@error-messages.mit.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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.
>
>
>
