-
Notifications
You must be signed in to change notification settings - Fork 711
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GUACAMOLE-374: Generalize Docker image to automatically map environment variables to properties. #979
Conversation
I believe this rewrite maintains parity with the features of the existing image, except that fewer sanity checks are performed. This revised process instead relies on the webapp itself to appropriately log errors related to configuration. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple of initial comments while I work through the rest of the changes...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple more minor things, but looks pretty good otherwise.
@jmuehlner Anything from you on this one?
… "*_FILE" environment variables.
…r configuring RemoteIpValve.
…ted with each enum value for EnumGuacamoleProperty.
c16ef15
to
1b271a2
Compare
Nope, seems like a reasonable change. If you're good with it, so am I. |
This change strips away much of the manual mapping of environment variables to properties, instead relying on automatic mapping of properties using
enable-environment-properties
.*_FILE
environment variables are also automatically mapped.Additionally:
log-level
property that maps to theLOG_LEVEL
environment variable.REMOTE_IP_VALVE_*
environment variables have been renamed to align with the attributes being configured.GUACAMOLE_HOME
is now transient and randomly generated to allow users to use the familiar/etc/guacamole
location for their configuration template without potential collisions. Users can even use/etc/guacamole
directly without overridingGUACAMOLE_HOME
and rely on the image to combine what they've provided with anything the image has configured via environment variables.As of these changes, there are only two mappings that must be manually maintained (and then only when a new extension is introduced):
.jar
files. This is handled byguacamole-docker/build.d/010-map-guacamole-extensions.sh
..jar
files (ie: JDBC drivers). This is handled byguacamole-docker/build.d/020-download-drivers.sh
.Both of the above mappings/scripts organize things within a directory hierarchy that allows the entrypoint to easily link extensions, drivers, etc. into place based on which environment variables are set. Once the extensions are in place, everything else is implicit via
enable-environment-properties
.In cases where environment variables are changing names, compatibility with the old naming is maintained with
guacamole-docker/entrypoint.d/000-migrate-legacy-variables.sh
. Old variables are automatically migrated to the new ones and a warning regarding deprecation is logged.