[
https://issues.apache.org/jira/browse/GUACAMOLE-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Meyer updated GUACAMOLE-1919:
-----------------------------------
Description:
The simple version of the idea is to be able to call an external script or
process before and after a connection is made in order to automate any number
of external systems in concert with the connection.
* An 'External Scripts' section in the connection editor
** 'Script Before' field to provide path to script/program
** 'Script After' field to provide path to script/program
** All script fields should have:
*** Numeric field to specify timeout for the script in seconds.
*** Checkbox to indicate if gauacmole should block until script returns /
timesout.
** + button to dynamically add multiple scripts called for both before / after
options - each script should have blocking/secure checkboxes. If multiple
scripts are configured it would be nice to run them in parallel if that's
possible.
* Metadata.
** For calling scripts the following details should be passed
*** Connection details including any expanded from placeholders
*** Include password value if option enabled.
** Option: Scripts could return string values to guacamole and display message
to connecting user.
* Function
** 'Before' scripts should be run after user clicks the connection link but
before guacd is called.
** 'After' scripts should be run once guacd returns on connection closure.
(When user is prompted for Home, Reconnect, Logout)
** Script runtime should be limited to a 'timeout' period to prevent runaway
scripts. If not defined by admin in connection then a default value should
exist that can be overridden system wide in guacamole.preferences.
** If blocking selected for script:
*** If script times out connection should fail.
*** If script returns false connection should fail.
*** Any failure condition should be displayed to the user.
** Ideally any script should be able to be used and the system would use the
#! to determine interpreter, however if this is not possible then allow for the
full interpreter path with parameter to location of script to call...
I see this as being a swiss army knife for many different integration options.
* Sending notifications to any messaging platform when users connect to notify
on connections opened / closed outside of the system being connected to.
* Script could send approval request to system owner via Ntfy, Slack, Teams,
SMS etc. If owner accepts connection continues, if not the connection fails and
message from owner is displayed to requestor. (Requires calling script to be
able to return values to guac)
* DIY VDI to quickly spin up desktop containers or linked clone VMs on demand
using ANY container / virtualization environment.
* DIY VDI If using VM pools, could checkout a running VM from pool and
depending on pool remaining capacity spin up additional VM. Then on closing
connection evaluation on pool capacity could destroy / suspend / poweroff
endpoints.
* Create a new tunneled port through a bastion host / launch VPN tunnel / etc.
to reach a secured remote system.
* Allow connections only during specified days / time of day.
* VDI service provider - be able to limit customer to specific number of
connections - OR - even a resource limit of CPU/RAM/Disk and each VDI spawned /
closed dynamically allocates / releases capacity from their resource pool.
Anything you could script could be extended to, this could be quite powerful.
was:
The simple version of the idea is to be able to call an external script or
process before and after a connection is made in order to automate any number
of external systems in concert with the connection.
* An 'External Scripts' section in the connection editor
** 'Script Before' field to provide path to script/program
** 'Script After' field to provide path to script/program
** For Before fields:
*** A checkbox to enable/disable blocking the connection until script returns
*** A checkbox to enable/disable passing connection password to script
** For both Before/After: A numeric field for all scripts for a timeout value
of seconds to wait for response.
*** Scripts set to block would timeout to connection failure. (ideally a
message to user for cause of failure.
*** Non-blocking scripts would timeout and proceed with connection.
** Add a + button to dynamically add multiple scripts called for both before /
after options - each script should have blocking/secure checkboxes.
*** If multiple scripts are configured it would be nice to run them in
parallel if that's possible.
* Metadata.
** For calling scripts the following details should be passed
*** Connection details including any expanded from placeholders
*** Include password value if option enabled.
** Option: Scripts could return string values to guacamole and display message
to connecting user.
* Function
** 'Before' scripts should be run after user clicks the connection link but
before guacd is called.
*** Script runtime should be limited to a 'timeout' period. If not defined by
admin in connection then a default value should exist that can be overridden
system wide in guacamole.preferences.
*** If blocking selected for script:
**** If script times out connection should fail.
**** If script returns false connection should fail.
**** Any failure condition should be displayed to the user.
** 'After' scripts should be run once guacd returns on connection closure.
(When user is prompted for Home, Reconnect, Logout)
**
*
I see this as being a swiss army knife for many different integration options.
* Sending notifications to any messaging platform when users connect to notify
on connections opened / closed outside of the system being connected to.
* Script could send approval request to system owner via Ntfy, Slack, Teams,
SMS etc. If owner accepts connection continues, if not the connection fails and
message from owner is displayed to requestor. (Requires calling script to be
able to return values to guac)
* DIY VDI to quickly spin up desktop containers or linked clone VMs on demand
using ANY container / virtualization environment.
* DIY VDI If using VM pools, could checkout a running VM from pool and
depending on pool remaining capacity spin up additional VM. Then on closing
connection evaluation on pool capacity could destroy / suspend / poweroff
endpoints.
* Create a new tunneled port through a bastion host / launch VPN tunnel / etc.
to reach a secured remote system.
* Allow connections only during specified days / time of day.
* VDI service provider - be able to limit customer to specific number of
connections - OR - even a resource limit of CPU/RAM/Disk and each VDI spawned /
closed dynamically allocates / releases capacity from their resource pool.
Anything you could script could be extended to, this could be quite powerful.
> Add option to call external scripts before/after connections are passed to
> guacd.
> ---------------------------------------------------------------------------------
>
> Key: GUACAMOLE-1919
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1919
> Project: Guacamole
> Issue Type: Wish
> Components: guacamole
> Reporter: Aaron Meyer
> Priority: Minor
>
> The simple version of the idea is to be able to call an external script or
> process before and after a connection is made in order to automate any number
> of external systems in concert with the connection.
> * An 'External Scripts' section in the connection editor
> ** 'Script Before' field to provide path to script/program
> ** 'Script After' field to provide path to script/program
> ** All script fields should have:
> *** Numeric field to specify timeout for the script in seconds.
> *** Checkbox to indicate if gauacmole should block until script returns /
> timesout.
> ** + button to dynamically add multiple scripts called for both before /
> after options - each script should have blocking/secure checkboxes. If
> multiple scripts are configured it would be nice to run them in parallel if
> that's possible.
> * Metadata.
> ** For calling scripts the following details should be passed
> *** Connection details including any expanded from placeholders
> *** Include password value if option enabled.
> ** Option: Scripts could return string values to guacamole and display
> message to connecting user.
> * Function
> ** 'Before' scripts should be run after user clicks the connection link but
> before guacd is called.
> ** 'After' scripts should be run once guacd returns on connection closure.
> (When user is prompted for Home, Reconnect, Logout)
> ** Script runtime should be limited to a 'timeout' period to prevent runaway
> scripts. If not defined by admin in connection then a default value should
> exist that can be overridden system wide in guacamole.preferences.
> ** If blocking selected for script:
> *** If script times out connection should fail.
> *** If script returns false connection should fail.
> *** Any failure condition should be displayed to the user.
> ** Ideally any script should be able to be used and the system would use the
> #! to determine interpreter, however if this is not possible then allow for
> the full interpreter path with parameter to location of script to call...
> I see this as being a swiss army knife for many different integration options.
> * Sending notifications to any messaging platform when users connect to
> notify on connections opened / closed outside of the system being connected
> to.
> * Script could send approval request to system owner via Ntfy, Slack, Teams,
> SMS etc. If owner accepts connection continues, if not the connection fails
> and message from owner is displayed to requestor. (Requires calling script to
> be able to return values to guac)
> * DIY VDI to quickly spin up desktop containers or linked clone VMs on
> demand using ANY container / virtualization environment.
> * DIY VDI If using VM pools, could checkout a running VM from pool and
> depending on pool remaining capacity spin up additional VM. Then on closing
> connection evaluation on pool capacity could destroy / suspend / poweroff
> endpoints.
> * Create a new tunneled port through a bastion host / launch VPN tunnel /
> etc. to reach a secured remote system.
> * Allow connections only during specified days / time of day.
> * VDI service provider - be able to limit customer to specific number of
> connections - OR - even a resource limit of CPU/RAM/Disk and each VDI spawned
> / closed dynamically allocates / releases capacity from their resource pool.
> Anything you could script could be extended to, this could be quite powerful.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
