Am 20.02.2013 09:22, schrieb Moritz Struebe:
On 2013-02-19 20:20, Stefan Baur wrote:
I can see that sshfs makes sense when you want to exchange files between host and client, but for printing it sounds like overkill.
Well, actually the best thing to do is probably letting the client "ls" every sec (it's prabably not worth the trouble to inotify) and then scp to temp. But it needs someone to code that. After all, a x2go started as a proof of concept rather then a product.
Uh, no. You see, currently, I'm not using X2Go to connect via the internet, it's all happening in my local network(s), so I don't have to worry about encryption and compression for print data. In this scenario, I'm simply letting the CUPS servers talk to each other directly, which works fine when the client is using Linux (or Mac OS, I guess - after all, the Apple guys kinda bought CUPS).
For Windows, I'm using the LPR Daemon that is an optional windows component, so to the server-side CUPS the Windows computer looks like a network printer. For printers that aren't supported by CUPS (the el-cheapo GDI-only ones) I'm using a combination of redmon (a printer port redirection tool usually used with ghostscript for Windows to create PDFs) and a free PDF viewer: CUPS sends the print job in PDF format via port 515/lpr, redmon accepts it, passes it to the PDF viewer, which in turn uses the windows printer driver to create the print output. If properly set up, all this happens in the background, with no user interaction required and no windows popping up. A bit of a hack for Windows, I admit, but it works just fine.
Now, it would be nice if that would work over the internet, too, by simply forwarding the proper ports through the already existing ssh tunnel created by X2Go. That way the print data would be encrypted and compressed as well.
That's why I don't see an advantage in mounting a remote filesystem via SSH (which is a Pandora's Box of its own) simply to be able to print.
And even if you don't want to use LPR and redmon on Windows, there'd still be the option of setting up a netcat listener on the client that only accepts connections from localhost (the tunneled port connecting to it), have that one write its data to a file, and print upon completion.
Something as simple as (pseudocode, not actual bash/batch)
printfile=$(makesafetempfilename) # note that we're using port 9100 - "raw" network printer mode # rather than 515 with its LPR protocol overhead, so we don't # need to have the windows LPD and redmon installed while nc -l -s 127.0.0.1 -p 9100 -w 1 >printfile; do process_and_print printfile # this is where you call the PDF tool delete printfile printfile=$(makesafetempfilename) done
would probably do the trick. Note that Windows netcat (at least the copy I found) doesn't support "-q", so you have to improvise with "-w".
The way netcat is called it terminates upon completely receiving the file, and the following tasks are not started before netcat terminates, so there is no need to check for completeness of the file.
Also, should a user fire off another print job before the while loop returns to its head and restarts netcat, CUPS will simply assume the printer is busy/offline and retry after a few seconds, so no print job is lost.
I'm sure that even integrating such code (with a listener and the option to pass a temporary file to a PDF tool) *directly* into the X2Go client, rather than having it as an add-on component, would be a simple task for a skilled programmer.
-Stefan