Hi all,
I just stumbled over this project: http://developer.berlios.de/projects/nxspooler/
It says that it is compliant with X2Go and FreeNX. Has anyone played
with it already? Any experiences?
Mike
--
DAS-NETZWERKTEAM mike gabriel, rothenstein 5, 24214 neudorf-bornstein fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Hi Mike.
Never used it but after reading the description on Berlios it looks that its similar to cups-x2go & x2go-printing. It uses a shared folder to transport a PDF file just like modern x2go does it.
Anyone?
--
Com os melhores cumprimentos.
Helmer Teles http://hteles.wordpress.com
"Sent from my Android Device"
Please don't send me proprietary file formats, use ISO standard ODF instead (ISO/IEC 26300)
.-. G N U
/v\ L I N U X
// \\ ---------
/( _ )\ May The Source Be
^^ ^^ With You...On Feb 18, 2013 4:41 AM, "Mike Gabriel" <mike.gabriel@das-netzwerkteam.de> wrote:
Hi all,
I just stumbled over this project: http://developer.berlios.de/**projects/nxspooler/<http://developer.berlios.de/projects/nxspooler/>
It says that it is compliant with X2Go and FreeNX. Has anyone played with it already? Any experiences?
Mike
--
DAS-NETZWERKTEAM mike gabriel, rothenstein 5, 24214 neudorf-bornstein fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.**de<mike.gabriel@das-netzwerkteam.de>, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.**de/freebusy/m.gabriel%40das-** netzwerkteam.de.xfb<https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb>
X2Go-Dev mailing list X2Go-Dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
On 02/17/2013 09:48 PM, Helmer Teles wrote:
Hi Mike.
Never used it but after reading the description on Berlios it looks that its similar to cups-x2go & x2go-printing. It uses a shared folder to transport a PDF file just like modern x2go does it.
Anyone?
From a quick glance it seems to create a spool directory but it seems to be up to you to manually share it, so it seems to do much less than cups-x2go.
That said, I've not been happy with the requirement to add users to the fuse group to use cups-x2go. I don't remember this from NX, although I'm not sure I ever tried printing from NX.
Hi all, I just stumbled over this project: http://developer.berlios.de/__projects/nxspooler/ <http://developer.berlios.de/projects/nxspooler/> It says that it is compliant with X2Go and FreeNX. Has anyone played with it already? Any experiences? Mike -- DAS-NETZWERKTEAM mike gabriel, rothenstein 5, 24214 neudorf-bornstein fon: +49 (1520) 1976 148 <tel:%2B49%20%281520%29%201976%20148> GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.__de <mailto:mike.gabriel@das-netzwerkteam.de>, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.__de/freebusy/m.gabriel%40das-__netzwerkteam.de.xfb <https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb> _______________________________________________ X2Go-Dev mailing list X2Go-Dev@lists.berlios.de <mailto:X2Go-Dev@lists.berlios.de> https://lists.berlios.de/mailman/listinfo/x2go-dev
X2Go-Dev mailing list X2Go-Dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
-- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion@nwra.com Boulder, CO 80301 http://www.nwra.com
On Feb 19, 2013 5:57 PM, "Orion Poplawski" <orion@cora.nwra.com> wrote:
On 02/17/2013 09:48 PM, Helmer Teles wrote:
Hi Mike.
Never used it but after reading the description on Berlios it looks that
similar to cups-x2go & x2go-printing. It uses a shared folder to
its transport a
PDF file just like modern x2go does it.
Anyone?
From a quick glance it seems to create a spool directory but it seems to be up to you to manually share it, so it seems to do much less than cups-x2go.
That said, I've not been happy with the requirement to add users to the fuse group to use cups-x2go. I don't remember this from NX, although I'm not sure I ever tried printing from NX.
Hello,
Regarding commercial NX from !machine you have to share in windows or Linux client a cifs printer and that resource is tunneled to the nxserver. Also in that case you have to match a printer driver also.
--
Com os melhores cumprimentos.
Helmer Teles http://hteles.wordpress.com
"Sent from my Android Device"
Please don't send me proprietary file formats, use ISO standard ODF instead (ISO/IEC 26300)
.-. G N U
/v\ L I N U X
// \\ ---------
/( _ )\ May The Source Be
^^ ^^ With You...Hi Orion,
On Di 19 Feb 2013 18:56:41 CET Orion Poplawski wrote:
That said, I've not been happy with the requirement to add users to
the fuse group to use cups-x2go. I don't remember this from NX,
although I'm not sure I ever tried printing from NX.
As the cups-x2go + x2goserver-printing mechanism works via SSHFS the
fuse membership is unfortunately necessary.
Mike
--
DAS-NETZWERKTEAM mike gabriel, rothenstein 5, 24214 neudorf-bornstein fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Am 19.02.2013 20:04, schrieb Mike Gabriel:
As the cups-x2go + x2goserver-printing mechanism works via SSHFS the fuse membership is unfortunately necessary.
Out of sheer curiousity, why aren't you streaming the file through a tunneled port (with the listener bound to 127.0.0.1 for security reasons)?
I can see that sshfs makes sense when you want to exchange files between host and client, but for printing it sounds like overkill.
-Stefan
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.
Morty
-- Dipl.-Ing. Moritz 'Morty' Struebe (Wissenschaftlicher Mitarbeiter) Lehrstuhl für Informatik 4 (Verteilte Systeme und Betriebssysteme) Friedrich-Alexander-Universität Erlangen-Nürnberg Martensstr. 1 91058 Erlangen
Tel : +49 9131 85-25419 Fax : +49 9131 85-28732 eMail : struebe@informatik.uni-erlangen.de WWW : http://www4.informatik.uni-erlangen.de/~morty
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
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 X2Go-Dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
-- Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team
email: oleksandr.shneyder@obviously-nice.de web: www.obviously-nice.de
--> X2go - everywhere@home
Am 20.02.2013 11:06, schrieb Oleksandr Shneyder:
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.
Again, this sounds like unneccessary overhead. You're turning a stream of data into a file, you need to have some sort of monitoring system (either polling regularly or triggered by the change to the filesystem) and what for - to turn the file into the stream of data that it originally was. With all this happening on the server.
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.
Well, you need the server-side cups or you wouldn't be able to print, with either solution. And my previous post contained a solution where you would only turn the data stream into a file after it arrives on the client, not on the server as well. This would work without *additional* cups, lpr or ssh on the client - it uses whatever the client (Linux, Mac OS and Windows) normally uses for printing and only needs an open tunneled port in the existing SSH connection.
Though, to be honest, I would simply connect to the existing CUPS via tunnel if the client uses Linux or Mac OS. No need to add complexity there.
-Stefan
I don't agree with you, Stefan. Simply redirect the ports is no solution for X2Go connections over Internet. The job should be converted in PDF on server or it will be just too big. So as result we will have a PDF File on server and it not a problem it all to download it to client system. And it could happens, that on client system you have no printers or printer system installed at all. So you can just save a print job as PDF-file.
regards Alex
Am 20.02.2013 11:16, schrieb Stefan Baur:
Am 20.02.2013 11:06, schrieb Oleksandr Shneyder:
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.
Again, this sounds like unneccessary overhead. You're turning a stream of data into a file, you need to have some sort of monitoring system (either polling regularly or triggered by the change to the filesystem) and what for - to turn the file into the stream of data that it originally was. With all this happening on the server.
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.
Well, you need the server-side cups or you wouldn't be able to print, with either solution. And my previous post contained a solution where you would only turn the data stream into a file after it arrives on the client, not on the server as well. This would work without *additional* cups, lpr or ssh on the client - it uses whatever the client (Linux, Mac OS and Windows) normally uses for printing and only needs an open tunneled port in the existing SSH connection.
Though, to be honest, I would simply connect to the existing CUPS via tunnel if the client uses Linux or Mac OS. No need to add complexity there.
-Stefan
X2Go-Dev mailing list X2Go-Dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
-- Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team
email: oleksandr.shneyder@obviously-nice.de web: www.obviously-nice.de
--> X2go - everywhere@home
Am 20.02.2013 11:31, schrieb Oleksandr Shneyder:
Simply redirect the ports is no solution for X2Go connections over Internet. The job should be converted in PDF on server or it will be just too big.
Fine, then do that on the server and after that *stream the PDF data stream* to the client. That's what the cups-pdf package does when you specify a socket or lpr instead of a file URI, so it's technically possible.
You might not know it, but there are printers that accept PDF natively via LPR or port 9100 (some Lexmark models, for example) just like most modern printers do with PCL or even Postscript.
So my way to drive them is cups-PDF generic ppd -> socket URI -> Printer.
And for the printers that don't natively speak PDF: a client-side CUPS that's already there because the user uses it for everyday print jobs will know how to handle a PDF data stream, and when there's no client-side CUPS (Windows), you can run a netcat-like listener and either print using a PDF tool or prompt the user to save to a file.
So as result we will have a PDF File on server and it not a problem it all to download it to client system.
Yes, it is a problem. Sorry, but it is a horrible design decision to convert data back and forth, causing disk IO and CPU cycles when there's no good reason to do so.
And it could happens, that on client system you have no printers
or printer system installed at all. So you can just save a print job as PDF-file.
That works just as well with a netcat-like listener. Simply tell the program to pop up a "save as" box when there's no PDF tool (which should be user-definable anyways, as some may prefer Adobe, others may prefer F/LOSS PDF tools) specified in its settings.
-Stefan
On 2013-02-20 11:55, Stefan Baur wrote:
So as result we will have a PDF File on server and it not a problem it all to download it to client system.
Yes, it is a problem. Sorry, but it is a horrible design decision to convert data back and forth, causing disk IO and CPU cycles when there's no good reason to do so.
Well, actually there is: Relieabilty and Maintainability. My solution has 3 little steps.
- Create pdf on the server (easy to check and not to difficult too debug)
- Copy file to client (easy to check, and can even be verified)
- Print pdf. This is also something quite easy to get running. Just exec "someprog --print $FILE"
While with your solution there is a multitude of things that can go wrong. It's really hard to find out whether it's a server side, client side, x2go-client (ssh forwarding), driver compability or whatever issue. The data gets piped through a lot of systems and you need quite a bit of knowledge to debug that. Also you need to handle connection losses - something that is not too easy either as you don't have direct control over the system having to cope with that. Further on reliability and maintainability is much more important than a little bit of performance. The spooler-dir also allows you to easily do things like adding "print@clinet"-button to OpenOffice (or any other scriptable app) by exporting the current document as pdf to the spool-dir.
Cheers Morty
-- Dipl.-Ing. Moritz 'Morty' Struebe (Wissenschaftlicher Mitarbeiter) Lehrstuhl für Informatik 4 (Verteilte Systeme und Betriebssysteme) Friedrich-Alexander-Universität Erlangen-Nürnberg Martensstr. 1 91058 Erlangen
Tel : +49 9131 85-25419 Fax : +49 9131 85-28732 eMail : struebe@informatik.uni-erlangen.de WWW : http://www4.informatik.uni-erlangen.de/~morty
Hi All,
On Mi 20 Feb 2013 11:06:46 CET Oleksandr Shneyder wrote:
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
As I see it, X2Go printing works quite ok ATM (at least +/-).
IMHO, if someone like Orion (i.e. someone who is not yet one of the
core devs but has the capability to become one) comes with a patch
that works by 80%, then let's continue this discussion.
But till then... If people agree, could we please focus on things that
do _not_ work so well at the moment????
E.g.:
- MesaGLX software rastering of Unity & co.
- Appropriate resizing of GNOME-fallback sessions (Xrandr)
- xkeyboard-config-2.6 breakage
- Xfixes and KUbuntu
- weird LibreOffice font renderings
- multi-session support in X2Go Client
- integrate new desktop shells (like CINNAMON, MATE, etc.)
The bug tracker contains quite a list of open issues, too: http://bugs.x2go.org/cgi-bin/pkgindex.cgi?indexon=src
And also: before inventing a new session handshake protocol for
printing, we really should start documenting the current status quo of
all X2Go Client/Server v4 protocols that we have so far. (I surely put
myself on the list of not-enough-documenting devs, as well.)
light+love, Mike
--
DAS-NETZWERKTEAM mike gabriel, rothenstein 5, 24214 neudorf-bornstein fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
On 13-02-20 09:31, Moritz Struebe <Moritz.Struebe@informatik.uni-erlangen.de> wrote:
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)
Its less trouble than getting an ls-loop right: http://linux.die.net/man/1/inotifywait
Ciao,
Alexander Wuerstlein.
On 02/20/2013 04:16 AM, Alexander Wuerstlein wrote:
On 13-02-20 09:31, Moritz Struebe <Moritz.Struebe@informatik.uni-erlangen.de> wrote:
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)
Its less trouble than getting an ls-loop right: http://linux.die.net/man/1/inotifywait
Yes, please do it properly. Having userspace wake up all the time is terrible in this day and age.
-- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion@nwra.com Boulder, CO 80301 http://www.nwra.com
-
Alexander Wuerstlein -
Helmer Teles -
Mike Gabriel -
Moritz Struebe -
Oleksandr Shneyder -
Orion Poplawski -
Stefan Baur