Bug 2152376
| Summary: | systemd-userdbd fails with NIS logins | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Terry Barnaby <terry1> | ||||
| Component: | nss_nis | Assignee: | Ondřej Sloup <osloup> | ||||
| Status: | NEW --- | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 37 | CC: | fedoraproject, filbranden, fjanus, lnykryn, mmuzila, msekleta, odubaj, rc040203, ryncsn, systemd-maint, yuwatana, zbyszek | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | Type: | Bug | |||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Terry Barnaby
2022-12-11 10:43:32 UTC
Can you log in successfully if you boot into multi-user.target and login on tty? If I login as a NIS user on a virtual console terminal, then yes I can login, but as per the sddm login session there is no /run/user/<userid> directory created and all of the XDG_* environment variables are not set. If I run "systemctl restart systemd-userdbd" then after this logins on both a console tty and through sddm are fine. As a workaround i have created a simple systemd unit file to restart systemd-userdbd after ypbind has started. I will attach this. Created attachment 1932122 [details]
Workaround systemd-userdbd-restart.service
This is copied to /usr/lib/systemd/system/ and then:
"systemctl enable systemd-userdbd-restart" is run to enable it
at the next boot.
nss_nis already has an override for systemd-userdbd.service: /usr/lib/systemd/system/systemd-userdbd.service.d/nss_nis.conf If something more needs to be added, it should be added there. I don't think that anything useful can be added to /usr/lib/systemd/system/systemd-userdbd.service.d/nss_nis.conf. We could only add something to make it start after ypbind but I think (others have said) this would yield a dependency loop and I suspect systemd-userdbd needs to be running well before ypbind and networking anyway and not have a network timeout possibility. I believe the real issue is within the systemd-userdbd daemon itself. If NIS is in use it should attempt to connect/reconnect while running. I presume it must do this already for other network authentication systems such as LDAP. I looked into this some more. The first issue is why 'userdbctl user myusername' says 'User myusername does not exist.' but 'userdbctl --service=x user myusername' returns some data. userdb has a concept of "services", provided by listening sockets in a well-known directory. One of them is /run/systemd/userdb/io.systemd.Multiplexer, which effectively connects to userdbd.service. But userdb also implements a fallback to nss for compatibility with normal lookups, and not as a "service", but as a separate step. When --service is not specified, userdbctl just connects to /run/systemd/userdb/io.systemd.Multiplexer and the query is resolved on the server side. When --service is specified, userdbctl tries to connect to /run/systemd/userdb/x, which fails. It then implements the nss fallback on client side. This is possibly a buglet: I'm not sure if the nss fallback should be used at all when a specific service is requested. But it isn't directly relevant for this bug: it just explains why the workaround works. The real issue is why the lookup via userdbd.service fails. The difference is that with the client side lookup, we start a fresh process every time. With the server side lookup, there's a long-running process. userdbd doesn't do any explicit caching, in case of the nss fallback it always just calls getpwnam_r(). The reasons that this does not work is that apparently nss-nis does not update the state after ypbind has been started. I don't know the nss-nis code very well, but it seems to call yp_get_default_domain() [1]. That does some caching… [2]. My guess is that this goes wrong somewhere and the module does not notice that ypbind has been started or the domain name has changed. [1] https://github.com/thkukuk/libnss_nis/blob/master/src/nis-network.c#L217 [2] https://sources.debian.org/src/libnsl/1.3.0-2/src/yp_get_default_domain.c/?hl=32#L32 This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component. *** Bug 2160898 has been marked as a duplicate of this bug. *** |