Bug 845686 - yppush doesn't update slave server maps
yppush doesn't update slave server maps
Status: CLOSED INSUFFICIENT_DATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: ypserv (Show other bugs)
6.3
x86_64 Unspecified
unspecified Severity high
: rc
: ---
Assigned To: Honza Horak
qe-baseos-daemons
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-03 17:06 EDT by Joshua Weage
Modified: 2013-01-24 11:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-01-24 11:10:14 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Joshua Weage 2012-08-03 17:06:59 EDT
Description of problem:
After updating a password on the master NIS server, rebuilding the maps does not transfer the updated maps to the slave server.

Version-Release number of selected component (if applicable):
2.19.22.el6

How reproducible:
Always

Steps to Reproduce:
1. Setup a NIS master and slave server.  I'm not merging the shadow and gshadow files.
2. Change a user password using passwd.
3. Rebuild the maps by running make in /var/yp/ and the freshly built maps are not pushed to the slave server.
  
Actual results:
[root@ls1 yp]# make
gmake[1]: Entering directory `/var/yp/ansa-usa.com'
gmake[1]: `ypservers' is up to date.
gmake[1]: Leaving directory `/var/yp/ansa-usa.com'
gmake[1]: Entering directory `/var/yp/ansa-usa.com'
Updating shadow.byname...
192.168.2.22: Master's version not newer
Updating netid.byname...
192.168.2.22: Master's version not newer
gmake[1]: Leaving directory `/var/yp/ansa-usa.com'

Expected results:
Updated maps should be pushed to the slave.

Additional info:
[root@ls1 yp]# yppush -d ansa-usa.com -vv shadow.byname
add_slave_server: Key=ls2.ansa-usa.com, Val=ls2.ansa-usa.com, status=1
add_slave_server: Key=ls1.ansa-usa.com, Val=ls1.ansa-usa.com, status=1
YPPUSH INFO: skipping ls1.ansa-usa.com
Start new child (1)
yppush_foreach: host=ls2.ansa-usa.com
ls2.ansa-usa.com has been called.
	->target: ls2.ansa-usa.com
	->domain: ansa-usa.com
	->map: shadow.byname
	->tarnsid: 10720
	->prog: 1073741824
	->master: ls1.ansa-usa.com
	->ordernum: 1344026074
yppush_xfrrespprog_1
yppushproc_xfrresp_1_svc
Status received from ypxfr on 192.168.2.22:
	Transfer not done: Master's version not newer
Child 1 exists
Running Children: 0
all done (0 running childs)

[root@ls2 ansa-usa.com]# ypserv --debug
[ypserv (ypserv) 2.19]

Find securenet: 255.255.0.0 192.168.0.0
ypserv.conf: dns: 0
ypserv.conf: files: 30
ypserv.conf: xfr_check_port: 1
ypserv.conf: 0.0.0.0/0.0.0.0:*:shadow.byname:2
ypserv.conf: 0.0.0.0/0.0.0.0:*:passwd.adjunct.byname:2
ypproc_xfr_2_svc(): [From: 192.168.2.21:940]
	map_parms:
		domain   = "ansa-usa.com"
		map      = "shadow.byname"
		ordernum = 1344026293
		peer     = "ls1.ansa-usa.com"
		transid  = 10940
		prog     = 1073741824
		port     = 941
connect from 192.168.2.21
	ypdb_open("ansa-usa.com", "shadow.byname")
		->Returning OK!
Opening: ansa-usa.com/shadow.byname (0) c539c990
ypdb_close() called
masterOrderNum=1344024367, localOrderNum=1344024367
Map on Master "ls1.ansa-usa.com" is not newer
ypxfr: Master's version not newer
Comment 2 Joshua Weage 2012-08-03 17:13:28 EDT
Notice that the ypserv on the slave gets the masterOrderNum incorrect.
Comment 3 Honza Horak 2012-10-08 07:20:55 EDT
Thank you for reporting. I've tried to reproduce this issue, but without success. Looking at the related code, the time skewing can be involved here. Can you, please, make sure your master/slave machines have time synchronized?
Comment 4 RHEL Product and Program Management 2012-12-14 03:32:57 EST
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 5 Honza Horak 2013-01-24 11:10:14 EST
Since there is no response from the reporter for few months, I'm closing this bug for now. Please, feel free to re-open it if the problem appears again.

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