[FreeNX-kNX] printing under freenx/knx

[Jon Severinsson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi again.

Kurt Pfeifle skrev:
> On Tuesday 12 April 2005 21:10, Jon Severinsson wrote:
>>Server Cases:
>>	Native X11 connection
>>	Proxy VNC to a Unix server
>>	Proxy VNC to a Windows server
>>	Proxy RDP to a Windows Server
>
> You forgot one:
>         Proxy X11 to a Unix server
>
You're right. Or rather, "Native X11 connection" should be replaced with
"Proxy X11 to a Unix server". ?Native X11 connection? is actually just
the special case of ? Proxy X11 to localhost?. As FreeNX currently only
supports proxying X11 to loaclhost, I forgot about this future feature.
All my rantings regarding "Native X11 connection" can be applied to
"Proxy X11 to a Unix server" as well, as all actual printing code would
be in nxnode. Just replace "the nxserver" with "the computer running
nxnode".

Kurt Pfeifle skrev:
>>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
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
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. 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,
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. In an office environment this might actually be the
case, and imo enabling printer support should *not* disable the existing
printers.
If not, almost all of my email is irrelevant. I'm trying to work out a
solution allowing printing to both sets of printers. If we only wants
printing to nxclient *or* nxserver there hopefully is simpler solutions.

>  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? 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. 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 (no ssh port forwarding, hasn't got that far
yet). That might very well be the problem.

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

>  * 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 (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? 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, so you must mean that cupsd on the nxclient might have been set up
not to allow the nxserver to poll it. You are right i that, but with ssh
port forwarding the poll would come from the nxclient. And by definition
the nxclient has permissions to do so, or the nxclient would not be able
to print itself. The problem is now the same polling-localhost problem
as I described.

>>This *should* be straightforward, but my personal experiments shows that
>>cups-polld refuses to add printers originating from the local computer,
>
> For good reasons.
>
When not run from a *different* cupsd instance: Yes.

>>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 ?
>
If there is no good workaround, that's pretty much it.

>>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...)
>
To my knowledge port forwarding a cupsd running at the nxclient would do
pretty much the same thing. (or does ssh forwarding only forward
connections made by the user setting up the ssh tunnel?)

>
>>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.)
>
Yes, I would try that first. ?worst case scenario? is just that, a worst
case scenario if nothing else works...

>>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.
>
This is true even if the cupsd.conf  file is on the nxserver.

>  * the "ServerName localhost" directive in cupsd.conf
>    could easily be used for the userspace cupsd.conf
>
Yes, this does make it simpler...

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

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

And running cupsd on the nxclient has the distinct drawback of
completely disabling all printers running on the nxserver. (Unless you
know how to print from the commandline of course. Then you can do
?IPP_PORT=631 lpr some-file.ps?.)

>>The proxying problem is however not as simple.
>
> True.
>
> Sorry, no time to comment on your further remarks just now.
>
Well, no problems. The X11 printing support should be solved first, as
it would be the base even for non-X11 printing support.

> Cheers,
> Kurt

Thanks very much for all your input! I hope you will take your time to
address my new email as well, as you seem to have quite an insight in cups.

Regards
- - Jonno
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCXM/0OOpxqcksWu4RAtZtAKCpX0KWfkbH+WWUYvxr5GLvoNU0QACfe0RQ
FThWMCy5CdESBicKllQ3fTY=
=4DAs
-----END PGP SIGNATURE-----