EnableScreenLock not working fully on Linux

[jayltee]

Appreciate any help on this one as it’s driving me crazy.

Server O/S = Leap42.1 (kernel 4.1.31-30) and NX v5.1.54.
All hosts below are in the same subnet.

I have been using the free NX version for some time but recently updated my Linux distribution from OpenSuse 13.1 to Leap 42.1.  I look after several hosts in an office environment and for security reasons we utilise the screen blanking option “EnableScreenLock” in the server.cfg file.  This has been fine with OpenSuse 13.1 and the screen is disabled when remotely taking over the physical desktop.  But this is not so with Leap 42.1 in certain scenarios.

Let’s take “host-A” as our server and I am logged in as JOE( it’s an XFCE window manager session).

From “host-B” (which is the exact same Leap 42.1 level) I remotely connect to “host-A” as user JOE – regardless of whether the screen is in power save mode, locked but splash screen is visible or whether it is unlocked, the screen is unlocked for anyone to see and control mouse/keyboard.

If I connect as JOE from “host-C” which is Windows7 running NX v5.x.x (tried various versions) the screen IS blanked as expected.

If I connect as JOE from “host-D” which is OpenSuse 13.1 running NX v5.0.63 and kernel 3.16.7-35 the screen IS blanked as expected.

If I connect as JOE from “host-E” which is a MAC laptop running NX v5.1.54 the screen IS NOT blanked (so the same as Leap 42.1).

If I connect as JOE from “host-F” which is an Ubuntu 16.04 laptop the screen IS NOT blanked.

If I do the reverse and connect as JOE from the “host-A” (Leap42) to “host-D” (opensuse 13.1) where JOE is logged in already – the screen blanks.

So it seems that the Leap 42.1 install can be locked but it depends on the client.  I have looked a the config of the two flavours of Linux and cannot find anything amiss.  I have tried uninstall, reboot, reinstall of NX and no change.  The only thing I can see in the logs is that I only get the disabling message and not the enabling message as well on the problem connections (I’ve removed the ipaddresses):

2016-10-06 11:36:28 579.667 31790 NXSERVER User ‘JOE’ logged in from ‘x.x.x.x’ using authentication method password.
2016-10-06 11:36:29 149.085 31579 NXNODE   Enabling ScreenLock by nxagent.
2016-10-06 11:38:38 582.708 31976 NXNODE   Disabling ScreenLock by nxagent.
2016-10-06 11:38:38 583.252 31790 NXSERVER User ‘JOE’ from ‘x.x.x.x’ logged out.
2016-10-06 13:31:06 009.402 10007 NXSERVER User ‘JOE’ logged in from ‘y.y.y.y’ using authentication method password.
2016-10-06 13:32:18 827.546 10198 NXNODE   Disabling ScreenLock by nxagent.
2016-10-06 13:32:18 827.920 10007 NXSERVER User ‘JOE’ from ‘y.y.y.y’ logged out.

Any hints or pointers appreciated.  Also if there’s any specific data that will help identify the issue can be provided.

Thanks in advance.
JT

[bucu]

Hi,

we tried to reproduce your scenario in our labs, but with no luck. To investigate further we would need logs from server and client side. Please follow instructions about collecting logs from https://www.nomachine.com/DT04M00076. After editing server.cfg and node.cfg please restart nxserver on the server side, reproduce, gather logs and send them to forum[at]nomachine[dot]com.

• This reply was modified 8 years, 2 months ago by bucu.
• This reply was modified 8 years, 2 months ago by bucu.

[jayltee]

I did not receive an email notification that you had accepted/updated this item so apologies for the delay.

After I had raised this post I did some more tests as I wondered if the XFCE window manager was part of the issue.  Here’s what I found:
NB. Server is always Leap42 and user is logged in. If session is password locked, when NX connected you need to put UNIX password in to access session.

Windows-> KDE window manager & user session is password locked -> Screen is blanked (Good!)
Windows-> KDE & user session is unlocked -> Screen is blanked (Good!)
Windows -> XFCE window manager & user session is password locked -> After using UNIX passwd, screen is open to everyone (Bad!)
Windows -> XFCE & user session is unlocked -> Screen is blanked (Good!)

Mac -> KDE (did not have a machine available to test at this time)
Mac -> XFCE & user session is password locked -> After using UNIX passwd, screen is open to everyone (Bad!)
Mac -> XFCE & user session is unlocked -> Screen is blanked (Good!)

Leap42 -> KDE & user session is password locked -> After using UNIX passwd, screen is open to everyone (Bad!)
Leap42 -> KDE & user session is unlocked -> Screen is open to everyone (Bad!)
Leap42 -> XFCE & user session is password locked -> After using UNIX passwd, screen is open to everyone (Bad!)
Leap42 -> XFCE & user session is unlocked -> Screen is open to everyone (Bad!)

