[cups.general] CUPS, Kerberos, and ServerName

[Rick Cochran]

Michal,

Thanks for your reply.  Comments below.

Michael Sweet wrote:
> Rick Cochran wrote:
>> I finally got Kerberos authenticated printing to work.  The part I was 
>> missing was that unless one wants to issue service principals for every 
>> client workstation, the client command has to send the print job 
>> directly to the remote server, bypassing the local spooler.  This can be 
>> accomplished by using, for example, "-H remote-server-name" in the lpr 
>> command.  It can also be accomplished by including "ServerName 
>> remote-server-name" in the "client.conf" file on the client 
>> workstation.  This raises some additional questions.
>>
>> 1. The "ServerName" directive can be used in either cupsd.conf or 
>> client.conf. One of my mistakes was using it in the cupsd.conf.  
>> Apparently this directive has different functionality depending on which 
>> of the conf files it is in.  What function does it have when used in the 
>> cupsd.conf file?
> 
> It changes the default hostname that is advertised by the local
> scheduler (cupsd) process.  These days the value is mostly-ignored
> since we usually advertise using the interface address/hostname
> instead.

A small nit, but having the same directive have two different functions is 
unnecessarily confusing.

>> 2. Is there some way to send print jobs for some printers to the local 
>> spooler, and send print jobs for other printers directly to a remote 
>> spooler?  I certainly hope so.  Otherwise it would be impossible to have 
>> a directly attached printer which did not require Kerberos 
>> authentication and a remote printer which did.
> 
> There is currently no way to do this, and for good reason.  Local
> spooling ensures that:
> 
> a) you can print at any time, not just when the server is up or
>     accessible (think of spooling a job from a remote location and
>     having the job start printing when you get to work)

One person's good reason can be another's bad reason.  For my application, 
precisely the opposite behavior is desirable.  If a student prints from a lab 
workstation and the server is down, they won't be around to pick up the output 
when it is eventually printed and charged to their account.

> b) you can't lose a job because the server dies before it prints
>     your job

This is only true if the local spooler retains the job until the remote spooler 
has sent it to the printer and the printer has printed it.  I had no idea that 
CUPS did that.

In any case, this is a solution to a problem which I don't have, since my server 
is never (knock on wood) down.

> c) you can participate in load-balanced printing services

Are you saying that the CUPS remote server cannot do load-balancing unless the 
print job reached it through the client workstation's spooler?  You of all 
people should know, but that doesn't sound right.

> That said, we are investigating optional behavior that can be turned
> on locally or on the server to force all jobs for a particular
> printer to be printed "direct" to the server rather than spooling
> locally.  This mode will have serious shortcomings and will likely
> require changes to the various desktop environments to support it,
> but it *will* allow you to use things like Kerberos on otherwise
> unmanaged networks.

This would be nice.  At the moment I can't see any way of using Kerberos with 
CUPS to eliminate my need to provide a fairly kludgy alternate method of 
Kerberos authenticated printing from Macs.

I would be interested in knowing what the "serious shortcomings" would be.

Indeed, "changes to the various desktop environments" would be necessary.  I 
note that if I create a client.conf file containing a ServerName directive on a 
MacOS machine, the queues on the server don't show up in the print dialog for 
any of the applications on the client.  But you knew that.

> You can also run per-user copies of cupsd that automatically
> inherit the user's Kerberos credentials so you can print both
> locally and remotely without needing the local service principle.
> You'll likely run into permission issues for USB/parallel/serial
> printers, and there is the potential for greater information
> disclosure since the print filters will have access to all of the
> user's files, but it would give you the functionality you are looking
> for today...

An interesting idea, but I don't see how this could work under MacOS without 
causing the AppleSauce to get confused.

Bottom line: my dream of being able to authenticate printing from MacOS and Unix 
hosts without having to install a kludgy client remains unfulfilled.

Not knowing when to quit, I will now attempt Kerberos authenticated printing 
from a Windows client (via "Internet Printing") to a CUPS server.

Yours,
-Rick