[cups.development] customized printer list per user

[Gian Filippo Pinzari]

pipitas wrote:
> Yes, we spent a *lot* of time to try and provide input. But we
> hardly got any feedback. Just check your public mailing list.

I remember a phone call discussing this with you that lasted 46
minutes. My mobile phone scored a record of 32 euros billed in
a single shot. My girlfriend never got so many attentions in
the last 3 years.

> We do recognize that.

Good.

> I havent seen the "-m $MODEL" parameter applied anywhere in practice
> on all occasions that I tested your various 1.4 snapshots. The effect
> was, that I only saw "raw" printers installed (without a PPD, without
> a "driver",without a user-selectable printjob options).
>
> But even if the "-m $MODEL" *was* applied, it would only give me one
> of the 12 basic CUPS model PPDs. That doesnt automatically match the
> user's local printer. It requires manual intervention to do that, and
> it demands more printing Knowhow from most users than they have.

Can it be that Jakub missed some of the needed information? Can the
current implementation be improved or is it a "religious war" and
we have to switch to a per-user CUPSD to get some help?

> lpadmin can be executed by any user which has been assigned the
> right to administer the CUPS system. A dedicated NX server could
> surely configure its cupsd to be administered by the nx user, no?

Jakub was incorrect here. There is no need to run lpadmin as
root, and in fact we run it as user nx.

> In my proposed solution, every user sees only his own printers.

Jakub recognized that this is a real plus. Can it be done while
still using a single CUPSD? If not, why?

> After all, it was *your* side which *asked* for advice. And which
> did get some very extensive, time-consuming advice,

Let me explain how I see it. You elaborated your solution and
this solution required to run a CUPSD per each user. I told you
that I didn't like it, not at least if it was possible to do with
one. Then we discussed the authentication stuff. One of the
requisites was to preserve the possibility for user B to print on
printers exported by user A. We wanted to do that by only knowing
the name of the printer and the password. You refused to evaluate
my proposal of using a user-friendly authentication by password,
telling that the CUPS certificate was incomparably better. In
which sense it was "better" you didn't say. Obviously I didn't
object the fact that a certificate was more secure (given that
security in this case was a concern). I just wanted to understand
how a user was going to share this certificate with others. Would
have the user sent the certificate by e-mail? Would have he phoned
the other user and made the spelling of the hex dump? Since then
you got hangry and refused to discuss anymore. The tone of this
debate is a proof that you didn't get it well :-).

> Our proposal didnt involve any KDE-specific items. It only used
> most of what CUPS provided. (In the end, it turned out, to our
> much enjoyed pleasur that KDE NX sessions could also make a very
> good use of it -- but please dont confuse that with the original
> proposal).

I agree.

> But that's not the point. The point is, that your side didnt even
> really investigate our proposals.

Untrue. We investigated it and decided that it was more complex
(requiring more code to be written at the server side), less scalable
(requiring a new CUPSD per each user), less mana-geable (requiring
more work to let other users or the server find out which other
printers were made available on the system), less usable (not letting
users easily print on other printers than their own). Obviously we
could have been wrong. We are here to learn more :-).

> Why shouldnt this be possible? If the private cupsd is "owned" by
> an NX user, that cupsd can surely be modified by the same user to
> allow access to another user for one of his printers, or two.

True, but how? Is it possible to do that by means of a handy tool
or we have to write it? Is it easy enough for the average office
user? Has the user to do that anytime he starts a new session?

Surely we could enhance the NX software to manage such printer
configuration, for example letting the user manage the uids and
groups that are allowed to print on his printers in a way that is
integrated with nxserver. We could also add persistence of printer
settings. This, anyway, was considered outside the scope of the
1.4.0 release. I asked Jakub to fullfill a limited set of require-
ments. Among them there was letting users to print on printers sha-
red by others by providing a simple password. Does your solution
allow that?

