[cups.general] CUPS, Kerberos, and ServerName

[Michael R Sweet]

Rick Cochran wrote:
> ...
>> 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.

Two different configuration files, one for the client (what server
to talk to) and one for the server (what server to be, essentially).

Not sure what the confusion is about, especially when there is so
much separate documentation on it...

> ...
> 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.

Which is why many schools hold jobs for printing until the student
comes to get them...

>> 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.

That is exactly what CUPS does.

>> 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.

The clients do the load-balancing, the server just prints what it
gets.  You can, of course, configure classes on a server to load-
balance across multiple printers, but that only provides printer
redundancy, not server redundancy.

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

No guarantee that the job will be printed - the client would send the
job to the server and "forgot it".  If the server dies, the job goes
with it.

There may also be limitations WRT monitoring the status of the job
and queue, although I hope we can overcome them in the final
implementation.

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

All of the Apple GUIs now respect the client.conf file, so a per-user
~/.cups/client.conf file can point to the per-user cupsd's domain
socket, and then everything works as before.

-- 
______________________________________________________________________
Michael R Sweet                        Senior Printing System Engineer