[cups.development] customized printer list per user

Gian Filippo Pinzari pinzari at nomachine.com
Fri Sep 17 12:38:18 PDT 2004


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, and Jakub has parte-
cipated as well to the discussions. Unfortunately your solution
missed to convince us. Maybe we are wrong, but at least you
have to recognize that we have some points:

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

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

> Known Limitations:
>
> We inherit the limitations of cups itself
> (for example no way to split list of printers.)
>
> The limitation of lpadmin (can be executed only by root
> user) is forcing us to use nxuexec.
>
> -------------------------------------------------------------
> 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
> 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 - and we didn't do that he way because it
> was too KDE centric. I know that KDE has wonderful KPrinter
> but standard Solaris doesn't have it.
> And not everybody is using the newest KDE. Probably gnome have
> nice printing UI now (in version 2.8).
>
> 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)
> - 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
>
> I know that our solution have limitations but we had some goals
> and some priorities that were driving our design.
>

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. The drawbacks I counted on our solution are not worse
than those I see in the solution proposed by you, Kurt. For
example you minimize the fact that CUPSD can't support passwords per-printer if the printing client is detected as local, something
I consider a pointless limitation of CUPSD.

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

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.

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.
What I don't like is the fact we should do that only for CUPS, at
the present moment, because of some CUPS limitations for which we
have already found a workaround. 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. It shouldn't be a complete CUPSD,
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.?

/Gian Filippo Pinzari.


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-devel mailing list