16.04 сервер: включение аутентификации LDAP приводит к сбою systemd-logind

7

Я здесь в тупике, извините, если мне не хватает чего-то очевидного. У меня был сервер 16.04, прошедший аутентификацию против LDAP, который в последний раз прекратил работать, я запускал обновления, и я построил чистый сервер 16.04 с нуля, запускал стандартные обновления и отлично работает, пока не включу аутентификацию LDAP. Я могу отключить LDAP, а затем снова работает.

[email protected]:/etc# systemctl status systemd-logind.service
● systemd-logind.service - Login Service
   Loaded: loaded (/lib/systemd/system/systemd-logind.service; static; vendor preset: enabled)
   Active: activating (start) since Tue 2016-07-12 15:13:07 EDT; 19s ago
     Docs: man:systemd-logind.service(8)
           man:logind.conf(5)
           http://www.freedesktop.org/wiki/Software/systemd/logind
           http://www.freedesktop.org/wiki/Software/systemd/multiseat
 Main PID: 2106 (systemd-logind)
    Tasks: 1
   Memory: 228.0K
      CPU: 2ms
   CGroup: /system.slice/systemd-logind.service
           └─2106 /lib/systemd/systemd-logind

Jul 12 15:13:07 myserver systemd[1]: Starting Login Service...

Он некоторое время откажется, потерпит неудачу, а затем попробуйте снова начать в бесконечных циклах. Я могу войти в локальную учетную запись, но это занимает много времени.

[email protected]:/etc# systemd-analyze blame
Bootup is not yet finished. Please try again later.

Между тем, журналctctl -xe возвращает свой собственный более подробный цикл:

[email protected]:/etc# journalctl -xe
-- Subject: Unit systemd-logind.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit systemd-logind.service has failed.
-- 
-- The result is failed.
Jul 12 15:16:27 myserver systemd[1]: systemd-logind.service: Unit entered failed state.
Jul 12 15:16:27 myserver systemd[1]: systemd-logind.service: Failed with result 'exit-code'.
Jul 12 15:16:27 myserver systemd[1]: systemd-logind.service: Service has no hold-off time, scheduling restart.
Jul 12 15:16:27 myserver systemd[1]: Stopped Login Service.
-- Subject: Unit systemd-logind.service has finished shutting down
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit systemd-logind.service has finished shutting down.
Jul 12 15:16:27 myserver systemd[1]: Starting Login Service...
-- Subject: Unit systemd-logind.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit systemd-logind.service has begun starting up.
Jul 12 15:16:52 myserver systemd-logind[2134]: Failed to enable subscription: Connection timed out
Jul 12 15:16:52 myserver systemd-logind[2134]: Failed to fully start up daemon: Connection timed out
Jul 12 15:16:52 myserver dbus[1012]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out
Jul 12 15:16:52 myserver systemd[1]: systemd-logind.service: Main process exited, code=exited, status=1/FAILURE
Jul 12 15:16:52 myserver systemd[1]: Failed to start Login Service.

У меня есть два десятка или около 14.04 серверов, работающих нормально с LDAP, то же самое.

Я пробовал вручную перезапускать systemd-logind, но он терпит неудачу.

Любые идеи? ТИА.

(ETA: только что построена такая же система на 14.04, и аутентификация LDAP работает нормально.)

Добавление информации dpkg.log: В этом файле много шума, поэтому не уверен, что актуально и полезно, но вот то, что кажется конечной строкой обработки для связанных пакетов:

2016-07-11 13:52:08 status installed libldap-2.4-2:amd64 2.4.42+dfsg-2ubuntu3
2016-07-11 14:11:40 status installed libldap-2.4-2:amd64 2.4.42+dfsg-2ubuntu3.1
2016-07-11 15:02:45 status installed libnss-ldap:amd64 265-3ubuntu2
2016-07-11 15:02:45 status installed ldap-auth-client:all 0.5.3
2016-07-11 15:02:45 status installed ldap-auth-config:all 0.5.3
2016-07-11 15:02:45 status installed libpam-ldap:amd64 184-8.7ubuntu1
2016-07-11 15:04:12 status installed ldap-utils:amd64 2.4.42+dfsg-2ubuntu3.1

Мой LDAP-сервер находится в другом месте; этот сервер должен только аутентифицироваться против него как клиента. Конфигурационные файлы на /etc/ldap.conf и /etc/ldap/ldap.conf идентичны и, по-видимому, не изменялись между 14.04 и 16.04

Стоит отметить, что хотя аутентификация LDAP не работает, я могу успешно выполнить запрос ldapsearch на сервере LDAP.

    
задан oxtoe 12.07.2016 в 19:25
источник

2 ответа

3

Была та же проблема с моими настольными клиентами 16.04.

Наконец, решено заменить пакет libnss-ldap на libnss-ldapd .

Похожая проблема, как в этом отчете об ошибке: Ссылка

EDIT : больше информации об этих пакетах из Debian wiki :

  

В настоящее время доступны два пакета для настройки запросов NSS   через LDAP: пакет libnss-ldap и пакет libnss-ldapd.   Какой из них выбрать, зависит от потребностей. В общем случае libnss-ldapd   более простой, но более новый и libnss-ldap более зрелый, но более сложный.   Также libnss-ldap имеет некоторые известные проблемы с информацией об обслуживании хоста   и поиск во время загрузки, который должен быть рассмотрен в libnss-ldapd . В   Кроме того, libnss-ldap прерывает программы setuid (su, sudo) при использовании   LDAP + SSL

    
ответ дан barotto 10.08.2016 в 10:47
источник
1

Способ предотвращения этой проблемы состоит в том, чтобы убедиться, что параметр nss_initgroups_ignoreusers - в /etc/ldap.conf (или /etc/libnss-ldap.conf , в зависимости от вашей системы) - заполняется всеми (локальными) пользователями в /etc/passwd :

NSS_IGNOREUSERS="$(cut -d: -f1 /etc/passwd | sort | tr '\n' ',' | sed 's|,$||')"
sed -i "s|^nss_initgroups_ignoreusers.*|nss_initgroups_ignoreusers ${NSS_IGNOREUSERS}|" /etc/ldap.conf

Таким образом, когда запрашиваются системные загрузки и службы имен пользователей / групп для запуска локальных служб, не будет выдано больше «nss_ldap: не удается связаться с сервером LDAP» (поскольку соответствующий локальный пользователь / группа игнорируется NSS LDAP).

(эта проблема существует уже много лет, независимо от systemd)

    
ответ дан Cédric Dufour 08.08.2017 в 17:08