Re: EXT: Re: X11 Server protocol plugin

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: EXT: Re: X11 Server protocol plugin

McRoy, Jeffrey (GE Healthcare)
Thanks for the quick reply Mike. Is the experimental code for the X11 server protocol plugin available for others to work with?

Regards,
Jeff




From: Mike Jumper <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Wednesday, March 15, 2017 at 1:57 PM
To: "[hidden email]" <[hidden email]>
Subject: EXT: Re: X11 Server protocol plugin

On Mar 15, 2017 11:53 AM, "McRoy, Jeffrey (GE Healthcare)" <[hidden email]> wrote:
Hi Everyone,

Does anyone know if any work has been done towards a X11 Server plugin
protocol for Guac?

Yes:


- Mike


smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: EXT: Re: X11 Server protocol plugin

Mike Jumper
On Wed, Mar 15, 2017 at 3:09 PM, McRoy, Jeffrey (GE Healthcare) <[hidden email]> wrote:
Thanks for the quick reply Mike. Is the experimental code for the X11 server protocol plugin available for others to work with?


You can find it on the "xf86-video-guac" branches of my GitHub forks of incubator-guacamole-client and incubator-guacamole-server, though beware that those branches get rebased occasionally:



For guacamole-server, you'll need to specify an additional "--with-xorg-module-dir" option for configure to locate the path for X.Org drivers:

    $ ./configure --with-xorg-module-dir=/usr/lib64/xorg/modules/

Keep in mind the path to X.Org's modules will likely vary by distribution.

The implementation is not an X11 protocol plugin, but a driver for X.Org which essentially contains an implementation of guacd, adding Guacamole protocol support to X.Org directly. The changes to guacamole-client deal with adding support for multiple guacd instances, since connecting to an X.Org desktop in this manner requires specifying a different guacd hostname for each distinct X.Org connection.

You'll need to write an xorg.conf to configure the X.Org server to use the "guac" driver for display and input. There's an example provided in the source:


Be warned also that the RENDER extension is not yet implemented. As such, the example xorg.conf explicitly disables that extension. Some applications will not be happy with that, and others may pretend to be happy yet fail in interesting ways.

Testing is definitely welcome.

- Mike

Reply | Threaded
Open this post in threaded view
|

Re: EXT: Re: X11 Server protocol plugin

McRoy, Jeffrey (GE Healthcare)
Thank you Mike. There will definitely be testing including load testing.

Thanks again,
Jeff

From: Mike Jumper <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Friday, March 17, 2017 at 2:48 PM
To: "[hidden email]" <[hidden email]>
Subject: Re: EXT: Re: X11 Server protocol plugin

On Wed, Mar 15, 2017 at 3:09 PM, McRoy, Jeffrey (GE Healthcare) <[hidden email]> wrote:
Thanks for the quick reply Mike. Is the experimental code for the X11 server protocol plugin available for others to work with?


You can find it on the "xf86-video-guac" branches of my GitHub forks of incubator-guacamole-client and incubator-guacamole-server, though beware that those branches get rebased occasionally:



For guacamole-server, you'll need to specify an additional "--with-xorg-module-dir" option for configure to locate the path for X.Org drivers:

    $ ./configure --with-xorg-module-dir=/usr/lib64/xorg/modules/

Keep in mind the path to X.Org's modules will likely vary by distribution.

The implementation is not an X11 protocol plugin, but a driver for X.Org which essentially contains an implementation of guacd, adding Guacamole protocol support to X.Org directly. The changes to guacamole-client deal with adding support for multiple guacd instances, since connecting to an X.Org desktop in this manner requires specifying a different guacd hostname for each distinct X.Org connection.

You'll need to write an xorg.conf to configure the X.Org server to use the "guac" driver for display and input. There's an example provided in the source:


Be warned also that the RENDER extension is not yet implemented. As such, the example xorg.conf explicitly disables that extension. Some applications will not be happy with that, and others may pretend to be happy yet fail in interesting ways.

Testing is definitely welcome.

- Mike


smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: EXT: Re: X11 Server protocol plugin

McRoy, Jeffrey (GE Healthcare)
In reply to this post by Mike Jumper
Hi Mike,

There was no configure file in the zip so I ran autoconf to generate one. It thought the bellow errors. Looks like an issue with configure.ac. Any ideas?  I’m not really a C developer, so forgive me if this is a dead simple thing that I’m missing.

Regards,
Jeff

configure.ac:29: error: possibly undefined macro: AM_INIT_AUTOMAKE
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.ac:30: error: possibly undefined macro: AM_SILENT_RULES
configure.ac:39: error: possibly undefined macro: AC_DEFINE
configure.ac:47: error: possibly undefined macro: AC_PROG_LIBTOOL
configure.ac:156: error: possibly undefined macro: AM_CONDITIONAL
configure.ac:1013: error: possibly undefined macro: AM_COND_IF




From: Mike Jumper <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Friday, March 17, 2017 at 2:48 PM
To: "[hidden email]" <[hidden email]>
Subject: Re: EXT: Re: X11 Server protocol plugin