> Our suggestion just made sure these very important points:
>
> * have a *default*NX printing capablility where each user only sees
>   his own printers, plus the system printers.
> * have a default where each user can only access his own printers,
>   plus the system printers.
> * have the default very secure by automatically used certificates
>   (as are provided "for free" by CUPS if you bother to change one
>   line into the config file).
> * have the default working very simple for the user (just click and
>   print)
> * have it very feature-rich for the user: provide the same powerful
>   print options inside the NX session as the user is used to from
>   his local desktop session (because it uses the very same PPD).
>   After all, this is about *printing*, ain't it?

I don't see "letting users easily print on printers shared by
others".

> And did you know that Samba spawns a new smbd even for each single
> share a user opens??

Well I know a little about Unix and I guessed something like that
:-P. My concerns were not about scalability but about manageability
and implementation. This CUPS process requires nxserver to configure
and monitor it. That's not a big problem, if you have the time to
write the software.

> From all what I can see implemented in your 1.4 NX snapshots, the
> NX user cannot select a single print job option (other than what
> CUPS provides). This is because all NX printers are installed as
> "raw" printers only. You dont use a printer-specific PPD for
> printing. You do not even use the 12 CUPS PPDs you are shipping.

Is it something that can be fixed in the current design?

> Well, but it doesnt fit most users' requirements: in that they
> want to use their local printers to the fullest possible feature
> set, just as they are used to when they print to it locally.

Right. Still: is it something that can be fixed in the current
design?

> And for the "especially mentioned one user requirement regarding
> the need to let other users print to a client printer shared by a
> user": that is the first time I hear this named as an important
> feature. Anyway, this is no problem: it is possible with our own
> proposal too.

This means that my 32 euros went for nothing.

> > if the printing client is detected as local, something I
> > consider a pointless limitation of CUPSD.
>
> This statement is something that I consider nearly an insult to us,
> because it proofs that you or your developers havent listened to what
> we tried to explain to them, or havent read the written material
> we put a lot of our private time in to prepare.

Please, read my previous post. If connections come from the
loopback device the connection gets automatically accepted. We
had to implement some workarounds in nxserver to make the password
work. As I said, it can be that we missed to add some other para-
meter. Hope that you'll not consider this an insult but only lack
of knowledge and time.

> How many additional protocols do you currently support? Or work
> on to support soonish?
> This is about 1 (in words: one).

SMB and audio are supported since the 1.0.0. HTTP is supported
by nxcomp starting from the 1.4.0, together with CUPS. That makes
4. Plain X connections channle, used for "services" like keyboard
handling, make 5. They all don't use a "agent" on the server side.

> Why is NX running a separate nsagent and nxnode process for each
> NX user session?
>
> According to your own rules, this would also be a weird workaround
> then.

nxagent is part of the proxy system. This proxy system has to be
as thin and lightweight as possible. This doesn't prevent running
"agent" modules for things like printing, but this is a design
choice that I would like to take after having carefully evaluated
all the possible alternatives. One of the design goals, in the long
run, is to let the NX proxy system become even thinner and let it
just handle things like authentication, transport and compression.

> Huh? What flawed logic is that? First you say that you planned
> and liked to do that for *any* service. Then you say, in the next
> sentence, that you dont like to do it for one service (CUPS) only.
> I must be missing something here, I dont get it...

The idea is to let the "agents" talk to the proxy system by
primitives allowing them to access network services and devices
on the clients, including printers. This has been discussed in
both the nxdevelopers and the nxproject list. In fact I don't see
this eventual CUPSD running per-user as part of the proxy system,
but rather part of the nxserver system. I have a different idea of
a printing agent. A printing agent should be something that gets
direct access to the printing daemon on the client, not a
complete printing server doing most of the job. Anyway I agree that
this is a meaningless distinction when compared to the need of
offering good printing functionalities to the user.

> And if you and your developers are good, you could make the private cupsd
> started and stopped even during the running NX session, on demand. And not
> have it run all the time.

Of course :-).

Let's make a pact: you stop whining and help us to improve the
current solution and we'll get give another run to this per-user
CUPS server in the next version. OK?

/Gian Filippo Pinzari.