sorry for the spam - some maybe small progress The "AH01144: No protocol handler was valid for the URL /guacamole/websocket-tunnel/ (scheme 'ws'). " is somehow sorted now, not sure what i did in all fairness.
if i connect to guacamole now in chrome devtools i'll get: First on login screen: Failed to load resource: the server responded with a status of 403 () /guacamole/api/tokens:1 then once i'm actually connected to the remote machine: angular.js:12845 GET http://xxx.xxx.xxx.xxx/guacamole/api/session/tunnels/f52676db-1190-447e-aa0d-a718c4dcab39/activeConnection/connection/sharingProfiles?token=4AA6577C623C44BE742D4E1F9E9BB73A054C74D138885550A666CE444A9E6248 404 NOT_FOUND No readable active connection for tunnel. (anonymous) @ angular.js:14607 (anonymous) @ app.js?v=1.3.0:507 (anonymous) @ app.js?v=1.3.0:506 (anonymous) @ angular.js:17215 $digest @ angular.js:18330 $apply @ angular.js:18506 l @ angular.js:12590 t @ angular.js:12898 A.onload @ angular.js:12772 load (async) (anonymous) @ angular.js:12898 n @ angular.js:12567 (anonymous) @ angular.js:12231 (anonymous) @ angular.js:17215 $digest @ angular.js:18330 (anonymous) @ angular.js:18506 e @ angular.js:5391 (anonymous) @ angular.js:6642 setTimeout (async) k.defer @ angular.js:6642 $evalAsync @ angular.js:18506 (anonymous) @ angular.js:16593 h @ angular.js:17215 then @ angular.js:861 p @ angular.js:12231 f @ app.js?v=1.3.0:506 a.getProtocol @ app.js?v=1.3.0:630 h.onuuid @ app.js?v=1.3.0:429 setUUID @ app.js?v=1.3.0:129 g @ app.js?v=1.3.0:143 a.onstatechange @ app.js?v=1.3.0:143 setState @ app.js?v=1.3.0:129 c.onmessage @ app.js?v=1.3.0:142 Error logs still not giving me very much. Thank you, On Wed, Mar 31, 2021 at 8:55 PM Alexandre Almosni < alexandre.almo...@gmail.com> wrote: > Thank you Mike for the prompt response. > > Indeed I can see quite a bit of http traffic if I go to > localhost:8080/guacamole, but no warning in the tomcat logs (catalina). > Also I can see that upon connection there's a request to > guacamole/api/tokens but the server is responding with 403, though > everything seems to be working normally. > > I've browsed through logs a bit more - can't see anything else worrying > apart from maybe this (which seems unrelated?) in catalina.log: > > 31-Mar-2021 18:31:48.771 INFO [Thread-3] > org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler > ["http-nio-8080"] > 31-Mar-2021 18:31:49.029 INFO [Thread-3] > org.apache.catalina.core.StandardService.stopInternal Stopping service > [Catalina] > 31-Mar-2021 18:31:52.031 WARNING [Thread-3] > org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The > web application [guacamole] appears to have started a thread named > [com.google.inject.internal.util.$Finalizer] but has failed to stop it. > This is very likely to create a memory leak. Stack trace of thread: > java.base@11.0.10/java.lang.Object.wait(Native Method) > java.base@11.0.10 > /java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:155) > java.base@11.0.10 > /java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:176) > com.google.inject.internal.util.$Finalizer.run(Finalizer.java:114) > > Sounds like i'll be stuck with http for now - but performance is > acceptable, not much slower than ssh/vnc. Thanks again for a fantastic > project. > > On Wed, Mar 31, 2021 at 6:32 PM Mike Jumper <mike.jum...@glyptodon.com> > wrote: > >> On Wed, Mar 31, 2021 at 9:52 AM Alexandre Almosni < >> alexandre.almo...@gmail.com> wrote: >> >>> ... >>> AH01144: No protocol handler was valid for the URL >>> /guacamole/websocket-tunnel/ (scheme 'ws'). If you are using a DSO version >>> of mod_proxy, make sure the proxy submodules are included in the >>> configuration using LoadModule. >>> >> >> The error suggests that the relevant proxy module is not loaded, but as >> you note, it does look like the "proxy_wstunnel" module is installed and >> loaded. Perhaps the "apache2ctl" tool is reading a different set of >> configuration information than the running Apache service? >> >> Browsing the web I've also tried adding “/“ in various places, or adding >>> lines such as: >>> >>> RewriteEngine On >>> ProxyPreserveHost On >>> ProxyRequests Off >>> RewriteCond %{HTTP:Upgrade} =websocket [NC] >>> RewriteRule /(.*) ws://localhost:5000/$1 [P,L] >>> RewriteCond %{HTTP:Upgrade} !=websocket [NC] >>> RewriteRule /(.*) http://localhost:5000/$1 [P,L] >>> >> >> You do not need to add anything extra for this beyond that single >> WebSocket-specific "Location" section. >> >> but to no avail. I've also tried the Chrome websocket Test Client on the >>> server and can't connect to ws://localhost:8080/guacamole/websocket-tunnel. >>> I'm actually wondering what is that address pointing to - do I need to >>> change something in Tomcat? could it be something wrong with my guacamole >>> installation? >>> >> >> No, WebSocket is always enabled and there are no configuration options on >> the Guacamole side which would influence WebSocket. If there were any >> options, that wouldn not account for the error being logged by Apache, >> which appears to be failing well before any WebSocket requests are received >> by Tomcat. >> >> The reason that you cannot connect to websocket-tunnel directly using an >> arbitrary test client is likely all the other credentials and information >> required by Guacamole's websocket-tunnel. It's not just an arbitrary >> WebSocket endpoint that will accept any inbound connection. It expects the >> WebSocket subprotocol to be set to a specific value ("guacamole"), it >> expects a valid authentication token to be present, and it expects several >> additional parameters that describe client details (initial display size, >> supported audio encodings, etc.) as well as the desired Guacamole >> connection. >> >> If you connect directly to http://localhost:8080/guacamole/, log in as a >> Guacamole user, and select a connection, that should be a decent test of >> whether WebSocket works at all (there will be a warning logged by Guacamole >> in the Tomcat logs if you are not using WebSocket, and you will also see a >> lot of HTTP network traffic in Chrome dev tools from the HTTP variation of >> the tunnel), but it's very unlikely that this is an issue. That would >> require WebSocket to be fundamentally broken within Guacamole, and such a >> problem would certainly have been noticed. >> >> Michael Jumper >> CEO, Lead Developer >> Glyptodon Inc <https://enterprise.glyptodon.com/>. >> >
