Используя клиент NIS в Ubuntu 18.04 разрушает и Gnome и Единицу
Я выполняю клиенты 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 секунд приблизительно прежде, чем дать мне оболочку удара, корневой каталог, локально ли это, или 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, othertimes таймаут, таким образом, не применимый в ситуации лаборатории. Я переустановил 16.04 снова, и это хорошо работало, так собирался оставить его, в котором до 18.04 располагается на ночлег немного. После выполнения, что Paulo я только что видел Ваш ответ! Я буду смотреть на переустановку 18.04 и возвращать Аплодисменты
Попробованные Paulos снабжают подсказкой как выше. К сожалению, я не мог отобразить те же файлы настройки на Ubuntu 18.04 (т.е. не мог найти/etc/systemd/system/systemd-login.service.d или/usr/lib/systemd/system/systemd-logind.service Взгляд далее, я нашел/etc/system/logind.conf. Я пытался включить оператор IPAddressAllow там (не было никакого упоминания или никакого значения по умолчанию там), но он не был распознан. Также испытанная вставка моего собственного .conf файла в том же каталоге без успеха. Это звучит в точности как те же признаки, или это могло быть мое отсутствие знаний здесь. Я буду бросать другой взгляд снова, но в настоящий момент надеяться, что Ubuntu могла бы произвести обновление или патч вскоре, который отсортирует эту проблему
7 ответов
У меня была похожая проблема, я обновился с 17.10 до 18.04. Несмотря на то, что я мог войти в систему с локальным пользователем, сеанс длился не так долго до перезапуска. Я не мог войти с моим пользователем nis без перезапуска графического интерфейса.
Переключив диспетчер отображения на lightdm, я смог обойти эту проблему.
sudo apt install lightdm
sudo dpkg-reconfigure gdm3
Затем выберите lightdm в качестве менеджера. Перезапустите, и я смог войти в систему с моим пользователем NIS.
Это не решает время, необходимое для входа в систему, но позволяет мне получить доступ к графическому интерфейсу.
Я столкнулся с той же проблемой в лаборатории, которую настраиваю для своих учеников. Моё решение было использовать 17.10 клиентов. Они работают, даже если сервер 18.04.
Но теперь, когда я вернулся домой, я только что нашел очень интересный комментарий на Arch Linux wiki . Это привлекает внимание к изменениям в systemd, которые произошли 10/2017. Похоже, это проблема. Они также предлагают решение, основанное на «Это можно сделать, создав новый файл .conf в /etc/systemd/system/systemd-logind.service.d/», который вносит в белый список сервер NIS. Я смогу попробовать это только в понедельник, когда вернусь на работу (или я не буду сопротивляться и попробую по ssh). Но если у вас есть доступ к вашей системе, вы можете попробовать и доложить.
Я попробовал совет Паулоса, но существуют разные проблемы с обходом, описанным при переходе по ссылке.
Второе решение у меня получилось. У них просто неправильный путь для 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 выдает нормальные сообщения, если вы запускаете:
dmesg | grep systemd
Как я уже сказал, второй метод простого переопределения системного файла работает для меня, возможно, кто-то может закончить первый метод, который кажется лучшим долгосрочным решением. [ 1114]
Том
Я могу подтвердить, что второе решение, о котором упоминает Том, теперь отлично работает и для меня (не заметил неправильный путь - спасибо). Я также попробовал первое решение, но опять-таки оно не работает для меня. Я также случайно обнаружил, что файл /etc/systemd/system.conf содержит
IPAddressAllow = (запись закомментирована)
Я попытался вставить записи во внутренней сети, т.е. ) но это, похоже, не влияет. Я системный новичок (выходит из Ubuntu 14.04). На данный момент решение 2 является идеальным, и я могу работать с обновлениями и т. Д., Но я еще раз посмотрю на вариант 1, если позволит время, или кто-то может взломать это. Спасибо миллион за помощь, ребята
Я был также затронут этим, и сначала я также решил эту проблему путем комментирования
IPAdressDeny=Any в /lib/systemd/system/systemd-logind.service
как многие другие, здесь упомянутые прежде.
Однако помимо того, чтобы быть угрозой безопасности, это будет только работать, пока следующее обновление systemd набора инструментальных средств не развертывает, как упомянуто в Wiki Дуги. То, что Wiki не объясняет очень хорошо, то, как расширить конфигурацию systemd-logind.service, таким образом, что определенный диапазон адресов добавлен в белый список и что эти настройки переживут обновление. После некоторого чтения в документации RHEL (особенно разделяют 10.6.4: Изменение Существующих Файлов Единицы), следующее решение работало на меня:
Создайте новый каталог в
/etc/systemd/system/названный точно в честь сервиса Вы хотите расшириться включая a.d, здесь это было бы:systemd-logind.service.dСоздайте новый файл
choose_an_appropriate_name.conf(например, nis_open_network_interface.conf) в недавно созданном каталоге со следующим содержанием, которое указывает диапазон IP или диапазон IP, который Вы хотите быть разрешенными:[Service] IPAddressAllow=10.10.0.0/16Сделайте a
systemctl daemon-reload- И проверьте, является ли новая конфигурация на самом деле частью Вашего systemd-logind.service использования единицы
systemctl cat systemd-logind.service - Наконец перезапустите сервис
systemctl restart systemd-logind.service(Это вышибет Вас из Вашей рабочей сессии гнома, и необходимо войти в систему снова.)
Нет никакой потребности изменить любой другой файл! В этой точке необходимо смочь войти в систему с пользователями NIS снова, не получая системное замораживание. Остерегайтесь, хотя, что это все еще считают небезопасным (добавляющий IP-адреса в белый список) и что поигравшее в песочнице поведение systemd-logind требуется. NIS/YP довольно устарел, но я все еще нахожу, что он использовал очень часто. Также может быть лучшее решение этого вовлечения имени, кэширующего демона, использующего nscd или sssd, как упомянуто в этой systemd проблеме GitHub, справляющейся с целой ситуацией. Но это вне моего объема в данный момент.
Этот ответ собирает все остатки из предыдущих сообщений, и я надеюсь, разъясняется немного для предоставления хорошего решения проблемы.
Удачи
На Ubuntu 18.04 LTS необходимо смочь устранить проблему, просто удаляют строку
IPAddressDeny=any
от /lib/systemd/system/systemd-logind.service
Это не делает, кажется, Вы случай, учитывая то, что Вы описали, но остерегайтесь этого, у Вас должен быть корневой каталог для пользователя NIS, которого Вы пытаетесь соединить, у того пользователя должно быть разрешение чтения-записи для того каталога, и что когда-то это может занять время для соединения с сервером NIS.
Из сообщения systemd github issue, которое Wiggles упомянул в своем ответе, просто установите nscd и затем перезагрузитесь. Это исправило это для меня.