guacamole-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Jumper <mike.jum...@guac-dev.org>
Subject Re: EXT: Re: X11 Server protocol plugin
Date Mon, 03 Apr 2017 23:43:33 GMT
On Mon, Apr 3, 2017 at 9:44 AM, McRoy, Jeffrey (GE Healthcare)
<Jeffrey.McRoy@ge.com> wrote:
> Hi Mike,
>
> I was able to get the X11 versions of the Guac client and server to build
> and deploy. I assume the guacamole.properties file for the server would look
> something like this:
>
> # Hostname and port of guacamole proxy
> guacd-hostname: localhost

If the X.Org driver will be running on localhost relative to the
Guacamole web application, this is correct.

> guacd-port: 4822
>

The X.Org driver listens on port 4823.

> # User authorization
> lib-directory: /Tomcat-8.5.5/webapps/guacamole-0.9.12/WEB-INF/classes

I don't know why so many tutorials keep recommending this, but it is wrong.

The "lib-directory" property was deprecated back in 0.9.7. You would
have received a warning in the logs about the deprecation until
version 0.9.10-incubating when support for these properties was
removed entirely. The property no longer has any effect:

http://guacamole.incubator.apache.org/releases/0.9.10-incubating/#deprecation--compatibility-notes

Even back when it did have an effect, specifying WEB-INF/classes/ as
Guacamole's lib directory would have caused the .jar files to be
loaded by both Tomcat's classloader and Guacamole's classloader, with
Guacamole's classloader overriding the duplicate classes loaded by
Tomcat. I'm not sure whether this would cause issues in practice or
not, but tying the classloaders in a knot like that just doesn't make
sense. My best guess would be that someone got confused many years
ago, flailed around until things worked, and then documented
everything as-is without determining what fixed the issue, ultimately
preserving the "lib-directory: .../WEB-INF/classes" recommendation for
all eternity.

Please follow the manual instead:

http://guacamole.incubator.apache.org/doc/gug/installing-guacamole.html

http://guacamole.incubator.apache.org/doc/gug/configuring-guacamole.html

You will not find any reference to the deprecated properties in the links above.

> auth-provider:
> net.sourceforge.guacamole.net.basic.BasicFileAuthenticationProvi$

As with the "lib-directory" property, the "auth-provider" property was
deprecated back in 0.9.7. You would have received a warning in the
logs about the deprecation until version 0.9.10-incubating when
support for these properties was removed entirely. The property no
longer has any effect (see deprecation notes linked above).

> basic-user-mapping:
> /Tomcat-8.5.5/webapps/guacamole-0.9.12/WEB-INF/classes/user-mapping.xml

This will not hurt anything, but it doesn't make sense to store
Guacamole's configuration files within WEB-INF/classes/. They'll be
wiped out every time you redeploy. Please instead follow the
installation instructions in the manual. I would recommend using the
default location for configuration files (aka "GUACAMOLE_HOME), which
is the ".guacamole" directory within the home directory of the user
running the Tomcat service.

>
> Do you have an example of what the “user-mapping.xml” file would look like
> for testing the X11 functionality?
>

The connection definition would look like:

        <connection name="Some Arbitrary Name">
            <protocol>xorg</protocol>
        </connection>

Note the lack of parameters. The hostname/port in this case are
dictated by the guacd-hostname and guacd-port properties (because the
X.Org driver implements guacd). This is not the expected mechanism for
using the X.Org driver in production - support for multiple guacd
instances is being added to facilitate this:

https://issues.apache.org/jira/browse/GUACAMOLE-189

That support is present on the "xf86-video-guac" branch of
guacamole-client in the form of modifications to the database
authentication. If you're willing to set up the database auth using a
build from the "xf86-video-guac" branch, that would be more intuitive.

- Mike

Mime
View raw message