Ubuntu – Using NIS client in Ubuntu 18.04 crashes both Gnome and Unity


I run NIS clients in Ubuntu desktop in our student labs. As part of our summer project, I've installed Ubuntu 18.04 on one PC, and put NIS client on it. All seemed fine, domain is correct, ypwhich, ypcat and yptest all work successfully.

When I login however using an NIS account ( either with a local home or NFS home ) both GDM and LightDM (I tried both) hang, and eventually X crashes. Works fine with local account and home directory.

Error log only shows this message:

pam_systemd(sshd:session): failed to create session

If I try the same NIS login using just a terminal (Ctrl+Alt+F1) I can authenticate, however the session freezes for 25 seconds approx before giving me a bash shell, home directory whether it be local or NFS is mounted correctly
This worked for me fine in Ubuntu 16.04 eventually. (I had to add the following line to make systemd start rpc.bind: /bin/systemctl add-wants multi-user.target rpcbind.service.) I tried this with Ubuntu 18.04 without success. Looks like there is a delay between authentication and creating session which is causing this issue. I've downloaded and installed latest updates etc and the latest apt-get of his etc.

Thanks for the replies. I tried installing lightdm, and had a little success with logging on as an NIS user to X. However I found it to be inconsistent for me, sometimes logging into X, othertimes timing out, so not usable in a lab situation. I re-installed 16.04 again and that worked fine, so was going to leave it at that till 18.04 beds down a bit. After doing that Paulo I've just seen your reply ! I'll take a look at reinstalling 18.04 and get back

Tried Paulos tip as above. Unfortunately I could not map the same setup files on Ubuntu 18.04 ( ie couldnt find a /etc/systemd/system/systemd-login.service.d or /usr/lib/systemd/system/systemd-logind.service
Looking further I found a /etc/system/logind.conf. I tried putting in IPAddressAllow statement there ( there was no mention or no default there ) but it was not recognised. Also tried inserting my own .conf file in the same directory without success. It sounds very like the same symptoms, or it could well be my lack of knowledge here. I'll take another look again, but for the moment hope that Ubuntu might put out an update or patch shortly that would sort this issue

Best Answer

I was also affected by this and at first I also solved this problem by commenting out

IPAdressDeny=Any in /lib/systemd/system/systemd-logind.service

like many others here mentioned before.

However, besides being a security risk, this will only work until the next update of the systemd toolchain rolls out, as mentioned in the Arch-Wiki. What the wiki does not explain very well, is how to extend the configuration of the systemd-logind.service such that a certain address range is whitelisted and that these settings will survive an update. After some reading in the RHEL documentation (especially section 10.6.4: Modifying Existing Unit Files), the following solution worked for me:

  1. Create a new directory in /etc/systemd/system/ named exactly after the service you want to extend including a .d, here this would be: systemd-logind.service.d

  2. Create a new file choose_an_appropriate_name.conf (e.g. nis_open_network_interface.conf) inside the newly created directory with the following content, which specifies the IP or IP range you want to be allowed:

  3. Do a systemctl daemon-reload

  4. And check if the new configuration is actually part of your systemd-logind.service unit using systemctl cat systemd-logind.service
  5. Finally restart the service systemctl restart systemd-logind.service (This will kick you out of your running gnome session and you have to login again.)

There is no need to modify any other file! At this point you should be able to login with NIS-users again without getting a system freeze. Beware though, that this is still considered insecure (whitelisting IP addresses) and that the sandboxed behavior of systemd-logind is wanted. NIS/YP is kind of outdated but I still find it used ever so often. Also there may be a better solution to this involving a name caching daemon using nscd or sssd as mentioned in this systemd github issue dealing with the whole situation. But this is out of my scope at the moment.

This answer collects all the bits and pieces from previous posts and I hope clarifies a bit to give a good solution to the problem.


Related Question