On Fri, Apr 28, 2017 at 10:42 PM, Suncatcher16 <[email protected]> wrote:
> Thanks for clarification. > My guacamole server and guacd are on the same server, so the firewall > issues > are excluded. > > In this case, I'm not referring to a firewall between the web application and guacd, but rather a firewall between the user's browser and the web application. > It seems my *guacd.conf* was missing. As I revealed, it should be placed in > /etc/guacamole. > "missing" isn't entirely correct. The guacd.conf file is optional, and only needed if you wish to override guacd's default configuration. Those same configuration options can also be specified on the command line when running guacd manually. I placed it and how can I be sure that guacd can ping the server correctly? > Is there any debugging tool? > The best debugging tool in this case would be a native RDP client. If you're unsure whether guacd can connect to the server in question, I would suggest trying to connect to that server using a native RDP client *from the same machine as guacd*. If the machine running guacd is headless, you can use an SSH tunnel to effectively test the connection in the same way. Testing using a native RDP client can also help iron out the connection parameters which you need to specify in your Guacamole connection. Alternatively, simply pinging the RDP server using "ping" from the same machine as guacd can be helpful, but that will only work if your RDP server, routers between guacd and the RDP server, etc. are not configured to ignore pings. As I understand syslog doesn't provide such info, or /user not responding/ > is the equivalent of /guacd cannot reach the server/? > "User is not responding" really means exactly what it says, but keep in mind that this message is logged from the perspective of guacd. It means that guacd has not received data from the user for long enough that it appeared the user was no longer present. Because a Guacamole connection involves several layers (browser <---> Tomcat <---> guacd ... or even browser <---> proxy <---> Tomcat <---> guacd), a breakdown in communication between any of those layers could result in this. To use a post office analogy, it's like if your mailbox logged a message saying "postman not delivering letters". You may simply have no mail, or maybe the mail truck crashed, or perhaps the roads were closed, or the postman quit his job, or ... etc. Absolutely any failure along the line from start to finish would result in the final point noting that nothing has been received. Each layer of the Guacamole stack has very separate concerns, and is only aware of its own little world within the overall deployment. - Mike
