4

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 Cheers

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

Improve this question
0

7 Answers 7

Reset to default
5

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:

    [Service]
IPAddressAllow=10.10.0.0/16

  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.

Cheers

Improve this answer
0

I had a similar problem, I had upgraded from 17.10 to 18.04. While I could log in with a local user, the session didn't last all that long before restarting. I couldn't log in with my nis user without the gui restarting.

By switching the display manager to lightdm, I was able to work around the problem.

sudo apt install lightdm
sudo dpkg-reconfigure gdm3

Then select lightdm as your manager. Restart and I was able to log in with my nis user.

It doesn't solve the time it takes to log in, it does allow me to get at a gui though.

Improve this answer
0

I was facing the same problem in a lab I am configuring for my students. My stopgap solution was to use 17.10 clients. They work even if the server is 18.04.

But now, that I am back home, I have just found a very interesting comment on Arch Linux wiki. It call a attention for a change in systemd that took place on 10/2017. It really looks like this is the problem. They also suggest a solution which is based on "This can be done by creating a new .conf file within the /etc/systemd/system/systemd-logind.service.d/" which whitelists the NIS server. I'll only be able to try this on Monday when I am back to work (or I'll not resist and try by ssh). But if you have access to your system you could give it a try and report back.

Improve this answer
0

I tried Paulos tip, but there are various problems with the work around described when you follow the link.

The second solution I got working. They just have the path wrong for ubuntu, the file is here:

/lib/systemd/system/systemd-logind.service

I just commented out this line:

# IPAddressDeny=any

and after reboot it worked.

The first solution seems the best though, but I have found various problems with it and can't get the syntax quite right. To start with the name is wrong, that isn't a valid name, then it must be a symlink, not a real file. I got as far as creating

/lib/systemd/system/open_nis_interface.service

and filling it with:

[Service]
IPAddressAllow=10.0.0.0/16

then linking:

mkdir /etc/systemd/system/systemd-logind.service.wants/
ln -s /lib/systemd/system/open_nis_interface.service /etc/systemd/system/systemd-logind.service.wants/

I have the file loading, but my syntax is not quite right. systemd gives ok messages if you run:

dmesg | grep systemd

As I said, the second method of just overriding the system file works for me, perhaps someone can finish the first method which seems a better long term solution.

Tom

Improve this answer
2
  • ubuntu recently got updated and I had to do this again as it overwrote the file
    – atomcraft
    Aug 10, 2018 at 11:18
  • I just posted a new answer with a solution that survives an update of the systemd toolchain. Hope it helps!
    – Wiggles
    Aug 12, 2018 at 10:36
0

I can confirm that second solution Tom mentions now works perfectly for me as well ( Hadnt noticed the wrong path - thanks). Ive also tried the first solution, but again it does not appear to work for me. I also inadvertantly spotted /etc/systemd/system.conf file has a

IPAddressAllow= ( entry commented out )

I tried putting in my internal network entries ie (eg 10.0.0.0/16 ) but it doesnt appear to take affect. Im a systemd newbie ( coming from ubuntu 14.04 ). For now solution 2 is perfect and I can work around updates etc, but will take another look at option 1 as time permits, or someone may crack this. Thanks a million for help guys

Improve this answer
0

On Ubuntu 18.04 LTS you should be able to fix your issue just remove the line

IPAddressDeny=any

from /lib/systemd/system/systemd-logind.service

It doesn't seems to be you case, given what you described, but beware that you must have the home directory for the NIS user you're trying to connect, that user must have read/write permission for that directory, and that sometime it may take some time to connect to the NIS server.

Improve this answer
0

From a post in the systemd github issue that Wiggles mentioned in their answer, just install nscd and then reboot. That fixed it for me.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .