[jira] [Commented] (GUACAMOLE-527) Add parameter for specifying known SSH/SFTP server fingerprint
[ https://issues.apache.org/jira/browse/GUACAMOLE-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16524213#comment-16524213 ] Nick Couchman commented on GUACAMOLE-527: - Manual PR submitted and waiting for review. > Add parameter for specifying known SSH/SFTP server fingerprint > -- > > Key: GUACAMOLE-527 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-527 > Project: Guacamole > Issue Type: New Feature > Components: Documentation, RDP, SSH, VNC >Reporter: Michael Jumper >Assignee: Nick Couchman >Priority: Major > Fix For: 1.0.0 > > > Guacamole's SSH support (used for both SSH terminal connections and SFTP) > currently does not provide a mechanism for verifying the identity of the SSH > server. In case Guacamole is used to access computers across untrusted > networks (or using hostnames queried from untrusted DNS), additional > parameters should be provided allowing the administrator to explicitly > specify the known key fingerprint of the SSH server. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-582) Manual still referneces Glyptodon JIRA
[ https://issues.apache.org/jira/browse/GUACAMOLE-582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman updated GUACAMOLE-582: Fix Version/s: 1.0.1 > Manual still referneces Glyptodon JIRA > -- > > Key: GUACAMOLE-582 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-582 > Project: Guacamole > Issue Type: Bug > Components: Documentation >Reporter: Nick Couchman >Assignee: Nick Couchman >Priority: Minor > Fix For: 1.0.1 > > > There's at least one reference currently to the Glyptodon.org JIRA instance. > I'm guessing this should probably be pointed at Apache, instead. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-582) Manual still referneces Glyptodon JIRA
[ https://issues.apache.org/jira/browse/GUACAMOLE-582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16524181#comment-16524181 ] Nick Couchman commented on GUACAMOLE-582: - Pull request submitted. > Manual still referneces Glyptodon JIRA > -- > > Key: GUACAMOLE-582 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-582 > Project: Guacamole > Issue Type: Bug > Components: Documentation >Reporter: Nick Couchman >Assignee: Nick Couchman >Priority: Minor > > There's at least one reference currently to the Glyptodon.org JIRA instance. > I'm guessing this should probably be pointed at Apache, instead. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GUACAMOLE-582) Manual still referneces Glyptodon JIRA
[ https://issues.apache.org/jira/browse/GUACAMOLE-582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman reassigned GUACAMOLE-582: --- Assignee: Nick Couchman > Manual still referneces Glyptodon JIRA > -- > > Key: GUACAMOLE-582 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-582 > Project: Guacamole > Issue Type: Bug > Components: Documentation >Reporter: Nick Couchman >Assignee: Nick Couchman >Priority: Minor > > There's at least one reference currently to the Glyptodon.org JIRA instance. > I'm guessing this should probably be pointed at Apache, instead. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GUACAMOLE-582) Manual still referneces Glyptodon JIRA
Nick Couchman created GUACAMOLE-582: --- Summary: Manual still referneces Glyptodon JIRA Key: GUACAMOLE-582 URL: https://issues.apache.org/jira/browse/GUACAMOLE-582 Project: Guacamole Issue Type: Bug Components: Documentation Reporter: Nick Couchman There's at least one reference currently to the Glyptodon.org JIRA instance. I'm guessing this should probably be pointed at Apache, instead. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-513) Wake on LAN integration
[ https://issues.apache.org/jira/browse/GUACAMOLE-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16523742#comment-16523742 ] M D Barber commented on GUACAMOLE-513: -- I haven't done any coding for twenty years, would love to if i can find a way to keep the wolves from the door to give me free time :) will try and get some friends who do involved. giving it a little thought it might be a simpler and maybe more flexible approach to have a wol button on the connections screen. > 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 >Priority: Minor > > 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 (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-513) Wake on LAN integration
[ https://issues.apache.org/jira/browse/GUACAMOLE-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16523737#comment-16523737 ] Nick Couchman commented on GUACAMOLE-513: - > In this day and age of eco conciousness surely this is top priority > especially if Guac is to be adopted by larger organisations who have to face > all sorts of energy saving compliance issues We would gladly welcome contributions to this effort. I've spent some time in the recent past working on it, but haven't had a lot of time to devote to it, and it isn't at the top of my priority list, in general or even as it relates to Guacamole. > 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 >Priority: Minor > > 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 (v7.6.3#76005)
[jira] [Comment Edited] (GUACAMOLE-513) Wake on LAN integration
[
https://issues.apache.org/jira/browse/GUACAMOLE-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16523737#comment-16523737
]
Nick Couchman edited comment on GUACAMOLE-513 at 6/26/18 1:43 PM:
--
{quote}
In this day and age of eco conciousness surely this is top priority especially
if Guac is to be adopted by larger organisations who have to face all sorts of
energy saving compliance issues
{quote}
We would gladly welcome contributions to this effort. I've spent some time in
the recent past working on it, but haven't had a lot of time to devote to it,
and it isn't at the top of my priority list, in general or even as it relates
to Guacamole.
was (Author: nick.couch...@yahoo.com):
> In this day and age of eco conciousness surely this is top priority
> especially if Guac is to be adopted by larger organisations who have to face
> all sorts of energy saving compliance issues
We would gladly welcome contributions to this effort. I've spent some time in
the recent past working on it, but haven't had a lot of time to devote to it,
and it isn't at the top of my priority list, in general or even as it relates
to Guacamole.
> 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
>Priority: Minor
>
> 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
(v7.6.3#76005)
