[FreeNX-kNX] printing under freenx/knx

[Kurt Pfeifle]

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