Re: how to get the xorg driver working
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 AstleReply-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
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
On Mon, Mar 12, 2018 at 4:45 AM, Amarjeet Singhwrote: > 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