Использование NIS-клиента в Ubuntu 18.04 приводит к сбоям как Gnome, так и Unity
Я запускаю клиентов NIS на рабочем столе Ubuntu в наших студенческих лабораториях. В рамках нашего летнего проекта я установил Ubuntu 18.04 на одном ПК и поместил на него клиент NIS. Все было нормально, домен верен, ypwhich, ypcat и yptest все работают успешно.
Когда я вхожу в систему, используя учетную запись NIS (либо с локальным домом, либо с NFS-сервером), оба GDM и LightDM (я попробовал оба) повесить, и в конечном итоге X сработает. Работает нормально с локальной учетной записью и домашним каталогом.
В журнале ошибок отображается только это сообщение:
pam_systemd(sshd:session): failed to create session
Если я пытаюсь использовать тот же вход в NIS, используя только терминал (Ctrl + Alt + F1 ) Я могу пройти аутентификацию, однако сеанс замерзает на 25 секунд, прежде чем дать мне оболочку bash, домашний каталог, будь то локальный или NFS, правильно смонтирован. В итоге это помогло мне в Ubuntu 16.04. (Мне пришлось добавить следующую строку, чтобы запустить systemd rpc.bind: /bin/systemctl add-wants multi-user.target rpcbind.service.) Я пробовал это с Ubuntu 18.04 без успеха. Похоже, существует задержка между аутентификацией и созданием сеанса, что вызывает эту проблему. Я загрузил и установил последние обновления и т. Д. И последние apt-get его и т. Д.
Спасибо за ответы. Я попытался установить lightdm и имел небольшой успех при входе в систему как пользователь NIS для X. Однако я счел это непоследовательным для меня, иногда регистрируясь в X, в другое время тайминга, поэтому не может использоваться в лабораторной ситуации. Я снова установил 16.04, и это сработало хорошо, поэтому собирался оставить его на этом до 18,04 места. После этого Пауло я только что видел ваш ответ! Я взгляну на переустановку 18.04 и вернусь. Cheers
Пробовал наконечник Паулоса, как указано выше. К сожалению, я не мог сопоставить одни и те же установочные файлы на Ubuntu 18.04 (т. Е. Не смог найти файл /etc/systemd/system/systemd-login.service.d или /usr/lib/systemd/system/systemd-logind.service. a /etc/system/logind.conf. Я попробовал включить в него заявление IPAddressAllow (там не было упоминания или не было по умолчанию), но он не был распознан. Также попытался вставить мой собственный .conf-файл в тот же каталог без успеха. очень похоже на те же симптомы, или это вполне может быть моим недостатком знаний здесь. Я еще раз посмотрю, но на данный момент надеюсь, что Ubuntu вскоре выпустит обновление или патч, которые будут сортировать эту проблему
8 ответов
Я попробовал подсказку Паулоса, но есть различные проблемы с описанной работой, когда вы следуете ссылке.
Второе решение у меня получилось. У них просто неправильный путь для ubuntu, файл здесь:
/lib/systemd/system/systemd-logind.service
Я просто прокомментировал эту строку:
# IPAddressDeny=any
и после перезагрузки он сработал.
Первое решение кажется лучшим, хотя, но я обнаружил различные проблемы с ним и не могу получить синтаксис совершенно правильно. Чтобы начать с имени неправильно, это не допустимое имя, тогда оно должно быть символической ссылкой, а не реальным файлом. Я добрался до создания
/lib/systemd/system/open_nis_interface.service
и заполнил его:
[Service]
IPAddressAllow=10.0.0.0/16
, а затем связал:
mkdir /etc/systemd/system/systemd-logind.service.wants/
ln -s /lib/systemd/system/open_nis_interface.service /etc/systemd/system/systemd-logind.service.wants/
У меня есть загрузка файла, но мой синтаксис не совсем прав. systemd дает ok сообщения, если вы запустите:
dmesg | grep systemd
Как я уже сказал, второй метод просто переопределения системного файла работает для меня, возможно, кто-то может закончить первый метод, который кажется лучшим долгосрочным решением.
Том
Я могу подтвердить, что второе решение, о котором говорит Том, теперь отлично работает для меня (Hadnt заметил неправильный путь - спасибо). Ive также попробовал первое решение, но опять же он не работает для меня. Я также случайно обнаружил, что файл /etc/systemd/system.conf имеет
IPAddressAllow = (запись закомментирована)
Я попытался вставить свои внутренние сетевые записи, т. Е. (Например, 10.0.0.0 / 16), но он, похоже, не влияет. Я новичок systemd (из ubuntu 14.04). На данный момент решение 2 идеально подходит, и я могу обойти обновления и т. Д., Но рассмотрю вариант 1 по мере того, как позволяет время, или кто-то может это взломать. Спасибо миллион за помощь ребятам
Я столкнулся с той же проблемой в лаборатории, которую я настраиваю для своих учеников. Моим решением было использовать 17.10 клиентов. Они работают, даже если сервер 18.04.
Но теперь, когда я вернулся домой, я только что нашел очень интересный комментарий к вики Arch Linux. Он обращает внимание на изменение системы, которое состоялось 10/2017. Кажется, это проблема. Они также предлагают решение, основанное на «Это можно сделать, создав новый .conf-файл в файле /etc/systemd/system/systemd-logind.service.d/», который присваивает белый список NIS-серверу. Я смогу попробовать это в понедельник, когда вернусь к работе (или я не буду сопротивляться и стараюсь ssh). Но если у вас есть доступ к вашей системе, вы можете попробовать и отчитаться.
У меня была аналогичная проблема, я обновился с 17.10 по 18.04. Хотя я мог войти в систему с локальным пользователем, сеанс не продлился так долго, прежде чем перезапуск. Я не смог войти в систему с моим nis-пользователем без перезапуска gui.
Переключив диспетчер дисплея в lightdm, я смог решить проблему.
sudo apt install lightdm
sudo dpkg-reconfigure gdm3
Тогда выберите lightdm в качестве менеджера. Перезагрузите, и я смог войти в систему с моим пользователем nis.
Он не решает время, которое требуется для входа в систему, но это позволяет мне получить доступ к gui.
Я попробовал подсказку Паулоса, но есть различные проблемы с описанной работой, когда вы следуете ссылке.
Второе решение у меня получилось. У них просто неправильный путь для ubuntu, файл здесь:
/lib/systemd/system/systemd-logind.service
Я просто прокомментировал эту строку:
# IPAddressDeny=any
и после перезагрузки он сработал.
Первое решение кажется лучшим, хотя, но я обнаружил различные проблемы с ним и не могу получить синтаксис совершенно правильно. Чтобы начать с имени неправильно, это не допустимое имя, тогда оно должно быть символической ссылкой, а не реальным файлом. Я добрался до создания
/lib/systemd/system/open_nis_interface.service
и заполнил его:
[Service]
IPAddressAllow=10.0.0.0/16
, а затем связал:
mkdir /etc/systemd/system/systemd-logind.service.wants/
ln -s /lib/systemd/system/open_nis_interface.service /etc/systemd/system/systemd-logind.service.wants/
У меня есть загрузка файла, но мой синтаксис не совсем прав. systemd дает ok сообщения, если вы запустите:
dmesg | grep systemd
Как я уже сказал, второй метод просто переопределения системного файла работает для меня, возможно, кто-то может закончить первый метод, который кажется лучшим долгосрочным решением.
Том
Я могу подтвердить, что второе решение, о котором говорит Том, теперь отлично работает для меня (Hadnt заметил неправильный путь - спасибо). Ive также попробовал первое решение, но опять же он не работает для меня. Я также случайно обнаружил, что файл /etc/systemd/system.conf имеет
IPAddressAllow = (запись закомментирована)
Я попытался вставить свои внутренние сетевые записи, т. Е. (Например, 10.0.0.0 / 16), но он, похоже, не влияет. Я новичок systemd (из ubuntu 14.04). На данный момент решение 2 идеально подходит, и я могу обойти обновления и т. Д., Но рассмотрю вариант 1 по мере того, как позволяет время, или кто-то может это взломать. Спасибо миллион за помощь ребятам
Я столкнулся с той же проблемой в лаборатории, которую я настраиваю для своих учеников. Моим решением было использовать 17.10 клиентов. Они работают, даже если сервер 18.04.
Но теперь, когда я вернулся домой, я только что нашел очень интересный комментарий к вики Arch Linux. Он обращает внимание на изменение системы, которое состоялось 10/2017. Кажется, это проблема. Они также предлагают решение, основанное на «Это можно сделать, создав новый .conf-файл в файле /etc/systemd/system/systemd-logind.service.d/», который присваивает белый список NIS-серверу. Я смогу попробовать это в понедельник, когда вернусь к работе (или я не буду сопротивляться и стараюсь ssh). Но если у вас есть доступ к вашей системе, вы можете попробовать и отчитаться.
У меня была аналогичная проблема, я обновился с 17.10 по 18.04. Хотя я мог войти в систему с локальным пользователем, сеанс не продлился так долго, прежде чем перезапуск. Я не смог войти в систему с моим nis-пользователем без перезапуска gui.
Переключив диспетчер дисплея в lightdm, я смог решить проблему.
sudo apt install lightdm
sudo dpkg-reconfigure gdm3
Тогда выберите lightdm в качестве менеджера. Перезагрузите, и я смог войти в систему с моим пользователем nis.
Он не решает время, которое требуется для входа в систему, но это позволяет мне получить доступ к gui.