[FreeNX-kNX] printing under freenx/knx

[Kurt Pfeifle]

On Tuesday 12 April 2005 21:10, Jon Severinsson wrote:

> For simplicity, I assume that all unix machines has cups, and windows
> has smb (windows file and print sharing). I also find it reasonable to
> require the nxserver administrator to install samba on the nxserver to
> get everything to work (already required for file sharing), but I don't
> think it reasonably to require any special setup on the clients.
>
> 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)?

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)
 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 you want to poll the NX client's cupsd, see below....

> for printers.  

I fiddled with that already. There are various problems with this 
approach, and one thing that definitely doesnt 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...)

Other various problems:

 * NX servers with many parallel sessions running (where most users
   have activated a userspace cupsd) will consume many more resources.

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

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.

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

> This *should* be straightforward, but my personal experiments shows that
> cups-polld refuses to add printers originating from the local computer,

For good reasons.

> even when run from a *different* cupsd instance.

Maybe we could convince Mike Sweet to change that for CUPS-1.2.

> This 'feature' is great when the printer originates from the same cupsd
> instance, avoiding to override a printer with an infinite loop, but in
> this case it simply sucks.

So what do you intend to do? Write an STR at 

   http://www.cups.org/str.php ?

> This 'feature' makes polling the system cupsd impossible if it runs on
> the nxserver (the most common case), and thus thwarts the entire idea.

The entire idea is superfluous anyway. The cupsd running on the 
nxserver, and the printer it provides, is accessible to any NX user 
from any NX session anyway. (However, these may be not the printers
the user wants to use...)

> In worst case scenario I will have to fix the cups sources, something I
> don't think I'm qualified for... 

Oh, try "negotiations" with the CUPS developers. They are at least
as friendly as we are... (If they disagree with our feature requests,
they may have good reasons.)

> Or perhaps parse what printers there is 
> and add them 'manually' (eg. by script), if that is possible.

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.

 * the "ServerName localhost" directive in cupsd.conf 
   could easily be used for the userspace cupsd.conf

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

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

> The proxying problem is however not as simple.

True. 

Sorry, no time to comment on your further remarks just now.

Cheers,
Kurt