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
Sorry for late response, there was maintainer change. Is the problem still actual?
(In reply to comment #1) > Sorry for late response, there was maintainer change. > > Is the problem still actual? Yes
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?
I no longer use 4.x, so it is no longer a problem for me :-)
(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 ***