Gracias por tomarse el tiempo de revisar mi problema.
Actualmente estoy trabajando en un problema que solo apareció una vez antes. El 3 de enero, cuando apareció esto por primera vez, pudimos reiniciar el servidor y todo parecía estar bien, pero ahora ha vuelto. Este es un sistema de base de datos de producción, por lo que a veces puede resultar difícil encontrar una ventana para reiniciar. Espero tener una idea clara de lo que realmente puede estar sucediendo esta vez antes de reiniciar nuevamente dentro de unos días para brindar otra solución temporal al problema. Aquí vamos...
La autenticación de usuario para el sistema en cuestión se maneja con LDAP a través de Red Hat Directory Server 9. El problema que se describe a continuación solo se ve en este servidor e incluso su contraparte que comparte la base de datos no muestra los mismos síntomas. En este momento, ninguna cuenta LDAP puede autenticarse e iniciar sesión en el servidor. La autenticación LDAP está a cargo de SSSD, que actualmente no se puede detener ni reiniciar. Al intentar hacer cualquiera de las dos cosas, la consola SSH deja de responder. (ctrl-c no puede salir del comando emitido)
PD muestra que se están ejecutando los procesos habituales relacionados con sssd, pero intentarlos kill -9no parece detener ninguno de ellos con éxito.
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 passwdpuedo ver que algunos de los intentos de conexión están siendo rechazados, pero no estoy realmente seguro de qué hacer al respecto.
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)
Las comprobaciones lsof | head -n1; lsof | grep /var/lib/sss/pipes/muestran muchos menos conductos abiertos entre el sistema bueno y el malo. Los PID para estas tuberías son los mismos que se informan en ps aux, por lo que intentarlo kill -9también ha sido infructuoso.
mal ssd
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
buen 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
Además, /var/log/secure contiene múltiples 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
Además, una de las primeras cosas que noté fue que el archivo /var/log/messages no contenía datos. Tanto él como /var/log/sssd/ logs parecen haber dejado de recopilarse alrededor de las 9:03 de esta mañana, /var/log/secure siguió acumulando datos sin problemas. Reiniciar syslog solucionó el problema de los mensajes, pero los registros sssd aún no funcionan.
Lo último que noté es que dmesg está lleno de mensajes como audit: backlog limit exceeded audit: audit_backlog=322 > audit_backlog_limit=320y audit_log_start: 122 callbacks suppressed. Supuse que eran de cuando syslog no funcionaba correctamente, pero aún no lo he verificado.
Todavía estoy investigando sobre esto y espero encontrar algo, pero agradezco cualquier sugerencia y comentario que la gente esté dispuesta a brindar.
¡Muchas gracias!
-Omni
Respuesta1
He tenido problemas con pam_ldap y sssd ejecutándose en el mismo sistema. Si desea dejar de usar sssd con pam, debe asegurarse de ejecutar:
pam-config -a --ldap
que agregará LDAP a pam y luego ejecutará:
pam-config -d --sss
que eliminará la configuración sssd en los archivos de configuración relacionados con pam en /etc/pam.d/
Para asegurarse de que no se utilice sss, es posible que también desee verificar que nsswitch.conf tenga ldap en los lugares correctos (o al menos no tenga sss). Aquí hay un /etc/nsswitch.conf con 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 archivo tiene sss deshabilitado y 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