Bug 243155 - Can not push new maps to slave servers
Can not push new maps to slave servers
Status: CLOSED DUPLICATE of bug 199236
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: ypserv (Show other bugs)
4.4
All Linux
low Severity low
: ---
: ---
Assigned To: Honza Horak
qe-baseos-daemons
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-07 12:16 EDT by James Pearson
Modified: 2012-05-14 11:02 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-05-14 11:02:13 EDT
Type: ---
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 James Pearson 2007-06-07 12:16:33 EDT
Description of problem:

If I create a new NIS map on a master NIS server, I can not push the map out to
 slave NIS servers

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

ypserv-2.13-14

How reproducible:

Every time

Steps to Reproduce:
1. Create a new NIS map on the NIS master
2. Run 'cd /var/yp; make'
3. Map fails to be transfered to any RHEL4 slave NIS server
  
Actual results:

Slave servers log:

refused connect from x.x.x.x:port to procedure ypproc_xfr (domainname,mapname;-4)

Expected results:

New map to transfer

Additional info:

On the slave servers, I have added to /etc/ypserv.conf the line:

trusted_master: name.of.master.server

which according to the man page says:

 trusted_master: server
        If this option is set on a slave server, new maps from the host
        server  will  be  accepted  as  master. The default is, that no
        trusted master is set and new maps will not be accepted.
        Example:
        trusted_master: ypmaster.example.org

However, looking at the source code, it appears the check for 'trusted_master'
is never reached as is_valid() returns '-4' before trusted_master is checked in
ypproc_xfr_2_svc()

This seems to be as a result of patch 'ypserv-2.11-nomap.patch'

If I rebuild ypserv without this patch, then I can successfully push new maps to
slave servers (with trusted_master defined in /etc/ypserv.conf)

There is nothing in the changelog for ypserv that mentions what this patch is
for, but it should not be preventing the pushing of new maps when the slave
servers explictly set trusted_master

I have not tried RHEL4.5, but looking at the ypserv-2.13-18 src, I can't see any
changes wrt to this issue
Comment 1 Vitezslav Crhonek 2008-08-26 07:08:57 EDT
Sorry for late response, there was maintainer change.

Is the problem still actual?
Comment 2 James Pearson 2008-09-04 09:21:09 EDT
(In reply to comment #1)
> Sorry for late response, there was maintainer change.
> 
> Is the problem still actual?

Yes
Comment 3 Honza Horak 2012-05-14 10:32:17 EDT
I believe this is a duplicate of bug #199236, which was fixed long time ago. Observing current RHEL-4.9 code (ypserv-2.13-19.el4_8.2):

 if ((status < 1 && status != -4) &&
		((sin->sin_addr.s_addr != oldaddr) || (status != oldstatus)))
	syslog (LOG_WARNING,
		"refused connect from %s:%d to procedure %s (%s,%s;%d)\n",
		inet_ntoa (sin->sin_addr), ntohs (sin->sin_port),
		ypproc_name (rqstp->rq_proc),
		domain ? domain : "", map ? map : "", status);

.. it's impossible to get an error like this:

refused connect from x.x.x.x:port to procedure ypproc_xfr (domainname,mapname;-4)

Is this issue really a problem even in an updated version?
Comment 4 James Pearson 2012-05-14 10:37:40 EDT
I no longer use 4.x, so it is no longer a problem for me :-)
Comment 5 Honza Horak 2012-05-14 11:02:13 EDT
(In reply to comment #4)
> I no longer use 4.x, so it is no longer a problem for me :-)

Thanks, I'm closing as duplicate then.

*** This bug has been marked as a duplicate of bug 199236 ***

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