Table of Contents
Guacamole can be deployed using Docker, removing the need to build guacamole-server from source or configure the web application manually. The Guacamole project provides officially-supported Docker images for both Guacamole and guacd which are kept up-to-date with each release.
A typical Docker deployment of Guacamole will involve three separate containers, linked together at creation time:
guacamole/guacd
Provides the guacd daemon, built from the released guacamole-server source with support for VNC, RDP, SSH, and telnet.
guacamole/guacamole
Provides the Guacamole web application running within Tomcat 8 with support for WebSocket. The configuration necessary to connect to guacd, MySQL, PostgreSQL, LDAP, etc. will be generated automatically when the image starts based on Docker links or environment variables.
mysql
orpostgresql
Provides the database that Guacamole will use for authentication and storage of connection configuration data.
This separation is important, as it facilitates upgrades and maintains proper separation of concerns. With the database separate from Guacamole and guacd, those containers can be freely destroyed and recreated at will. The only container which must persist data through upgrades is the database.
The guacd Docker image is built from the released guacamole-server source with support for VNC, RDP, SSH, and telnet. Common pitfalls like installing the required dependencies, installing fonts for SSH or telnet, and ensuring the FreeRDP plugins are installed to the correct location are all taken care of. It will simply just work.
When running the guacd image with the intent of linking to a Guacamole container, no ports need be exposed on the network. Access to these ports will be handled automatically by Docker during linking, and the Guacamole image will properly detect and configure the connection to guacd.
$
docker run --namesome-guacd
-d guacamole/guacd
When run in this manner, guacd will be listening on its default
port 4822, but this port will only be available to Docker containers that have been
explicitly linked to
.some-guacd
If you are not going to use the Guacamole image, you can still leverage the guacd image for ease of installation and maintenance. By exposing the guacd port, 4822, services external to Docker will be able to access guacd.
Important
Take great care when doing this - guacd is a passive proxy and does not perform any kind of authentication.
If you do not properly isolate guacd from untrusted parts of your network, malicious users may be able to use guacd as a jumping point to other systems.
$
docker run --namesome-guacd
-d -p 4822:4822 guacamole/guacd
guacd will now be listening on port 4822, and Docker will expose this port on the same server hosting Docker. Other services, such as an instance of Tomcat running outside of Docker, will be able to connect to guacd directly.
The Guacamole Docker image is built on top of a standard Tomcat 8 image and takes care of all configuration automatically. The configuration information required for guacd and the various authentication mechanisms are specified with environment variables or Docker links given when the container is created.
Important
If using PostgreSQL or MySQL for authentication, you will need to initialize the database manually. Guacamole will not automatically create its own tables, but SQL scripts are provided to do this.
Once the Guacamole image is running, Guacamole will be accessible at
http://
, where
HOSTNAME
:8080/guacamole/HOSTNAME
is the hostname or address of the machine
hosting Docker.
The Guacamole Docker image needs to be able to connect to guacd to establish remote desktop connections, just like any other Guacamole deployment. The connection information needed by Guacamole will be provided either via a Docker link or through environment variables.
If you will be using Docker to provide guacd, and you wish to use a Docker link to connect the Guacamole image to guacd, the connection details are implied by the Docker link:
$
docker run --namesome-guacamole
\ --linksome-guacd
:guacd \ ... -d -p 8080:8080 guacamole/guacamole
If you are not using Docker to provide guacd, you will need to provide the network connection information yourself using additional environment variables:
Variable | Description |
---|---|
GUACD_HOSTNAME |
The hostname of the guacd instance to use to establish remote desktop connections. This is required if you are not using Docker to provide guacd. |
GUACD_PORT |
The port that Guacamole should use when connecting to guacd. This environment variable is optional. If not provided, the standard guacd port of 4822 will be used. |
The GUACD_HOSTNAME
and, if necessary, GUACD_PORT
environment variables can thus be used in place of a Docker link if using a
Docker link is impossible or undesirable:
$
docker run --namesome-guacamole
\ -e GUACD_HOSTNAME=172.17.42.1
\ -e GUACD_PORT=4822
\ ... -d -p 8080:8080 guacamole/guacamole
A connection to guacd is not the only thing required for Guacamole to work; some authentication mechanism needs to be configured, as well. MySQL, PostgreSQL, and LDAP are supported for this, and are described in more detail in the sections below. If the required configuration options for at least one authentication mechanism are not provided, the Guacamole image will not be able to start up, and you will see an error.
To use Guacamole with the MySQL authentication backend, you will need either a
Docker container running the mysql
image, or network access
to a working installation of MySQL. The connection to MySQL can be specified using
either environment variables or a Docker link.
If your database is not already initialized with the Guacamole schema, you will need to do so prior to using Guacamole. A convenience script for generating the necessary SQL to do this is included in the Guacamole image.
To generate a SQL script which can be used to initialize a fresh MySQL database as documented in Chapter 6, Database authentication:
$
docker run --rm guacamole/guacamole /opt/guacamole/bin/initdb.sh --mysql >initdb.sql
Alternatively, you can use the SQL scripts included with the database authentication.
Once this script is generated, you must:
Create a database for Guacamole within MySQL, such as
guacamole_db
.Create a user for Guacamole within MySQL with access to this database, such as
.guacamole_user
Run the script on the newly-created database.
The process for doing this via the mysql utility included with MySQL is documented in Chapter 6, Database authentication.
If your MySQL database is provided by another Docker container, and you wish to use a Docker link to connect the Guacamole image to your database, the connection details are implied by the Docker link itself:
$
docker run --namesome-guacamole
\ --link some-guacd:guacd \ --linksome-mysql
:mysql \ ... -d -p 8080:8080 guacamole/guacamole
If you are not using Docker to provide your MySQL database, you will need to provide the network connection information yourself using additional environment variables:
Variable | Description |
---|---|
MYSQL_HOSTNAME |
The hostname of the database to use for Guacamole authentication. This is required if you are not using Docker to provide your MySQL database. |
MYSQL_PORT |
The port that Guacamole should use when connecting to MySQL. This environment variable is optional. If not provided, the standard MySQL port of 3306 will be used. |
The MYSQL_HOSTNAME
and, if necessary, MYSQL_PORT
environment variables can thus be used in place of a Docker link if using a
Docker link is impossible or undesirable:
$
docker run --namesome-guacamole
\ --link some-guacd:guacd \ -e MYSQL_HOSTNAME=172.17.42.1
\ ... -d -p 8080:8080 guacamole/guacamole
Note that a Docker link to guacd (the --link
some-guacd:guacd
option above) is not required any more than a
Docker link is required for MySQL. The connection information for
guacd can be specified using environment variables, as
described in the section called “Connecting Guacamole to guacd”.
Using MySQL for authentication requires additional configuration parameters specified via environment variables. These variables collectively describe how Guacamole will connect to MySQL:
Variable | Description |
---|---|
MYSQL_DATABASE |
The name of the database to use for Guacamole authentication. |
MYSQL_USER |
The user that Guacamole will use to connect to MySQL. |
MYSQL_PASSWORD |
The password that Guacamole will provide when connecting
to MySQL as |
If any required environment variables are omitted, you will receive an error message in the logs, and the image will stop. You will then need to recreate the container with the proper variables specified.
Additional optional environment variables may be used to override Guacamole's default behavior with respect to concurrent connection use by one or more users. Concurrent use of connections and connection groups can be limited to an overall maximum and/or a per-user maximum:
Variable | Description |
---|---|
MYSQL_ABSOLUTE_MAX_CONNECTIONS |
The absolute maximum number of concurrent connections to allow at any time, regardless of the Guacamole connection or user involved. If set to "0", this will be unlimited. Because this limit applies across all Guacamole connections, it cannot be overridden if set. By default, the absolute total number of concurrent connections is unlimited ("0"). |
MYSQL_DEFAULT_MAX_CONNECTIONS |
The maximum number of concurrent connections to allow to any one Guacamole connection. If set to "0", this will be unlimited. This can be overridden on a per-connection basis when editing a connection. By default, overall concurrent use of connections is unlimited ("0"). |
MYSQL_DEFAULT_MAX_GROUP_CONNECTIONS |
The maximum number of concurrent connections to allow to any one Guacamole connection group. If set to "0", this will be unlimited. This can be overridden on a per-group basis when editing a connection group. By default, overall concurrent use of connection groups is unlimited ("0"). |
MYSQL_DEFAULT_MAX_CONNECTIONS_PER_USER |
The maximum number of concurrent connections to allow a single user to maintain to any one Guacamole connection. If set to "0", this will be unlimited. This can be overridden on a per-connection basis when editing a connection. By default, per-user concurrent use of connections is unlimited ("0"). |
MYSQL_DEFAULT_MAX_GROUP_CONNECTIONS_PER_USER |
The maximum number of concurrent connections to allow a single user to maintain to any one Guacamole connection group. If set to "0", this will be unlimited. This can be overridden on a per-group basis when editing a connection group. By default, per-user concurrent use of connection groups is limited to one ("1"), to prevent a balancing connection group from being completely exhausted by one user alone. |
To use Guacamole with the PostgreSQL authentication backend, you will need either
a Docker container running the postgres
image, or network
access to a working installation of PostgreSQL. The connection to PostgreSQL can be
specified using either environment variables or a Docker link.
If your database is not already initialized with the Guacamole schema, you will need to do so prior to using Guacamole. A convenience script for generating the necessary SQL to do this is included in the Guacamole image.
To generate a SQL script which can be used to initialize a fresh PostgreSQL database as documented in Chapter 6, Database authentication:
$
docker run --rm guacamole/guacamole /opt/guacamole/bin/initdb.sh --postgres >initdb.sql
Alternatively, you can use the SQL scripts included with the database authentication.
Once this script is generated, you must:
Create a database for Guacamole within PostgreSQL, such as
guacamole_db
.Run the script on the newly-created database.
Create a user for Guacamole within PostgreSQL with access to the tables and sequences of this database, such as
.guacamole_user
The process for doing this via the psql and createdb utilities included with PostgreSQL is documented in Chapter 6, Database authentication.
If your PostgreSQL database is provided by another Docker container, and you wish to use a Docker link to connect the Guacamole image to your database, the connection details are implied by the Docker link itself:
$
docker run --namesome-guacamole
\ --link some-guacd:guacd \ --linksome-postgres
:postgres \ ... -d -p 8080:8080 guacamole/guacamole
If you are not using Docker to provide your PostgreSQL database, you will need to provide the network connection information yourself using additional environment variables:
Variable | Description |
---|---|
POSTGRES_HOSTNAME |
The hostname of the database to use for Guacamole authentication. This is required if you are not using Docker to provide your PostgreSQL database. |
POSTGRES_PORT |
The port that Guacamole should use when connecting to PostgreSQL. This environment variable is optional. If not provided, the standard PostgreSQL port of 5432 will be used. |
The POSTGRES_HOSTNAME
and, if necessary,
POSTGRES_PORT
environment variables can thus be used in place
of a Docker link if using a Docker link is impossible or undesirable:
$
docker run --namesome-guacamole
\ --link some-guacd:guacd \ -e POSTGRES_HOSTNAME=172.17.42.1
\ ... -d -p 8080:8080 guacamole/guacamole
Note that a Docker link to guacd (the --link
some-guacd:guacd
option above) is not required any more than a
Docker link is required for PostgreSQL. The connection information for
guacd can be specified using environment variables, as
described in the section called “Connecting Guacamole to guacd”.
Using PostgreSQL for authentication requires additional configuration parameters specified via environment variables. These variables collectively describe how Guacamole will connect to PostgreSQL:
Variable | Description |
---|---|
POSTGRES_DATABASE |
The name of the database to use for Guacamole authentication. |
POSTGRES_USER |
The user that Guacamole will use to connect to PostgreSQL. |
POSTGRES_PASSWORD |
The password that Guacamole will provide when connecting
to PostgreSQL as |
If any required environment variables are omitted, you will receive an error message in the logs, and the image will stop. You will then need to recreate the container with the proper variables specified.
Additional optional environment variables may be used to override Guacamole's default behavior with respect to concurrent connection use by one or more users. Concurrent use of connections and connection groups can be limited to an overall maximum and/or a per-user maximum:
Variable | Description |
---|---|
POSTGRES_ABSOLUTE_MAX_CONNECTIONS |
The absolute maximum number of concurrent connections to allow at any time, regardless of the Guacamole connection or user involved. If set to "0", this will be unlimited. Because this limit applies across all Guacamole connections, it cannot be overridden if set. By default, the absolute total number of concurrent connections is unlimited ("0"). |
POSTGRES_DEFAULT_MAX_CONNECTIONS |
The maximum number of concurrent connections to allow to any one Guacamole connection. If set to "0", this will be unlimited. This can be overridden on a per-connection basis when editing a connection. By default, overall concurrent use of connections is unlimited ("0"). |
POSTGRES_DEFAULT_MAX_GROUP_CONNECTIONS |
The maximum number of concurrent connections to allow to any one Guacamole connection group. If set to "0", this will be unlimited. This can be overridden on a per-group basis when editing a connection group. By default, overall concurrent use of connection groups is unlimited ("0"). |
POSTGRES_DEFAULT_MAX_CONNECTIONS_PER_USER |
The maximum number of concurrent connections to allow a single user to maintain to any one Guacamole connection. If set to "0", this will be unlimited. This can be overridden on a per-connection basis when editing a connection. By default, per-user concurrent use of connections is unlimited ("0"). |
POSTGRES_DEFAULT_MAX_GROUP_CONNECTIONS_PER_USER |
The maximum number of concurrent connections to allow a single user to maintain to any one Guacamole connection group. If set to "0", this will be unlimited. This can be overridden on a per-group basis when editing a connection group. By default, per-user concurrent use of connection groups is limited to one ("1"), to prevent a balancing connection group from being completely exhausted by one user alone. |
To use Guacamole with the LDAP authentication backend, you will need network access to an LDAP directory. Unlike MySQL and PostgreSQL, the Guacamole Docker image does support Docker links for LDAP; the connection information must be specified using environment variables:
Variable | Description |
---|---|
LDAP_HOSTNAME |
The hostname or IP address of your LDAP server. |
LDAP_PORT |
The port your LDAP server listens on. By default, this will be 389 for unencrypted LDAP or LDAP using STARTTLS, and 636 for LDAP over SSL (LDAPS). |
LDAP_ENCRYPTION_METHOD |
The encryption mechanism that Guacamole should use when communicating with your LDAP server. Legal values are "none" for unencrypted LDAP, "ssl" for LDAP over SSL/TLS (commonly known as LDAPS), or "starttls" for STARTTLS. If omitted, encryption will not be used. |
Only the LDAP_HOSTNAME
variable is required, but you may also need
to specify LDAP_PORT
or LDAP_ENCRYPTION_METHOD
if your
LDAP directory uses encryption or listens on a non-standard port:
$
docker run --namesome-guacamole
\ --link some-guacd:guacd \ -e LDAP_HOSTNAME=172.17.42.1
\ ... -d -p 8080:8080 guacamole/guacamole
Note that a Docker link to guacd (the --link
some-guacd:guacd
option above) is not required. Similar to LDAP, the
connection information for guacd can be specified using
environment variables, as described in the section called “Connecting Guacamole to guacd”.
Using LDAP for authentication requires additional configuration parameters specified via environment variables. These variables collectively describe how Guacamole will query your LDAP directory:
Variable | Description |
---|---|
LDAP_USER_BASE_DN |
The base of the DN for all Guacamole users. All Guacamole users that will be authenticating against LDAP must be descendents of this base DN. |
As with the other authentication mechanisms, if any required environment variables are omitted (including those required for connecting to the LDAP directory over the network), you will receive an error message in the logs, and the image will stop. You will then need to recreate the container with the proper variables specified.
Additional optional environment variables may be used to configure the details of your LDAP directory hierarchy, or to enable more flexible searching for user accounts:
Variable | Description |
---|---|
LDAP_GROUP_BASE_DN |
The base of the DN for all groups that may be referenced within Guacamole configurations using the standard seeAlso attribute. All groups which will be used to control access to Guacamole configurations must be descendents of this base DN. If this variable is omitted, the seeAlso attribute will have no effect on Guacamole configurations. |
LDAP_SEARCH_BIND_DN |
The DN (Distinguished Name) of the user to bind as when
authenticating users that are attempting to log in. If
specified, Guacamole will query the LDAP directory to
determine the DN of each user that logs in. If omitted, each
user's DN will be derived directly using the base DN
specified with |
LDAP_SEARCH_BIND_PASSWORD |
The password to provide to the LDAP server when binding as
|
LDAP_USERNAME_ATTRIBUTE |
The attribute or attributes which contain the username
within all Guacamole user objects in the LDAP directory.
Usually, and by default, this will simply be
"uid". If your LDAP directory
contains users whose usernames are dictated by different
attributes, multiple attributes can be specified here,
separated by commas, but beware: doing so requires
that a search DN be provided with
|
LDAP_CONFIG_BASE_DN |
The base of the DN for all Guacamole configurations. If omitted, the configurations of Guacamole connections will simply not be queried from the LDAP directory, and you will need to store them elsewhere, such as within a MySQL or PostgreSQL database. |
As documented in Chapter 7, LDAP authentication, Guacamole does support combining LDAP with a MySQL or PostgreSQL database, and this can be configured with the Guacamole Docker image, as well. Each of these authentication mechanisms is independently configurable using their respective environment variables, and by providing the required environment variables for multiple systems, Guacamole will automatically be configured to use each when the Docker image starts.
If you have your own or third-party extensions for Guacamole which are not
supported by the Guacamole Docker image, but are compatible with the version of
Guacamole within the image, you can still use them by providing a custom base
configuration using the GUACAMOLE_HOME
environment variable:
Variable | Description |
---|---|
GUACAMOLE_HOME |
The absolute path to the directory within the Docker container
to use as a template for the image's
automatically-generated |
You will still need to follow the steps required to create
the contents of GUACAMOLE_HOME
specific to your
extension (placing the extension itself within
,
adding any properties to GUACAMOLE_HOME
/extensions/guacamole.properties
, etc.), but the
rest of Guacamole's configuration will be handled automatically, overlaid on top of
a copy of the GUACAMOLE_HOME
you provide.
Because the Docker image's GUACAMOLE_HOME
environment variable must
point to a directory within the container, you will need to
expose your custom GUACAMOLE_HOME
to the container using the
-v
option of docker run. The container
directory chosen can then be referenced in the GUACAMOLE_HOME
environment variable, and the image will handle the rest automatically:
$
docker run --namesome-guacamole
\ ... -v/local/path
:/some-directory
\ -e GUACAMOLE_HOME=/some-directory
\ -d -p 8080:8080 guacamole/guacamole
Once the Guacamole image is running, Guacamole should be accessible at
http://
, where
HOSTNAME
:8080/guacamole/HOSTNAME
is the hostname or address of the machine
hosting Docker, and you should a login screen. If using MySQL
or PostgreSQL, the database initialization scripts will have created a default
administrative user called "guacadmin
" with the password
"guacadmin
". You should log in and change
your password immediately. If using LDAP, you should be able to log
in as any valid user within your LDAP directory.
If you cannot access Guacamole, or you do not see a login screen, check Docker's logs using the docker logs command to determine if something is wrong. Configuration parameters may have been given incorrectly, or the database may be improperly initialized:
$
docker logssome-guacamole