RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 845686 - yppush doesn't update slave server maps
Summary: yppush doesn't update slave server maps
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: ypserv
Version: 6.3
Hardware: x86_64
OS: Unspecified
unspecified
high
Target Milestone: rc
: ---
Assignee: Honza Horak
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-08-03 21:06 UTC by Joshua Weage
Modified: 2013-01-24 16:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-01-24 16:10:14 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Joshua Weage 2012-08-03 21:06:59 UTC 
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 21:13:28 UTC 
Notice that the ypserv on the slave gets the masterOrderNum incorrect.
Comment 3 Honza Horak 2012-10-08 11:20:55 UTC 
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 Program Management 2012-12-14 08:32:57 UTC 
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 16:10:14 UTC 
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.