SSSD / NSS lento al usar Sudo


0

Tengo un servidor que ejecuta OpenLDAP, y los problemas con los que me encuentro están relacionados con mi cliente. Mi cliente está ejecutando SSSD con NSS.

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

Empiezo a tener problemas después de intentar instalar o modificar un paquete. Algunas veces aurmanse agota el tiempo de espera, otras veces se descarga inmediatamente. Cuando sí lo hace pasar la descarga, se congelará en Creating system user accounts..., Creating temporary files...o Arming ConditionNeedsUpdate....

A continuación se muestra el resultado de sudo journalctl --followcuando se aurman -S accountsserviceejecuta:

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 --followcuándo sudo -ise 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 los sudoers, servicios 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 hacerlo 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 sudollamada):

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

Las dos openatllamadas fueron cuando /etc/lcoale.conf existía, cuando eliminé eso se detuvo. El problema más común fue la recvmsgllamada varias veces. Pero getent hoststerminó bien. Sin embargo, getent passwdlleva unos 25 años y lo siguiente aparece 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 passwdme sale:

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

Por favor incluya su /etc/nsswitch.conf.
Grawity

Lo tengo actualizado, lo olvidé la primera vez, así que gracias.
Vi1i

Respuestas:


0

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

Cuando systemd inicia un servicio, debe 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 a 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 de "archivos" nsswitch), pero quizás debido a una mala decisión (ahora revertida en Git) , algunos servicios de systemd no crean sus cuentas de usuario allí - en su lugar, solicitan un UID dinámico a través del módulo nsswitch "systemd".

En su configuración actual, un módulo passwd (sss) basado en red aparece antes del módulo "systemd". Entonces, cuando systemd o dbus-daemon intentan buscar el UID, por ejemplo systemd-timesyncd, terminan pasando por SSSD. Pero SSSD está en cola para comenzar después de systemd-timesyncd, lo que resulta en un punto muerto (dependencia cíclica, si lo desea).

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


Lo probaré por la mañana. Lo he convertido a nslcd y ldap funcionando. Pero puedo verificar y ver si eso marcará la diferencia, hice muchas cosas para depurar, pero esa no es una.
Vi1i

Lo más probable es que nslcd no se vea tan afectado porque su inicio no utiliza la 'activación de socket' basada en systemd, a diferencia de SSSD.
Grawity

Así que esto fue todo ... Me siento aliviado e irritado porque fue tan fácil. Estaba saliendo de la página de autenticación de ArchWiki LDAP. La mayoría de los lugares que explican la configuración solo muestran brevemente que sss está detrás de los archivos, por lo que asumí incorrectamente que es donde se suponía que debía estar.
Vi1i

"Los proveedores remotos deberían estar detrá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
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.