Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#878625: systemd: NIS users login takes longtime.
269 views
Skip to first unread message
Elimar Riesebieter
Oct 15, 2017, 5:30:03 AM10/15/17
to
* Elimar Riesebieter <ries...@lxtec.de> [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 ;-)
> 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 ;-)
Michael Biebl
Oct 16, 2017, 5:40:03 AM10/16/17
to
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?
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.
>
Marking accordingly.
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Elimar Riesebieter
Oct 17, 2017, 12:30:03 PM10/17/17
to
* Michael Biebl <bi...@debian.org> [2017-10-17 16:38 +0200]:
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;-)
systemd-logind.service. All runs fine now :-)
Elimar
--
Excellent day for drinking heavily.
Spike the office water cooler;-)
Elimar Riesebieter
Oct 17, 2017, 1:40:03 PM10/17/17
to
* Elimar Riesebieter <ries...@lxtec.de> [2017-10-17 18:24 +0200]:
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.
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.
Elimar Riesebieter
Oct 20, 2017, 12:30:03 PM10/20/17
to
Control: reassign -1 nis
Control: retitle -1 "nscd should be a Depends"
* Michael Biebl <bi...@debian.org> [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;-)
Control: retitle -1 "nscd should be a Depends"
* Michael Biebl <bi...@debian.org> [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
Elimar
--
On the keyboard of life you have always
to keep a finger at the escape key;-)
Christian Lauinger
Mar 30, 2018, 4:00:03 AM3/30/18
to
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.
Petter Reinholdtsen
Jun 12, 2019, 8:10:03 AM6/12/19
to
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
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
Petter Reinholdtsen
Jun 12, 2019, 2:10:03 PM6/12/19
to
[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.
> 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.
Petter Reinholdtsen
Jun 12, 2019, 5:00:03 PM6/12/19
to
[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.
0 new messages