Forum Replies Created
-
AuthorPosts
-
fermulatorParticipant
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.0What target release is it going to be fixed it?
It says last updated today, but I do not see any differences.
fermulatorParticipantIndeed, my system has a newer version of this.
$ rpm -qa | grep krb5-workstation
krb5-workstation-1.15.2-9.fc27.x86_64Come 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?
fermulatorParticipantFinally 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)
fermulatorParticipantWell 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 6How 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 0and 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.
fermulatorParticipant(’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?)
fermulatorParticipantnx 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.sothere 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
nattafermulatorParticipantalso,
$ 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.66fermulatorParticipantRetried, 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.binDURING 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.fermulatorParticipantSounds 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:
fermulatorParticipantNOTE: 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
fermulatorParticipantI 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=falseThe 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_64Since 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.
fermulatorParticipantthis is most likely a network accessibility issue
you should troubleshoot with things like:
- nslookup <host>
- ping <host>
- tracert(..) <host>
fermulatorParticipant(trying to re-upload what failed first post)
fermulatorParticipantA 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?
fermulatorParticipantThis 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 ;/
-
AuthorPosts