fermulator

[fermulator]

Status doesn’t really make sense.

I was already running 6.0.X version, and the KB says:

https://www.nomachine.com/TR07P08710

TR07P08710
Added on: 2018-07-11
Last update: 2018-08-23
Affects: 6.0
Due to be solved in: 6.0

What target release is it going to be fixed it?

It says last updated today, but I do not see any differences.

[fermulator]

Indeed, my system has a newer version of this.

$ rpm -qa | grep krb5-workstation
krb5-workstation-1.15.2-9.fc27.x86_64

Come to think of it, it’s possible that it aligns with the system upgrade from Fedora26 -> Fedora27 (I think I noticed the problem much later post-upgrade, so the correlation did not come to mind).

That problem report linked seems quite light-weight. Is NoMachine planning to update it with more information + workaround + ETA for resolution?

[fermulator]

Finally able to retest today.

Yesterday was physically on site, performed various OS updates, rebooted, and confirmed that there is a physical session initiated from the physical keyboard. (used the system all day)

Today attempted to remote, and the UI connects, however:

1. never gives me the option to “create a display”

2. never shows that there is an “existing display” to connect to

Let it sit there for a few minutes, nothing. Checked the server logs and it was spewing all sorts of stuff in a loop. (sending logs via e-mail)

[fermulator]

Well this is awkward …

$ egrep -i “CreateDisplay|SessionLogLevel” /usr/NX/etc/server.cfg
SessionLogLevel 7
CreateDisplay 0
# When ‘CreateDisplay’ is enabled, specify the display owner and let
# When ‘CreateDisplay’ is enabled, specify the resolution of the new
CreateDisplay 1
#WebSessionLogLevel 6

How are there TWO entries in there …

I see first what looks to be the default section

#
# Enable or disable the automatic creation of an X11 display when no
# X servers are running on this host (e.g. headless machine) to let
# users connect to the desktop. This setting applies to NoMachine
# servers not supporting virtual desktops and permits to have one
# single display.
#
# 1: Enabled. NoMachine will create automatically the new display at
#    server startup. This setting has to be used in conjunction with
#    ‘DisplayOwner’ and ‘DisplayGeometry’.
#
# 0: Disabled. NoMachine will prompt the user for creating the new
#    display. This is the default.
#
CreateDisplay 0

and indeed, it’s set to zero

 

then immediately following …

#
# When ‘CreateDisplay’ is enabled, specify the display owner and let
# NoMachine create the new display without querying the user. If the
# server supports only one concurrent connection, the connecting user
# must be the display owner set in this key.
#
#DisplayOwner “”
DisplayOwner mcallaghan

#
# When ‘CreateDisplay’ is enabled, specify the resolution of the new
CreateDisplay 1
# desktop in the WxH format. Default is 800×600.
#
#DisplayGeometry 800×600
DisplayGeometry 800×600

—-

I do not recall having manually changed any of this, though it’s possible in some previous NoMachine debug session someone from support had me try that …. I will remove that and retest next week.

[fermulator]

(’tis been about 2 weeks since my last reply, any next steps or is there sufficient information now for NoMachine to work on a fix?)

[fermulator]

nx probably shouldn’t crash if it can’t utilize ‘su’ ;o

–> Of note, this system uses sssd for authentication. (the physical display we’re trying to connect to is initiated by a REMOTE user to MS active directory) , AND indeed, these remote users are ONLY allowed to run “sudo” and never “sudo su” or “su” for security audit reasons.

$ sudo ls > /dev/null
$ sudo su
This account is currently not available.

$ sudo su –
This account is currently not available.
$ su –

Password:
su: Authentication failure

(as you can see, user accounts are NOT allowed to become root for any reason)

—

What exactly is nx trying to switch user to/for?

—-

here’s some dump of information …

—-

pam.d/nx

$ cat /etc/pam.d/nx
# This is a default PAM configuration for NoMachine. It is based on
# system’s ‘su’ configuration and can be adjusted freely according
# to administrative needs on the system.

auth       include       su
account    include       su
password   include       su
session    include       su

$ cat /etc/pam.d/su
#%PAM-1.0
auth        sufficient    pam_rootok.so
# Uncomment the following line to implicitly trust users in the “wheel” group.
#auth        sufficient    pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the “wheel” group.
#auth        required    pam_wheel.so use_uid
auth        substack    system-auth
auth        include        postlogin
account        sufficient    pam_succeed_if.so uid = 0 use_uid quiet
account        include        system-auth
password    include        system-auth
session        include        system-auth
session        include        postlogin
session        optional    pam_xauth.so

