On 09/30/2009 07:22 AM, Howard Wilkinson wrote:
> Steve,
>
> just for clarity what you are actually saying is that.
> On Tue, 2009-09-29 at 22:45 -0400, Steve Dickson wrote:
>> On 09/29/2009 09:42 PM, Chris Adams wrote:
>>> Once upon a time, Steve Dickson <SteveD@xxxxxxxxxx> said:
>>>> On the server (Which is suggested):
>>>> * Add the following entry to the /etc/exports file:
>>>> / *(ro,fsid=0) Note: 'fsid=0' is explained in the exports(5) man pages.
>>>
>>> The "suggested solution" is to change your NFS servers (that work just
>>> fine with other clients today) to export the root filesystem to
>>> everybody?
>>>
>> Unfortunately the answer to your question yes...
>>
>> With version 4 there is this concept of a pseudo root. Which meanings
>> one can define, through exports, what the root of an export
>> can be. Which is a good idea because you can define /export as
>> the root, and nothing above /export can be accessed...
> But if there is a /data *(ro,fsid=0) export then that will do, but it
> becomes the root of the export tree against which mounts are made?
Yes.. For example say the directory tree under /data looks like
/data
dir1/
subdir1/
dir2/
subdir2/
Then the client could do a
mount server:/ /mnt/
which would make every thing under /data visible, meaning
ls /mnt/dir1
ls /mnt/dir2
Now the client could also do a
mount server:/dir1 /mnt
which would only make the the directories under /data/dir1 visible, meaning
ls /mnt/subdir1
>>
>> So the idea was to use 'fsid=0' to define the V4 root of the
>> exports. Which, in theory is a good idea because you can define
>> the namespace the client have access to. A feature, I believe,
>> is not available in any other NFS implementation... But...
>>
>> The problem is the V4 protocol requires a pseudo root to exist.
>> So with Linux servers, if the fsid=0 export does not exist, the
>> mount will die with ENOENT (or 'No such file or directory').
>>
>> Other NFS implementation decided not to support a definable pseudo
>> roots and they just made, under the covers, their '/' as the pseudo
>> root, along with the appropriate protections.
> So putting the / *(ro,fsid=0) is only adding an export of that part of
> the name space into the tree to make it compatible with pre-V4 name
> spaces.
Exactly...
>>
>> With F-12, I have added code to both the kernel and nfs-utils that will
>> do both. Allow the 'fsid=0' export to define the pseudo root and
>> make '/' the pseudo root (with the appropriate protections) when
>> there is not an fsid=0 entry.
>>
>> So Yes, one work around to make F-12 mounts work with Linux servers is
>> to define a pseudo root on the server with a fsid=0 export. But if
>> that is not an option, you can make the F12 clients only use V3 mount
>> (which would avoid the problem, but not take advantage of the
>> V4 protocol) by set either setting the '-o v3' mount option or
>> set the Nfsvers=3 in the new /etc/nfsmount.conf file (which would make
>> all mounts from that machine v3 mounts).
>>
> But the downside of the / *(ro,fsid=0) approach is we now have all of
> the root files (but not any other filing systems visible).
No, other mounts files systems would be visible as well..
>
> So perhaps a better approach would be to specify a /V4root *(ro,fsid=0)
> directory being created and a bind mount for each export from the pre-V3
> name space being made into that tree. Or have I missed something
> entirely?
That sounds like it could work, although it may not be too scalable with
large and complicated export tree...
The real answer is use a F-12 NFS server since all this stuff goes away..
steved.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
