[cups.development] customized printer list per user

pipitas k1pfeifle at gmx.net
Fri Sep 17 19:15:38 PDT 2004


Gian Filippo Pinzari wrote:

> Hi,
> 
> I receive this from Jakub Troszok, the developer that has been
> in charge of CUPS integration and that, supposedly, was not
> listening to you, Kurt. In reality, I think that me and you
> have had -lot- of talks about this topic, 

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

("We" -- that is Fabian Franz from the Knoppix and FreeNX Team, 
and myself.)

> and Jakub has parte- 
> cipated as well to the discussions. Unfortunately your solution
> missed to convince us. 

That's what I can clearly see.   ;-(

> Maybe we are wrong, but at least you 
> have to recognize that we have some points:

We do recognize that.

> Jakub Troszok wrote:
>> Just to remind the original ideas behind the current solution:
>>
>> Scheme:
>>
>>     nxclient side                                      nxserver side
>>      CUPSD
>>        |
>>      cupsd -c $HOME/.nx/cups/cupsd.conf
>>        |
>>        ----------------- nxproxy 'cups' channel ------------ CUPSD
>>
>>
>> Files used(on NX Server side):
>>
>> /usr/NX/bin/nxuexec (suided)
>> /usr/NX/scripts/restricted/nxprinter.sh (sgided according to permisions
>> of printers.conf from the cups directory)
>>
>> Used system commands: lpadmin lpoptions
>>
>> 1)
>> command for add the printer:
>> nxuexec nxprinter.sh add username printer_name model public|private
>>
>>  nxprinter.sh executes:
>>  lpadmin -p "$NAME" -E -v "$DEVICE_URI" -m "$MODEL" $PUBLIC

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.

If I can only have raw printing from the NX session, I could as well 
execute 

  nxssh username at remote.nx.host "cat printfile" | lp -d my-localprinter -

or even

  nxssh username at remote.nx.host "cat printfile" | kprinter --stdin

which would give me the opportunity to select one known local printer
including all known printer driver options.

>> command for set printer as default:
>>         lpoptions -d name_of_printer
>>
>>
>> 2)
>> command for remove printer:
>> nxuexec nxprinter.sh delete username printer_name
>>
>> command for unset printer:
>>         lpoptions -x
>>
>>
>> Plus of our solution:
>>
>> - transparence (if applications support cups, and cups is up on the
>> server printing works like locally)
>>
>> - scalability (not performance problem for the system (1-XXX printers)),
>>   we don't add the cups daemon with every session
>>
>> - simple ( just click and print! ) -
>>
>> - better support for reconnection.(delete printer on suspend, and we can
>> add new printer/printers on recoonect)
>>
>> Minus of our solution:
>>
>> - nxuexec not increasing security level of the system

May I add to the minusses of your solution the following?

   - only very basic printing support (uses only the very simple PPDs 
     shipped with CUPS, doesnt use the local NX Client's fully-featured
     drivers).

> NOTE: What Jakub intends is that we use nxuexec to execute a
>       script that is sgid.

NOTE: our solution doesnt require a sgid-ed script.

>> Known Limitations:
>>
>> We inherit the limitations of cups itself
>> (for example no way to split list of printers.)

This is because CUPS is designed as a system service, in the traditional
Unix way. At the time CUPS was designed, no-one ever dreamt of a remote
possibility of such an innovative and break-through development as
NX/NoMachine have in fact now achieved.

>> The limitation of lpadmin (can be executed only by root
>> user) is forcing us to use nxuexec.

This is very uninformed. CUPS is a bit more advanced than that. 
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?

>> -------------------------------------------------------------
>> Kurt Pfeifle in his email is saying two important things:
>> first:
>>
>> "I think this design detail of NoMachine's NX printing support is
>> *flawed* precisely because of that mess. I tried to discuss this with
>> them repeatedly, but their printing developers didnt want to listen or
>> even talk about it"
>> and then at the end:
>> "But this is no different from what many users in Enterprise
>> environments see anyway (with CUPS or with Windows printing)....
>> (It is an argument to implement "printerlist filtering" in CUPS
>> regardless of NX.)"
>>
>> In both phrases he is speaking about "too many printers on
>> the server". So users are confused by seeing those printers.
>> While this could be a problem we tried to do our best to minize

You are not doing *anything* to minimize it. Every NX user can see
all the printers of all the other user sessions.

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

>> that problem by the special naming of the printers (where
>> we use the username + display +). In the second phrase
>> he is saying anyway that this is limitation of CUPS....
>>
>> I don't think it's right how Kurt adressed this problem to
>> us. I think he could be a little angry that we didn't do
>> that his way 

