noVNC failed to connect to server

Get Help
1

Hello,

Sorry, this is my 3rd question in 24 hours, but here goes…

I am having trouble getting noVNC to connect to my interactive desktop session. When I look at the node running the job, Websockify and TurboVNC are both running, and I have links to the interactive session in the OOD portal. However, when I open the “Launch Desktop” link, noVNC gives me the error “Failed to connect to the server.”

If I look in the Chrome dev tools, I see the following error:

app.v1.js:9501 WebSocket connection to 'wss://ondemand.ccast.ndsu.edu/rnode/node0073.thunder.ccast/17053/websockify' failed: Error during WebSocket handshake: Unexpected response code: 302
open @ app.v1.js:9501
_connect @ app.v1.js:6641
_updateConnectionState @ app.v1.js:6879

I see some other posts about Websockets here and here, but in one of those cases, you mentioned WS might be a “red herring.”

I also saw this post, so I double checked my node regex, and that appears to be showing up correctly in the noVNC link. I also made sure that I can SSH from the OOD node to the node where the desktop is running using this same domain name, and that all works.

Can you suggest some troubleshooting steps so that I can pinpoint the error? I tried looking in the httpd24 logs and the ondemand-nginx/$USER logs and didn’t see anything obvious; but I don’t know exactly what I should be looking for.

Any help would be much appreciated.

Thanks,
Nick

2

Hi! No need to be sorry at all! Especially with the info given.

302 is a redirect from apache, so it’s likely redirecting you to authenticate (it does that for us using open id connect). Do you use CAS by any chance? If you are you may need to change your CASSCope in apache.

It should see you as already authenticated, but it doesn’t. What’s happening is you’re going to create the websock upgrade, but before you can, apache sees you’re not authenticated - for whatever reason, and so doesn’t care and redirects you to do so. The red herring in the other thread was websockify, which is installed on your compute node for VNC (as you need it) but that user was using the shell app which doesn’t rely on it.

1 Like
3

Yes! We are using CAS. From the mod_auth_cas documentation, I see the following:

Directive:	CASScope
Default:	Off
Description:	Use this directive with an argument as a relative path (e.g. /application/) to specify
		the scope for which a mod_auth_cas cookie is valid.  This is beneficial to prevent
		additional round trips to the CAS server.  Assume someone authenticates to /application/subdir/
		and then browses to /application/ - without CASScope set, each request would result in
		a round trip to the CAS server and a new cookie being created (one for each directory).
		CASScope would set one cookie, which will be presented on access to both directories.
		Note that if someone accessed /application/ and then /application/subdir/ this would not
		be an issue, but that order of access can not be guaranteed.  To disable this feature,
		the special argument 'Off' will return to per-directory cookie paths for this directory
		and subdirectories.

So should I set the relative path to /pun/sys/dashboard or how would you recommend handling this?

Thanks!
Nick

4

Yea so I think it’s got to be /. I don’t know if you can do multiple entires, but if you could there would be at least /pun, /node and /rnode.

5

Awesome, setting CASScope / fixed the problem.

Thanks so much!

Nick

1 Like