On Wed, Mar 15, 2017 at 3:09 PM, McRoy, Jeffrey (GE Healthcare) <[hidden email]> wrote:
Thanks for the quick reply Mike. Is the experimental code for the X11 server protocol plugin available for others to work with?


You can find it on the "xf86-video-guac" branches of my GitHub forks of incubator-guacamole-client and incubator-guacamole-server, though beware that those branches get rebased occasionally:



For guacamole-server, you'll need to specify an additional "--with-xorg-module-dir" option for configure to locate the path for X.Org drivers:

    $ ./configure --with-xorg-module-dir=/usr/lib64/xorg/modules/

Keep in mind the path to X.Org's modules will likely vary by distribution.

The implementation is not an X11 protocol plugin, but a driver for X.Org which essentially contains an implementation of guacd, adding Guacamole protocol support to X.Org directly. The changes to guacamole-client deal with adding support for multiple guacd instances, since connecting to an X.Org desktop in this manner requires specifying a different guacd hostname for each distinct X.Org connection.

You'll need to write an xorg.conf to configure the X.Org server to use the "guac" driver for display and input. There's an example provided in the source:


Be warned also that the RENDER extension is not yet implemented. As such, the example xorg.conf explicitly disables that extension. Some applications will not be happy with that, and others may pretend to be happy yet fail in interesting ways.

Testing is definitely welcome.

- Mike


smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: EXT: Re: X11 Server protocol plugin

Mike Jumper
On Wed, Mar 29, 2017 at 8:21 AM, McRoy, Jeffrey (GE Healthcare) <[hidden email]> wrote:
Hi Mike,

There was no configure file in the zip so I ran autoconf to generate one. It thought the bellow errors. ...

You need to run "autoreconf -fi", not autoconf.

See the documentation for building Guacamole from git:


Specifically:

>
> Source downloaded directly from git will not contain this
> configure script, as autogenerated code is not included in
> the project's repositories. If you downloaded the code from
> the project's git repositories directly, you will need to
> generate configure manually:
>
>     $ cd guacamole-server/
>     $ autoreconf -fi
>     $
>
> Doing this requires GNU Autotools to be installed.
>
> Source archives downloaded from the project website contain
> the configure script and all other necessary build files, and
> thus do not require GNU Autotools to be installed on the
> build machine.
>
- Mike

Reply | Threaded
Open this post in threaded view
|

Re: EXT: Re: X11 Server protocol plugin

McRoy, Jeffrey (GE Healthcare)
In reply to this post by Mike Jumper
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
guacd-port: 4822

# User authorization
lib-directory: /Tomcat-8.5.5/webapps/guacamole-0.9.12/WEB-INF/classes
auth-provider: net.sourceforge.guacamole.net.basic.BasicFileAuthenticationProvi$
basic-user-mapping: /Tomcat-8.5.5/webapps/guacamole-0.9.12/WEB-INF/classes/user-mapping.xml

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

Thanks & Regards,
Jeff




From: Mike Jumper <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Friday, March 17, 2017 at 2:48 PM
To: "[hidden email]" <[hidden email]>
Subject: Re: EXT: Re: X11 Server protocol plugin

On Wed, Mar 15, 2017 at 3:09 PM, McRoy, Jeffrey (GE Healthcare) <[hidden email]> wrote:
Thanks for the quick reply Mike. Is the experimental code for the X11 server protocol plugin available for others to work with?


You can find it on the "xf86-video-guac" branches of my GitHub forks of incubator-guacamole-client and incubator-guacamole-server, though beware that those branches get rebased occasionally:



For guacamole-server, you'll need to specify an additional "--with-xorg-module-dir" option for configure to locate the path for X.Org drivers:

    $ ./configure --with-xorg-module-dir=/usr/lib64/xorg/modules/

Keep in mind the path to X.Org's modules will likely vary by distribution.

The implementation is not an X11 protocol plugin, but a driver for X.Org which essentially contains an implementation of guacd, adding Guacamole protocol support to X.Org directly. The changes to guacamole-client deal with adding support for multiple guacd instances, since connecting to an X.Org desktop in this manner requires specifying a different guacd hostname for each distinct X.Org connection.

You'll need to write an xorg.conf to configure the X.Org server to use the "guac" driver for display and input. There's an example provided in the source:


Be warned also that the RENDER extension is not yet implemented. As such, the example xorg.conf explicitly disables that extension. Some applications will not be happy with that, and others may pretend to be happy yet fail in interesting ways.

Testing is definitely welcome.

- Mike


smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: EXT: Re: X11 Server protocol plugin

Mike Jumper
On Mon, Apr 3, 2017 at 9:44 AM, McRoy, Jeffrey (GE Healthcare)
<[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: EXT: Re: X11 Server protocol plugin

AGroth
This post has NOT been accepted by the mailing list yet.
I was wondering,

how well does this play with GPU accelerated applications (OpenGL, Qt/QML)?

If it doesn't, wouldn't a compatible Solution be more desirable?

To be fair my Knowledge on X.Org drivers is limited, and i don't know if there may or may not be interaction between multiple Drivers to allow utilization of already existing proprietary hardware drivers.