ejs@god.goldhill.com (Eric Swenson) (04/22/89)
First of all, my apologies to those on sun-nets@brillig.umd.edu who may have already seen this, but since I'm still stuck, I thought I'd try this newsgroup as well. To set the stage: We have a network of 5 Sun 3/60s and 1 Sun 386i. Up until recently the 3/60s were running SunOS 3.5 and the Sun 386i was running SunOS 4.0.1. One of the 3/60s was the YP master server, and the other 3/60s were YP clients (no slave servers). The 386i was not running YP at all. The YP master server had its own /usr partition and the other 3/60s NFS mounted the /usr on the YP master server. Each of the YP clients, however, had disks and exported their file systems. Each machine mounted the NFS file systems of each of the others. This configuration worked perfectly fine up until... SunOS 4.0.1: I installed SunOS 4.0 on each of the Sun 3/60s and applied the patches for SunOS 4.0.1. Since that time, if the YP master server attempts to mount any NFS file systems from the YP client machines, it hangs. Indeed, the /etc/fstab of the YP master server specifies the mounting of various file systems from the other machines. When I come up in multi-user mode, the system hangs during the "mount -vat nfs" command in rc.local. If I then type ^C, the mount command must abort, for the rest of rc.local gets executed. Of course, the file systems aren't mounted. I did some experimenting, based on a suggestion by Paul O'Neill at OSU (pvo@oce.orst.edu). I would appear that the running of YPBIND trashes the portmap database and/or process. If I come up single user mode and invoke the necessary commands from rc and rc.local up until the portmap/YP-related commands in rc.local, I can perform the following: portmap rpcinfo -p ;; I get the display I would expect ypserv rpcinfo -p ;; I get the display I would expect ypbind rpcinfo -p ;; This hangs. (If I substitute a "mount -vat nfs" for the "rpcinfo -p" command above, I also hang. The mount is what I'm really trying to get to work, but the "rpcinfo -p" demonstrates that things are messed up) If I kill the "rpcinfo -p" process (which is hung) by typing ^C, and then kill the ypbind process (with the kill command), I can reissue the "rpcinfo -p" command and it runs. Paul O'Neil suggested that portmap is getting trashed and that I should place the following two commands in rc.local after the "ypbind" invocation: portmap ypset 128.168.1.211 ; this is the ip address of the yp server I did this and the system still hangs at the "mount -vat nfs" command. Various people have suggested to me that my netmask(s) may be wrong. In fact, I don't think this is the case. I'm using the standard /etc/netmasks file that comes with 4.0 (or 4.0.1) which defines a netmask for 128.32.0.0 (which isn't our network number and thus is a NOP). Our network number is 128.168.0.0. The resulting active netmask, as reported by "ifconfig le0" is 255.255.0.0 with a broadcast address of 128.168.0.0. This should work fine. All machines agree on the netmask. [For those who really care, we are actually subnetting since 128.168.1 is the ethernet which all these machines are connected to, and 128.168.2 is the SLIP interface between an IBM/PC clone and the DDN Internet. But all hosts in the /etc/hosts database and indeed all the ones we ever communicate with are 128.168.1.xxx. Thus the netmask should be fine the way it is, and indeed, it has been working fine for us for all the time we had been running SunOS 3.5.] If anyone can make any additional suggestions I'd really appreciate it. We are currently running with YP (with the same NFS configuration) without problems. But we really want to be running YP and are running into Internet domain name resolution problems running without it. Thanks. Eric Swenson Gold Hill Computers, Inc. (617) 621-3405