[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freenx-knx
Subject:    [FreeNX-kNX] printing under freenx/knx
From:       jon () severinsson ! net (Jon Severinsson)
Date:       2005-04-12 20:10:15
Message-ID: 425C2B27.1060208 () severinsson ! net
[Download RAW message or body]

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

Hi everyone.

With printing on the agenda again, I would like to share my thoughts.

Analyzing the situation, I find that there is 4 different cases on the
server and 2 different cases on the client to take into account in any
combination for everything to ?just work?
Server Cases:
	Native X11 connection
	Proxy VNC to a Unix server
	Proxy VNC to a Windows server
	Proxy RDP to a Windows Server
Client Cases:
	Windows Client
	Unix Client.

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) for printers. 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.

This *should* be straightforward, but my personal experiments shows that
cups-polld refuses to add printers originating from the local computer,
even when run from a *different* cupsd instance.
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.
This 'feature' makes polling the system cupsd impossible if it runs on
the nxserver (the most common case), and thus thwarts the entire idea.
In worst case scenario I will have to fix the cups sources, something I
don't think I'm qualified for... Or perhaps parse what printers there is
and add them 'manually' (eg. by script), if that is possible.

The proxying problem is however not as simple.
When proxying VNC to a Unix server you would basicly have to do the same
as above, but on the VNC server instead of the nxserver. I'm no expert
on the VNC protocol, but I don't think you can send commands to be
executed over it, so exactly how to implement this is beyond me.

When proxying VNC or RDP to a Windows server the problem is different.
On windows you don't have cups to play with, but you have to make due
with smb. For a windows (or unix/samba) client this is no big deal,
you'll just have to forward the smb connection to the client, and the
problem is just the same as for VNC-on-Unix: executing the connect
command on the VNC/RDP server. When a unix client does the connection
and wants to share it's cups printers it becomes more complex. You would
more or less have to set up a usermode cupsd server on the nxserver
polling the cupsd server on the nxclient and then a usermode samba
server on the nxserver sharing those printers and then have the VNC/RDP
server to connect to the usermode samba server on the nxserver...

I don't think proxying printers to a VNC/RDP server is feasibly for
0.4.0, but if I just could work out polling I could probably write
native X11 support in a week or so.

Anyone else have any thoughts on this. I'm especially interested if
someone knows anything about polling localhost for printers. Anyone, please!

Regards
- - Jonno

PS. Some more direct comments to Kurt's mail:

Kurt Pfeifle wrote:
> (I have/had a script that clones and adapts the
> system cupsd into user space, and automates the process.)
I would *LOVE* to take a look at this!

> The disadvantage of all this is that it only works, if
>   a) the local NX client has a CUPS server installed (that is the NX 
>      client must either be on Linux, FreeBSD, Mac OS X or Solaris --
>      Windows is not supported
This can be avoided as cups can connect to a printer shared with samba.
Just run the cupsd on the server side instead on the client, and forward
the smb connection instead of the cups connection through ssh.
(similarly to filesharing today).

>   b) and the remote session must go to a Unix server which has at
>      least the CUPS client parts installed (no support for most 
>      VNC or RDP sessions).
Actually, adobe has a windows printer client supporting ipp (eg cupsd).
It does require the ppd from the server though, as well as a separate
installation. I don't think this can easily be automated, but as a
manual workaround it does work.

> To support also Windows clients, we are interested in someone who 
> could make some effort in getting CUPS compiled and installed on
> a Windows system. There are two options:
This can be avoided with samba (se above).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCXCsmOOpxqcksWu4RAhiBAJwPf1rX7BnFS3XEFxeIvL45XWub4ACdG1BV
pzom/koszPXJDzt3E2h2g0k=
=v1Um
-----END PGP SIGNATURE-----


[prev in list] [next in list] [prev in thread] [next in thread]