there appear to be no nx:session entries in the audit logs .. (this is a CentOS based system fwiw, Fedora27, so “auth.log” isn’t a thing – that’s only on debian (+Ubuntu) systems

$ for audit_log in $(sudo ls /var/log/audit); do sudo zgrep -ei /var/log/audit/$audit_log | egrep “nx\:session”; done
$ for audit_log in $(sudo ls /var/log/audit); do sudo zgrep -ei /var/log/audit/$audit_log | egrep “nx:session”; done
natta

 

 

[fermulator]

also,

$ sudo ls -al /usr/NX/bin/nxexec
-r-sr-xr-x 1 root root 106944 Nov 27  2017 /usr/NX/bin/nxexec
$ /etc/NX/nxnode –version
NoMachine Node – Version 6.0.66

 

[fermulator]

Retried, extra logs/info. (logs send to email)

You’re right, after attempts to attach to the physical display, the nx pids die out. After logging out of the dumb virtual display, no pids are running:

BEFORE: (initial state)

[ ~]$ ps wauxxx | grep nxexec
root       871  0.0  0.0 145424   140 ?        S<   May21   0:00 /usr/NX/bin/nxexec –node –user USER –priority realtime –mode 0 –pid 21
[ ~]$ ps wauxxx | grep nxnode
USER+   894  0.0  0.1 1903060 38824 ?       S<l  May21   2:44 /usr/NX/bin/nxnode.bin

DURING FIRST ATTEMPT

$ ps wauxxx | grep nxexec
root      8072  0.0  0.0 145424  8028 ?        S<   09:12   0:00 /usr/NX/bin/nxexec –node –user USER –priority realtime –mode 0 –pid 25
root      9295  0.0  0.0 139164  8048 ?        S<   09:12   0:00 /usr/NX/bin/nxexec –node –user USER –priority realtime –mode 0 –pid 16 -H 5

$ ps wauxxx | grep nxnode
USER+  8098 22.3  0.7 3300988 193736 ?      S<l  09:12   0:09 /usr/NX/bin/nxnode.bin
USER+  9347  1.8  0.3 2261336 88748 ?       S<l  09:12   0:00 /usr/NX/bin/nxnode.bin -H 5

# THEN, after logging out of virtual, nothing 🙁

(no more nxexec nor nxnode active pids)

 

I saw these errors in error.log

Info: Handler started with pid 6970 on Mon Jun 18 09:11:33 2018.
Info: Handling connection from 192.168.130.4 port 41330 on Mon Jun 18 09:11:33 2018.
Info: Connection from 192.168.130.4 port 41330 closed on Mon Jun 18 09:11:38 2018.
Info: Handler with pid 6970 terminated on Mon Jun 18 09:11:38 2018.
Info: Handler started with pid 7920 on Mon Jun 18 09:12:36 2018.
Info: Handling connection from 192.168.130.4 port 41342 on Mon Jun 18 09:12:36 2018.
/bin/cp: cannot stat ‘/usr/NX/share/config/knotifyrc.esd’: No such file or directory
Info: Connection from 192.168.130.4 port 41342 closed on Mon Jun 18 09:12:51 2018.
Info: Handler with pid 7920 terminated on Mon Jun 18 09:12:51 2018.

 

 

[fermulator]

Sounds like NoMachine has some bugs to figure out 🙂

 

Just retried:

once again, couldn’t connect, based on your theory, ran restart service again

sudo /usr/NX/bin/nxserver –restart

then:

(see attached) it prompts to connect to existing session, kk YES — but then no desktop sessions 🙁

logs again sent to NoMachine forums

Attachments:

1. 

   nx_nm_connect_to_it_query.png
   

2. 

   nx_nm_no_available_sessions.png
   

[fermulator]

NOTE: i also tried to restart nxserver

$ sudo /usr/NX/bin/nxserver –restart
NX> 162 Disabled service: nxserver.
NX> 162 Disabled service: nxnode.
NX> 162 Disabled service: nxd.
NX> 161 Enabled service: nxserver.
NX> 161 Enabled service: nxnode.
NX> 161 Enabled service: nxd.

logs got further but still not connecting

[fermulator]

I was not aware of the Wayland new support w/ NoMachine as of 6.1.x. However, my system is not using Wayland ever, I disabled it at the beginning.

$ grep Wayland /etc/gdm/custom.conf
WaylandEnable=false

The system is running gnome-shell (gnome3), and GDM

$ rpm -qa | grep gnome-shell
gnome-shell-3.24.3-2.fc26.x86_64
$ rpm -qa | grep gdm
gdm-3.24.3-1.fc26.x86_64

Since this persistent issue, I recently (a few days ago) was physically at the workstation and performed a full system restart + physical login. Today attempted to remotely connect via NoMachine. The client still refuses to connect. This time in a different way … the client spins for minutes “Connecting to <host>…”.

Logs sent to forum[at]nomachine[dot]com.

[fermulator]

this is most likely a network accessibility issue

you should troubleshoot with things like:

• nslookup <host>
• ping <host>
• tracert(..) <host>

[fermulator]

(trying to re-upload what failed first post)

Attachments:

1. 1_nx_retry_sequence-1.zip
2. nx_virtual_physical_woes_nxserver.zip

[fermulator]

A bit of testing on a server with dual physical monitors:

*  connecting from a client with dual monitors, different resolution, the system DOES NOT fix the resolution

* connecting from a client with single monitor, different resolution, the system DOES fix the resolution

 

So it could be specific to dual monitor –> dual monitor?

[fermulator]

This is an issue. I can confirm that if GDM (login) or window session (i.e. gnome) crashes or is restarted, the display ID can change, and having NoMachine connect to the new one specifically is seemingly impossible, … when physical access is not possible at such a given moment, the user is forced to restart the entire system ;/

[Author]

Posts