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

[Colin Walters]

On Thu, 2004-08-26 at 23:49 -0400, Michael Sweet wrote:
> 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)?

It's easier to just do things from the user session, instead of defining
an interface to pass credentials to the system CUPS daemon.  I can
understand your disagreement on this point, it is a technical decision
that is arguable either way, I believe.

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

Surely a network with even 1000s of users can handle the small overhead
of status polling for the relatively small percentage of those users
actually printing at one time.

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

So the local server would poll if the remote server doesn't support it?
Fair enough.

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

Err...again, the session CUPS server is only used for remote printers.
Also currently, they only queue to remote CUPS-based servers.  So there
is no concurrency problem.

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

It is not.  Again, the system cups server stays around for these
purposes.

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

cups-polld gets a list of printers?  That seems to me to be a somewhat
orthogonal problem to job notification.  For many setups, supporting 50
clients printing simultaneously seems quite reasonable.  If you need
more than that, subdivide into separate servers, or get better hardware.

> The same setup using the broadcast method
> scales to about 2000 clients...

Sure, but again, that's for printer lists, which is not the same as job
notification.  Surely you aren't suggesting the cups server broadcast
the status of each job every 30 seconds?  After all, a client may not
even be on the same subnet.

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

You didn't read the printing-architecture document carefully enough. For
a remote printer, the document is sent to the session cups server.  The
applications are not responsible for sending jobs over the network,
which is the point.

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

Um, certainly I understand that, since I implemented eggcups, which
provides job status feedback independent of the application.

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

How does it work then?

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

I can imagine, it must have been a proprietary protocol on top of SMTP.

> > SMTP doesn't have any way of talking back to the client session.
> 
> Right, we had to cache credentials...

Yep, evil.

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

I completely agree, our implementation does not and basically will not
support multi-level authentication.  That is not its goal.   The goal is
to solve the common authentication and notification cases for the near
future.

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

That's rather unfortunate :/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <https://lists.cups.org/pipermail/cups/attachments/20040827/7eb18afe/attachment.bin>