Pregunta SSSD / NSS lento cuando se usa Sudo


Tengo un servidor que ejecuta OpenLDAP y los problemas con los que me estoy encontrando es con mi cliente. Mi cliente ejecuta SSSD con NSS.

En el primer arranque, no tengo problemas, y los comandos sudo se emiten correctamente.

Empiezo a tener problemas después de intentar instalar o modificar un paquete. A veces aurman Tiempo de espera, otras veces se descargará inmediatamente. Cuando lo haga pasar la descarga, se congelará Creating system user accounts..., Creating temporary files..., o Arming ConditionNeedsUpdate....

A continuación se muestra el resultado de sudo journalctl --follow cuando aurman -S accountsservice ejecutado:

Jul 26 16:39:52 test sudo[1400]: REDACTED_USER : problem with defaults entries ; TTY=pts/2 ; PWD=/home/REDACTED_USER ; USER=root ;
Jul 26 16:39:52 test sudo[1399]: REDACTED_USER : TTY=pts/2 ; PWD=/home/REDACTED_USER ; USER=root ; COMMAND=validate
Jul 26 16:39:52 test sudo[1400]: REDACTED_USER : TTY=pts/2 ; PWD=/home/REDACTED_USER ; USER=root ; COMMAND=/usr/bin/pacman --sync --asdeps -- lightdm
Jul 26 16:39:52 test sudo[1400]: pam_unix(sudo:session): session opened for user root by REDACTED_USER(uid=0)
Jul 26 16:39:53 test systemd[1]: Reloading.
Jul 26 16:39:53 test systemd-fstab-generator[1437]: x-systemd.device-timeout ignored for REDACTED_HOSTNAME:/srv/nfs/home/
Jul 26 16:39:53 test sudo[1400]: pam_unix(sudo:session): session closed for user root
Jul 26 16:39:53 test sudo[1449]: REDACTED_USER : problem with defaults entries ; TTY=pts/2 ; PWD=/home/REDACTED_USER ; USER=root ;
Jul 26 16:40:18 test systemd[1]: Failed to get initial list of names: Connection timed out
Jul 26 16:40:25 test dbus-daemon[374]: Unknown username "systemd-timesync" in message bus configuration file
Jul 26 16:40:45 test dbus-daemon[374]: [system] Reloaded configuration
Jul 26 16:41:10 test dbus-daemon[374]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out (service_start_timeout=25000ms)
Jul 26 16:41:10 test sudo[1449]: REDACTED_USER : TTY=pts/2 ; PWD=/home/REDACTED_USER ; USER=root ; COMMAND=/usr/bin/pacman -D --asexplicit lightdm
Jul 26 16:41:10 test sudo[1449]: pam_unix(sudo:session): session opened for user root by REDACTED_USER(uid=0)
Jul 26 16:41:10 test sudo[1449]: pam_unix(sudo:session): session closed for user root

A continuación se muestra el resultado de sudo journalctl --follow cuando sudo -i se ejecuta:

Jul 26 17:02:00 test sudo[1645]: REDACTED_USER : problem with defaults entries ; TTY=pts/0 ; PWD=/home/REDACTED_USER ; USER=root ;
Jul 26 17:02:25 test dbus-daemon[374]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out (service_start_timeout=25000ms)
Jul 26 17:02:28 test sudo[1645]: pam_sss(sudo:auth): authentication success; logname=REDACTED_USER uid=8102 euid=0 tty=/dev/pts/0 ruser=REDACTED_USER rhost= user=REDACTED_USER
Jul 26 17:02:28 test sudo[1645]: REDACTED_USER : TTY=pts/0 ; PWD=/home/REDACTED_USER ; USER=root ; COMMAND=/bin/bash
Jul 26 17:02:28 test sudo[1645]: pam_unix(sudo:session): session opened for user root by REDACTED_USER(uid=0)

Este es mi archivo sssd.conf:

[sssd]
config_file_version = 2
services = nss, pam
domains = LDAP

[domain/LDAP]
cache_credentials = true
enumerate = true

id_provider = ldap
auth_provider = ldap
chpass_provider = ldap

ldap_uri = ldaps://REDACTED_HOSTNAME
ldap_search_base = dc=REDACTED,dc=HOST,dc=NAME
ldap_id_use_start_tls = true
ldap_tls_reqcert = demand
ldap_tls_cacert = /etc/openldap/certs/slapdcert.pem
ldap_chpass_uri = ldaps://REDACTED_HOSTNAME

