Bug 1376986

Summary: Depend on nss_nis if NIS support is needed.
Product: [Fedora] Fedora Reporter: Dr. Tilmann Bubeck <tilmann>
Component: ypbindAssignee: Petr Kubat <pkubat>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 25CC: arjun.is, codonell, dj, eloranta, francesco.simula, fweimer, hhorak, jakub, law, mfabian, mmuzila, pfrankli, pkubat, rc040203, r.kruglicky, siddhesh
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ypbind-1.38-6.fc25 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-11-19 21:14:18 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Dr. Tilmann Bubeck 2016-09-17 08:23:02 UTC
Description of problem:
NIS is not working, as nss_nis is not installed. Before fc25 /lib64/libnss_nis.so.2 was part of glibc and is now in a seperate RPM called "nss_nis". This is not installed by default or as a dependency of ypbind (or some other package) or by using "setup". This results in a proper NIS configuration without the NIS users being available.

e.g. ypwhich shows the bound NIS server correctly and also "ypcat passwd" works, but "id some-username-from-NIS" shows "no such user".

Version-Release number of selected component (if applicable):
2.24-3.fc25

How reproducible:
always

Steps to Reproduce:
1. dnf install ypbind
2. setup (and configure NIS)
3. id some-username-from-NIS

Actual results:
"no such user"

Expected results:
the correct output of "id"

Additional info:
This fixed the problem "dnf install nss_nis". I would propose to add nss_nis as a dependency of ypbind.

Comment 1 Florian Weimer 2016-09-17 08:55:41 UTC
This is basically a documentation issue, see bug 1358430.

A straight dependency for ypbind is difficult because you would still have to install nss_nis.i686 manually if on a mixed 32/64 bit system.

Comment 2 Carlos O'Donell 2016-09-21 03:59:04 UTC
(In reply to Florian Weimer from comment #1)
> This is basically a documentation issue, see bug 1358430.
> 
> A straight dependency for ypbind is difficult because you would still have
> to install nss_nis.i686 manually if on a mixed 32/64 bit system.

It would fix the non-mixed cases though, and those are becoming much more common.

I agree that there is an issue of documentation though.

I'm retitling and passing to ypbind for consideration to see what they would like to do.

In summary:

- Bug 1358429 documents that 'nss_nis' package needs installing now.

- This bug, bug 1376986, is open to discuss ways this might be made more automatic e.g. ypbind depends on nss_nis.

Comment 3 Petr Kubat 2016-09-22 08:10:56 UTC
I feel like ypbind should not depend on nss_nis as (if I am not mistaken) it does not need NSS to work. It definitely should be documented somewhere that you need to install nss_nis if you want to use NSS though.

Comment 4 Carlos O'Donell 2016-09-29 18:39:14 UTC
(In reply to Petr Kubat from comment #3)
> I feel like ypbind should not depend on nss_nis as (if I am not mistaken) it
> does not need NSS to work. It definitely should be documented somewhere that
> you need to install nss_nis if you want to use NSS though.

Despite the fact that you could conceivably operate without nss_nis, the point is that it would do all NIS users a benefit if ypbind depended on nss_nis to make all the other APIs NIS-enabled.

Again, requiring nss_nis would simply make user configuration easier. They wouldn't have to go read the documentation to find what they need, it would just work.

We want to go from having glibc _always_ install nss_nis (the old glibc packaging with everything in place) to having ypbind install nss_nis. This streamlines cloud and container installs, and yet keeps things similar to how it used to be for NIS users.

Does that make sense?

Is there a strong technical argument for not having ypbind require nss_nis?

Comment 5 Petr Kubat 2016-10-03 06:02:29 UTC
(In reply to Carlos O'Donell from comment #4)
> We want to go from having glibc _always_ install nss_nis (the old glibc
> packaging with everything in place) to having ypbind install nss_nis. This
> streamlines cloud and container installs, and yet keeps things similar to
> how it used to be for NIS users.

Right, having the users not go through more documentation to fix things might be a better approach. There would be some issues with mixed systems (as Florian already pointed out) so the documentation would still need to be updated.

> Is there a strong technical argument for not having ypbind require nss_nis?

I don't see any reason not to add the requirement from the technical side of things.

Comment 6 Jussi Eloranta 2016-11-04 16:51:10 UTC
This really needs to be fixed! I just wasted couple of hours on trying to figure why NIS authentication does not work. Finally running finger <user> gave a clue about the missing libraries. Whatever the technical details might be, installing ypbind must result in installation of nss_nis.

And note that this was not needed before F25. So I have already started to expect that everything will more or less break with every major upgrade.

Comment 7 Jussi Eloranta 2016-11-05 02:53:24 UTC
That should have read strace finger <user>

Comment 8 Fedora Update System 2016-11-08 14:34:34 UTC
ypbind-1.38-6.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-c99e46d2c2

Comment 9 Fedora Update System 2016-11-09 02:27:18 UTC
ypbind-1.38-6.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-c99e46d2c2

Comment 10 Jussi Eloranta 2016-11-17 17:57:12 UTC
What I am seeing now is that systemctl fails to start ypbind completely! For example, it tries to start it during boot - waits for a long time and then gives up. Then I login as root and do systemctl start ypbind  and that hangs for some time and then ypbind does not start. However, during the time systemctl hangs ypbind is actually running correctly and things like ypcat passwd work fine. As soon as systemctl command ends, ypbind disappears. Also, if I start ypbind by hand (# ypbind &), it works just fine. This is with up to date F25 (with ypbind-1.38-6.fc25.x86_64). This could be something else but it just started recently.

Comment 11 Jussi Eloranta 2016-11-17 17:58:17 UTC
sorry, replace the first systemctl with systemd

Comment 12 Fedora Update System 2016-11-19 21:14:18 UTC
ypbind-1.38-6.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

Comment 13 Ralf Corsepius 2016-11-20 16:07:24 UTC
(In reply to Jussi Eloranta from comment #10)
> What I am seeing now is that systemctl fails to start ypbind completely!

I am now seeing this with ypbind-1.38-6.fc25 as well. Downgrading to ypbind-1.38-5.fc24.x86_64 immediately remedied it.

Comment 14 Francesco Simula 2016-11-23 15:11:07 UTC
(In reply to Ralf Corsepius from comment #13)
> (In reply to Jussi Eloranta from comment #10)
> > What I am seeing now is that systemctl fails to start ypbind completely!
> 
> I am now seeing this with ypbind-1.38-6.fc25 as well. Downgrading to
> ypbind-1.38-5.fc24.x86_64 immediately remedied it.

Same thing here: a freshly installed box with Fedora 25 upgraded from Fedora 24 (where ypbind was working) stopped authenticating the users, with the very same symptoms described in comment #10.

I confirm that the downgrade to ypbind-1.38-5.fc24.x86_64 from ypbind-1.38-6.fc25 restored NIS functions.

Maybe this need be pushed to a different bug?

Comment 15 Ralf Corsepius 2016-11-23 15:45:51 UTC
(In reply to Francesco Simula from comment #14)
> Maybe this need be pushed to a different bug?
See: https://bugzilla.redhat.com/show_bug.cgi?id=1396893