Not true. I dont think that it should be done "my way"....

What I however *do* think is that it should at least be *discussed*. 
That there should be at least *some* substantial feedback....

After all, it was *your* side which *asked* for advice. And which 
did get some very extensive, time-consuming advice, both in writing 
(private mails as well as mails on your lists), on IRC and on the 
phone. It is very very disappointing to not receive any appropriate 
feedback and to learn that your developers have quietly choosen the 
second best solution only.

>> - and we didn't do that he way because it 
>> was too KDE centric.

That is complete rubbish, Jakub!

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 know that KDE has wonderful KPrinter 
>> but standard Solaris doesn't have it.

Right. I even knew that. And GNOME doesnt have it either. And I
know that too.

>> And not everybody is using the newest KDE.

Well, the features I talked about are there since KDE-2.2.2. And
unfortunately not even close to these is GNOME-2.8.

But that's not the point. The point is, that your side didnt even 
really investigate our proposals. Otherwise Jakub couldnt come up 
with hair-raising arguments like that.

>> Probably gnome have 
>> nice printing UI now (in version 2.8).

I am keen to test it. I will even wait for GNOME version 3.0 to see 
it happen.

>> Other problems i can see in his solutions are:

>> - if there are system printers on the nxserver and somebody want to
>> use also them togheter with his local ones - it extremely difficult
>> (as his kprinter will connect only to his private cups on nxserver)

Wrong. kprinter can be made to also connect to a different CUPS server
very easily.

>> - if user want to give other users possiblity to use his local
>> pinters it's not possible because they would have to connect to his
>> private cupsd

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. 

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?

It is ridiculous to say that this "is not scalable". After all,
each single user session needs extra ressources, no?. You dont get
around *that* "limitation", as hard as you might try. Each additional
NX feature needs extra ressources. After all, you have additional
nxagent and nxnode processes starting and running for each additional
user session, no?

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

I just cant believe that you would want to cripple the wonderful
NX package when it comes to printing, by only using a very limited
feature set of what CUPS provides. And it is ridiculous to then talk 
about "CUPS limitations".  NX printing could be that one killer
feature that immmediately outshines Citrix printing if it were
implemented properly with the help of CUPS!

The way you do it, you stay way behind Citrix if it comes to 
printing.

>> I know that our solution have limitations but we had some goals
>> and some priorities that were driving our design.

It doesnt seem that the design goal was feature-rich printing.
You are content with *some* form of printing....

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

> I think that the analysis of Jakub is quite accurate. The current
> solution fits our requirements, especially the one regarding the
> need to let other users to print to a client printer shared by
> a user.

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.

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.

> The drawbacks I counted on our solution are not worse 
> than those I see in the solution proposed by you, Kurt. 

This is because you, peraonally, acturally dont ever use a printer. 
;-)

But *I* see them much worse. Especially with what is important when
I want to print: I want to produce a *print product* and not put out
a loose collections of single sided sheets of A4 paper. I want A3,
A4 and A5, I want stapling, duplexing, folding, punching -- and I 
want to determine the exact feature set at the moment I print, and 
not just accept sheepishly on the momentary default job options 
setup to the print queue.

> For 
> example you minimize the fact that CUPSD can't support passwords
> per-printer 

Huh? Who told you so? Certainly not me. Must have been one of
your developers then.

Because I know perfectly well that CUPS *can* support passwords
per printer. (I just wanted to avoid it by going for the more
elegant solution with the certificates, and go for the per-user
separated cupsd/printerlists).

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

> Using a private key is a good solution, in general, and I'm
> not against it in principle. On the contrary the security model
> I have in mind is to let the client set a private key for each
> session/protocol and make it accept tunneling of arbitrary
> protocols only from applications on the server presenting the
> right key (no need to insert a password).

Hear, hear!

> This is the way X11 
> handles the authentication. We could implement this with a
> little more sofistication, for example by using a NX auth agent
> (similar to the ssh-agent) that would check the credentials of
> the user on behalf of the nxclient or nxserver.
> 
> Unfortunately  this must be done for all the supported protocols,
> in an integrated and seamless way, and under the control of
> nxclient and nxserver. We can't adopt a different auth model for
> each protocol 

How many additional protocols do you currently support? Or work 
on to support soonish?

This is about 1 (in words: one). And by all means the most important
one for most professional users. And doesnt need to design and code
an additional nxauth-agent at all. Everything is there! Just use it!

