[FreeNX-kNX] printing under freenx/knx
Jon Severinsson
jon at severinsson.net
Sat Apr 23 10:12:05 UTC 2005
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I have now read through your mails again, and I think you are right, my
idea of how to do this is probably not the best.
A *simple* GUI for how to swich would be good enough. Even though it
still does complicate it for the user, the technical problems with my
solotion outwights this drawback. The proposed GUI must be simple (more
or less or less just two buttons: "enable serverside printers" and
"enable clientside printers"), and easily accesible (desktop icon?).
Regards
- - Jonno
Kurt Pfeifle skrev:
> On Wednesday 13 April 2005 08:53, Jon Severinsson wrote:
>
>
>>>>A general support for the native X11 connection the solution could be
>>>>really simple:
>>>>On the nxserver run an additional usermode cupsd on a random port for
>>>>each session, and configure it to poll the system cupsd (the one in
>>>>/etc/cups/client.conf)
>>>
>>>I am not sure if we both think about the same thing here. Could you
>>>*exactly* specify the directive line that you think should be in the
>>>client.conf (this is on the NX server, mind you)?
>>
>>This is on the NX server (or rather "the computer running nxnode").
>>My (default) /etc/cups/client.conf contains the line
>> ServerName localhost
>
>
> The question is for which systems this is the "default" nowadays.
>
> CUPS (as installed from source) defaults to have an empty client.conf
> (a.k.a. a commented out "ServerName" line) and a locally installed
> and running cupsd. It lets all its client commands (lp, lpr, lpoptions,
> lpc, lpq, lpadmin, lpstat, lpinfo) by default access the local cupsd.
>
> Using a ServerName specified in the client.conf is switching to so
> called "spoolerless printing" (i.e. jobs are not spooled locally)
> and implies the assumption that no local cupsd is running at all.
> Spoolerless printing is mainly meant for thin clients and small
> gadgets. In general, it is not recommended for workstations, and
> less so for servers....
>
> An enabled client.conf activates *polling* the specified server for
> printers. Polling is much getting more "expensive" for more clients
> doing so. It causes at least linear growth of resource usage:
>
> * each client poll creates a response from the server causint
> additional traffic on the net.
> * each client poll causes more CPU and memory consumption on
> the CUPS server.
>
> Compare that to the default browsing mechanism (where the CUPS server
> regularly pushes the printer list via UDP broadcasts to the network)
> once, and each client has a local cupsd running just listening to
> these browse packages to build a list of available printers from them.
>
> The browsing mechanism announcing 100 printers to one CUPS client
> causes the same amount of (almost neglectible) network traffic as
> the polling mechanism causes if used by the client.
>
> But different with 1000 clients: The browsing mechanism still only
> causes the same traffic -- but all clients polling increases the
> traffic 1000fold to the network (no longer neglectible), and also
> the CUPS server CPU may be starting to be more loaded than what
> is efficient....
>
>
>>However, on a larger site it might well be
>> ServerName cups.mydepartment.mycompany.com
>>In this case we should poll cups.mydepartment.mycompany.com for printers
>
>
> No, we should *not*. Most definitely not. Not on large sites. See
> arguments above.
>
>
>>instead of localhost, to include all printers that would be present with
>>print support disabled (ie. today). That is, our usermode cupds.conf
>>should contain:
>> BrowsePoll cups.mydepartment.mycompany.com:631
>>My problem is that
>> BrowsePoll localhost:631
>>won't work.
>
>
> Forget usermode cupsd on the NX server. It is not needed. (There may
> be special cases where it is useful, but these are not the basis for
> the general solution).
>
>
>>The log states that cups-polld finds my 2 printers, but
>>won't add any. If I poll my remote server, it will find both printers,
>
>
> Which are these "both" printers?
>
> Where is each one of these installed/defined? (i.e. in which
> printers.conf are they listed?)
>
>
>>but only and add the one that is not attached to the NX server.
>>
>>
>>>If you want to poll the NX server's cupsd (even if that is a
>>>remote cupsd), this
>>>
>>> 1st -- doesnt help in many cases, since that cupsd may not
>>> be accessing the local printers at my NX client location
>>> (where I usually want to print to)
>>
>>Well, this is a question. Do you ever want a session where you can print
>>to both servers connected to the nxserver as well as printers connected
>>to the nxclient.
>
>
> There is one additional problem I forgot to mention in my last
> mail: the client.conf and .cupsrc files currently do not provide
> for specifying a non-standard port for accessing the server named
> in the ServerName directive...
>
> See
>
> http://www.cups.org/str.php?L906
>
>
>>In an office environment this might actually be the
>>case, and imo enabling printer support should *not* disable the existing
>>printers.
>
>
> Right. It is only a matter of creating an easy way to switch (or
> choose printers).
>
> Using the printers that are available to the NX server machine
> is the eaiest: nothing to be done. Works already.
>
> To access the local printers that are available to the NX client
> machine is the most important. In a way it is the "holy grale"
> (grail?) of terminal services and remote sessions.
>
> Switching between the two is also not too difficult then. It is
> already possible now, if you manually did setup and configure
> the "print from NX session to my local NX client printer". It is
> just not *as easy* and as intuitive as it should be. (It should
> be that it is a "one-click switch" or action at all -- currently
> it requires too much thought and more knowledge than should be
> expected from the common computer user. Remember, NX and FreeNX
> are not just about "make X fast", but also to make its usage
> "as easy as eating pies". We are still quite a bit away from
> that goal.)
>
>
>>If not, almost all of my email is irrelevant. I'm trying to work out a
>>solution allowing printing to both sets of printers.
>
>
> I am with you here.
>
> But I dont see the userspace cupsd on the NX server side as the
> best and most efficient way to go.
>
> My own initial proposal for an NX printing design included that
> "one userspace cupsd on the NX server for each NX session which
> wants to print"-idea too -- but at that time I couldnt see any
> other solution to *make it happen at all*.
>
> My own suggestion was for a userspace cupsd on the NX *clients*
> (the Unix-based ones, that is), and it was only born out of *need*.
> The need is to make available the driver settings from inside the
> remote sessions, and make it un-necessary to configure anything on
> the NX server.
>
> But Fabian's solution will be even better, and participants in
> our Chemnitz workshop have seen a proof of concept already...
>
>
>>If we only wants
>>printing to nxclient *or* nxserver there hopefully is simpler solutions.
>
>
> As I said, printing to the printers seen naturally by the NX server
> is a no-brainer already. It works *now*.
>
> Printing to local NX client's printers (and make it easy and
> powerful at the same time) is the real challenge.
>
> And then, make ascessing both sets of printers also easy...
>
>
>>> 2nd -- is unnecessary, since the user sees any local CUPS printers
>>> anyway (counting in the ones his local client.conf may be
>>> pointing him to.)
>>
>>???
>>If we set the session to use the user mode cupsd, will the user actually
>>see the printers in the system cupsd as well?
>
>
> Of course not. But we will *not* have the userspace cupsd on the NX
> server.
>
>
>>Or do you mean the
>>printers of the nxclient. If so, see above.
>>
>>
>>>I fiddled with that already. There are various problems with this
>>>approach, and one thing that definitely doesn't work.
>>>
>>>If the userspace cupsd on the NX server polls the system cupsd on
>>>the NX client,
>>>
>>> * it gets the list of printers just fine
>>> * it can print (basic) jobs just fine
>>> * it can get lists of jobs (completed and in-process) just fine
>>> * but it cannot get the driver info for the target printer (i.e. what
>>> any non-NX remote CUPS client would retrieve by executing
>>> "lpoptions -h cupsserver -p printername -l"
>>>
>>>That means, all jobs will only print (from any GUI) with the default
>>>settings of the target printer; if you *know* how to print from the
>>>commandline and call upon the print options you need there, you can
>>>do it. But it will only be possible for very few users.
>>>
>>>(There is one exception: if the NX client's system cupsd is named
>>>"localhost" [that is, in the cupsd.conf the directive "ServerName
>>>localhost" is set], the driver info will transfer correctly to the
>>>remote NX session, and be visible there [f.e. in the kprinter GUI].
>>>But then, the NX client cupsd will not work as before. And many users
>>>will not have the privileges to change the cupsd.conf of their local
>>>NX client computer at will...)
>>
>>This is odd.
>
>
> See maybe these links for more details of my investigations and findings:
>
> http://www.cups.org/str.php?L940
> http://www.cups.org/str.php?L
>
>
>>I can poll a remote computer (ie. the nxclient) perfectly,
>>and my cupsd.conf doesn't contain ?ServerName localhost?, but rather
>>?ServerName 192.168.80.1?. Though so far all my connections has been
>>outside the ssh connection
>
>
> Ok. That is a different matter altogether.
>
> That works. It works *if*, and only *if* you can access your
> "it-happens-that-it-is-an-NX-client-currently" machine from the
> "it-happens-that-it-is-an-NX-server-currently" machine. But have
> you thought about gateways, proxies, firewalls??
>
> To make printing in NX sessions omnipresent, you need to use the
> established NX channel. That means either port-forwarding or some
> other mechanism using that channel. You cannot rely on building
> and maintaining a completely unrelated link from the NX server
> back to the NX client.
>
>
>>(no ssh port forwarding,
>
>
> *That*'s your problem!
>
> Setting up a completely separate channel, outside of all NX context,
> from a machine that happens to be an NX server acting as the print
> client, to another machine that is the NX client acting as the print
> server just doesnt work for many common cases. Certainly not for as
> many that makes it easy to cover by some sort of automated setup.
>
>
>>hasn't got that far
>>yet). That might very well be the problem.
>
>
> Indeed.
>
>
>>>Other various problems:
>>> * NX servers with many parallel sessions running (where most users
>>> have activated a userspace cupsd) will consume many more resources.
>>
>>Yes. But that must be the case if we are to support both local and
>>remote printers at the same time.
>
>
> I disagree.
>
>
>>> * the NX client's system cupsd may not be setup in a secure enough
>>> way. That could give any other NX session user of the same remote
>>> NX server access to that cupsd, just by accessing the forwarded
>>> port.
>>
>>Yes, this is a problem, but unless cups starts to support pipes
>
>
> CUPS 1.2 will start to support Unix domain sockets.
>
>
>>(Wouln't
>> CUPS_SERVER=socket:/$FAKE_HOME/.nx/C-$session/cups be great?) I don't
>>know how to fix this. Whether cupsd runs at the client or the server the
>>program running at the nxserver must be allowed to access it. This is
>>the case even if the port on the nxserver is just a ssh forwarding to a
>>port on the nxclient. (Or does ssh port forwarding only forward
>>connections made by the user setting up the ssh tunnel?
>
>
> I'm not sure, but I dont think so.
>
> Maybe an inquiry with the OpenSSH developers is in order. Maybe we
> should submit a feature request?
>
>
>>That would
>>change quite a lot of things!)
>>
>>
>>>So, what if you don't poll the NX client's cupsd?
>>>
>>>After all, each user has his own cupsd in userspace, and could
>>>*install* printqueues and PPDs into it, with the backend using
>>>ipp:// to forward the job to the NX client's CUPS daemon.
>>>
>>>Problem here is: you do not know for sure which is the correct
>>>driver/PPD for the target printer. OK, this is just an additional
>>>complication, which could be solved by asking the user which of his
>>>locally available printers he wants to use in the upcoming NX session,
>>>and auto-transfering the correct local NX Client PPDs to the remote
>>>userspace cupsd for using with the newly setup queues.
>>
>>This is pretty much my conclusion as well.
>>
>>
>>>>In addition it can then poll a
>>>>client-side cupsd for a unix nxclient, or add samba printers shared on a
>>>>windows (or unix/samba) nxclient.
>>>
>>>It may not have the privileges to do so...
>>
>>The usermode cupsd we set up have exactly all the privileges we give
>>it,
>
>
> Yes. But I was talking about "the userspace cupsd on the NX server (which
> *you* are proposing, not I), or its user may not have the privileges to
> access the system cupsd on the NX client".
>
>
>>so you must mean that cupsd on the nxclient might have been set up
>>not to allow the nxserver to poll it.
>
>
> Yes.
>
>
>>You are right i that, but with ssh
>>port forwarding
>
>
> But now you start to discuss a different concept. Further above you said
> that you didnt consider SSH port forwarding yet.
>
> However, I have outlined the ins and outs of that concept in my last
> mail.
>
>
>>the poll would come from the nxclient.
>
>
> Correct. But usually we wouldn't use the expensive "poll", but the "cheap"
> browsing mechanism.
>
>
>>And by definition
>>the nxclient has permissions to do so, or the nxclient would not be able
>>to print itself.
>
>
> Correct. But that was never a point in question.
>
> [....]
>
>
>>>The userspace cupsd on the NX server is not required.
>>>
>>>What my suggestions said is to use a userspace cupsd on
>>>the *NX Client*. That userspace cupsd would bind to any
>>>port above 1024, which would be SSH port-forwarded to a
>>>port above 1024 on the remote NX server. The print client
>>>programs and commands (lp, lpr, lpq, lpadmin, lpoptions,
>>>kprinter, gtklp, xpp) would just have to prefix
>>>
>>> 'IPP_PORT="<whatever-port-is-used>"'
>>>
>>>all calls. (BTW, kprinter can do that through its GUI
>>>already, or through the "kdeprintrc" file setting). That
>>>would, through the channel, directly access the userspace
>>>cupsd on the NX client.
>>>
>>>This solves all of the problems mentioned above:
>>>
>>> + local (for the NX client) userspace cupsd.conf could
>>> be customized with all security options one wnats. By
>>> default we could only allow the NX user to access it.
>>
>>This is true even if the cupsd.conf file is on the nxserver.
>
>
> I know.
>
> But it loads all the resource consumers onto one place, the
> NX server. That doesnt scale well. That's why I oppose it.
> (I would support it if there were no other alternative.)
> Keeping the userspace cupsd on the NX client (should there
> be *any* userspace cupsd required at all) scales nearly
> indefinitely (well, it scales as long as the NX server can
> run additional sessions at all.)
>
>
>>> * the "ServerName localhost" directive in cupsd.conf
>>> could easily be used for the userspace cupsd.conf
>>
>>Yes, this does make it simpler...
>
>
> Bingo.
>
>
>>> * either full list of the system NX client's system cupsd
>>> printers could be used as the backend (via IPP), or a
>>> completely customized subset of them (or an entirely
>>> different list). The system cupsd's PPDs could easily
>>> be compied to the userspace cupsd's realm (and even
>>> should be, to make the next point work...)
>>>
>>> * all printer options would be available without further
>>> configuration inside the remote CUPS session.
>>
>>This *should* work with cupsd running on the nxserver as well, though it
>>obviously does not atm.
>
>
> My concepts works. (But Fabian's new one is even better.) This
> concept
>
>
> http://developer.berlios.de/feature/?func=detailfeature&feature_id=617&group_id=2978
>
> can be manually setup within 2 minutes if you know what you
> do. (It misses support for printer-specific driver/PPD settings).
> The other one
>
>
> http://developer.berlios.de/feature/?func=detailfeature&feature_id=618&group_id=2978
>
> can be done manually too, but takes longer, and needs more
> expertise.
>
> What we need is an automatic method, with zero configuration and
> setup for the NX user, that provids by default all printers to
> the NX session which a local session on the NX client would also
> have.
>
>
>>> * each NX session would "see" and use different printers
>>> (the ones defined on the NX client userspace cupsd), and
>>> they would be completely isolated from each other by
>>> default (with an option to let a colleague NX user still
>>> print to my own local printers).
>>
>>This is true even if the cupsd.conf file is on the nxserver.
>
>
> I know. But it still doesnt give more sense to actually do it
> that way.
>
>
>>And running cupsd on the nxclient has the distinct drawback of
>>completely disabling all printers running on the nxserver.
>
>
> That drawback is....
>
> ...cornercase. In most scenarios, users need to print to their
> *local* printers, not the ones attached to the
> NX server.
>
> ...relative. It can easily be overcome by setting the IPP_PORT
> env variable back to 631. And users can switch
> back to using their own local NX client printers
> any time by again setting IPP_PORT to the forwarded
> port.
>
> If you have in mind an enterprise level NX server, servicing
> applications to users who work inhouse during work hours -- this
> type of sessions would mostly require no change to (Free)NX code.
> Let the NX server admin install the CUPS printers (or get them
> via browsing), and you are done.
>
> Ah, you think of those mobile workers who go home and wan to
> continue to work from their (within the same session as used at
> work, by resuming it), but now print to the local printer at
> home?
>
> OK, teach them how to switch IPP_PORT. Create a GUI or a script
> that automates that. Technically it's solved. Usability is the
> main problem here.
>
>
> Cheers,
> Kurt
> _______________________________________________
> FreeNX-kNX mailing list
> FreeNX-kNX at kde.org
> https://mail.kde.org/mailman/listinfo/freenx-knx
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFCahADOOpxqcksWu4RArC5AJ0dfkW2fOh4Bw+wZ0QNvSzVwd4ixACdH8Ou
5miDTKZC0oQRN5I+B6cOOAc=
=ZSGu
-----END PGP SIGNATURE-----
More information about the FreeNX-kNX
mailing list