guacamole-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ronny Aasen <>
Subject Re: http as a guacamole protocol
Date Wed, 03 Oct 2018 08:19:39 GMT
On 10/3/18 2:36 AM, Nick Couchman wrote:
> Warning - TL;DR.  Summary version: The decision was not made 
> arbitrarily, there was a reason for it, to keep the features of the 
> project within the defined scope.
>     Hello
>     Thanks for your reply, and the link. I did not find that in my
>     googling. although i was looking for instruction on how to configure
>     it in today's guacamole, since it seemed such a obvious thing to me.
> The JIRA issues do not always show up in search results - I don't know 
> how much indexing is done of the JIRA instance by search providers like 
> Google.  In the future, if you're ever curious about a feature request, 
> bug, etc., you can always go to the JIRA page and browser/filter/search 
> that way.
>     very sorry to hear that it have been considered, and found
>     unwanted..  It seems a bit odd to me to limit the usefulness of a
>     tool due to some arbitrary scope. unless that scope is required in
>     order to secure financing the project or something similar.  Since
>     guacamole is an excellent remote management tool for the things it
>     supports, it makes it a pity that it can not support the other
>     common remote management protocols.
> I sense some frustration here :-).  When you say "arbitrary scope" you 
> are implying that we (the Guacamole Project) have decided not to 
> implement this feature without any reason at all - "based on random 
> choice or personal whim, rather than any reason or system."  Your 
> assertion that this decision was made based on random choice or personal 
> whim is not true.  It was decided that it was outside the scope of the 
> project - that is, the project already had a scope and definition, and 
> the maintainers of the project decided this was not within that scope.  
> It was not random, or a personal whim, and it also was not without any 
> consideration or discussion.
>     I may have misunderstood guacamoles purpose. what are people use it
>     for if not remote management via desktop and ssh... is the intention
>     a VDI solution fopr end users?
> Apache Guacamole is a clientless remote desktop gateway. (Take from the 
> home page,
> The key that I'd ask you to focus in on, here, is "remote desktop 
> gateway."  Its goal is to broker remote desktop connections between web 
> browsers (as the client) and the back-end servers.  Several remote 
> desktop protocols are supported - RDP, SSH, Telnet, and VNC - with 
> others being added (Kubernetes console support has recently been merged 
> into the guacd side, SPICE protocol support has been requested, though 
> not implemented, and a X(11/free86/org) Guacamole driver is in the 
> works).  All of these, both supported and in progress, are protocols 
> that are recognized as "remote desktop" protocols at some level or 
> another.  HTTP does not fall into that category.
> What Guacamole is *not* designed to be is a comprehensive web-based SSL 
> VPN (e.g. Cisco AnyConnect, FortiNet, PaloAlto Global Connect, etc.).  
> It's true that most web-based SSL VPNs implement both a generic reverse 
> proxy, allowing you to access web pages within the protected network 
> from that browser session, and also some subset of remote desktop 
> connections, like RDP or SSH.  Guacamole is not trying to be a web-based 
> SSL VPN, even if it has features that these software packages routinely 
> implement.
> Guacamole could, however, be one piece of a larger, overall solution, 
> for whatever use you have for a "clientless remote desktop gateway."  It 
> could certainly be part of a SSL VPN.  I, personally, would love to see 
> a complete, Open Source, web-based SSL VPN implemented that included 
> Guacamole as one of its core components, but also included things like 
> reverse proxy, file sharing/browsing, and port tunneling.  It could be 
> part of a VDI solution, though, in itself, it is not a VDI solution.  It 
> could be part of a method for providing centralized access to a server 
> farm, without requiring additional client installs.  There are many 
> possible ways that it could integrate into a solution with a broader 
> scope.  At a previous place that I worked we used it to provide access 
> to legacy applications that we did not want to (or could not) distribute 
> to everyone's system.
>     I do run both nginx and haproxy as revers proxies for things where
>     this is appropriate (web clusters and such) but i was looking for a
>     solution that gave me access to a web based management interface
>     that are not meant to be available online without a security login
>     with 2FA like guacamole.
>     I use openvpn access server today, with 2FA. and it does it's job. I
>     can access rdp/ssh/vnc/http/etc  but it is a bit clunky when you
>     connect to different gateways all the time. and guacamole was a much
>     "sexier" and smoother solution.
> On behalf of the project, I'll take the "much sexier and smoother" as a 
> compliment :-).
>     I agree it may not "fit" into guacd, but there should be nothing
>     stopping someone from making a gauc-p revers proxy that could be
>     accessed via the guacamole web interface. all it needs to do is what
>     ssh -D8080 does today in practicality. but since the requirements
>     are small i would think adding a guacd client plugin that functioned
>     as a tunnel would be more sane, instead a whole new server.
> Certainly, there is nothing from stopping anyone from adding this 
> functionality to Guacamole.  One of the beautiful things about open 
> source software is that, if you don't like what's already there, you can 
> take the source code and modify it to fit your needs.  I do realize that 
> not everyone has the skills to do this, and that puts you somewhat at 
> the mercy of the community that is developing the project, but those of 
> us developing the project also have limitations - sometimes skills, but 
> also time and money - and we have to draw feature lines somewhere and 
> focus on features and improvements that we feel are important to the 
> current scope of the project.  You can see from the number of opened 
> JIRA issues for the project that there is no shortage of directions for 
> us to go at the moment.
> I'd also point out that I think you miss a little bit of the complexity 
> here in what Guacamole is doing behind the scenes.  You assert that 
> (paraphrasing) it should be as simple as "ssh -D8080", but that's not 
> really true.  What Guacamole is doing behind the scenes is taking remote 
> desktop protocols, like RDP, SSH, and VNC, translating those protocols 
> into the Guacamole protocol (yes, Guacamole is a protocol, not just a 
> client/server), and then sending that on the web browser (essentially as 
> either JPEG or PNG images plus audio, clipboard, and file transfers).  
> This is different than doing port forwarding or establishing some sort 
> of VPN tunnel between your browser and the remote server.  Here's some 
> quick (and very poor) ASCII Art to illustrate the flow (using RDP to a 
> Windows Server as an example):
> Web Browser Client <-- (HTTP and/or WebSocket) --> Guacamole Client <-- 
> (Guacamole Protocol) --> guacd <-- (RDP) --> Windows Server
> Essentially, and very simply, adding HTTP support would involve having 
> guacd render the web pages itself, and then generate the images (+audio, 
> clipboard, and file transfers) to send via the Guacamole Protocol over 
> to the Guacamole Client, which would then provide that via HTTP(s) or 
> WebSocket(S) to the browser.  I've no doubt that it *could* be done, but 
> this isn't really the function of a remote desktop gateway or client, 
> it's more like a VPN or reverse proxy.  It's also ever so slightly more 
> complex than just forwarding a port on the client to the server.
> Finally on this point, you mention "adding a guacd client plugin" to do 
> the port forwarding.  This would go directly against one of the key 
> goals of the Guacamole Project - *clientless* remote desktop gateway, 
> where "clientless" is referring to not requiring any additional client 
> or plugin within the web browser.
>     Since guacamole is limited to displaying Is it perhaps possible to
>     do a single application of a remote desktop X11 application via
>     guacamole, that could open just a single browser, to "cheat" into
>     getting a web page at the remote location. that could run the remote
>     "browser" on the guacd linux server host.
> Yes, this is certainly a way you could work around the challenge - you 
> could have a RDP (XRDP, if you like, on Linux) or VNC connection open 
> Chrome or Firefox, and you could then use that to browse around the 
> internal network.
> Hopefully I've been able to clear up the goals of the project and answer 
> some of your questions.  I'm sorry that it appears to have frustrated 
> you, but hopefully now it makes more sense what the project is trying to 
> accomplish, and, just as importantly, what we're not trying to 
> accomplish, achieve, or be.
> -Nick


my comment about client plugin, was from this page where 
it is stated that protocol support in guacd is added as "client plugins"

I am sorry if my frustration was so visible, was not my intention :)
I just liked guacamole so much that i had hoped to use it for 
$everything right away. But I do realize it is more complex then one can 
assume at first glance.

the sexy and smooth is absolutely a compliment, what guacamole does for 
RDP and VNC is just amazing.

thank you for your time.
Ronny Aasen

View raw message