Bug 163964 - yppush fails if updating existing maps from a new NIS master
yppush fails if updating existing maps from a new NIS master
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: ypserv (Show other bugs)
4.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Chris Feist
Jay Turner
: Reopened
Depends On:
Blocks: 198694
  Show dependency treegraph
 
Reported: 2005-07-22 10:01 EDT by Brad Hinson
Modified: 2015-01-07 19:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-17 17:09:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Patch to allow trusted_master to update existing NIS maps (1.21 KB, patch)
2005-07-22 10:03 EDT, Brad Hinson
no flags Details | Diff
Patch against RHEL 4 ypserv (1.28 KB, patch)
2006-07-31 13:12 EDT, Brad Hinson
no flags Details | Diff

  None (edit)
Description Brad Hinson 2005-07-22 10:01:45 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050512 Red Hat/1.7.8-1.1.3.1

Description of problem:
When performing a yppush of existing maps from a new NIS master to an existing NIS slave, say in the event of a catastrophic failure of the NIS master, yppush fails with the error message:

ypserv[13608]: refuse to transfer <<mapname>> from <<ip addr>>, master
is hostname.domain.com

where <<ip addr>> == IP of new NIS master, and hostname.domain.com == the original NIS master.  There are only two ways around this:

1.) Assign the same hostname/IP to the new NIS master, or
2.) Run /usr/lib/yp/ypinit -s to reinit the maps on the NIS slave

At first glance there seems to be a way around this with a trusted_master specified in /etc/ypserv.conf, but according to the man page only new maps are allowed from a trusted master.

The attached patch to server.c allows a trusted_master to update existing maps.  I have heard that this is the default behavior on Solaris, but I have not tested that.  Is allowing a trusted_master to update the existing maps a bad idea, or has it just never come up before?

Version-Release number of selected component (if applicable):
ypserv-2.8-13

How reproducible:
Always

Steps to Reproduce:
1. Configure a NIS master/slave so that yppush succeeds.
2. Start ypserv on a new NIS master with a different hostname/IP
3. Attempt yppush from new master to slave
  

Actual Results:  yppush fails with error message:

ypserv[13608]: refuse to transfer <<mapname>> from <<ip addr>>, master
is hostname.domain.com

where <<ip addr>> == IP of new NIS master, and hostname.domain.com == the original NIS master.

Expected Results:  yppush silently succeeds

Additional info:
Comment 1 Brad Hinson 2005-07-22 10:03:41 EDT
Created attachment 117061 [details]
Patch to allow trusted_master to update existing NIS maps
Comment 3 Brad Hinson 2006-07-31 13:12:08 EDT
Created attachment 133334 [details]
Patch against RHEL 4 ypserv
Comment 17 Chris Feist 2007-08-17 17:09:21 EDT
Resolving bug as WONTFIX because there is a simple work around to the issue.

To switch masters the following commands must be issued.

/usr/lib/yp/ypinit -s newmaster
service ypserv restart

Note You need to log in before you can comment on or make changes to this bug.