> or we would end up with a mess. For now, the best 
> solution is to use a password, the way we do for SMB. This gives
> us the best flexibility with only minor drawbacks. The problem
> of the huge listing of printers must, again, solved into CUPS.

As long as it isnt in CUPS, there are other solutions. And even
if it once *is* in CUPS-1.2 or -1.3, the other solution may well 
still be the best for the purpose of NX printing. 

But that seems to be a point NX developers play deaf about....

> I completely ignore the details, but I assume that printers
> should be distinguished by the server by checking the user that
> is sharing them. This info can be provided by the CUPS client
> adding the printer to the CUPS server at the time the printer is
> appended.

How long do you want to wait for this CUPS feature to come
about?

How long will you deprive your hopeful users (like myself) from
a better solution?

> The applet listing the printers could then query the 
> server for all the printers in the system or only the printers
> added by a given user.
> 
> Can it be that the CUPS designers overlooked some problems and
> NX is now higlighting these CUPS limitations? 

Can it be that the NX designers, or some individual module 
developers, overlooked some existing CUPS features, or pretend 
these weren't here? And the current debate is just highlighting 
it?

> If this is the case, 
> why such limitations can be solved in CUPS? Implementing weird
> warkarounds, like running a CUPS server for each user is not an
> acceptable solution.

This is not a weird workaround. I see it as a very elegant solution,
killing several birds with one stone.

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.

> Why I don't want to run a CUPS server for each user? You mention
> the possibility that the CUPS server is not killed at the end of
> the session. This is a really minor problem.

Fine. That minor problem could surely be solved by some very simple
nxcleaning daemon or some other means....

> I don't have anything against running "agents" shadowing the
> services on behalf of the user. We do that for X11, I planned to
> do that for SMB and I would like to do that for -any- service, so
> for me the solution is perfectly acceptable, at least in principle.

Fine.

> What I don't like is the fact we should do that only for CUPS, at
> the present moment,

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

> because of some CUPS limitations for which we 
> have already found a workaround. 

No you havent found a "workaround". You now have the most primitive,
simple printing support that can be imagined. (I admit that this
already is wonderful, as compared to no printing support at all.)

> Given that we should run a CUPS 
> "agent", I would like to see a nxcupsd, providing only the features
> we need (for example authentication, compression and forwarding of
> printing jobs), no more no less. 

Fine. 

This could be the second stage of development, based on our proposal.

> It shouldn't be a complete CUPSD, 

OK then.

> regardless the footprint, the CPU usage and the list of dependencies. How
> can I envision a NX server where to support 1000 users I have to run 1000
> CUPSD, 1000 HTTPD, 1000 ARTSD, 1000 SMBD, etc., etc.?

Well, you run already 1000 nxagents and nxnodes then too, dont you?
And you'll hardly get round the 1000++ smbd's either, as long as
Samba spawns a new smbd for each file new share access.

And let's be serious now: not each and every NX user session does
require a shared printer.

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.

> /Gian Filippo Pinzari.

Cheers,
Kurt  [ who recommends to testdrive NX to each reader here. And who
        wants to make clear that the only reason he debates so 
        passionately with Gian Filippo is, because he likes NX so much...]



