Re: how to get the xorg driver working

[McRoy, Jeffrey (GE Healthcare)]

Hi Thomas,

 

Below are some notes that might help you.

 

Regards,

Jeff

 

 

When the xorg branch of Guac is built the resulting libraries typically go to 
/usr/lib64/xorg/modules/, but this could vary by OS/xorg installation.

- (as the root user) chmod 755 /usr/lib64/xorg/modules/drivers/guac_drv*

- (as the root user) ldconfig

 

The xorg.conf file typically goes in /etc/X11/xorg.conf.d/, but this could vary 
by OS/xorg installation.

 

- Set the access permissions for the config file: chmod 644 xorg.conf

 

To allow external connections:

- Edit /usr/bin/startx script to listenarg="-listen tcp" instead of 
listenarg="-nolisten tcp"

 

The X server also uses a host-based access control list for deciding whether or

not to accept connections from clients on a particular machine. If no other

authorization mechanism is being used, this list initially consists of the host

on which the server is running as well as any machines listed in the file

/etc/Xn.hosts, where n is the display number of the server. Each line of the

file should contain either an IP Address, Internet hostname (e.g. 
expo.lcs.mit.edu) or a

DECnet hostname in double colon format (e.g. hydra::) or a complete name in the

format family:name as described in the xhost(1) manual page. There should be no

leading or trailing spaces on any lines. For example:

 

192.168.1.1

joesworkstation

corporate.company.com

star::

inet:bigcpu

local:

 

 

Determine if xauth is being used.

Procedure:

# xauth

xauth> list

 

If the above command sequence does not show any host other than the localhost, 
than xauth is not being used.

Search the system for an X*.hosts file, where "*" is a display number used to 
limit X window connections.

If no files are found, X*.hosts files are not being used. If the X*.hosts files 
contain any unauthorized hosts, this is a finding.

If both xauth and X*.hosts files are not being used, this is a finding.

 

 

To turn off xauth

- Edit /usr/bin/startx script to enable_xauth=0 instead of enable_xauth=1

 

 

To start the X Server without an X application using display 1:

startx -- :1 -ac -config /etc/X11/xorg.conf.d/xorg.conf &

(-ac shuts off access control for this instance)

 

To start the X Server with an X application usong display 1:

startx /path/to/application -- :1 -ac -config 
/etc/X11/xorg.conf.d/xorg.conf.guac

 

To start the X Server with LXDE lightweight desktop using display 0 (if 
installed):

startx /usr/bin/startlxde -display :0 -- :0 -ac -config 
/etc/X11/xorg.conf.d/xorg.conf &

 

startx must be run from the console, not from within an X session.

 

startx needs an absolute path to the program.

 

Everything before '--' is executed as a command after the server is running. 
Everything after '--' gets passed to the server.

':1' is the display name. It must be unique (default is ':0').

startx (or more accurately, the X server), searches /etc/X11/ for the file you 
specify with the -config option. For more details, run man Xorg.

 

 

How to debug X problems (Fedora)

https://fedoraproject.org/wiki/How_to_debug_Xorg_problems

 

 

 

From: Tom Astle 
Reply-To: "user@guacamole.apache.org" 
Date: Monday, March 12, 2018 at 3:45 PM
To: " user@guacamole.apache.org" 
Subject: EXT: how to get the xorg driver working

 

I recompiled Mike Jumper’s xorg branch and installed it on my CentOS 7 server

 

I placed the xorg.conf file where it typically would land, but I’m not sure how 
one starts the Xserver so that it uses the guac xorg.conf?

 

Any ideas would be most appreciated.

 


​​Thomas Astle 
System Administrator 
Red Hat Certified System Administrator 
Phone: (800)722-1082

 



smime.p7s
Description: S/MIME cryptographic signature

how to get the xorg driver working

[Tom Astle]

I recompiled Mike Jumper’s xorg branch and installed it on my CentOS 7 server

I placed the xorg.conf file where it typically would land, but I’m not sure how 
one starts the Xserver so that it uses the guac xorg.conf?

Any ideas would be most appreciated.


​​Thomas Astle 
System Administrator 
Red Hat Certified System Administrator 
Phone: (800)722-1082

Re: Getting ERROR : Network too slow

[Nick Couchman]

On Mon, Mar 12, 2018 at 4:45 AM, Amarjeet Singh 
wrote:

> Thanks Mike. I appreciate that.
>
> I can't speak to why your RDP server is not responding within the ~15
>> seconds that Guacamole waits for connections to be established. If the
>> server was just started, it likely simply isn't ready to accept RDP
>> connections at the time the attempt was made.
>
>
> How can we make sure that RDP server isn't ready to accept RDP connections
> ?
>
> This is not only happening if server was just started but if user connects
> once and again try to reconnect after an hour ( any time ...)
>

You're going to need to dig in and do some analysis and debugging.  If I
were trying to track down the issue, I would look at the following things:

- Make sure you're using the "released" Guacamole version, or, at the very
least, a clean copy from the Git repos.  Since this issue you're
encountering is not being widely reporting by other users of Guacamole,
it's probably something in your environment causing it - perhaps triggering
a bug in guacd, but, more likely, some other factor between guacd and the
RDP host.  I know you've made a handful of changes to the Guacamole code
for you environment - eliminate those changes as the cause of the problem
by using the same code that other people are using.

- Examine the network between guacd and the RDP hosts.  Is it physically
adjacent/close to the hosts (same building, data center, rack, etc.), is it
remote, what are the characteristics of the link between guacd and the RDP
servers, what is the load on that link (or those links, if multiple ones
are involved), etc.?  Do not assume anything about these links - test them
thoroughly for bandwidth/throughput and latency, monitor them during
connections, etc.  There are many, many tools available for this, and many
free ones, at that, so find the tools for testing and monitoring network
performance and use them.

- On both the guacd host and the RDP host, make sure that resources are
adequate such that the system is not experiencing problems getting CPU time
or memory for the necessary processes.  If load on either the guacd host or
the RDP host, or both, causes too much slowness, this could result in the
error you're seeing.  Again, do not assume that they are okay - use at
least the standard monitoring tools and record or watch performance of all
of the various resources during the problem and make sure that the process
or system is not contending for resources.

- Using tcpdump, watch the traffic between the system running guacd and the
RDP host you're trying to attach to.  Look for any signs of network
problems - invalid TCP checksums, TCP retransmissions, duplicate packets
(indicating the same IP assigned to multiple hosts, or a network loop or
routing issue), etc.  If you see network issues, try to determine the
source and cause of the issue, and eliminate one thing at a time.  Fix an
issue, then test, again.

- Simplify the environment and test, and gradually build up.  Start with a
single client, single Guacamole instance, and single RDP server.  If you
experience problems in the simplest of environments, troubleshoot the
environment - do not assume that guacd is broken, use standard techniques
to figure out where the problem is.  Once you've verified the simple
environment works, build up from there, growing and changing things until
you encounter the problem, again, and then back up and undo the last change.

-Nick