From owner-freebsd-bugs  Thu Oct 15 14:43:54 1998
Return-Path: <owner-freebsd-bugs@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id OAA12196
          for freebsd-bugs-outgoing; Thu, 15 Oct 1998 14:43:54 -0700 (PDT)
          (envelope-from owner-freebsd-bugs@FreeBSD.ORG)
Received: (from wpaul@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id OAA12183;
          Thu, 15 Oct 1998 14:43:52 -0700 (PDT)
          (envelope-from wpaul)
Date: Thu, 15 Oct 1998 14:43:52 -0700 (PDT)
From: Bill Paul <wpaul>
Message-Id: <199810152143.OAA12183@hub.freebsd.org>
To: jin@eubie.lbl.gov, wpaul, freebsd-bugs
Subject: Re: bin/8338
Sender: owner-freebsd-bugs@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

Synopsis: ypserv fails to get master name for ypxfr

State-Changed-From-To: open-closed
State-Changed-By: wpaul
State-Changed-When: Thu Oct 15 14:21:37 PDT 1998
State-Changed-Why: 
The code is correct. There is no bug here. The problem is a mis-configuration
on your part, or a misunderstanding of how NIS works.

The ypproc_master_2_svc() routine looks up the name of the master
server by checking the YP_MASTER_NAME key which is encoded into the
local copy of the map. It does _NOT_ trust the hostname supplied by
the in the YPPROC_XFR request because the host that sends the request
might lie, and trick the slave into transfering a map from a bogus host.
  
You can look at the contents of the map on the slave using the yp_mkdb
command. Do the following:
  
# cd /var/yp/<your domain>
# yp_mkdb -u passwd.byname | grep YP_MASTER_NAME

You will see that there is a special record in the map database with a 
key of YP_MASTER_NAME and a data field with the name of the master host.  
This is the information that ypserv uses to determine the master name 
when it receives a YPPROC_XFR request. It deliberately ignores the hostname  
specified in the request arguments because it knows that it might be wrong,
and the information in the map is always supposed to be correct.

When you first initialize a slave, you need to use ypxfr to transfer copies
manually onto the slave from the master. If you have FreeBSD 3.0, then
the ypinit script will do this for you: use ypinit -s. After you do this,
then the FreeBSD slave server will contain the correct YP_MASTER_NAME
information.

There are several reasons why may be having problems:

- You previously set up the FreeBSD host as an NIS master server and
  did not erase the old maps before turning the machine into a slave.
- The maps on the NIS master server have the wrong YP_MASTER_NAME
  in them. To check, do a yppoll passwd.byname from a client that is
  bound to the master name. If yppoll reports the wrong information,
  then you should rebuild the maps on the master server.


I have been using a FreeBSD 3.0 machine as an NIS slave server for some
time now using a SunOS 4.1.3 master, and it works perfectly once the slave
has been initialized correctly. I would strongly suggest deleting all of
the map files on the FreeBSD slave server and using ypinit -s to reinitialize
the server.


-Bill

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message