Danke, dass Sie sich die Zeit genommen haben, mein Problem zu prüfen.
Ich arbeite derzeit an einem Problem, das bisher nur einmal aufgetreten ist. Am 3. Januar, als es zum ersten Mal auftrat, konnten wir den Server neu starten und alles schien in Ordnung zu sein, aber jetzt ist es wieder da. Dies ist ein Produktionsdatenbanksystem, daher kann es manchmal schwierig sein, ein Zeitfenster für den Neustart zu finden. Ich hoffe, dass ich genau weiß, was dieses Mal tatsächlich passiert, bevor wir in ein paar Tagen erneut neu starten, um eine weitere temporäre Lösung für das Problem bereitzustellen. Los geht’s …
Die Benutzerauthentifizierung für das betreffende System wird mit LDAP über Red Hat Directory Server 9 abgewickelt. Das unten beschriebene Problem tritt nur auf diesem einen Server auf und selbst sein Gegenstück, das die Datenbank teilt, zeigt nicht dieselben Symptome. Derzeit können sich keine LDAP-Konten authentifizieren und beim Server anmelden. Die LDAP-Authentifizierung wird von SSSD abgewickelt, das derzeit weder gestoppt noch neu gestartet werden kann. Beim Versuch, dies zu tun, reagiert die SSH-Konsole nicht mehr. (Strg-C kann den ausgegebenen Befehl nicht beenden)
PS: Es werden die üblichen SSD-bezogenen Prozesse ausgeführt, aber Versuche, kill -9sie zu stoppen, scheinen keinen davon erfolgreich zu stoppen.
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
Mithilfe von strace getent -s sss passwdkann ich sehen, dass einige Verbindungsversuche abgelehnt werden, aber ich bin nicht sicher, was ich dagegen tun kann.
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)
Die Überprüfung lsof | head -n1; lsof | grep /var/lib/sss/pipes/zeigt, dass zwischen dem guten und dem schlechten System weitaus weniger offene Leitungen vorhanden sind. Die PIDs für diese Leitungen sind dieselben, die von gemeldet wurden , daher waren auch hier ps auxVersuche erfolglos.kill -9
schlechte 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
gute 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
Außerdem enthält /var/log/secure mehrere Einträge von
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
Außerdem war eines der ersten Dinge, die mir auffielen, dass die Datei /var/log/messages keine Daten enthielt. Sowohl diese als auch die /var/log/sssd/-Protokolle scheinen heute Morgen gegen 9:03 Uhr aufgehört zu haben, Daten zu sammeln, /var/log/secure sammelte weiterhin problemlos Daten. Ein Neustart von Syslog behob das Problem für Nachrichten, aber die SSDSD-Protokolle funktionieren immer noch nicht.
audit: backlog limit exceeded audit: audit_backlog=322 > audit_backlog_limit=320Das Letzte, was mir aufgefallen ist, ist, dass dmesg mit Meldungen wie und gefüllt ist audit_log_start: 122 callbacks suppressed. Ich nahm an, dass diese von der Zeit stammen, als Syslog nicht richtig funktionierte, habe das aber noch nicht überprüft.
Ich bin noch dabei, dies zu erforschen und hoffe, etwas zu finden, freue mich aber über alle Vorschläge und Rückmeldungen, die ich geben kann.
Vielen Dank!
-Omni
Antwort1
Ich habe Probleme mit pam_ldap und sssd, die auf demselben System laufen. Wenn Sie sssd nicht mehr mit pam verwenden möchten, sollten Sie Folgendes ausführen:
pam-config -a --ldap
Dadurch wird LDAP zu PAM hinzugefügt. Anschließend wird Folgendes ausgeführt:
pam-config -d --sss
Dadurch werden die SSDD-Einstellungen in PAM-bezogenen Konfigurationsdateien in /etc/pam.d/ gelöscht.
Um sicherzustellen, dass SSS nicht verwendet wird, sollten Sie auch überprüfen, ob nsswitch.conf LDAP an den richtigen Stellen enthält (oder zumindest kein SSS). Hier ist eine /etc/nsswitch.conf mit aktiviertem 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
In dieser Datei ist SSS deaktiviert und LDAP aktiviert:
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