Questão SSSD / NSS lento ao usar Sudo


Eu tenho um servidor executando o OpenLDAP, e os problemas que estou enfrentando estão com o meu cliente. Meu cliente está executando o SSSD com o NSS.

Na primeira inicialização, não tenho problemas e os comandos sudo são emitidos corretamente.

Eu começo a ter problemas depois de tentar instalar ou modificar um pacote. As vezes aurman vai timeout, outras vezes ele irá baixar imediatamente. Quando ele faz passar o download, ele irá congelar Creating system user accounts..., Creating temporary files...ou Arming ConditionNeedsUpdate....

Abaixo está o resultado de sudo journalctl --follow quando aurman -S accountsservice executado:

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

Abaixo está o resultado de sudo journalctl --follow quando sudo -i é executado:

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 é o meu arquivo 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 é o meu arquivo nsswitch.conf (NOTA: Eu brinquei com o sss nos sudoers, serviços e netgroup e o mesmo 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

Abaixo está o resultado de fazer time sudo strace -r -o trace_5.log sudo echo hi, cada um veio em um momento diferente como eu estava depurando (para reiterar, cada linha é um arquivo diferente, e o atraso de 25s era por sudo ligar):

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

Os dois openat as chamadas eram quando o /etc/lcoale.conf existia, quando removi que ele parou. A questão mais comum foi a recvmsg ligue várias vezes. Mas getent hosts terminou bem. Ainda, getent passwd leva cerca de 25s e o seguinte aparece em 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)

Qualquer ajuda seria muito apreciada...

[EDITAR]

Quando eu corro strace -r -o trace_8 getent passwd Eu recebo:

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

0


origem


Por favor, inclua seu /etc/nsswitch.conf. - grawity
Tenho a atualização, eu esqueci a primeira vez, então obrigado. - Vi1i


Respostas:


Seus módulos nsswitch.conf "passwd" e "group" estão na ordem errada: sss deve ser depois systemd.

Quando o systemd inicia um serviço, ele precisa resolver seu nome de usuário (se houver) para o UID. Quando o dbus-daemon carrega sua configuração, ele também precisa resolver nomes de usuários encontrados em políticas de segurança para UIDs. Isso passa pelo nsswitch da mesma maneira que todas as outras contas de usuário.

Normalmente, esses mapeamentos para todos os serviços do sistema são encontrados em / etc / passwd (que é o módulo "arquivos" do nsswitch), mas talvez devido a uma má decisão (agora revertido no Git), alguns serviços do systemd não criam suas contas de usuário lá - em vez disso, eles solicitam um UID dinâmico através do módulo "systemd" do nsswitch.

Na sua configuração atual, uma rede baseada em passwd módulo (sss) é listado antes do módulo "systemd". Então, sempre que o systemd ou dbus-daemon tentar procurar o UID por ex. systemd-timesyncd, eles acabam passando por SSSD. Mas o SSSD está na fila para começar depois de systemd-timesyncd, que resulta em um deadlock (dependência cíclica, se você quiser).

Embora eu suspeite que não seja a única causa de seus problemas. Mas é quase definitivamente uma causa...


0



Vou testá-lo de manhã. Eu tenho convertido para apenas nslcd e ldap funcionando. Mas eu posso verificar e ver se isso vai fazer a diferença, eu fiz um monte de coisas para depurar, mas isso não é um. - Vi1i
Muito provavelmente, o nslcd não é afetado tanto porque sua inicialização não usa o 'socket activation' baseado em systemd, ao contrário do SSSD. - grawity
Então foi isso ... Eu me sinto aliviada e irritada por ter sido tão fácil. Eu estava saindo da página de autenticação LDAP do ArchWiki. A maioria dos lugares que explicam a configuração mostram brevemente que sss é depois de arquivos, então eu assumi incorretamente que é onde deveria estar. - Vi1i
"Provedores remotos devem ser depois de todos os provedores locais" seria uma melhor descrição. - grawity
Concordo totalmente, isso teria me salvado um dia e meio de problemas. Vou ver se consigo alterar a página. - Vi1i