[jira] [Assigned] (GUACAMOLE-464) Extension configuration properties from the OS environment

2018-02-04 Thread Nick Couchman (JIRA)

 [ 
https://issues.apache.org/jira/browse/GUACAMOLE-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nick Couchman reassigned GUACAMOLE-464:
---

Assignee: Carl Harris  (was: Nick Couchman)

> Extension configuration properties from the OS environment
> --
>
> Key: GUACAMOLE-464
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-464
> Project: Guacamole
>  Issue Type: New Feature
>  Components: Documentation, guacamole-client
>Reporter: Carl Harris
>Assignee: Carl Harris
>Priority: Major
> Fix For: 1.0.0
>
>
> In the start.sh script of the Docker container image for Guacamole, 
> environment variables are used to pass configuration properties to several 
> different authentication providers. The names of the environment variables 
> are derived from the names of the corresponding properties by converting all 
> letters to upper case and replacing all hyphens with underscores. It would he 
> helpful if this was generalized such that the configuration properties for 
> any extension module could be specified in the environment.
> As described in [The Twelve Factor App](https://12factor.net), the 
> environment should be the preferred way to inject deployment-specific 
> configuration. This is particularly helpful in the context of containers, but 
> in general is easier for operations personnel than application-specific 
> configuration files/formats/locations.
> Extension modules generally use an Environment instance to get configuration 
> property values. Through a relatively small modification of the 
> LocalEnvironment implementation, the System.getenv(String) method could be 
> used to first check for the configuration property in the environment (using 
> the name transformed as described above) and if not set in the environment, 
> then fallback to retrieving it from the Properties instance that was used to 
> load guacamole.properties.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (GUACAMOLE-464) Extension configuration properties from the OS environment

2018-02-04 Thread Nick Couchman (JIRA)

 [ 
https://issues.apache.org/jira/browse/GUACAMOLE-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nick Couchman reassigned GUACAMOLE-464:
---

Assignee: Nick Couchman  (was: Carl Harris)

> Extension configuration properties from the OS environment
> --
>
> Key: GUACAMOLE-464
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-464
> Project: Guacamole
>  Issue Type: New Feature
>  Components: Documentation, guacamole-client
>Reporter: Carl Harris
>Assignee: Nick Couchman
>Priority: Major
> Fix For: 1.0.0
>
>
> In the start.sh script of the Docker container image for Guacamole, 
> environment variables are used to pass configuration properties to several 
> different authentication providers. The names of the environment variables 
> are derived from the names of the corresponding properties by converting all 
> letters to upper case and replacing all hyphens with underscores. It would he 
> helpful if this was generalized such that the configuration properties for 
> any extension module could be specified in the environment.
> As described in [The Twelve Factor App](https://12factor.net), the 
> environment should be the preferred way to inject deployment-specific 
> configuration. This is particularly helpful in the context of containers, but 
> in general is easier for operations personnel than application-specific 
> configuration files/formats/locations.
> Extension modules generally use an Environment instance to get configuration 
> property values. Through a relatively small modification of the 
> LocalEnvironment implementation, the System.getenv(String) method could be 
> used to first check for the configuration property in the environment (using 
> the name transformed as described above) and if not set in the environment, 
> then fallback to retrieving it from the Properties instance that was used to 
> load guacamole.properties.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (GUACAMOLE-464) Extension configuration properties from the OS environment

2018-01-01 Thread Nick Couchman (JIRA)

 [ 
https://issues.apache.org/jira/browse/GUACAMOLE-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nick Couchman reassigned GUACAMOLE-464:
---

Assignee: Carl Harris

> Extension configuration properties from the OS environment
> --
>
> Key: GUACAMOLE-464
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-464
> Project: Guacamole
>  Issue Type: New Feature
>Reporter: Carl Harris
>Assignee: Carl Harris
>
> In the start.sh script of the Docker container image for Guacamole, 
> environment variables are used to pass configuration properties to several 
> different authentication providers. The names of the environment variables 
> are derived from the names of the corresponding properties by converting all 
> letters to upper case and replacing all hyphens with underscores. It would he 
> helpful if this was generalized such that the configuration properties for 
> any extension module could be specified in the environment.
> As described in [The Twelve Factor App](https://12factor.net), the 
> environment should be the preferred way to inject deployment-specific 
> configuration. This is particularly helpful in the context of containers, but 
> in general is easier for operations personnel than application-specific 
> configuration files/formats/locations.
> Extension modules generally use an Environment instance to get configuration 
> property values. Through a relatively small modification of the 
> LocalEnvironment implementation, the System.getenv(String) method could be 
> used to first check for the configuration property in the environment (using 
> the name transformed as described above) and if not set in the environment, 
> then fallback to retrieving it from the Properties instance that was used to 
> load guacamole.properties.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)