schemers@vela.acs.oakland.edu (Roland Schemers III) (03/24/91)
Hello! I'm looking into an NFS auto mounter for Ultrix. Two questions: 1. Does the one that comes with Ultrix require yellow pages to be running ? (we are using bind/hesiod) 2. Is there a PD version out there on gatekeeper or uunet? Thanx! Roland -- Roland J. Schemers III Systems/Network Manager schemers@vela.acs.oakland.edu (Ultrix) Oakland University schemers@argo.acs.oakland.edu (VMS) Rochester, MI 48309-4401 You can tune a piano, but you can't tuna VMS! (313)-370-4323
iglesias@draco.acs.uci.edu (Mike Iglesias) (03/24/91)
In article <5513@vela.acs.oakland.edu> schemers@vela.acs.oakland.edu (Roland Schemers III) writes: >Hello! I'm looking into an NFS auto mounter for Ultrix. Two >questions: > >1. Does the one that comes with Ultrix require yellow pages to > be running ? (we are using bind/hesiod) No. You can use a local file, YP, or both to drive automount. >2. Is there a PD version out there on gatekeeper or uunet? Yes, on usc.edu you can get amd. It's supposed to be better than automount, but I haven't tried it yet. Mike Iglesias University of California, Irvine Internet: iglesias@draco.acs.uci.edu BITNET: iglesias@uci uucp: ...!ucbvax!ucivax!iglesias
jag@cs.mu.oz.au (John Gilmour) (03/26/91)
In article <27EC1C6E.5742@orion.oac.uci.edu>, iglesias@draco.acs.uci.edu (Mike Iglesias) writes: > In article <5513@vela.acs.oakland.edu> schemers@vela.acs.oakland.edu (Roland Schemers III) writes: > >1. Does the one that comes with Ultrix require yellow pages to > > be running ? (we are using bind/hesiod) > > No. You can use a local file, YP, or both to drive automount. > > >2. Is there a PD version out there on gatekeeper or uunet? > > Yes, on usc.edu you can get amd. It's supposed to be better than > automount, but I haven't tried it yet. If you run it on a MIPS machine you'll need to rebuild your kernel with a fixed nfs_subr.o module. 4.0 and 4.1 versions are available from dip.cs.wisc.edu. Plea to DEC: please fix this module, it's supposed to be a simple fix.
cks@hawkwind.utcs.toronto.edu (Chris Siebenmann) (03/30/91)
jag@cs.mu.oz.au (John Gilmour) writes: [...] | If you run it on a MIPS machine you'll need to rebuild your kernel | with a fixed nfs_subr.o module. 4.0 and 4.1 versions are available | from dip.cs.wisc.edu. Does anyone know what the fix consists of? We're source licensed, and I'd much rather patch the source rather than run with a binary object file I can't regenerate or modify further if I need to. -- "This is what separates us system programmers from the application programmers: we can ruin an entire machine and then recover it, they can only ruin their own files and then get someone else to restore them" - Geoff Collyer cks@hawkwind.utcs.toronto.edu ...!{utgpu,utzoo,watmath}!utgpu!cks
jag@cs.mu.oz.au (John Gilmour) (03/30/91)
In article <1991Mar29.210846.21818@jarvis.csri.toronto.edu>, cks@hawkwind.utcs.toronto.edu (Chris Siebenmann) writes: > jag@cs.mu.oz.au (John Gilmour) writes: > [...] > | If you run it on a MIPS machine you'll need to rebuild your kernel > | with a fixed nfs_subr.o module. 4.0 and 4.1 versions are available > | from dip.cs.wisc.edu. > > Does anyone know what the fix consists of? We're source licensed, and > I'd much rather patch the source rather than run with a binary object > file I can't regenerate or modify further if I need to. > From owner-amd-workers%acl%LANL.GOV@munnari.cs.mu.oz Thu Oct 25 07:25:19 1990 From: cole%cs.wisc.edu@munnari.oz (Bruce Cole) Received: by dip.cs.wisc.edu; Wed, 24 Oct 90 15:33:15 -0500 To: amd-workers%acl@LANL.GOV Subject: The reason why amd has problems on Ultrix MIPS processors Status: O In /usr/include/fs/nfs/nfs.h, the structure declaration for NFS file handles (fhandle_t) is incorrect. This causes sizeof(struct fhandle_t) to yield 36 instead of the proper size (32). The Ultrix kernel code that handles the caching of NFS file handles depends upon this size and because of the mis-declaration, it breaks when amd is used. Fixing this problem fixes the mount point traversing behavior under Ultrix. Workarounds: For Ultrix 3.1, change the rfind() routine in sys/fs/nfs/nfs_subr.c to use the proper file handle size. *** /tmp/,RCSt1a09412 Wed Oct 24 15:14:09 1990 --- /tmp/,RCSt2a09412 Wed Oct 24 15:14:14 1990 *************** *** 748,754 **** --- 748,760 ---- for (gp = ih->gh_chain[0]; gp != (struct gnode *)ih; gp = gp->g_forw) { if (gno == gp->g_number && fsid == gp->g_dev) { + #ifdef UW + /* For the MIPS architecture, sizeof(*fh) = 36, + instead of the expected 32. */ + if (bcmp(vtofh((struct vnode *)gp), fh, NFS_FHSIZE)) { + #else if (bcmp(vtofh((struct vnode *)gp), fh, sizeof(*fh))) { + #endif UW if (cachedebug) printf("rfind: rejected stale gnode, #%d, 0x%x\n", gp->g_number, gp); continue; For Ultrix 4.0, make the equivalent change to the nfs_match() routine in sys/fs/nfs/nfs_subr.c: *** /tmp/,RCSt1a09579 Wed Oct 24 15:27:21 1990 --- nfs_subr.c Wed Oct 24 15:25:25 1990 *************** *** 607,613 **** --- 607,619 ---- struct rnode_data *rdp; { return(!bcmp(vtofh((struct vnode *)gp), rdp->rn_fh, + #ifdef UW + /* For the MIPS architecture, sizeof(*fh) = 36, + instead of the expected 32. */ + NFS_FHSIZE)); + #else sizeof(fhandle_t))); + #endif UW }