[
https://issues.apache.org/jira/browse/GUACAMOLE-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17136772#comment-17136772
]
Nick Couchman commented on GUACAMOLE-513:
-----------------------------------------
[~mjumper]
{quote}
The VNC support has had an autoretry parameter for some time. I think generally
supporting autoretry across the board, perhaps coupled with configurable
connect timeouts, would be a better approach than ICMP ping.
{quote}
That's already kind of Guacamole's behavior, isn't it? It tries, fails, does a
15 second count-down, and then tries, again, etc., until you click a button
canceling it. We could modify that behavior to limit the number of retries so
that it doesn't just keep doing it forever, but seems like this should be
pretty doable.
Regarding the connect timeouts, I think we can accomplish those pretty easily
in all but the RDP case, which might require some duct tape and bailing wire
to make it work. I looked into it related to a JIRA issues specifically about
setting connection timeouts, and it seems like VNC, RDP, and Telnet, and maybe
Kubernetes, are all easily doable because they just use the socket library, but
RDP abstracts that underneath the FreeRDP API calls. They have also already
rejected requests from the community to provide a configurable parameter. I'm
guessing we could do something with a timer to kill the connection if it goes
too long, but not sure how we'd go about extending it out. Anyway, that's a
conversation for a different issue...
[~jcharaoui]
{quote}
While it's true that unprivileged ICMP is disallowed on most Linux
distribution, it's not a hard limitation. For example the
"net.ipv4.ping_group_range" kernel parameter can be used to allow unprivileged
ICMP to a range of group ids.
{quote}
True, but this support is relatively new, I believe, and requires more
configuration on the end-user's part, in sysctl (or the boot prompt), no less.
I suppose we could consider a configurable mode for how guacd "pings" the
remote system, but it feels simpler/safer/easier to just attempt the connection
and allow configuration around how quickly that retries, how many retries
happen, etc.
{quote}
That wait time would have to be potentially endured every time the user wanted
(or had to) switch WiFi networks, changed client devices, experienced a network
hiccup, etc.
{quote}
Your point is absolutely valid, and it seems like in a future iteration of this
support we should definitely try to organize things such that guacd first
determines if the remote system is already online and available, tries to wake
it, waits a respectable (or configurable) amount of time, and then tries
again...lather, rinse, repeat.
> Wake on LAN integration
> -----------------------
>
> Key: GUACAMOLE-513
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-513
> Project: Guacamole
> Issue Type: New Feature
> Reporter: Matt Blecha
> Assignee: Nick Couchman
> Priority: Minor
> Fix For: 1.2.0
>
>
> I'm beating this horse back to life from the old issue tracker as I do
> believe this is a rather important feature.
> I know it was stated a day or two ago in the old issue tracker that there was
> better justification necessary for this to be considered. Seeing as this
> appears to be supported by both Microsoft in their RD Gateway and in Citrix's
> gateway products since ~2014, there appears to be a fairly reasonable
> justification for such a feature already in the business community, as well
> as demand (seeing as Citrix made a fairly prominent announcement about it.)
>
> ===Begin TL;DR===
>
> We love Guacamole in terms of performance (even when most of our users opted
> to go the VNC route, despite having the RDP option made available to them),
> mobile device operation, ease of use and administration and the pure
> brain-dead simplicity of implementation and integration. (Thanks to the
> developer who wrote that installation script, we were zero to deployed and
> operating in less than 15 minutes, VM server spin-up included!)
> That being said, we may be forced to abandon the whole infrastructure on
> nearly 500 devices (and growing fast) in favor of a solution that is not as
> efficient, yet provides one feature that we dearly need.
> From my research (not as a coder, but serious DevOps experience) it's
> relatively trivial to craft and broadcast a magic packet in Java (A GitHub
> search yields several project with examples averaging about ~75 LOC,
> including sanity checking.) Adding in a sort of "timeout hold-off" should
> yield less than an additional 100 LOC, and user interface adjustments,
> probably another few dozen or so. (Semi-educated guess.) All that would be
> left then is to add an optional MAC address field to the proper table and
> connection form, maybe a checkbox to enable WOL.
> If WOL is simply too hard to code into Guacamole, then a more expansive set
> of classes in the connection API would go a long way towards being able to
> develop an extension. (From what I can see of the API docs, there appears to
> be one call that would allow us to start the WOL process, but there are
> several others necessary, for example; being able to hold off the connection
> timeout while the remote station completes waking up. We do, after all, want
> this to be a seamless process to the end user.)
>
> ===End TL;DR===
>
> It seems to me that there are several reasonable use cases for such a
> feature, even if it is an extension and not a core component, though it seems
> this would probably be easier to merge into core as it would work more
> elegantly with some database integration, which I did not see in the API
> docs. (Admittedly, might not have looked closely enough, and I don't really
> code Java, so I'm not sure what's in that section.)
> I do think this would go a long way in scoring a decent amount of points for
> this project. It seems like there are others out there who support such a
> feature, hacky as it may be in some products.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