Opensuse 13.1 -> KDE & user session is password locked -> Screen is blanked (Good!)
Opensuse 13.1 -> KDE & user session is unlocked -> Screen is blanked (Good!)
Opensuse 13.1 -> XFCE & user session is password locked -> After using UNIX passwd, screen is open to everyone (Bad!)
Opensuse 13.1 -> XFCE & user session is unlocked -> Screen is blanked (Good!)

I will look to gather the logs as you ask shortly.

Thanks, JT

[jayltee]

Logs have been emailed.

[bucu]

Unfortunately the logs you have sent us indicate that you were connecting to local host (same machine used as server and client) and in that case blanking would not work by default. However we have found some problems with switching users on Leap42 that could affect blanking, although it is not related to desktop manager. We would like to ask you two things:

1. Could you please confirm that the logs you have sent us are from the reproduced issue?

2. Would you be willing to test a package with a possible fix?

Regards.

[jayltee]

I can confirm I connected from machine A to machine B which are physically separate for the test logs you have. Can you not see that from the ipaddresses in the logs?  I just looked in the nxserver.log I provided and can see the server address (which ends in .158) and the client (which ends in .81).

I do use the same system image for both machines (ie. dump machine A and restore to machine B) but I have done this forever and it was not an issue with opensuse 13.1.

I am willing to test a fix package.  Either tell me where to pick it up from or send it via email to my registered address (which by the way is not getting any notifications for this thread so I am having to refresh the webpage each day).

Cheers.

[Britgirl]

We’ve opened a TR since we’ve reproduced the problem. Sign up to be notified when a fix has been released. https://www.nomachine.com/TR10N07299

[jayltee]

As you have reproduced it, may I have a test version to confirm the fix works?

[bucu]

Hi, sorry for the delay.

You mentioned you are using system images on different machines. We reproduced the issue in our labs and it seems to be caused by those system images. This is something that will affect blanking and unfortunately you will not be able to blank the server in that case. You would have to reinstall nomachine (assuming you have it installed on the system image that you use) on one side for it to start working properly.

Could you confirm that you are using !M free x64 version so that we can send you a possible fix for the blanking problem we have reproduced related to Leap42 and user switching?

• This reply was modified 8 years, 2 months ago by bucu.
• This reply was modified 8 years, 2 months ago by bucu.
• This reply was modified 8 years, 2 months ago by bucu.

[jayltee]

Sorry I have been on vacation.

I can confirm that I am using the free x86_64 version.

Just to explain a little more about  what I said before – I have been using NX since v3 on OpenSuse and have always taken an image from one machine (using the dump command) and then via a PXE boot I use the “restore” command so we have all identical installations in use.  Once the screen blanking support was added in NX v4 I have not had an issue whilst doing the dump/restore using OpenSuse 13.1 and I have done so on many occasions.  It is only since using Suse Leap 42.1 that I have hit this issue so if it is down to using the same image can you point me at a specific file or something that may be the cause?  Is it possible to “clean” a file so that I can continue to deploy my images in this manner?  It is not feasible to hand tend the reinstallation on each machine I deploy.

I am happy to test a fix if you supply a download location.

Thanks.

[jayltee]

On one machine I have just done ‘rpm -e nomachine_5.1.54_1’  followed by ‘rpm -ivh  /tmp/nomachine_5.1.54_1_x86_64.rpm’ plus a reboot.  The screen blanking does not work still – just in case you wondered.

I’ll wait for the test fixed version and try again.

[jayltee]

The test fix provided worked with Leap 42 and XFCE.  Great work.  Please advise on an approximate time frame for the official release.

Thanks.

[Britgirl]

Hi, thanks for letting us know.

It will be most likely be in the next release. I don’t have an ETA unfortunately, but you can sign up to receive a notification when it’s fixed: https://www.nomachine.com/TR10N07299.

[jayltee]

Hello again – unfortunately I did not test it fully and when I do my normal image deployment as mentioned before (dump of system A, restore on system B via PXE) the screenlock behaves as before the fix 🙁

I need to be able to deploy in this manner and it always worked on Opensuse 13.1 so please can you point me at a file or something that can be sanitised so the NX client and server do not think they are the same machine?

I can confirm that if I uninstall/reinstall the test package on one host then the screenlocking behaves as we had hoped between the two machines so it does smell of what you eluded to before regarding both machines believing they are the same.

Thanks in advance.

[mlyn]

If you have the same NoMachine installation (for example copy system image with installed NoMacine) on client and server side please reinstall one of them.

If you have a different installation on either, to investigate further we would need logs from server and client side. Please follow instructions about collecting logs from https://www.nomachine.com/DT04M00076. After editing server.cfg and node.cfg please restart nxserver on the server side, reproduce, gather logs and send them to forum[at]nomachine[dot]com.

[Author]

Posts