Forum Replies Created
I ended up reinstalling NoMachine Enterprise Server and now it successfully recognizes that KDE is indeed installed. Still have no idea what caused that though…
Thanks! That does seem to solve the issue when I install that .deb. However, I’d probably prefer to build that .deb myself. Is there a specific bug in nss_ldap that you could point me to so I can build something that includes the fix?
Also, do you know if nss-pam-ldapd works any better with NoMachine Enterprise? I already was considering changing all of my hosts to that library for LDAP anyway.
Just to follow up on that last post: through my own testing I can see that libnss-pam-ldapd is NOT affected by the same bug and works great. I’ll probably go the route of just switching everything over to libnss-pam-ldapd + nslcd.
So I have narrowed it down to LDAP being in nsswitch.conf. Once I remove the “ldap” entries, the /usr/NX/bin/nxd daemon starts up properly and virtual desktops are started successfully.
Is there something about having ldap in the nsswitch that is known to cause these failures with signal 13?
# Example configuration of GNU Name Service Switch functionality.
# If you have the
glibc-doc-reference' andinfo’ packages installed, try:
# `info libc “Name Service Switch”‘ for information about this file.
hosts: files dns
protocols: db files
services: db files
ethers: db files
rpc: db files
I am using LDAP, yes, but the nx user is not an LDAP account.
Relevant PAM section for LDAP:
auth [success=3 default=ignore] pam_krb5.so minimum_uid=1000
auth [success=2 default=ignore] pam_unix.so nullok_secure try_first_pass
auth [success=1 default=ignore] pam_ldap.so use_first_pass
auth requisite pam_deny.so
auth required pam_permit.so
When I run commands manually as the nx user with “su – nx -s /bin/bash” they all seem to succeed. I even did them with “su – nx -s /bin/bash -c ‘command'” and they worked.
Definitely no apparmor or selinux installed (only required, related packages for KDE and such):
root@myhost1:/usr/NX/var/log# dpkg -l |grep -iw apparmor
ii libapparmor-perl 2.8.95~2430-0ubuntu5.1 amd64 AppArmor library Perl bindings
ii libapparmor1:amd64 2.8.95~2430-0ubuntu5.1 amd64 changehat AppArmor library
ii python3-apparmor 2.8.95~2430-0ubuntu5.1 amd64 AppArmor Python3 utility library
ii python3-libapparmor 2.8.95~2430-0ubuntu5.1 amd64 AppArmor library Python3 bindings
root@myhost1:/usr/NX/var/log# dpkg -l |grep selin
ii libselinux1:amd64 2.2.2-1ubuntu0.1 amd64 SELinux runtime shared libraries
ii libselinux1-dev:amd64 2.2.2-1ubuntu0.1 amd64 SELinux development headers
System auth.log does not record any instance of denying execution of those commands, though yes, I can see that everything seems to fail in the same way. Is there any way for me to manually reproduce those commands in an interactive session? It seems difficult to do since the nx user’s shell is /etc/NX/nxserver:
Is nx trying to run these commands with sudo privileges? syslog is totally empty as well, so the nxserver.log and nxerror.log are all I have to go on at the moment. Any insight you can provide on how to manually test these commands that nx is trying to run would be helpful.