Obrigado por reservar um tempo para verificar meu problema.
Atualmente estou trabalhando em um problema que apareceu apenas uma vez antes. No dia 3 de janeiro, quando isso apareceu pela primeira vez, conseguimos reiniciar o servidor e tudo parecia bem, mas agora ele está de volta. Este é um sistema de banco de dados de produção, portanto, às vezes pode ser difícil encontrar uma janela para reinicializar. Espero ter uma ideia clara do que pode realmente estar acontecendo desta vez, antes de reiniciarmos novamente em alguns dias para fornecer outra solução temporária para o problema. Aqui vamos nós...
A autenticação do usuário para o sistema em questão é tratada com LDAP via Red Hat Directory Server 9. O problema descrito abaixo só é visto neste servidor e mesmo sua contraparte que compartilha o banco de dados não apresenta os mesmos sintomas. No momento, nenhuma conta LDAP consegue autenticar e fazer login no servidor. A autenticação LDAP está sendo tratada pelo SSSD, que atualmente não pode ser interrompido ou reiniciado. Ao tentar fazer isso, o console SSH não responde. (ctrl-c não consegue sair do comando emitido)
PS mostra que os processos usuais relacionados ao sssd estão em execução, mas tentar kill -9executá-los não parece interromper com êxito nenhum deles.
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
Usando, strace getent -s sss passwdposso ver que algumas das tentativas de conexão estão sendo recusadas, mas não tenho certeza do que fazer com elas.
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)
A verificação lsof | head -n1; lsof | grep /var/lib/sss/pipes/mostra muito menos canais abertos entre o sistema bom e o sistema ruim. Os PIDs para esses pipes são os mesmos relatados em ps aux, portanto, tentar kill -9usá-los também foi infrutífero.
SSD ruim
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
bom SSD
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
Além disso, /var/log/secure contém múltiplas entradas de
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
Além disso, uma das primeiras coisas que notei foi que o arquivo /var/log/messages não continha dados. Tanto ele quanto /var/log/sssd/ logs parecem ter parado de coletar por volta das 9h03 desta manhã, /var/log/secure continuou acumulando dados sem problemas. Reiniciar o syslog corrigiu o problema das mensagens, mas os logs sssd ainda não estão funcionando.
A última coisa que notei é que o dmesg está cheio de mensagens como audit: backlog limit exceeded audit: audit_backlog=322 > audit_backlog_limit=320e audit_log_start: 122 callbacks suppressed. Presumi que fossem de quando o syslog não estava funcionando corretamente, mas ainda não verifiquei isso.
Ainda estou pesquisando sobre isso e espero encontrar algo, mas qualquer sugestão e feedback que as pessoas estejam dispostas a fornecer são bem-vindos.
Muito obrigado!
-Omni
Responder1
Tive problemas com pam_ldap e sssd em execução no mesmo sistema. Se você quiser parar de usar sssd com pam, certifique-se de executar:
pam-config -a --ldap
que adicionará LDAP ao pam e depois executará:
pam-config -d --sss
que excluirá a configuração sssd nos arquivos de configuração relacionados ao pam em /etc/pam.d/
Para garantir que o sss não seja usado, você também pode verificar se o nsswitch.conf possui o ldap nos locais corretos (ou pelo menos não possui o sss). Aqui está um /etc/nsswitch.conf com sss habilitado:
#
# /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
Este arquivo tem sss desabilitado e ldap habilitado:
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