[116] in athena10
Re: [RHE] Is Athena10 using LPRng, CUPS or both?
daemon@ATHENA.MIT.EDU (Timothy G Abbott)
Tue Mar 11 14:17:02 2008
Date: Tue, 11 Mar 2008 14:16:16 -0400 (EDT)
From: Timothy G Abbott <tabbott@MIT.EDU>
To: William Cattey <wdc@mit.edu>
cc: Evan Broder <broder@mit.edu>, Greg Hudson <ghudson@mit.edu>,
rhe-release@mit.edu, sipb-cups@mit.edu, athena10@mit.edu
In-Reply-To: <88A3357C-AEC2-472E-B93B-20502C31D635@mit.edu>
Message-ID: <Pine.LNX.4.64L.0803102349430.28857@opus.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Evan Broder and I did some source diving into the CUPS source to
investigate these issues.
Apparently, the CUPS client software does not support using more than our
CUPS server simultaneously. This seems to be a feature of the
implementation of the CUPS client, not of the server infrastructure.
They do make it easy to change which CUPS server you're talking to (via
the CUPS_SERVER environment variable), but this isn't a great interface.
This seems to be fairly hardcoded into the CUPS sources; more on this
later.
The SIPB CUPS folks are still waiting on getting an ipp/ keytab to find
out whether and how the Kerberos support in CUPS works, but given how
Kerberos works, it does seem likely that there will be problems proxying
Kerberos authentication through a local CUPS server that doesn't have a
Kerberos identity of its own. Hopefully we'll be able to test this stuff
out soon.
But it does seem with the current CUPS implementation that Kerberos
authentication and local printing may be mutually exclusive (since you
can't have two CUPS servers accessible simultaneously).
It may be possible to change the CUPS client implementation to support
using more than one CUPS server.
The CUPS implementation has a _cups_globals_t type that contains a field
called "server" which is the name of the CUPS server. This is referenced
only in the code to set and get the default CUPS server; most of the code
that depends on there being only one CUPS server is when the CUPS server
name is obtained via the cupsServer() function, which returns a string
that is the hostname of the CUPS server; this is then used in the
httpConnectEncrypt function that connects to the server and returns a
connection object that is used for all the actual work. Basically, what
we'd want to do is replace the cupsServer() function with one that takes
an additional argument, the printer name, and return the name of the
server from a configured list of servers that hosts that printer.
There are 58 references of cupsServer() in the cupsys sources, and another
2 in libgnomecups (the GNOME library that is used for doing CUPS stuff).
Of the 58 references in the cupsys sources,
- 27 are in the sources for the System V command set. These are
containing in the cupsys-client package, and I don't think we necessarily
care about them, since CUPS printing works fine with cupsys-client not
installed.
- 6 are in the sources for the CUPS web administration system, and
probably aren't relevant for our purposes.
- 9 are in the sources for the CUPS server, and probably don't matter for
our purposes.
- 3 are in documentation.
- 4 are in the sources for the berkeley commands (lprm, lpc, lpq); these
look easy to fix because the printer name is available.
- 9 are in the CUPS client/library code; these would need some new code to
handle combining lists of the printers from two different servers, etc.,
but for the ones I inspected it doesn't look hard.
There is also some Java code that uses some totally different mechanism
for handling things, but also doesn't seem to support Kerberos anyway.
So, it does not seem completely infeasible to patch CUPS to support
multiple CUPS servers, but also not something to be taken lightly.
We'd probably want to talk to upstream first to make sure they'd be
willing to merge it (and they'd probably want us to not ignore some things
that don't matter to us), since this isn't the kind of changeset that'd be
easy to maintain long-term.
-Tim Abbott
On Mon, 10 Mar 2008, William Cattey wrote:
> 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
>
