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, http://guacamole.apache.org)
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
Hello
my comment about client plugin, was from this page
https://guacamole.apache.org/doc/gug/guacamole-architecture.html 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
