Hi Stefan, I would prefer the solution suggested by Morty. Actually, I already thought about it and i want include it in new implementation of x2goclient. X2goclient will simply check a spool directory on server and download a print jobs in PDF format via existing libssh connection. This solution is much simpler, no need a cups, lpr, or ssh daemon running on a client and implementation is just the same for all operating systems. I can also implement this solution in current version of x2goclient if somebody will sponsor the development.
regards Alex Am 20.02.2013 09:51, schrieb Stefan Baur: > 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 > _______________________________________________ > X2Go-Dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/x2go-dev -- Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team email: [email protected] web: www.obviously-nice.de --> X2go - everywhere@home
signature.asc
Description: OpenPGP digital signature
_______________________________________________ X2Go-Dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/x2go-dev
