Bug 827267

Summary:	ypbind still fails
Product:	[Fedora] Fedora	Reporter:	Dave Close <dave.close>
Component:	ypbind	Assignee:	Honza Horak <hhorak>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	17	CC:	ekanter, hhorak, kklic
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-07-09 10:55:00 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:
Embargoed:

Description Dave Close 2012-06-01 00:46:03 UTC

Description of problem:
May 31 17:16:32 pses04top setsebool[8968]: setsebool:  SELinux is disabled.
May 31 17:16:32 pses04top ypbind: Binding NIS service
May 31 17:17:18 pses04top ypbind: Binding took 46 seconds
May 31 17:17:18 pses04top ypbind: NIS domain: dom1, ypbind not registered with rpcbind.

Version-Release number of selected component (if applicable):
systemd-44-12.fc17.x86_64
ypbind-1.35-2.fc17.x86_64


How reproducible:
Every time.

Steps to Reproduce:
1. systemctl start (or restart) ypbind.service
2.
3.
  
Actual results:
ypbind fails

Expected results:
ypbind succeeds

Additional info:

Comment 1 Honza Horak 2012-06-01 11:38:52 UTC

It works for me with the same builds. From what I see in your syslog output, I'd guess there's some communication problem with ypserv. I have some questions to make a better picture about your environment:

Do you run ypbind/ypserv on the same machine or on two different machines?
Do domain name correspond on client/server?
What is the output of "ypbind -d" and does ypbind work when running this way?
What is the output of "rpcinfo -p" during systemctl start ypbind.service is running (which should take some time according your log)?
Are you using Network Manager or network service?

Comment 2 Dave Close 2012-06-01 18:28:53 UTC

The machine in question has two interfaces, one wired and the other wireless. The wired interface was marked NM_CONTROLLED=no and the wireless one was NM_CONTROLLED=yes and ONBOOT=no. So both NetworkManager and the network service were active. The wired interface was active and was the route to NIS.

Your comments provided the clue that resolved the issue. Running ypbind -d showed that ypbind was not trying to use the wired interface because it detected NetworkManager active and NetworkManager was not controlling the wired interface. Changing that interface to NM_CONTROLLED=yes and restarting NetworkManager allowed ypbind to start and bind properly.

So, while my problem is solved, this seems to indicate to me that merely detecting NetworkManager active should not be sufficient to presume that it is controlling the interface ypbind needs to use.

Comment 3 Honza Horak 2012-07-09 10:55:00 UTC

I've consulted this use-case with Thorsten from upstream. We agreed, that your solution is right (either use -no-dbus or let all interfaces be controlled by NM) and there is probably no way how to make ypbind more clever in this case.

Comment 4 Honza Horak 2012-11-19 13:39:31 UTC

*** Bug 877789 has been marked as a duplicate of this bug. ***