> Kurt Pfeifle wrote:
>> On Thursday 16 September 2004 13:48, Martin Grimm wrote:
>>
>> > Our problem: we need a customized printer list in CUPS depending on
>> > the user asking for it.
>> >
>> > Here are the details:
>> >
>> > Imagine a larger network with some network printers served by
>> > a cups print server and a linux based X application server accessed
>> > by remote X clients via NoMachine (www.nomachine.com). The clients
>> > have local printers. On connection to the X App server via ssh tunnel
>> > the local cups service is tunneled to the server and a script on
>> > the server adds the printer via lpadmin to the running CUPS server
>>
>> I think this design detail of NoMachine's NX printing support is *flawed*
>> precisely because of that mess. I tried to discuss this with them
>> repeatedly, but their printing developers didnt want to listen or even
>> talk about it.    :-(
>>
>> Other than that, I think NoMachine's NX technology is the next big thing
>> in the computing world. It achieves wonders in speed on slow and high
>> latency links. I recommend to anyone who ever uses remote X access (or MS
>> RDP remote access to Windows Terminal Servers, or VNC access) to at least
>> once testdrive NX (http://www.nomachine.com/testdrive.php)
>>
>> There is workaround for your problem, if you use a KDE session on the NX
>> server, or, if you use "kprinter" as your general print command inside
>> GNOME sessions.
>>
>> The mechanic is this: KDEPrint is powerful enough and able to "filter"
>> the list of printers indiviually to each user. (A user can set and change
>> this for himself, or, if you use the KDE "Kiosk Mode" (an Enterprise
>> Desktop feature), an administrator can lock it down to be immutable and
>> the user only sees a pre-defined list of printers.)
>>
>> To investigate the "printerlist filtering":
>>
>>  * start "kprinter",
>>  * click "Expand",
>>  * click "System Options...",
>>  * select "Filter" (right column)
>>
>> and find your way from there. (There is even an option to define the
>> filter list based on a regex on the "Location" string). To activate the
>> filtering, click on the "funnel" icon sitting on the right of the printer
>> drop-down list in the kprinter dialog.
>>
>> The user-specific KDEPrint settings are written to
>> "$HOME/.kde*/share/config/" into the files "kdeprintrc" and "kprinterrc".
>> Look for the lines "LocationRe" and "Printers" in the {Filter} section of
>> kdeprintrc. Look for the lines "FilterEnabled" in the {KFileDialog
>> Speedbar} section of kprinterrc.
>>
>> If these files are written accordingly by a "nxaddcupsprinter.sh" script
>> upon the NX sesssion creation, you are there.
>>
>> ----
>>
>> Fabian Franz and myself (from the FreeNX Development Team) had suggested
>> an alternative architecture for NX printing support:
>>
>> This would start a separate cupsd for each NX session. This new cupsd
>> would run entirely in userspace of the remote NX server and not use the
>> port 631, but its own. It woulod be completely separate from the system
>> cupsd and from each other userspace cupsd.
>>
>> It would relay the info about its printers via an ssh-forwarded port
>> (tunnelled thru the NX link). By this design, you wouldnt even need a
>> password for the user, because you could alocal certificate as supported
>> by CUPS. The userspace cupsd on the remote end could even receive the
>> printer driver (==PPD) info via the CUPS standard browsing options.
>>
>> The printer connection would use a device-URI of
>> "http://<nxclient>:<forwarded-port>/printers/printername-of-nxclient"
>> An "nxaddcupsprintsupport.sh" script would need to be executed at each
>> connection. It would:
>>   * create a "$HOME/.nx/etc/cups/nxuser-cupsd.conf" with the specific
>>     settings required (specifically it would set the "ServerRoot"
>>     directive to "$HOME/.nx/etc/cups/" and the "BrowsePort" to non-631,
>>     and would only allow the user to connect).
>>   * create a ""$HOME/.nx/etc/cups/printers.conf" in the ServerRoot
>>     with the printers the user wanted to use in the session.
>>   * create a "$HOME/.cupsrc" (or is it "$HOME/.clientrc"?) for the
>>     user to point to his own userspace cupsd.
>> The userspace cupsd could be stripped to the bare necessities. It would
>> not need to use any local filtering and could forward the printjobs
>> to the "real" CUPS server (that is the NX client's CUPS server) for
>> processing.
>>
>> On the NX Client you would also run a userspace cupsd to forward
>> just the selected session printers to the remote NX end.
>>
>> I hope you get the idea...
>>
>> I hope the NoMachine developers will get it sometime too.
>>
>> (To be fair, they had *one* valid objection: that was "what happens
>> if the session closes, and the remote userspace cupsd keeps running?".
>> That hasnt been addressed by me. I just expect them to write a "cleanup
>> daemon" or similar, which removes instances of NX session userspance
>> cupsd where the session is lost.... After all, their current
>> 1.4 snapshot implementation isnt that clean at all in that it doesnt
>> delete NX printers after session termination, so they pile up more
>> and more from session to session. But, to be fair again, these are
>> "only" Beta snapshots, and the problem will likely be solved before the
>> final 1.4.0 release.)
>>
>> > there with options -u, so only the user is able to print to it.
>> >
>> > However all local printers of all clients are in the printer list on
>> > the server and so every user sees all local printers of all other
>> > users. Think of >300 client and you can imagine the mess.
>>
>> But this is no different from what many users in Enterprise environments
>> see anyway (with CUPS or with Windows printing)....    ;-P
>>
>> (It is an argument to implement "printerlist filtering" in CUPS
>> regardless of NX.)
>>
>> > Finally my question:
>> >
>> > Is there anything we can do to hide the local printers of other users
>> > so every user sees only his local printer and the network printers.
>> > If this is not possible, is anything planned regarding this problem?
>>
>> Search here: http://www.cups.org/str.php for a trouble report regarding
>> long lists of printers. Or create your own  ;-)
>>
>> > Kind regards,
>> > Martin Grimm
>>
>> Cheers,
>> Kurt
>>





More information about the cups mailing list