I got the interactive desktop session working on OOD 2.0 on the xfce4 vnc session. But one problem I am running into, screensaver timeout, or the user might lock their screen. How to disable it since the vnc password doesn’t work once the screen is locked after timeout?
Any suggestions to disable the lock-screen option and timeout are appreciated.
The best practice here is to naviagate back to Open OnDemand → My Iterative Sessions → click to reconnect to the session. The desktop session will be there just as you left it.
Timeouts, though annoying, are good for all sorts of reasons. So I’d maybe avoid that route and instead just navigate back.
We usually allow users to run interactive desktop for a couple of hours. Some of our users have left their desktop session running and went away from the keyboard. Once they come back, XFCE has a screen lock and asks them for a password. If they close the window and try to reconnect as you mentioned then get an authentication error. (See my screenshots attached)
Ya, I think the screensaver issue would be resolved with that. And also just disabling that process on startup solves that as well.
Do you have any other suggestions for keeping the VNC session reconnectable? Since my users are unable to reconnect their VNC sessions similar to the thread I mentioned earlier.
Thanks for your feedback.
@bennet we are having issues with basically re-connecting the VNC session. At the reconnecting of the session, we get the error, Authentication failed as shown in the screenshot.
I think I narrowed out our problem. Basically, I looked at the connections.yml file for the password
and if I edit the VNC connection join hyperlink then I am able to connect it.
But for some reason Launch VNC session button link is not reflecting the new password from the interactive desktop card.
vnc.log for more info
18/11/2021 11:30:28 Got connection from client 127.0.0.1
18/11/2021 11:30:28 Using protocol version 3.8
18/11/2021 11:30:28 Enabling TightVNC protocol extensions
18/11/2021 11:30:28 Advertising Tight auth cap ‘VENCRYPT’
18/11/2021 11:30:28 Advertising Tight auth cap ‘VNCAUTH_’
18/11/2021 11:30:28 Advertising Tight auth cap ‘ULGNAUTH’
18/11/2021 11:30:28 rfbVncAuthProcessResponse: authentication failed from 127.0.0.1
18/11/2021 11:30:28 Client 127.0.0.1 gone
18/11/2021 11:30:28 Statistics:
Which VNC client/server are you using? I think it needs to be TurboVNC everywhere. Any chance that the server is falling back to a different VNC server?
First of it’s important to know that this password is a 1 time use password. As soon as you use it, we generate a new one and put it in the connection.yml. So this can happen as many times over the lifetime of the job.
Did you happen to set POLL_DELAY? If you have the right information in the connection.yml then it should get reflected in the card. The question then becomes - how often is the file read (determined by POLL_DELAY which I think is 30 seconds). And where did you read the connection.yml and observe that it had a new password. Perhaps theres a sync issue where the compute node updated the file but the web node (where OnDemand is deployed) is unable to see the updated file due to NFS latency.
I have not seen the setting for POLL_DELAY yet, where should I find that?
I basically went inside the ondemand session interactive destop creates. Then I copied the password generated by connection.yml then edit the hyperlink generated by VNC session and I was able to reconnect to my running VNC session.
However the problem is, upon refresh of the interactive desktop under my sessions card, join button is not getting that changed password, it still shows uses old password in hyperlink hence we get authentication error upon trying to reconnect VNC session.
Could that be a permissions issue? Would the update possibly change the permissions from those that were in effect when the file is first created? If so, then perhaps a group read permission is being removed, or an ownership change is (or is not) happening that should not (should)?