Спасибо, что уделили время изучению моей проблемы.
В настоящее время я работаю над проблемой, которая ранее возникала только один раз. 3 января, когда это впервые появилось, мы смогли перезагрузить сервер, и все казалось в порядке, но теперь все вернулось. Это производственная система баз данных, поэтому иногда бывает сложно найти время для перезагрузки. Я надеюсь получить четкое представление о том, что на самом деле происходит в этот раз, прежде чем мы снова перезагрузимся через несколько дней, чтобы предоставить еще одно временное решение проблемы. Вот так...
Аутентификация пользователя для рассматриваемой системы обрабатывается с помощью LDAP через Red Hat Directory Server 9. Описанная ниже проблема наблюдается только на этом сервере, и даже его аналог, который использует эту же базу данных, не демонстрирует тех же симптомов. На данный момент ни одна учетная запись LDAP не может пройти аутентификацию и войти на сервер. Аутентификация LDAP обрабатывается SSSD, который в настоящее время не может быть остановлен или перезапущен. При попытке сделать что-либо из этого консоль SSH перестает отвечать. (ctrl-c не позволяет выйти из выданной команды)
PS показывает, что обычные процессы, связанные с sssd, запущены, но попытка kill -9их остановить, похоже, не приводит к успешному завершению ни одного из них.
ps aux | grep sss | grep -v grep
root 1150 0.0 0.0 150828 2908 ? D 09:05 0:00 /usr/libexec/sssd/sssd_nss -d 0 --debug-to-files
root 7025 0.0 0.0 93616 2504 pts/2 D 16:18 0:00 /usr/sbin/sssd -f -D
root 11148 0.0 0.0 179436 5672 ? D Jan08 16:22 /usr/libexec/sssd/sssd_be -d 0 --debug-to-files --domain default
root 32700 0.0 0.0 150784 2908 ? D 10:10 0:00 /usr/libexec/sssd/sssd_pam -d 0 --debug-to-files
Используя strace getent -s sss passwdЯ вижу, что некоторые попытки подключения отклоняются, но я не совсем понимаю, что с этим делать.
connect(3, {sa_family=AF_FILE, path="/var/lib/sss/pipes/nss"...}, 110) = -1 ECONNREFUSED (Connection refused)
close(3) = 0
socket(PF_FILE, SOCK_STREAM, 0) = 3
fcntl(3, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
fcntl(3, F_GETFD) = 0
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
connect(3, {sa_family=AF_FILE, path="/var/lib/sss/pipes/nss"...}, 110) = -1 ECONNREFUSED (Connection refused)
close(3) = 0
socket(PF_FILE, SOCK_STREAM, 0) = 3
fcntl(3, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
fcntl(3, F_GETFD) = 0
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
connect(3, {sa_family=AF_FILE, path="/var/lib/sss/pipes/nss"...}, 110) = -1 ECONNREFUSED (Connection refused)
Проверка lsof | head -n1; lsof | grep /var/lib/sss/pipes/показывает, что открытых труб между хорошей и плохой системой гораздо меньше. PID для этих труб те же, что и сообщалось из ps aux, поэтому попытки kill -9на них также оказались бесплодными.
плохой sssd
lsof | head -n1; lsof | grep /var/lib/sss/pipes/
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
sssd_be 11148 root 15u unix 0xffff8806635911c0 0t0 31817638 /var/lib/sss/pipes/private/sbus-dp_default.11148
sssd_be 11148 root 16u unix 0xffff880d443d6180 0t0 31783555 /var/lib/sss/pipes/private/sbus-dp_default.11148
sssd_be 11148 root 17u unix 0xffff880c536d94c0 0t0 31783560 /var/lib/sss/pipes/private/sbus-dp_default.11148
хороший ссд
lsof | head -n1; lsof | grep /var/lib/sss/pipes/
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
sssd 26793 root 13u unix 0xffff88030b5d8c40 0t0 3248762734 /var/lib/sss/pipes/private/sbus-monitor
sssd 26793 root 14u unix 0xffff8808cc064bc0 0t0 3248762735 /var/lib/sss/pipes/private/sbus-monitor
sssd 26793 root 15u unix 0xffff880a9d9bc840 0t0 3248768164 /var/lib/sss/pipes/private/sbus-monitor
sssd 26793 root 16u unix 0xffff880040a32f00 0t0 3248768165 /var/lib/sss/pipes/private/sbus-monitor
sssd_be 26794 root 15u unix 0xffff8808cc064200 0t0 3248767368 /var/lib/sss/pipes/private/sbus-dp_default.26794
sssd_be 26794 root 16u unix 0xffff880a9d9bd880 0t0 3248763661 /var/lib/sss/pipes/private/sbus-dp_default.26794
sssd_be 26794 root 17u unix 0xffff8809841b4480 0t0 3248763662 /var/lib/sss/pipes/private/sbus-dp_default.26794
sssd_nss 26795 root 16u unix 0xffff880a9d9bd200 0t0 3248751954 /var/lib/sss/pipes/nss
sssd_pam 26796 root 16u unix 0xffff880859e26180 0t0 3248774325 /var/lib/sss/pipes/pam
sssd_pam 26796 root 17u unix 0xffff880859e27b80 0t0 3248774326 /var/lib/sss/pipes/private/pam
Также /var/log/secure содержит несколько записей
sshd[9177]: pam_succeed_if(sshd:auth): error retrieving information about user
su: pam_sss(su-l:session): Request to sssd failed. Connection refuse
crond[29568]: pam_sss(crond:session): Request to sssd failed. Connection refused
Кроме того, одним из первых, что я заметил, было то, что файл /var/log/messages не содержал данных. И он, и логи /var/log/sssd/, похоже, перестали собираться около 9:03 утра, /var/log/secure продолжал накапливать данные без проблем. Перезапуск syslog исправил проблему с сообщениями, но логи sssd по-прежнему не работают.
Последнее, что я заметил, dmesg заполнен сообщениями типа audit: backlog limit exceeded audit: audit_backlog=322 > audit_backlog_limit=320и audit_log_start: 122 callbacks suppressed. Я предположил, что это из тех времен, когда syslog работал некорректно, но пока не проверял.
Я все еще изучаю этот вопрос и надеюсь, что найду что-нибудь, но буду более чем приветствовать любые предложения и отзывы, которые люди готовы предоставить.
Большое спасибо!
-Омни
решение1
Я столкнулся с проблемами pam_ldap и sssd, запущенных в одной системе. Если вы хотите прекратить использование sssd с pam, вам следует убедиться, что вы запустили:
pam-config -a --ldap
который добавит LDAP в pam, а затем запустит:
pam-config -d --sss
что удалит настройку sssd в файлах конфигурации, связанных с pam, в /etc/pam.d/
Чтобы убедиться, что sss не используется, вы также можете проверить, что nsswitch.conf имеет ldap в правильных местах (или, по крайней мере, не имеет sss). Вот /etc/nsswitch.conf с включенным sss:
#
# /etc/nsswitch.conf
#
# An example Name Service Switch config file. This file should be
# sorted with the most-used services at the beginning.
#
# The entry '[NOTFOUND=return]' means that the search for an
# entry should stop if the search in the previous entry turned
# up nothing. Note that if the search failed due to some other reason
# (like no NIS server responding) then the search continues with the
# next entry.
#
# Legal entries are:
#
# compat Use compatibility setup
# nisplus Use NIS+ (NIS version 3)
# nis Use NIS (NIS version 2), also called YP
# dns Use DNS (Domain Name Service)
# files Use the local files
# [NOTFOUND=return] Stop searching if not found so far
#
# For more information, please read the nsswitch.conf.5 manual page.
#
passwd: compat sss
group: compat sss
hosts: files mdns_minimal [NOTFOUND=return] dns
networks: files dns
services: files
protocols: files
rpc: files
ethers: files
netmasks: files
netgroup: files
publickey: files
bootparams: files
automount: files
aliases: files
passwd_compat: files
group_compat: files
В этом файле отключен sss и включен ldap:
passwd: compat ldap
group: compat ldap
hosts: files mdns_minimal [NOTFOUND=return] dns
networks: files dns
services: files
protocols: files
rpc: files
ethers: files
netmasks: files
netgroup: files
publickey: files
bootparams: files
automount: files
aliases: files
passwd_compat: files
group_compat: files