Este es mi archivo nsswitch.conf (NOTA: He jugado con sss en sudoers, services, y netgroup y el mismo problema):

passwd: files sss mymachines systemd
group: files sss mymachines systemd
shadow: files sss
sudoers: files sss

publickey: files

hosts: files mymachines myhostname resolve [!UNAVAIL=return] dns
networks: files

protocols: files
services: files sss
ethers: files
rpc: files

netgroup: files sss

A continuación se muestra el resultado de hacer time sudo strace -r -o trace_5.log sudo echo hi, cada uno llegó en un momento diferente cuando estaba depurando (para reiterar, cada línea es un archivo diferente, y el retraso de 25 segundos fue por sudo llamada):

25.007024 recvmsg(6, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\3\1\1e\0\0\0\3\0\0\0m\0\0\0\6\1s\0\5\0\0\0", iov_len=24}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 24
25.025124 openat(AT_FDCWD, "/usr/share/locale/en_US.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
25.025143 openat(AT_FDCWD, "/usr/share/locale/en_US.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
25.019033 recvmsg(6, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\3\1\1e\0\0\0\3\0\0\0m\0\0\0\6\1s\0\5\0\0\0", iov_len=24}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 24
25.025170 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0

Los dos openat Las llamadas eran cuando /etc/lcoale.conf existía, cuando lo quité, se detuvo. El problema más común fue el recvmsg llamar varias veces Pero getent hosts terminado bien Todavía, getent passwd toma alrededor de 25 segundos y aparece lo siguiente en sudo journctl --follow:

Jul 26 17:11:47 test dbus-daemon[374]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out (service_start_timeout=25000ms)

Cualquier ayuda sería muy apreciada ...

[EDITAR]

Cuando corro strace -r -o trace_8 getent passwd Yo obtengo:

25.025198 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0

0


origen


Por favor incluye tu /etc/nsswitch.conf. - grawity
Lo tengo actualizado, lo olvidé la primera vez, así que gracias. - Vi1i


Respuestas:


Los módulos nsswitch.conf "passwd" y "group" están en el orden incorrecto: sss debe estar después systemd.

Cuando systemd inicia un servicio, necesita resolver su nombre de usuario (si corresponde) a UID. Cuando dbus-daemon carga su configuración, también necesita resolver los nombres de usuario que se encuentran en las políticas de seguridad en los UID. Esto pasa por nsswitch de la misma manera que todas las demás cuentas de usuario.

Por lo general, estas asignaciones para todos los servicios del sistema se encuentran en / etc / passwd (que es el módulo nsswitch "archivos"), pero tal vez debido a una mala decisión (ahora revertido en Git), algunos servicios systemd no crean sus cuentas de usuario allí, sino que solicitan un UID dinámico a través del módulo nsswitch "systemd".

En su configuración actual una red basada passwd El módulo (sss) se enumera antes del módulo "systemd". Entonces, cuando systemd o dbus-daemon intenten buscar el UID, p. systemd-timesyncd, terminan pasando por SSSD. Pero SSSD está en cola para comenzar después systemd-timesyncd, que da como resultado un interbloqueo (dependencia cíclica, si lo desea).

Aunque sospecho que esa no es la única causa de tus problemas. Pero es casi definitivamente un porque...


0



Voy a probarlo en la mañana. Lo he convertido a solo nslcd y ldap funcionando. Pero puedo verificar y ver si eso hará la diferencia, hice muchas cosas para depurar, pero esa no es una. - Vi1i
Lo más probable es que nslcd no se vea afectado porque su inicio no utiliza 'activación de socket' basada en sistema, a diferencia de SSSD. - grawity
Así que esto fue ... Me siento aliviada e irritada de que fuera tan fácil. Estaba saliendo de la página de autenticación LDAP de ArchWiki. La mayoría de los lugares que explican la configuración solo muestran brevemente que sss está detrás de los archivos, así que asumí incorrectamente que es donde se suponía que debía estar. - Vi1i
"Los proveedores remotos deberían ser después de todos los proveedores locales" sería una mejor descripción. - grawity
Totalmente de acuerdo, esto me habría ahorrado un día y medio de problemas. Veré si puedo obtener un cambio en la página. - Vi1i