Bug#878625: systemd: NIS users login takes longtime.
Am 12.06.19 um 22:47 schrieb Petter Reinholdtsen: > > [Michael Biebl] >> If you know any modules besides libnss_nis and libnss_ldap, please let >> us know. > > I do not _know_, but here is my best guess based on the output from > 'apt-cache search libpam-', 'apt-cache search libnss-' and experience: > > libpam-heimdal > libpam-krb5-migrate-mit > libpam-krb5 > libpam-radius-auth > libpam-python (depending on script used, know debian edu have such script) > libpam-script (depending on script used) > libpam-slurm > libpam-sshauth > libpam-winbind > libnss-lwres > libnss-mdns > libnss-pgsql2 (depending on server location) > libnss-winbind > > Might be useful to check those out. > > It is unclear to me if the login daemon in question uses the PAM system > too. I don't think libpam-* is relevant here. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#878625: systemd: NIS users login takes longtime.
[Michael Biebl] > If you know any modules besides libnss_nis and libnss_ldap, please let > us know. I do not _know_, but here is my best guess based on the output from 'apt-cache search libpam-', 'apt-cache search libnss-' and experience: libpam-heimdal libpam-krb5-migrate-mit libpam-krb5 libpam-radius-auth libpam-python (depending on script used, know debian edu have such script) libpam-script (depending on script used) libpam-slurm libpam-sshauth libpam-winbind libnss-lwres libnss-mdns libnss-pgsql2 (depending on server location) libnss-winbind Might be useful to check those out. It is unclear to me if the login daemon in question uses the PAM system too. -- Happy hacking Petter Reinholdtsen
Bug#878625: systemd: NIS users login takes longtime.
Am 12.06.19 um 20:01 schrieb Petter Reinholdtsen: > [Michael Biebl] >> Afair, libnss-ldapd is nowadays recommended over libnss-ldap. > > Sure, but my point is that this issue affect any nss module (and pam > modules, perhaps) asking processes to look up information over the net, > not only the nis module. > If you know any modules besides libnss_nis and libnss_ldap, please let us know. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#878625: systemd: NIS users login takes longtime.
[Michael Biebl] > Afair, libnss-ldapd is nowadays recommended over libnss-ldap. Sure, but my point is that this issue affect any nss module (and pam modules, perhaps) asking processes to look up information over the net, not only the nis module. > As for libnss-mdns: Doesn't it use the locally installed avahi-daemon > to do the lookups? I'm not sure. I believed it worked without avahi-daemon, but have not invstigated. -- Happy hacking Petter Reinholdtsen
Bug#878625: systemd: NIS users login takes longtime.
Am 12.06.19 um 14:06 schrieb Petter Reinholdtsen: > If so, this problem will affect others, like libnss-ldap and > libnss-mdns, and is not NIS specific. Afair, libnss-ldapd is nowadays recommended over libnss-ldap. As for libnss-mdns: Doesn't it use the locally installed avahi-daemon to do the lookups? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#878625: systemd: NIS users login takes longtime.
Am 12.06.19 um 14:06 schrieb Petter Reinholdtsen: > If I understand the problem correct, systemd changed the setup to block access > to the network for several services used during login, and this break > any NSS module fetching information from a network service, like the NIS > one. More specifically, systemd-logind.service was locked down considerably including IPAddressDeny=any If so, this problem will affect others, like libnss-ldap and > libnss-mdns, and is not NIS specific. It will not affect NSS modules > with a separate daemon connecting to the network service, like libnss-ldapd > and libnss-sss. > > The recommondation to use the Name Service Cache Daemon (nscd) will cause > new and interesting problems with NIS, and is perhaps not the best way to > solve this. The NSCD cache some times will end up in an inconsistent state, > and might cause users to log in with an incomplete set of groups, if I > recall the problem correctly. > > It seem safer to not block all network connections when some of the > "network enabled" NSS modules are active. See Lennart's comment at https://github.com/systemd/systemd/issues/7074#issuecomment-338157851 He suggests that the nis package could ship a drop-in config snippet in /lib/systemd/system/systemd-logind.service.d/ which turns off that sandbox feature. This seems like a reasonable fix that would be worthwile having in buster in case anyone still cares for the nis package. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#878625: systemd: NIS users login takes longtime.
If I understand the problem correct, systemd changed the setup to block access to the network for several services used during login, and this break any NSS module fetching information from a network service, like the NIS one. If so, this problem will affect others, like libnss-ldap and libnss-mdns, and is not NIS specific. It will not affect NSS modules with a separate daemon connecting to the network service, like libnss-ldapd and libnss-sss. The recommondation to use the Name Service Cache Daemon (nscd) will cause new and interesting problems with NIS, and is perhaps not the best way to solve this. The NSCD cache some times will end up in an inconsistent state, and might cause users to log in with an incomplete set of groups, if I recall the problem correctly. It seem safer to not block all network connections when some of the "network enabled" NSS modules are active. -- Happy hacking Petter Reinholdtsen
Bug#878625: systemd: NIS users login takes longtime.
On Fri, 20 Oct 2017 18:25:03 +0200 Elimar Riesebieter wrote: > Control: reassign -1 nis > Control: retitle -1 "nscd should be a Depends" > > > * Michael Biebl [2017-10-16 11:27 +0200]: > > > Control: forwarded -1 https://github.com/systemd/systemd/issues/707 4 > > > > Am 15.10.2017 um 10:55 schrieb Elimar Riesebieter: > > > Package: systemd > > > Version: 235-2 > > > Severity: normal > > > > > > Login as a NIS user journalctl tells: > > > > > > systemd-logind[666]: do_ypcall: clnt_call: RPC: Unable to send; errno = Operation not permitted > > > pam_systemd(login:session): Failed to create session: Connection timed out > > > > > > User is logged in after a while and there is no /run/user/UID > > > > > > Running 234-3 from testing runs just fine. > > > > > > > Looks like https://github.com/systemd/systemd/issues/7074 > > Installed nscd as proposed from Poettering. All runs fine now. > > Elimar > -- > On the keyboard of life you have always > to keep a finger at the escape key;-) I had the same issue with the login since I updated to kernel 4.15. Installing nscd fixed it - thx ! -- Grüße / Regards Christian visit http://www.lauinger-clan.de Realität ist, wenn Du's nicht mit der Maus wegklicken kannst.
Bug#878625: systemd: NIS users login takes longtime.
Control: reassign -1 nis Control: retitle -1 "nscd should be a Depends" * Michael Biebl [2017-10-16 11:27 +0200]: > Control: forwarded -1 https://github.com/systemd/systemd/issues/7074 > > Am 15.10.2017 um 10:55 schrieb Elimar Riesebieter: > > Package: systemd > > Version: 235-2 > > Severity: normal > > > > Login as a NIS user journalctl tells: > > > > systemd-logind[666]: do_ypcall: clnt_call: RPC: Unable to send; errno = > > Operation not permitted > > pam_systemd(login:session): Failed to create session: Connection timed out > > > > User is logged in after a while and there is no /run/user/UID > > > > Running 234-3 from testing runs just fine. > > > > Looks like https://github.com/systemd/systemd/issues/7074 Installed nscd as proposed from Poettering. All runs fine now. Elimar -- On the keyboard of life you have always to keep a finger at the escape key;-) signature.asc Description: PGP signature
Bug#878625: systemd: NIS users login takes longtime.
* Elimar Riesebieter [2017-10-17 18:24 +0200]: > * Michael Biebl [2017-10-17 16:38 +0200]: > > > Am 15.10.2017 um 11:15 schrieb Elimar Riesebieter: > > > * Elimar Riesebieter [2017-10-15 10:55 +0200]: > > > > > >> Package: systemd > > >> Version: 235-2 > > >> Severity: normal > > >> > > >> Login as a NIS user journalctl tells: > > >> > > >> systemd-logind[666]: do_ypcall: clnt_call: RPC: Unable to send; errno = > > >> Operation not permitted > > >> pam_systemd(login:session): Failed to create session: Connection timed > > >> out > > >> > > >> User is logged in after a while and there is no /run/user/UID > > >> > > >> Running 234-3 from testing runs just fine. > > >> > > >> Running a kernel with "CONFIG_CGROUP_BPF is not set" there are no > > >> errors and the NIS user is logged in quite fast. But then systemd > > >> tells: > > >> > > >> File /lib/systemd/system/systemd-udevd.service:32 configures an IP > > >> firewall (IPAddressDeny=any), but the local system does not support > > >> BPF/cgroup based firewalling. > > > > > > Commenting out /lib/systemd/system/systemd-udevd.service:32 and > > > after a restart doesn't help either. > > > > Could you also comment that out in > > /lib/systemd/system/systemd-logind.service and retry? > > Commented "IPAddressDeny=any" in both systemd-udevd.service and > systemd-logind.service. All runs fine now :-) Commenting "IPAddressDeny=any" in systemd-logind.service only runs fine as well. -- From The Collaborative International Dictionary of English v.0.48 [gcide]: . arsehole \arse"hole`\ ([aum]rs"h[=o]l`), n. 1. execretory opening at the end of the alimentary canal. signature.asc Description: PGP signature
Bug#878625: systemd: NIS users login takes longtime.
* Michael Biebl [2017-10-17 16:38 +0200]: > Am 15.10.2017 um 11:15 schrieb Elimar Riesebieter: > > * Elimar Riesebieter [2017-10-15 10:55 +0200]: > > > >> Package: systemd > >> Version: 235-2 > >> Severity: normal > >> > >> Login as a NIS user journalctl tells: > >> > >> systemd-logind[666]: do_ypcall: clnt_call: RPC: Unable to send; errno = > >> Operation not permitted > >> pam_systemd(login:session): Failed to create session: Connection timed out > >> > >> User is logged in after a while and there is no /run/user/UID > >> > >> Running 234-3 from testing runs just fine. > >> > >> Running a kernel with "CONFIG_CGROUP_BPF is not set" there are no > >> errors and the NIS user is logged in quite fast. But then systemd > >> tells: > >> > >> File /lib/systemd/system/systemd-udevd.service:32 configures an IP > >> firewall (IPAddressDeny=any), but the local system does not support > >> BPF/cgroup based firewalling. > > > > Commenting out /lib/systemd/system/systemd-udevd.service:32 and > > after a restart doesn't help either. > > Could you also comment that out in > /lib/systemd/system/systemd-logind.service and retry? Commented "IPAddressDeny=any" in both systemd-udevd.service and systemd-logind.service. All runs fine now :-) Elimar -- Excellent day for drinking heavily. Spike the office water cooler;-) signature.asc Description: PGP signature
Bug#878625: systemd: NIS users login takes longtime.
Am 15.10.2017 um 11:15 schrieb Elimar Riesebieter: > * Elimar Riesebieter [2017-10-15 10:55 +0200]: > >> Package: systemd >> Version: 235-2 >> Severity: normal >> >> Login as a NIS user journalctl tells: >> >> systemd-logind[666]: do_ypcall: clnt_call: RPC: Unable to send; errno = >> Operation not permitted >> pam_systemd(login:session): Failed to create session: Connection timed out >> >> User is logged in after a while and there is no /run/user/UID >> >> Running 234-3 from testing runs just fine. >> >> Running a kernel with "CONFIG_CGROUP_BPF is not set" there are no >> errors and the NIS user is logged in quite fast. But then systemd >> tells: >> >> File /lib/systemd/system/systemd-udevd.service:32 configures an IP firewall >> (IPAddressDeny=any), but the local system does not support BPF/cgroup based >> firewalling. > > Commenting out /lib/systemd/system/systemd-udevd.service:32 and > after a restart doesn't help either. Could you also comment that out in /lib/systemd/system/systemd-logind.service and retry? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#878625: systemd: NIS users login takes longtime.
Control: forwarded -1 https://github.com/systemd/systemd/issues/7074 Am 15.10.2017 um 10:55 schrieb Elimar Riesebieter: > Package: systemd > Version: 235-2 > Severity: normal > > Login as a NIS user journalctl tells: > > systemd-logind[666]: do_ypcall: clnt_call: RPC: Unable to send; errno = > Operation not permitted > pam_systemd(login:session): Failed to create session: Connection timed out > > User is logged in after a while and there is no /run/user/UID > > Running 234-3 from testing runs just fine. > Looks like https://github.com/systemd/systemd/issues/7074 Marking accordingly. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#878625: systemd: NIS users login takes longtime.
* Elimar Riesebieter [2017-10-15 10:55 +0200]: > Package: systemd > Version: 235-2 > Severity: normal > > Login as a NIS user journalctl tells: > > systemd-logind[666]: do_ypcall: clnt_call: RPC: Unable to send; errno = > Operation not permitted > pam_systemd(login:session): Failed to create session: Connection timed out > > User is logged in after a while and there is no /run/user/UID > > Running 234-3 from testing runs just fine. > > Running a kernel with "CONFIG_CGROUP_BPF is not set" there are no > errors and the NIS user is logged in quite fast. But then systemd > tells: > > File /lib/systemd/system/systemd-udevd.service:32 configures an IP firewall > (IPAddressDeny=any), but the local system does not support BPF/cgroup based > firewalling. Commenting out /lib/systemd/system/systemd-udevd.service:32 and after a restart doesn't help either. Elimar -- Learned men are the cisterns of knowledge, not the fountainheads ;-)
