[cups.general] Re: How to authenticate from printing software?

[Michael Sweet]

Colin Walters wrote:
> ...
>>I guess I don't see the usefulness of the session server 
> 
> 
> Basically, for Kerberos authentication.  When the IPP backend is exec'd
> from the session server, it can just pick up the credentials from the
> user session.

And how is this different from passing the credentials to the server
(encrypted, of course)?

> ...
>>>already doing this in eggcups; you get an icon with your print jobs and
>>>their status.  This works by having the session cups IPP backend send
>>>the remote job ID to the user session over DBus, which picks it up and
>>>starts polling until completion.
>>
>>... which won't scale,
> 
> 
> Why won't it scale?  The user session only polls their particular jobs,
> while the jobs are active.  As soon as the job is complete, polling
> stops.

Imagine 1000's of users polling all the time while they wait for
their job to complete.

>> which is why we are keen on using IPP
>>notifications for this sort of monitoring.  
> 
> 
> I could be convinced that IPP notification is the way of the future.
> Right now our printing architecture is based on polling, which obviously
> sucks.  But the fact is, IPP notification doesn't exist at all yet in
> CUPS, and I'm doubtful it has been implemented in very many other IPP
> servers.  On the client side, we will still need to keep the polling
> architecture as a fallback even after IPP notification is implemented.

Given your current architecture, once you have notifications in the
local servers (session and system cupsd's), it doesn't matter if the
remote server supports notifications or not, since you'll be getting
notifications from the local server...

You'd only need to keep the polling code if you queued directly to
the remote device.

> ...
>>they can quite easily stomp all
>>over each other, 
> 
> 
> How is that?

Let's see, multiple users on a single system, each with their own
cupsd running and printing to printers at the same time.  Depending
on the printers, interfaces, and configuration, it is possible that
two cupsd's could be sending jobs to the same device concurrently.

>>and printer sharing on non-server machines becomes
>>an issue.  
> 
> 
> That was an issue before, too.

No more than working around the configuration changes you've made
to CUPS...

Let me put it another way - a system process can broadcast on port
631, a user process cannot.  If the session cupsd is responsible
for sharing printers defined by the user, then it must run as root
to share its printers with other users on the network or use a
non-standard port.

> ...
> All I can say in response to this is: I don't think so.  If you can come
> up with some hard facts about this instead of some vague references to
> "extra processes" and "polling", I'd be happy to discuss.

Kindof hard to give you hard facts with just a description of what
you are doing, however I *can* say that our performance testing of
cups-polld against a 100-printer server shows a definite network
and server slow-down starting around the 50 client mark using the
default server settings.  The same setup using the broadcast method
scales to about 2000 clients...

(You can tune things to improve the polling performance, but not by
much...)

>>>We considered this, but the interaction model we want is that the user
>>>clicks "print", and they can close the application, and not lose their
>>>print job.  To do this you need some means of queueing, and running a
>>>session CUPS server seems to me like a sensible solution.
>>
>>Um, since the remote CUPS server will queue the file, 
> 
> 
> After the job is ultimately sent, yes.  Imagine a very large job (say a
> 100 page OpenOffice document).  We want the user to just be able to
> click "print", and close OpenOffice, and the job should keep printing.

I don't think you get it - OpenOffice creates a print file, and the
file is sent to the print server (or even to a printer).  The
application cannot exit before the job is completely sent, otherwise
the job will be cancelled by the IPP server (this is part of the IPP
spec - the HTTP request would not have completed).

Once the job is created, it will print regardless of whether the
application sticks around or not.  The *only* issue is when
printing directly to an IPP printer, where the user could turn the
power off and lose their job...

(I'm purposely *not* considering an application that prints directly
to a non-IPP printer, and I sincerely hope that that is not what you
are trying to support)

>>The problem with your implementation is simply that you are using
>>a sledgehammer to hang a picture.
> 
> 
> That's not clear at all; if our solution is a sledgehammer, then it
> certainly seems to me that for this problem, IPP notification is a
> construction crew wielding sledgehammers :)  Obviously IPP notification
> is trying to solve a larger problem than hanging a picture, as you've
> said.

Actually, I would say the opposite - your implementation is using
all of CUPS in a user process and polling, while a notification
implementation would *not* have that extra process and would only
send/update information as it happens.  Your implementation is
doing a lot of extra work to accomplish the same thing...

>>It is much simpler to either 1) talk to the remote cupsd directly
> 
> 
> See above.

I'd say the same, but I'm not sure you understand that the lifetime
of a job lasts beyond the life of an application in IPP.

>>and/or 2) define a way for the application/user to provide the
>>authentication information that is required through the existing
>>system cupsd.  CUPS 1.2 will provide the infrastructure to do #2,
> 
> 
> Like I said, I'm interested in this.
> 
> 
>>>We simply assume there is no *user* authentication required here.  This
>>>would be like having user authentication required between internal
>>>corporate mail servers; it just won't work, and doesn't even make sense.
>>
>>Um, it is already used in a LOT of corporate and government
>>environments!
> 
> 
> For MTAs, or for CUPS?  I very seriously doubt it is used for many MTA
> setups, since for example with Kerberos, short of actually shipping the
> user's Kerberos credentials over the network (violating several
> principles of Kerberos), you can't do it.  In the case of plaintext
> logins, you need to ship the user's unencrypted password. 

With CUPS for sure, and my previous life working for the Navy saw
a 2-level MTA setup which was a major pain.

> SMTP doesn't have any way of talking back to the client session.

Right, we had to cache credentials...

> As for CUPS - certainly it doesn't implement this now.  So what are you
> talking about?

I am talking about where CUPS is going and how your current
implementation won't support it (multi-level authentication)...

 > ...
> The SMB backend should work similarly to IPP, being invoked directly
> from the user session.  But since Windows is moving to IPP for printing,
> I am not too concerned about it.

LOL!  Microsoft still only implements IPP/1.0 and is only barely
conformant.  They have no real interest in supporting IPP more than
they have to, and as far as I can see they haven't updated their
implementation in 3-4 years.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Printing Software for UNIX                       http://www.easysw.com