Hi,
my question was basically why the straightforward looking command
share -F nfs -o ro=hosta,rw=netgroupb /export/foo
not works although it does when you replace the netgroup by the list of
hosts it comprises.
Thanks to
Casper Dik <casper@holland.sun.com>,
"Tilford, Wayne" <wtilford@lgc.com>,
Linda Pratt <lcp@ns.ph.liv.ac.uk>,
"Alan Lichty" <lichty@genetics.utah.edu>
for their replies.
To the impatient readers: it does not work because of the
implementation of NFS although this is not mentioned in the
docs. (maybe it should be included in the FAQ of comp.unix.solaris?)
Alan recommended to export everything rw and mount ro where necessary
but this is not feasible in my environment. Wayne pointed out that he
doesn't use netgroups and with long hostlists it does work (well,
that's the point - I wanted to use netgroups).
Linda told me that there has been the same discussion some time ago on
comp.unix.solaris and mailed me the summary ( must have been before I
started reading that newsgroup ;-) which I will append to this mail and
finally Casper gave the technical explanation why it can't work.
First, Casper's explanation:
>>>>> "Casper" == Casper Dik <casper@holland.sun.com> writes:
[..]
Casper> .... it all boils down to: "when can I use netgroups with
Casper> share?".
Casper> The anser is extremely simple: "you cannot use netgroups if
Casper> the list of members of the netgroup must be stored inside
Casper> the kernel."
Casper> In Sun's NFS implementation there are two cases where a
Casper> list is downloaded:
Casper> - root access (with root=xxxx) - readmostly access
Casper> (most host get readonly, some get read/write, the
Casper> read/write hosts are listed in the kernel.
Casper> So you can combine ro & rw, but only ro goes with
Casper> netgroups, and rw with hosts.
Now to Linda:
>>>>> "Linda" == Linda Pratt <lcp@ns.ph.liv.ac.uk> writes:
--> There has been a thread on comp.unix.solaris about netgroups and NFS.
--> Someone wanted to get a disc readonly to one netgroup and readwrite to another
--> and they complained the share command kept giving an error. I tried exactly
--> the same thing and found this does not work. However there are some permission
--> combinations that do work with netgroups. It is all rather confusing.
-->
--> Here is some of the mail I sent to answer the poster. Although we were
--> discussing NIS+ netgroups under solaris 2.3, my understanding is that the
--> features we were discussing were to do with netgroups in general and NFS
--> and any SunOs. The share command is the solaris 2 equivalent of exportfs.
-->
--> --> I wanted to have a disc that was writable from our own network, but only
--> --> readable by another department network.
--> -->
--> --> share -F nfs -o rw=ourgroup,ro=theirgroup /export/scratch
--> -->
--> --> where ourgroup and theirgroup were both valid netgroups defined in our NIS+
--> --> table. As you know, this does not work. The first reaction I got from
--> --> the other department, which runs hp machines, was serve you right for using
--> --> NIS, but in fact it has nothing to do with NIS or NIS+, you get the same
--> --> problem no matter what name service you use to define your netgroups, even
--> --> if in /etc/netgroup files.
--> -->
--> --> So I asked for help from our computing services department who also had
--> --> a Solaris 2 system and they found the command behaved in a similar fashion
--> --> on their system also. So I did some experiments on exactly what would and
--> --> would not work and put a call in on the Sun-UK hotline.
--> -->
--> --> /* Netgroups seem to work fine alone. */
--> --> server# share -F nfs -o ro=ourgroup /export/scratch
--> --> server# unshare /export/scratch
--> --> server# share -F nfs -o ro=theirgroup /export/scratch
--> --> server# unshare /export/scratch
--> --> server# share -F nfs -o rw=ourgroup /export/scratch
--> --> server# unshare /export/scratch
--> --> server# share -F nfs -o rw=theirgroup /export/scratch
--> --> server# unshare /export/scratch
--> -->
--> --> /* It likes 2 hostnames */
--> --> server# share -F nfs -o rw=ourhost,ro=theirhost /export/scratch
--> --> server# unshare /export/scratch
--> --> server# share -F nfs -o ro=theirhost,rw=ourhost /export/scratch
--> --> server# unshare /export/scratch
--> --> server# share -F nfs -o rw=theirhost,ro=ourhost /export/scratch
--> --> server# unshare /export/scratch
--> --> server# share -F nfs -o ro=ourhost,rw=theirhost /export/scratch
--> --> server# unshare /export/scratch
--> -->
--> --> /* Doesnt like 2 netgroups. */
--> --> server# share -F nfs -o rw=ourgroup,ro=theirgroup /export/scratch
--> --> nfs share: ourgroup: network address not known
--> --> server# unshare /export/scratch
--> --> nfs unshare: /export/scratch not shared
--> --> server# share -F nfs -o ro=theirgroup,rw=ourgroup /export/scratch
--> --> nfs share: ourgroup: network address not known
--> --> server# unshare /export/scratch
--> --> nfs unshare: /export/scratch not shared
--> --> server# share -F nfs -o rw=theirgroup,ro=ourgroup /export/scratch
--> --> nfs share: theirgroup: network address not known
--> --> server# unshare /export/scratch
--> --> nfs unshare: /export/scratch not shared
--> --> server# share -F nfs -o ro=ourgroup,rw=theirgroup /export/scratch
--> --> nfs share: theirgroup: network address not known
--> --> server# unshare /export/scratch
--> --> nfs unshare: /export/scratch not shared
--> -->
--> --> /* It doesnt like a rw netgroup. */
--> --> server# share -F nfs -o rw=theirgroup,ro=ourhost /export/scratch
--> --> nfs share: theirgroup: network address not known
--> --> server# unshare /export/scratch
--> --> nfs unshare: /export/scratch not shared
--> --> server# share -F nfs -o ro=ourhost,rw=theirgroup /export/scratch
--> --> nfs share: theirgroup: network address not known
--> --> server# unshare /export/scratch
--> --> nfs unshare: /export/scratch not shared
--> --> server# share -F nfs -o rw=ourgroup,ro=theirhost /export/scratch
--> --> nfs share: ourgroup: network address not known
--> --> server# unshare /export/scratch
--> --> nfs unshare: /export/scratch not shared
--> --> server# share -F nfs -o ro=theirhost,rw=ourgroup /export/scratch
--> --> nfs share: ourgroup: network address not known
--> --> server# unshare /export/scratch
--> --> nfs unshare: /export/scratch not shared
--> -->
--> --> /* It likes a ro netgroup. */
--> --> server# share -F nfs -o rw=ourhost,ro=theirgroup /export/scratch
--> --> server# unshare /export/scratch
--> --> server# share -F nfs -o ro=theirgroup,rw=ourhost /export/scratch
--> --> server# unshare /export/scratch
--> --> server# share -F nfs -o rw=theirhost,ro=ourgroup /export/scratch
--> --> server# unshare /export/scratch
--> --> server# share -F nfs -o ro=ourgroup,rw=theirhost /export/scratch
--> --> server# unshare /export/scratch
--> -->
--> --> ourhost is a host in ourgroup and theirhost is a host in theirgroup (names
--> --> having been changed to protect the innocent).
--> -->
--> --> It is asymetric between ro and rw access as to what you can define using a
--> --> netgroup and what combinations are allowed.
--> -->
--> --> My call to Sun took days to resolve, as the initial contact staff thought the
--> --> same as I did that it should work. Also the man pages and AnswerBook appeared
--> --> to say it should. So I kept escalating the call. Eventually I got back an
--> --> answer that the behaviour I described is how it is supposed to work. I
--> --> got a load of technical verbage about what is in the kernel and what is not and
--> --> sending queries and requests and ro vs rw filesystem types that I didnt
--> --> understand at all. It seems it is a "feature" of how NFS is implemented at
--> --> an underlying level and that to fix it would cause too much of a performance
--> --> penalty.
--> -->
--> --> The advised workaround was that it would work if it was done without using
--> --> netgroups, naming each host explicitly in the share command. But I never
--> --> bothered to test this, as it seems like a maintenance nightmare with large
--> --> numbers of hosts in each netgroup. We just told the other department we
--> --> would not give them access to our discs after all (there were other reasons
--> --> for this also....not relevant).
--> -->
--> --> However, Sun did agree the man pages are confusing, inaccurate and wrong
--> --> in places, ditto the AnswerBook and ditto the write up on whatever data base
--> --> the initial contact people were trying to use.
-->
--> --> Perhaps some of the combinations that do work will be of use to you.
-->
-->
--> Here is Casper Dik's poster in explanation as to why rw netgroups dont always
--> work.
-->
--> --> From casper@fwi.uva.nl (Casper H.S. Dik)
--> --> Newsgroups: comp.unix.solaris
--> --> Subject: Re: Q: NFS exporting with netgroups
--> --> Date: Fri Jan 27 14:00:08 GMT 1995
--> --> Organization: FWI, University of Amsterdam
--> -->
--> --> Joe.Ammann@svusenet.ubs.ch writes:
--> -->
--> --> > share -F nfs -o rw=abc,ro=xyz /var/tmp
--> -->
--> --> The problem with this command is that as soon as you export
--> --> a filesystem with read-only it becomes a read-mostly export.
--> --> That makes that the kernel has to keep a list of all hosts
--> --> that are allowed write access. And at that point the same
--> --> rules for the root= option apply: no netgroups, hosts only.
--> -->
--> --> Ok:
--> -->
--> --> share -F nfs ro=xyz:abc /var/tmp
--> --> share -F nfs rw=xyz:abc /var/tmp
--> --> share -F nfs rw=host1:host2:host3,ro=xyz /var/tmp
--> -->
--> --> Not
--> --> share -F nfs rw=abc,ro=xyz /var/tmp
--> -->
--> --> Casper
-->
-->
--> Cheers,
-->
--> Linda
-->
--> Ms. L.C. Pratt, Software Support, Nuclear Structure Group, University of Liverpool
-->
--> email:lcp@ns.ph.liv.ac.uk
--> tel: + 44 51 794 3398
-->
-->
-- Nils Ellmenreich University of Passau Nils.Ellmenreich@fmi.uni-passau.de Germany
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:25 CDT