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
