fermulator

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 24 total)
  • Author
    Posts
  • in reply to: NoMachine refuses to re-attach to physical session #19406
    fermulator
    Participant

    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.

    in reply to: NoMachine refuses to re-attach to physical session #19129
    fermulator
    Participant

    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?

    in reply to: NoMachine refuses to re-attach to physical session #18999
    fermulator
    Participant

    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)

    in reply to: NoMachine refuses to re-attach to physical session #18945
    fermulator
    Participant

    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.

    in reply to: NoMachine refuses to re-attach to physical session #18886
    fermulator
    Participant

    (’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?)

    in reply to: NoMachine refuses to re-attach to physical session #18799
    fermulator
    Participant

    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

     

     

    in reply to: NoMachine refuses to re-attach to physical session #18736
    fermulator
    Participant

    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

     

    in reply to: NoMachine refuses to re-attach to physical session #18735
    fermulator
    Participant

    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.

     

     

    in reply to: NoMachine refuses to re-attach to physical session #18441
    fermulator
    Participant

    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

    in reply to: NoMachine refuses to re-attach to physical session #18371
    fermulator
    Participant

    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

    in reply to: NoMachine refuses to re-attach to physical session #18370
    fermulator
    Participant

    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.

    in reply to: Error 113 no route to host #18278
    fermulator
    Participant

    this is most likely a network accessibility issue

    you should troubleshoot with things like:

    • nslookup <host>
    • ping <host>
    • tracert(..) <host>
    in reply to: NoMachine refuses to re-attach to physical session #18259
    fermulator
    Participant

    (trying to re-upload what failed first post)

    in reply to: Resolution does not change upon connecting #14469
    fermulator
    Participant

    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?

    in reply to: Specify which display to connect to #14429
    fermulator
    Participant

    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 ;/

Viewing 15 posts - 1 through 15 (of 24 total)