Description of problem: 'getent' ignores netgroups in /etc/passwd when listing users with passwd_compat in RHEL8 Version-Release number of selected component (if applicable): RHEL 8.7 glibc-2.28-211.el8.x86_64 How reproducible: Always Steps to Reproduce: 1. Configure RHEL 8.7 as NIS client 2. Configure 'compat' mode in /etc/nsswitch.conf: --- passwd: compat group: compat shadow: files netgroup: files nis --- 3. Add netgroup entries at the bottom of /etc/passwd file: --- +@netgroup1::0:0::: +@netgroup2::0:0::: --- 4. Run 'getent passwd' command, it doesn't show list of users which are part of netgroups mentioned in /etc/passwd file. Only local users list is displayed, users in the netgroup don't get enumerated. Actual results: Only the local users from /etc/passwd get listed. Users in the netgroup don't get enumerated. Expected results: Users in the netgroup should be listed too. Additional info: Similar setup seems to be working just fine in RHEL 7glibc-2.28-211.el8.x86_64
(In reply to Akshay Sakure from comment #0) > Description of problem: > 'getent' ignores netgroups in /etc/passwd when listing users with > passwd_compat in RHEL8 Yes, this should work just like it does in RHEL7. Please note that the glibc package no longer provides the NSS NIS plugin that is needed by "compat" support. Have you installed the required "nss_nis" package to provide the new IPv4/IPv6-enabled TIRPC-based NIS client support?
I think strace shows that nss_nis is being loaded, so that can't be it. I'm afraid we'll need access to a reproduction environment to track this one down. Akshay, would you be able to provide us with access to an environment? Thanks.
Florian, allow me a couple of days, let me try build a reproducer environment so that you can have access to it.
Development has reviewed this issue and while we are able to reproduce problems that resemble the customers problems, we are also able to correct those issues by using standard NIS tooling as intended. Developer notes are as follows: ~~~ I was able to reproduce this on my local system. However, I was also able to fix it using YP tools as in my case it was a misconfigured YP server that caused this problem. I'll go over what I found here, in case you're having the same problem. First, I found that a "ypset -ypsetme" was required on both server and host before any NIS commands would succeed. This is not covered in most public NIS configuration docs. Second, I had to remember to run "make" in /var/yp *and* restart the ypserv service after editing /etc/passwd on the server. My tests: serv7$ getent passwd (shows all entries) client8$ getent passwd (netgroup entries missing) client8$ ypcat passwd (shows all entries) client8$ ypmatch nisuser3 passwd (no entry returned!) serv7$ ypmatch nisuser3 passwd (none here either?) This is where I rebuild the YP maps and restarted the YP server. serv7$ ypmatch nisuser3 passwd (shows entry) client8$ ypmatch nisuser3 passwd (shows entry) client8$ getent passwd (netgroup entries present) In summary, "getent passwd" does not use "ypcat passwd"; it reads the netgroups from the YP server and then uses passwd.byname to fill in each entry. So, please use ypmatch to verify that passwd.byname is working. ~~~ Please tell us if this helps you resolve your issues. If this doesn't resolve your issue then we will need more information about your configuration.