Re: Working with pipes
Ah, ok. I did not do the following from the Guac server:
$ ./guacctl -o "test-pipe"; echo -n "hello world"; ./guacctl -c
I thought the pipe would be available as part of the SSH or Telnet connection
being established and the text coming from the connected device would be
available in the pipe. I was hoping to access the text data at the javascript
level.
-Jeff
From: Mike Jumper
Reply-To: "user@guacamole.apache.org"
Date: Wednesday, February 21, 2018 at 2:07 PM
To: "user@guacamole.apache.org"
Subject: EXT: Re: Working with pipes
Yes, onpipe should be firing for pipe streams created in this way. To
demonstrate general usage and expectations here, I've created a quick topic
branch to act as a temporary POC which adds handling for "text/plain" pipe
streams, logging their creation, closure, and any data received along the
stream:
https://github.com/mike-jumper/guacamole-client/commit/58537771afcbaa5619e11cdf3e6ad52aa9f6584d
After establishing an SSH connection via a Guacamole server having the above
commit, I ran the following one-liner to open a new pipe stream called
"test-pipe", print "hello world" while output is redirected to that pipe
stream, and finally close the stream:
$ ./guacctl -o "test-pipe"; echo -n "hello world"; ./guacctl -c
The log within the browser displayed:
pipe: test-pipe: stream begins
pipe: test-pipe: "hello world"
pipe: test-pipe: stream ends
and withing guacd:
...
guacd[3374]: DEBUG: Terminal output now redirected to pipe 'test-pipe'.
guacd[3374]: DEBUG: Terminal output now redirected to display.
...
- Mike
On Wed, Feb 21, 2018 at 6:48 AM, McRoy, Jeffrey (GE Healthcare)
wrote:
If the Guac server is opening a pipe stream and redirecting output to it,
wouldn’t the onpipe event fire in the Guac client?
guacClient.onpipe = function(input_stream, mimetype, name) {
reader = new Guacamole.StringReader(input_stream);
reader.ontext = function receiveText(text) {
console.log(text);
};
}
-Jeff
From: Mike Jumper
Reply-To: "user@guacamole.apache.org"
Date: Tuesday, February 20, 2018 at 9:33 PM
To: "user@guacamole.apache.org"
Subject: EXT: Re: Working with pipes
On Tue, Feb 20, 2018 at 7:23 PM, Nick Couchman wrote:
Is it possible for the client to access the terminal output at either the
javascript or java layer?
So, one thing to keep in mind, here, is that the terminal output from SSH and
Telnet is transmitted from guacd to the Guacamole Client as an image, not as
text. I know it doesn't *seem* like it, particularly since the client allows
you to select text and copy it to the clipboard (and vice-versa), but if you
look at the actual data going back and forth, all of the screen output, include
"text" from the terminal, is image data. So, doing anything with it (parsing,
etc.) at the JavaScript layer is probably impractical, if not impossible.
Waait! Guacamole does send images, yes, but there is also an OSC which
temporarily redirects output to a pipe stream:
https://github.com/apache/guacamole-server/blob/99e6f89eba56b6effc189d1c2c160686ed880beb/src/terminal/terminal_handlers.c#L1314-L1320
There is an example of this within guacctl:
https://github.com/apache/guacamole-server/blob/99e6f89eba56b6effc189d1c2c160686ed880beb/bin/guacctl#L285-L301
- Mike
smime.p7s
Description: S/MIME cryptographic signature
Re: Working with pipes
Yes, onpipe should be firing for pipe streams created in this way. To
demonstrate general usage and expectations here, I've created a quick topic
branch to act as a temporary POC which adds handling for "text/plain" pipe
streams, logging their creation, closure, and any data received along the
stream:
https://github.com/mike-jumper/guacamole-client/commit/58537771afcbaa5619e11cdf3e6ad52aa9f6584d
After establishing an SSH connection via a Guacamole server having the
above commit, I ran the following one-liner to open a new pipe stream
called "test-pipe", print "hello world" while output is redirected to that
pipe stream, and finally close the stream:
$ ./guacctl -o "test-pipe"; echo -n "hello world"; ./guacctl -c
The log within the browser displayed:
pipe: test-pipe: stream begins
pipe: test-pipe: "hello world"
pipe: test-pipe: stream ends
and withing guacd:
...
guacd[3374]: DEBUG: Terminal output now redirected to pipe 'test-pipe'.
guacd[3374]: DEBUG: Terminal output now redirected to display.
...
- Mike
On Wed, Feb 21, 2018 at 6:48 AM, McRoy, Jeffrey (GE Healthcare) <
jeffrey.mc...@ge.com> wrote:
> If the Guac server is opening a pipe stream and redirecting output to it,
> wouldn’t the onpipe event fire in the Guac client?
>
>
>
> guacClient.onpipe = function(input_stream, mimetype, name) {
>
> reader = new Guacamole.StringReader(input_stream);
>
> reader.ontext = function receiveText(text) {
>
> console.log(text);
>
> };
>
> }
>
>
>
> -Jeff
>
>
>
>
>
> *From: *Mike Jumper
> *Reply-To: *"user@guacamole.apache.org"
> *Date: *Tuesday, February 20, 2018 at 9:33 PM
> *To: *"user@guacamole.apache.org"
> *Subject: *EXT: Re: Working with pipes
>
>
>
> On Tue, Feb 20, 2018 at 7:23 PM, Nick Couchman wrote:
>
> Is it possible for the client to access the terminal output at either the
> javascript or java layer?
>
>
>
>
>
> So, one thing to keep in mind, here, is that the terminal output from SSH
> and Telnet is transmitted from guacd to the Guacamole Client as an image,
> not as text. I know it doesn't *seem* like it, particularly since the
> client allows you to select text and copy it to the clipboard (and
> vice-versa), but if you look at the actual data going back and forth, all
> of the screen output, include "text" from the terminal, is image data. So,
> doing anything with it (parsing, etc.) at the JavaScript layer is probably
> impractical, if not impossible.
>
>
>
> Waait! Guacamole does send images, yes, but there is also an OSC which
> temporarily redirects output to a pipe stream:
>
>
>
> https://github.com/apache/guacamole-server/blob/
> 99e6f89eba56b6effc189d1c2c160686ed880beb/src/terminal/
> terminal_handlers.c#L1314-L1320
>
>
>
> There is an example of this within guacctl:
>
>
>
> https://github.com/apache/guacamole-server/blob/
> 99e6f89eba56b6effc189d1c2c160686ed880beb/bin/guacctl#L285-L301
>
>
>
> - Mike
>
>
>
Re: Working with pipes
If the Guac server is opening a pipe stream and redirecting output to it,
wouldn’t the onpipe event fire in the Guac client?
guacClient.onpipe = function(input_stream, mimetype, name) {
reader = new Guacamole.StringReader(input_stream);
reader.ontext = function receiveText(text) {
console.log(text);
};
}
-Jeff
From: Mike Jumper
Reply-To: "user@guacamole.apache.org"
Date: Tuesday, February 20, 2018 at 9:33 PM
To: "user@guacamole.apache.org"
Subject: EXT: Re: Working with pipes
On Tue, Feb 20, 2018 at 7:23 PM, Nick Couchman wrote:
Is it possible for the client to access the terminal output at either the
javascript or java layer?
So, one thing to keep in mind, here, is that the terminal output from SSH and
Telnet is transmitted from guacd to the Guacamole Client as an image, not as
text. I know it doesn't *seem* like it, particularly since the client allows
you to select text and copy it to the clipboard (and vice-versa), but if you
look at the actual data going back and forth, all of the screen output, include
"text" from the terminal, is image data. So, doing anything with it (parsing,
etc.) at the JavaScript layer is probably impractical, if not impossible.
Waait! Guacamole does send images, yes, but there is also an OSC which
temporarily redirects output to a pipe stream:
https://github.com/apache/guacamole-server/blob/99e6f89eba56b6effc189d1c2c160686ed880beb/src/terminal/terminal_handlers.c#L1314-L1320
There is an example of this within guacctl:
https://github.com/apache/guacamole-server/blob/99e6f89eba56b6effc189d1c2c160686ed880beb/bin/guacctl#L285-L301
- Mike
smime.p7s
Description: S/MIME cryptographic signature
Re: Working with pipes
. > > Waait! Guacamole does send images, yes, but there is also an OSC which > temporarily redirects output to a pipe stream: > > . Sorry. Very nice.
Re: Working with pipes
On Tue, Feb 20, 2018 at 7:23 PM, Nick Couchman wrote: > Is it possible for the client to access the terminal output at either the >> javascript or java layer? >> >> >> > So, one thing to keep in mind, here, is that the terminal output from SSH > and Telnet is transmitted from guacd to the Guacamole Client as an image, > not as text. I know it doesn't *seem* like it, particularly since the > client allows you to select text and copy it to the clipboard (and > vice-versa), but if you look at the actual data going back and forth, all > of the screen output, include "text" from the terminal, is image data. So, > doing anything with it (parsing, etc.) at the JavaScript layer is probably > impractical, if not impossible. > Waait! Guacamole does send images, yes, but there is also an OSC which temporarily redirects output to a pipe stream: https://github.com/apache/guacamole-server/blob/99e6f89eba56b6effc189d1c2c160686ed880beb/src/terminal/terminal_handlers.c#L1314-L1320 There is an example of this within guacctl: https://github.com/apache/guacamole-server/blob/99e6f89eba56b6effc189d1c2c160686ed880beb/bin/guacctl#L285-L301 - Mike
Re: Working with pipes
> > Is it possible for the client to access the terminal output at either the > javascript or java layer? > > > So, one thing to keep in mind, here, is that the terminal output from SSH and Telnet is transmitted from guacd to the Guacamole Client as an image, not as text. I know it doesn't *seem* like it, particularly since the client allows you to select text and copy it to the clipboard (and vice-versa), but if you look at the actual data going back and forth, all of the screen output, include "text" from the terminal, is image data. So, doing anything with it (parsing, etc.) at the JavaScript layer is probably impractical, if not impossible. As far as at the Java layer, I believe it's already an image by the time it hits the Java Servlet part of the client - I believe the process of making it an image is done by guacd. I could be wrong about that, I'm less certain than when it hits the JavaScript portion, but I believe that's a Guacamole protocol-level thing, and not just a Java Servlet -> JavaScript Webapp deal. So, any capture/process of text that coming off the terminal that youd' want to do would, more than likely, need to be done in guacd. -Nick
Re: Working with pipes
I’m interested in inspecting the text output from the terminal. If I have an
active SSH or Telnet connection the events onpipe, ontext, and ondata don’t
seem to fire. They looked like possibilities since they return an inputstream,
a string, and a buffer respectively. I was thinking something like the below
would gain access to the server stream from the client.
guacClient.onpipe = function(input_stream, mimetype, name) {
reader = new Guacamole.StringReader(input_stream);
reader.ontext = function receiveText(text) {
console.log(text);
};
}
If I understand your comment below, the above events only fire in response to
Guac instructions received from the Guac server. So, I assume these events are
not associated with terminal’s output. Is it possible for the client to access
the terminal output at either the javascript or java layer?
Regards,
Jeff
From: Mike Jumper
Reply-To: "user@guacamole.apache.org"
Date: Saturday, February 17, 2018 at 1:29 PM
To: "user@guacamole.apache.org"
Subject: EXT: Re: Working with pipes
On Fri, Feb 16, 2018 at 2:46 PM, McRoy, Jeffrey (GE Healthcare)
wrote:
Hi Everyone,
I’m looking at how pipes work with the Guac client. For example…
.
.
// Instantiate client, using an HTTP tunnel - tenet connection
var guac = new Guacamole.Client(
new Guacamole.HTTPTunnel("tunnel")
);
var stream = guac.createPipeStream("text/plain", "response");
.
.
guac.onpipe = function(input_stream, mimetype, name) {
console.log("onpipe");
if (name == "response") {
reader = new Guacamole.StringReader(input_stream);
reader.ontext = function receiveText(text) {
console.log(text);
};
}
}
.
.
The client makes a successful telnet connection and the I’m able to use it.
However, I never see anything echoed to the Javascript console. I’m fairly sure
onpipe is supposed to fire whenever a pipe is created. In my example it seems
like onpipe does not execute. Is this the correct usage?
Nope. There is a distinction between createPipeStream() and onpipe:
createPipeStream() creates an outbound pipe stream from client to server. It
sends a "pipe" instruction [1] declaring the stream with the parameters given,
and the handlers of that stream object will be invoked in response to
instructions received from the server. Data ("blob" instructions [2]) is sent
strictly from client to server. In this case, as the telnet protocol support
does not attempt to handle inbound pipe streams, this will most likely result
in an "ack" [3] with an associated error code, implicitly closing the stream.
If the code you've provided here is exactly what you are doing, it's also
likely that doing this has no real effect, since the tunnel will not be open at
the time that the "pipe" instruction needs to be sent, and the outbound
instruction will simply be dropped by the tunnel implementation.
The onpipe handler, on the other hand, is invoked in response to an *inbound*
pipe stream from server to client. This occurs when a "pipe" instruction is
sent by the server. It will not be invoked as a direct result of functions that
you call on the client-side; this and other handlers on the Guacamole.Client
object deal only with received Guacamole instructions.
- Mike
[1] http://guacamole.apache.org/doc/gug/protocol-reference.html#pipe-instruction
[2] http://guacamole.apache.org/doc/gug/protocol-reference.html#blob-instruction
[3] http://guacamole.apache.org/doc/gug/protocol-reference.html#ack-instruction
smime.p7s
Description: S/MIME cryptographic signature
Re: Working with pipes
On Fri, Feb 16, 2018 at 2:46 PM, McRoy, Jeffrey (GE Healthcare) <
jeffrey.mc...@ge.com> wrote:
> Hi Everyone,
>
>
>
> I’m looking at how pipes work with the Guac client. For example…
>
> .
>
> .
>
> // Instantiate client, using an HTTP tunnel - tenet connection
>
> var guac = new Guacamole.Client(
>
> new Guacamole.HTTPTunnel("tunnel")
>
> );
>
> var stream = guac.createPipeStream("text/plain", "response");
>
> .
>
> .
>
> guac.onpipe = function(input_stream, mimetype, name) {
>
> console.log("onpipe");
>
> if (name == "response") {
>
> reader = new Guacamole.StringReader(input_stream);
>
> reader.ontext = function receiveText(text) {
>
> console.log(text);
>
> };
>
> }
>
> }
>
> .
>
> .
>
>
>
> The client makes a successful telnet connection and the I’m able to use
> it. However, I never see anything echoed to the Javascript console. I’m
> fairly sure onpipe is supposed to fire whenever a pipe is created. In my
> example it seems like onpipe does not execute. Is this the correct usage?
>
>
>
Nope. There is a distinction between createPipeStream() and onpipe:
createPipeStream() creates an outbound pipe stream from client to server.
It sends a "pipe" instruction [1] declaring the stream with the parameters
given, and the handlers of that stream object will be invoked in response
to instructions received from the server. Data ("blob" instructions [2]) is
sent strictly from client to server. In this case, as the telnet protocol
support does not attempt to handle inbound pipe streams, this will most
likely result in an "ack" [3] with an associated error code, implicitly
closing the stream. If the code you've provided here is exactly what you
are doing, it's also likely that doing this has no real effect, since the
tunnel will not be open at the time that the "pipe" instruction needs to be
sent, and the outbound instruction will simply be dropped by the tunnel
implementation.
The onpipe handler, on the other hand, is invoked in response to an
*inbound* pipe stream from server to client. This occurs when a "pipe"
instruction is sent by the server. It will not be invoked as a direct
result of functions that you call on the client-side; this and other
handlers on the Guacamole.Client object deal only with received Guacamole
instructions.
- Mike
[1]
http://guacamole.apache.org/doc/gug/protocol-reference.html#pipe-instruction
[2]
http://guacamole.apache.org/doc/gug/protocol-reference.html#blob-instruction
[3]
http://guacamole.apache.org/doc/gug/protocol-reference.html#ack-instruction
