Date: Tue, 11 May 1999 09:43:54 -0700 (PDT) From: David Wolfskill <dhw@whistle.com> To: bwithrow@nortelnetworks.com, hackers@FreeBSD.ORG Cc: bwithrow@BayNetworks.COM Subject: Re: AMD: local overrides on NIS maps? Message-ID: <199905111643.JAA20152@pau-amma.whistle.com> In-Reply-To: <199905101741.NAA07716@tuva.engeast.baynetworks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>Date: Mon, 10 May 1999 13:41:54 -0400
>From: Robert Withrow <bwithrow@nortelnetworks.com>
>I need to be able to locally (or on an OS basis) override mount options
>in AMD maps, but I've been unsuccessful.
>Assume I have a amd.conf that reads, in part:
> [ /foo/home ]
> map_name = foo_home
>and a NIS map (foo_home) that contains exactly:
> bwithrow -type:=nfs;rfs:=/home/bwithrow; rhost:=pizzahut
>I want to restrict NFS to be version 2 and UDP for certain hosts
>(say freebsd ones ;-) *without* modifying the map, because that
>may is centrally maintained and I don't want system/os specific
>things in it. I might want to modify other things (like rsize
>and wsize) on a specific machine basis, and that *clearly* shouldn't
>be in the map.
>As far as I can tell, nothing I put in amd.conf will affect the mount
>options in this map. (And before suggesting doing that, please try
>it out on a system to be sure it works!)
>Any suggestions on how I can override mount options locally?
Well, here's what I've been doing to deal with a similar problem.
First, I inherited a fair amount of NFS & amd stuff when I got here.
Part of that was the use of per-host files for the amd maps. Since my
background is more Sun-oriented, it didn't take too long for my
frustration with the inability of most of the boxes on the net to know
of my home directory's existence to overcome my laziness.
So I implemented a set of NIS maps, along with an "amd.master" map.
(That's why 3.x has the stuff about amd_map_program in the rc.conf*
files.)
And when we started putting 3.x machines on the Net, things were getting
unpleasant.
One of the maps I use is called (for lack of a better name) "amd.n", and
looks like:
#
# net.map:
#
/defaults rhost:=${key}
* host!=${key};os==freebsd3;type:=host;fs:=${autodir}/${rhost}/root;opts:=vers=2,proto=udp,nosuid,grpid,soft,intr \
host!=${key};os!=freebsd3;type:=host;fs:=${autodir}/${rhost}/root;opts:=nfsv2,noconn,nosuid,grpid,soft,intr \
host==${key};type:=link;fs:=/
(The main NFS server on our net is (still) running 2.2.6-R, at this point.
I'll need to twek the amd maps somewhat when it comes time to upgrade
the OS on that machine.)
Also, I recall poking around (back when I was working on the
construction of that thing) trying to figure out a way to cause the
system to tell me what the mount options for a given mount really were.
Unfortunately, I was unable to find a place where that information was
stashed -- certainly from user-land. :-( But it *would* be of use to
be able to run a goofy little program that would provide a definitive
answer to the question "What mount options really *are* in use for
such-and-such a mount?" If I could find where the information is, I'd
even be willing to cobble such a beastie up (& contribute it, if anyone
would have it).
One of the other things I inherited was the use of /usr/local as an
NFS-mounted network-wide FS. However, some folks wanted their own
/usr/local; an example of coping with that is:
cvs[1]% grep amd /etc/rc.conf.local
amd_enable="YES"
amd_flags="-nr -k i396 -l syslog -x all"
amd_map_program="ypcat -k amd.master | sed -e 's#/usr/local#/usr/local.shrimp#'"
(The amd.master map has an entry "/usr/local amd.usr-local" in it.)
One of the things that's on my plate is to have a net-visible place for
things that resemble /usr/local things (and that really should be kept
in one place), while having /usr/local reside on each local machine (so
that folks installing ports don't stomp all over each other).
And I'd like to integrate the SPARC/Solaris boxen a bit more into the
local net, so I'll want to tweak the maps (such as the amd.n map, above)
so that I can share as much stuff as possible (such as the "sudoers"
list), while keeping executables and endian-specific data to OS and/or
architecture-specific filesystems (and servers).
But that's secondary to ensuring that my colleagues (some of whom are
certainly better known in the FreeBSD community) don't need to spend
their time doing sysadmin stuff; that's why I'm here. :-)
Cheers,
david
--
David Wolfskill UNIX System Administrator
dhw@whistle.com voice: (650) 577-7158 pager: (650) 371-4621
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199905111643.JAA20152>