9:34 a.m.
[With the next nfs-utils rawhide build, I will be flipping the ]
[switch that will cause all NFS client mounts to try NFS v4 first ]
[At the bottom of this email has the workarounds if this change does ]
[indeed cause pain ]
As part of the https://fedoraproject.org/wiki/Features/NFSv4Default feature
I am one commit away from changing the default protocol version NFS will
be using (or at least trying to use).
What does this means to you? Hopefully nothing! In theory this should
be a very seamless transition but with all new technology there
will be (and are) some rough spots.
Why are make the change? See the NFSv4Default wiki for details,
but in a nutshell:
* Better performance - V4 is now a stateful protocol. Meaning the server keeps
state on all the clients access a particular file or directory. This
allows the server to give out delegations (or leases) which in turn
allows the client to aggressive cache both data and meta data locally
* Firewall Friendly- With v4 only one port is used 2049 for all traffic
including mounting and file locking.
* Finally it enables us use upcoming minor releases of the the protocol.
NFS version 4.1 and pNFS are two example of upcoming minor releases.
FYI, V4 was introduced in Fedora Core 2 so it has been around for a while. I
personally have been using it for my home directory for a couple years now..
For more of the nitty gritty details see
http://www.iaps.com/NFSv4-new-features.html
That's the good news... Here is the bad....
Because the mount command will try NFS v4 first, mounts to older Linux servers
will start failing like:
# mount linux-server:/export /mnt
mount.nfs: mounting linux-server:/export failed, reason given by server:
No such file or directory
This is due to a defect in the Linux server exporting code, which is fixed
in F-12, *but* there are a number of workarounds
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.
On the client, go back to v3 mounts by doing one of the following:
* Add -o v3 to command line, similar to:
mount linux-server:/export /mnt
* Change the default mount version in the new /etc/nfsmount.conf file by
uncommenting the Nfsvers=3 setting in the 'NFSMount_Global_Options' section.
See nfsmount.conf(5) man page for details. The diff would look like:
--- /etc/nfsmount.conf.orig 2009-10-26 09:30:21.000000000 -0400
+++ /etc/nfsmount.conf 2009-10-26 10:31:30.227443686 -0400
@@ -31,7 +31,7 @@
# Protocol Version [2,3,4]
# This defines the default protocol version which will
# be used to start the negotiation with the server.
-# Defaultvers=4
+Defaultvers=3
#
# Setting this option makes it mandatory the server supports the
# given version. The mount will fail if the given version is
steved.
11:06 a.m.
Steve Dickson <SteveD(a)redhat.com> writes:
[With the next nfs-utils rawhide build, I will be flipping the ]
[switch that will cause all NFS client mounts to try NFS v4 first ]
[...]
Is this really "first" or rather "only"? Was there a conclusion
about
whether the nfs client code would be changed to fall back from v4 to
v3 automatically?
- FChE
12:13 p.m.
On 10/26/2009 12:06 PM, Frank Ch. Eigler wrote:
Steve Dickson <SteveD(a)redhat.com> writes:
> [With the next nfs-utils rawhide build, I will be flipping the ]
> [switch that will cause all NFS client mounts to try NFS v4 first ]
> [...]
Is this really "first" or rather "only"? Was there a conclusion
about
whether the nfs client code would be changed to fall back from v4 to
v3 automatically?
It meant "first"... If the server does not support V4,
the mount will
automatically roll back to v3/tcp,v3/udp,v2/tcp,v2/udp...
The problem comes in when the server does support v4 but the exports are
not configured correctly (like pre F-12 Linux servers). In that case the
mount will fail with ENOENT which will look like:
mount.nfs: mounting laptop:/home failed, reason given by server:
No such file or directory
The there are a couple fixes to this problem:
1) Upgrade to an F-12 server
On a pre F-12 Server:
2) Added the '/ *(ro,fsid=0)' entry to the /etc/exportsfile and
reset the exports with 'exportfs -arv' (see exports(5) for details).
3) Set the 'RPCNFSDARGS="-N 4"' shell variable in the
/etc/sysconfig/nfs
file and restart the server via 'service nfs restart'
On a Rawhide Client:
4) Set the Defaultvers=3 in the /etc/nfsmount.conf file
5) Explicitly set the version (meaning don't do any server negotiation)
by either using the '-o v4' mount option on the command line or
set Nfsvers=3 in the /etc/nfsmount.conf file.
The first fixes two are preferred...
steved.
12:34 p.m.
Steve Dickson <SteveD(a)redhat.com> writes:
On 10/26/2009 12:06 PM, Frank Ch. Eigler wrote:
> Is this really "first" or rather "only"? Was there a conclusion
about
> whether the nfs client code would be changed to fall back from v4 to
> v3 automatically?
It meant "first"... [...]
The problem comes in when the server does support v4 but the exports are
not configured correctly (like pre F-12 Linux servers). [...]
mount.nfs: mounting laptop:/home failed, reason given by server:
No such file or directory
Unfortunately, this sounds like "only". Is it out of the question to
make the client look for this case (an upgraded client in an existing
unupgraded, unchanged network) and handle it?
- FChE
12:40 p.m.
At the least, there ought to be an F-11 update of whatever server-side
stuff needs to change (in the minimal way not touching non-v4 uses) to
make v4 exports work without temporary configuration hacks. IMHO if you
can't do anything better, you should make F-11 default to not registering
as a v4 server at all.
Thanks,
Roland
1:08 p.m.
On 10/26/2009 01:40 PM, Roland McGrath wrote:
At the least, there ought to be an F-11 update of whatever
server-side
stuff needs to change (in the minimal way not touching non-v4 uses) to
make v4 exports work without temporary configuration hacks. IMHO if you
can't do anything better, you should make F-11 default to not registering
as a v4 server at all.
That is one of the valid options, but I would think it would
better if
the server owner did that tweak, than an nfs-utils update, no?
steved.
1:11 p.m.
That is one of the valid options, but I would think it would better
if
the server owner did that tweak, than an nfs-utils update, no?
I'm not suggesting that you do an update that just tweaks config files in
%post or anything like that. I'm suggesting you make the out-of-the-box
behavior with configs people use today do something useful. Claiming to
support v4 is not useful if it doesn't really work.
1:49 p.m.
On 10/26/2009 02:11 PM, Roland McGrath wrote:
> That is one of the valid options, but I would think it would
better if
> the server owner did that tweak, than an nfs-utils update, no?
I'm not suggesting that you do an update that just tweaks config files in
%post or anything like that. I'm suggesting you make the out-of-the-box
behavior with configs people use today do something useful. Claiming to
support v4 is not useful if it doesn't really work.
Right... I'm assuming
the later... which is exactly how the set the default
version to v3 in F-12. I install a /etc/nfsmount.conf with Defaultvers=3 set.
But with with older releases I don't messing with people configuration
files since I would not want to break an existing configuration...
Note, there is a number of people who are currently running with
correctly configured v4 server... I would hate to mess those people up..
steved.
1:33 p.m.
But with with older releases I don't messing with people
configuration
files since I would not want to break an existing configuration...
Still never suggested that.
Note, there is a number of people who are currently running with
correctly configured v4 server... I would hate to mess those people up..
Of course. So push an F-11 update where whatever configuration never
mentions v4 and doesn't work for v4, doesn't advertise v4.
3:38 p.m.
On 10/27/2009 02:33 PM, Roland McGrath wrote:
> But with with older releases I don't messing with people
configuration
> files since I would not want to break an existing configuration...
Still never suggested that.
> Note, there is a number of people who are currently running with
> correctly configured v4 server... I would hate to mess those people up..
Of course. So push an F-11 update where whatever configuration never
mentions v4 and doesn't work for v4, doesn't advertise v4.
Not sure how I would do this without the update being called a
regression... any update that disables features does not seem
like a good thing...
steved.
4:25 p.m.
> Of course. So push an F-11 update where whatever configuration
never
> mentions v4 and doesn't work for v4, doesn't advertise v4.
>
Not sure how I would do this without the update being called a
regression... any update that disables features does not seem
like a good thing...
I described an update that disables FEATURES YOU SAID DO NOT WORK.
1:06 p.m.
On 10/26/2009 01:34 PM, Frank Ch. Eigler wrote:
Steve Dickson <SteveD(a)redhat.com> writes:
> On 10/26/2009 12:06 PM, Frank Ch. Eigler wrote:
>> Is this really "first" or rather "only"? Was there a
conclusion about
>> whether the nfs client code would be changed to fall back from v4 to
>> v3 automatically?
> It meant "first"... [...]
> The problem comes in when the server does support v4 but the exports are
> not configured correctly (like pre F-12 Linux servers). [...]
> mount.nfs: mounting laptop:/home failed, reason given by server:
> No such file or directory
Unfortunately, this sounds like "only". Is it out of the question to
make the client look for this case (an upgraded client in an existing
unupgraded, unchanged network) and handle it?
We talked about it... See
http://linux-nfs.org/pipermail/nfsv4/2009-October/011471.html
But in the end, I decided not to do this since its not clear how the change
would interact with other NFS servers...
steved.
2:53 p.m.
On Mon, Oct 26, 2009 at 02:06:45PM -0400, Steve Dickson wrote:
On 10/26/2009 01:34 PM, Frank Ch. Eigler wrote:
> Steve Dickson <SteveD(a)redhat.com> writes:
>
>> On 10/26/2009 12:06 PM, Frank Ch. Eigler wrote:
>
> Unfortunately, this sounds like "only". Is it out of the question to
> make the client look for this case (an upgraded client in an existing
> unupgraded, unchanged network) and handle it?
We talked about it... See http://linux-nfs.org/pipermail/nfsv4/2009-October/011471.html
But in the end, I decided not to do this since its not clear how the change
would interact with other NFS servers...
It's not clear to me how falling back to NFSv3 if v4 fails (and the
version wasn't explicitly set to v4) could ever cause a problem - it
might not help, but under what circumstances could it possibly be
harmful? I had a look at the linked thread from linux-nfs and no-one
there seemed to come up with anything concrete.
Ewan
6:03 a.m.
Ewan Mac Mahon wrote:
On Mon, Oct 26, 2009 at 02:06:45PM -0400, Steve Dickson wrote:
> On 10/26/2009 01:34 PM, Frank Ch. Eigler wrote:
>> Steve Dickson <SteveD(a)redhat.com> writes:
>>
>>> On 10/26/2009 12:06 PM, Frank Ch. Eigler wrote:
>> Unfortunately, this sounds like "only". Is it out of the question to
>> make the client look for this case (an upgraded client in an existing
>> unupgraded, unchanged network) and handle it?
> We talked about it... See
http://linux-nfs.org/pipermail/nfsv4/2009-October/011471.html
>
> But in the end, I decided not to do this since its not clear how the change
> would interact with other NFS servers...
>
It's not clear to me how falling back to NFSv3 if v4 fails (and the
version wasn't explicitly set to v4) could ever cause a problem - it
might not help, but under what circumstances could it possibly be
harmful? I had a look at the linked thread from linux-nfs and no-one
there seemed to come up with anything concrete.
The strongest objection I found was
Older versions of ONTAP (like 6.0 through 6.2?), for example, have
the
same problem as the Linux NFSv4 server does currently, iirc.
It's also worth noting that modern Solaris clients do not have this
ENOENT workaround. So, if automounter maps are shared with Linux
clients _with_ the workaround, mounting a Linux NFSv4 server, there
may be some issues.
In the long term, I think we are much better off living with a few
months of complaints about the new version negotiation behavior,
rather than having this mount.nfs workaround. I'm not going to object
to it outright, though...
(chuck[dot]lever[at]oracle[dot]com)
"I'm not going to object outright" sounds to me like we can fall back
to V3. I think this is the best plan for us: we should not break things
for users of Fedora clients with RHEL servers or Fedora clients with
Fedora servers.
Further,
On Oct 22, 2009, at 10:04 AM, Steve Dickson wrote:
> On 10/22/2009 12:21 PM, Chuck Lever wrote:
>> This would be mitigated instantly by leaving the version negotiation
>> default set to v3/v2. Then no workaround would be needed.
> Right... Or defining the negotiation in the configuration file
> would also cause the workaround not to be needed...
That's what I meant: set defaultvers: 3 in the config file, and allow
early adopters to change it. After a while, we can bump the default
setting. I think this is roughly what Sun did during their transition.
(chuck[dot]lever[at]oracle[dot]com)
Leaving the default at Version 3 for the next year or two would mostly
solve the problem.
Andrew.
3:06 p.m.
Steve Dickson <SteveD(a)redhat.com> writes:
[...]
> Unfortunately, this sounds like "only". Is it out of the question to
> make the client look for this case (an upgraded client in an existing
> unupgraded, unchanged network) and handle it?
We talked about it... See [...]
But in the end, I decided not to do this since its not clear how the change
would interact with other NFS servers...
It's a bit odd that we're about to push a backward-incompatible
change into Fedora, just in case non-Fedora servers are around.
- FChE
3:45 p.m.
On 10/26/2009 04:06 PM, Frank Ch. Eigler wrote:
Steve Dickson <SteveD(a)redhat.com> writes:
> [...]
>> Unfortunately, this sounds like "only". Is it out of the question to
>> make the client look for this case (an upgraded client in an existing
>> unupgraded, unchanged network) and handle it?
> We talked about it... See [...]
>
> But in the end, I decided not to do this since its not clear how the change
> would interact with other NFS servers...
It's a bit odd that we're about to push a backward-incompatible
change into Fedora, just in case non-Fedora servers are around.
Well the reason for
the incompatibility is the simple fact that
the Linux server is a bit behind the rest of the servers out there
when it comes to this particular type of v4 support...
Note, I've been pushing kernel patches to for over a year now (which are
in currently in the F-12) which would bring the server up to speed in
this area... but they gained any priority with the maintainer...
until recently...
steved.
10:17 a.m.
New subject: Buyer Beware: A Major Change in NFS (in Rawhide) is about to happen
On Mon, Oct 26, 2009 at 1:13 PM, Steve Dickson <SteveD(a)redhat.com> wrote:
On a pre F-12 Server:
2) Added the '/ *(ro,fsid=0)' entry to the /etc/exportsfile and
reset the exports with 'exportfs -arv' (see exports(5) for details).
*Please* stop recommending this to people.
This is a myopic configuration change which will violate the security
assumptions of almost any system out there. It's not what
practically anyone wants. Arguably the exports tool should even
prohibit this kind of configuration unless you set some
yes-I-really-intend-to-be-completely-insecure knob, it's certainly not
something that should be recommended as a fix for "help! nfs stopped
working when I upgrade to F13".
10:20 a.m.
On 10/29/2009 11:17 AM, Gregory Maxwell wrote:
On Mon, Oct 26, 2009 at 1:13 PM, Steve Dickson
<SteveD(a)redhat.com> wrote:
> On a pre F-12 Server:
> 2) Added the '/ *(ro,fsid=0)' entry to the /etc/exportsfile and
> reset the exports with 'exportfs -arv' (see exports(5) for details).
*Please* stop recommending this to people.
This is a myopic configuration change which will violate the security
assumptions of almost any system out there. It's not what
practically anyone wants. Arguably the exports tool should even
prohibit this kind of configuration unless you set some
yes-I-really-intend-to-be-completely-insecure knob, it's certainly not
something that should be recommended as a fix for "help! nfs stopped
working when I upgrade to F13".
I guess I just have confidence that people understand what
they are doing... sorry...
steved.
11:52 a.m.
Hi.
On Mon, 26 Oct 2009 12:39:07 -0400, Tom Lane wrote:
Steve Dickson <SteveD(a)redhat.com> writes:
> Because the mount command will try NFS v4 first, mounts to older
> Linux servers will start failing like:
What happens with a mount to a UDP-only server? (or actually /net
automount is what I care about...)
automount does not care one way or another, I think. At least it mounts
my solaris server just fine in 3/udp and 4/tcp.
12:18 p.m.
On 10/26/2009 12:39 PM, Tom Lane wrote:
Steve Dickson <SteveD(a)redhat.com> writes:
> Because the mount command will try NFS v4 first, mounts to older Linux servers
> will start failing like:
What happens with a mount to a UDP-only server? (or actually /net
automount is what I care about...)
Well since TCP is needed for NFS v4 support, I
can assume the server
does not support V4. In this case the mount/automount will
automatically roll back to v3/udp or v2/udp as it does today...
steved.
9 a.m.
On Mon, 2009-10-26 at 10:34 -0400, Steve Dickson wrote:
[With the next nfs-utils rawhide build, I will be flipping the ]
[switch that will cause all NFS client mounts to try NFS v4 first ]
[At the bottom of this email has the workarounds if this change does ]
[indeed cause pain ]
As part of the https://fedoraproject.org/wiki/Features/NFSv4Default feature
I am one commit away from changing the default protocol version NFS will
be using (or at least trying to use).
What does this means to you? Hopefully nothing! In theory this should
be a very seamless transition but with all new technology there
will be (and are) some rough spots.
Why are make the change? See the NFSv4Default wiki for details,
but in a nutshell:
* Better performance - V4 is now a stateful protocol. Meaning the server keeps
state on all the clients access a particular file or directory. This
allows the server to give out delegations (or leases) which in turn
allows the client to aggressive cache both data and meta data locally
* Firewall Friendly- With v4 only one port is used 2049 for all traffic
including mounting and file locking.
* Finally it enables us use upcoming minor releases of the the protocol.
NFS version 4.1 and pNFS are two example of upcoming minor releases.
FYI, V4 was introduced in Fedora Core 2 so it has been around for a while. I
personally have been using it for my home directory for a couple years now..
For more of the nitty gritty details see
http://www.iaps.com/NFSv4-new-features.html
That's the good news... Here is the bad....
Because the mount command will try NFS v4 first, mounts to older Linux servers
will start failing like:
# mount linux-server:/export /mnt
mount.nfs: mounting linux-server:/export failed, reason given by server:
No such file or directory
This is due to a defect in the Linux server exporting code, which is fixed
in F-12, *but* there are a number of workarounds
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.
On the client, go back to v3 mounts by doing one of the following:
* Add -o v3 to command line, similar to:
mount linux-server:/export /mnt
* Change the default mount version in the new /etc/nfsmount.conf file by
uncommenting the Nfsvers=3 setting in the 'NFSMount_Global_Options'
section.
See nfsmount.conf(5) man page for details. The diff would look like:
--- /etc/nfsmount.conf.orig 2009-10-26 09:30:21.000000000 -0400
+++ /etc/nfsmount.conf 2009-10-26 10:31:30.227443686 -0400
@@ -31,7 +31,7 @@
# Protocol Version [2,3,4]
# This defines the default protocol version which will
# be used to start the negotiation with the server.
-# Defaultvers=4
+Defaultvers=3
#
# Setting this option makes it mandatory the server supports the
# given version. The mount will fail if the given version is
Haven't gone through the full thread yet, but is it worth adding a
note/admonition to our NFS installation instructions that changing the
nfs server configuration may be necessary?
http://docs.fedoraproject.org/install-guide/f12/en-US/html/ch03s05s02.html
Thanks,
James
9:05 a.m.
On 10/27/2009 10:00 AM, James Laska wrote:
On Mon, 2009-10-26 at 10:34 -0400, Steve Dickson wrote:
> [With the next nfs-utils rawhide build, I will be flipping the ]
> [switch that will cause all NFS client mounts to try NFS v4 first ]
> [At the bottom of this email has the workarounds if this change does ]
> [indeed cause pain ]
>
> As part of the https://fedoraproject.org/wiki/Features/NFSv4Default feature
> I am one commit away from changing the default protocol version NFS will
> be using (or at least trying to use).
>
> What does this means to you? Hopefully nothing! In theory this should
> be a very seamless transition but with all new technology there
> will be (and are) some rough spots.
>
> Why are make the change? See the NFSv4Default wiki for details,
> but in a nutshell:
> * Better performance - V4 is now a stateful protocol. Meaning the server keeps
> state on all the clients access a particular file or directory. This
> allows the server to give out delegations (or leases) which in turn
> allows the client to aggressive cache both data and meta data locally
>
> * Firewall Friendly- With v4 only one port is used 2049 for all traffic
> including mounting and file locking.
>
> * Finally it enables us use upcoming minor releases of the the protocol.
> NFS version 4.1 and pNFS are two example of upcoming minor releases.
>
>
> FYI, V4 was introduced in Fedora Core 2 so it has been around for a while. I
> personally have been using it for my home directory for a couple years now..
> For more of the nitty gritty details see
> http://www.iaps.com/NFSv4-new-features.html
>
> That's the good news... Here is the bad....
>
> Because the mount command will try NFS v4 first, mounts to older Linux servers
> will start failing like:
>
> # mount linux-server:/export /mnt
> mount.nfs: mounting linux-server:/export failed, reason given by server:
> No such file or directory
>
> This is due to a defect in the Linux server exporting code, which is fixed
> in F-12, *but* there are a number of workarounds
>
> 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.
>
> On the client, go back to v3 mounts by doing one of the following:
>
> * Add -o v3 to command line, similar to:
> mount linux-server:/export /mnt
>
> * Change the default mount version in the new /etc/nfsmount.conf file by
> uncommenting the Nfsvers=3 setting in the 'NFSMount_Global_Options'
section.
> See nfsmount.conf(5) man page for details. The diff would look like:
>
> --- /etc/nfsmount.conf.orig 2009-10-26 09:30:21.000000000 -0400
> +++ /etc/nfsmount.conf 2009-10-26 10:31:30.227443686 -0400
> @@ -31,7 +31,7 @@
> # Protocol Version [2,3,4]
> # This defines the default protocol version which will
> # be used to start the negotiation with the server.
> -# Defaultvers=4
> +Defaultvers=3
> #
> # Setting this option makes it mandatory the server supports the
> # given version. The mount will fail if the given version is
Haven't gone through the full thread yet, but is it worth adding a
note/admonition to our NFS installation instructions that changing the
nfs server configuration may be necessary?
http://docs.fedoraproject.org/install-guide/f12/en-US/html/ch03s05s02.html
Thanks,
James
I think that adding a note to the documentation would be a very good thing...
ric
12:06 p.m.
On Tue, 2009-10-27 at 10:00 -0400, James Laska wrote:
Haven't gone through the full thread yet, but is it worth adding a
note/admonition to our NFS installation instructions that changing the
nfs server configuration may be necessary?
http://docs.fedoraproject.org/install-guide/f12/en-US/html/ch03s05s02.html
I do believe this change is targeting F13 though, not F12, so please
don't change any F12 documentation (:
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
4:06 p.m.
>>>> "SD" == Steve Dickson
<SteveD(a)redhat.com> writes:
SD> On the server (Which is suggested): Add the following entry to the
SD> /etc/exports file:
SD> / *(ro,fsid=0)
SD> Note: 'fsid=0' is explained in the exports(5) man pages.
Could someone comment on any potential security issues that exporting
the root in this way exposes? If all of my exported filesystems happen
to live under /export, can I export that directory instead of '/' and
have things work properly? If, for whatever reason, I need to export a
file system that doesn't live in /export, would I still be able to mount
it?
- J<
1:59 p.m.
On 10/27/2009 05:06 PM, Jason L Tibbitts III wrote:
>>>>> "SD" == Steve Dickson
<SteveD(a)redhat.com> writes:
SD> On the server (Which is suggested): Add the following entry to the
SD> /etc/exports file:
SD> / *(ro,fsid=0)
SD> Note: 'fsid=0' is explained in the exports(5) man pages.
Could someone comment on any potential security issues that exporting
the root in this way exposes?
Unfortunately this entry will expose your entire
root in a read-only
fashion...
If all of my exported filesystems happen to live under /export, can I
export that directory instead of '/' and have things work properly?
Only
by adding the above export entry would you be able to mount /export.
But since all your exports are under /export you might want to consider
making '/export' your pseudo root by doing something like:
/export *(ro,fsid=0)
/export/home *(rw)
Then the clients could do a 'mount /home' which would mount the
/export/home directory on the server... Plus if the client dose
a mount / the only directory they could 'see' would be 'home'
If, for whatever reason, I need to export a file system that
doesn't
live in /export, would I still be able to mount it?
With the '/
*(ro,fsid=0)' entry, Yes, you would be able to mount other
exported directories..
With the '/export *(ro,fsid=0)' entry, No, the client will only see
directories under '/export'. The rest of the filesystem would not be
seen...
I hope this helps...
steved.
2:05 p.m.
It sounds like you are saying that there is no way to export the same
host filesystems with the same client-perceived names under v4 as was
being done before under v[23]. Is that really true?
My old /etc/exports is:
/mirror *(ro,insecure,sync,mp,all_squash)
So clients mount server:/mirror to see my /mirror directory's contents.
No other /foo directory is exported or visible at all to clients, and
that's how it should stay.
How do I get the same results for v4 clients?
Thanks,
Roland
10:17 a.m.
On 10/28/2009 03:05 PM, Roland McGrath wrote:
It sounds like you are saying that there is no way to export the
same
host filesystems with the same client-perceived names under v4 as was
being done before under v[23]. Is that really true?
With Pre-F12 servers...
Yeah...
The V4 protocol requires a 'pseudo root' to be defined. Other servers simply
make '/' the pseudo root which allows all exports just to work with all versions.
The Linux server have the feature of being able to define the pseudo root with
the use of the 'fsid=0' export option. A feature none of the other servers
have.
Unfortunately, there was no forethought as to what happens when a
pseudo root is not defined, until recently... Patches in both the
F-12 kernel and rpc.mountd now dynamically allocate a pseudo root
when one is not defined... Basically meaning '/' becomes the pseudo
root when there is no fsid=0 export option.
My old /etc/exports is:
/mirror *(ro,insecure,sync,mp,all_squash)
So clients mount server:/mirror to see my /mirror directory's contents.
No other /foo directory is exported or visible at all to clients, and
that's how it should stay.
How do I get the same results for v4 clients?
Use a F-12 server or added the '/
*(ro,fsid=0)' export entry like:
/ *(ro,fsid=0)
/mirror *(ro,insecure,sync,mp,all_squash)
steved.-
9:41 a.m.
On 10/29/2009 11:17 AM, Steve Dickson wrote:
On 10/28/2009 03:05 PM, Roland McGrath wrote:
> It sounds like you are saying that there is no way to export the same
> host filesystems with the same client-perceived names under v4 as was
> being done before under v[23]. Is that really true?
With Pre-F12 servers... Yeah...
The V4 protocol requires a 'pseudo root' to be defined. Other servers simply
make '/' the pseudo root which allows all exports just to work with all
versions.
The Linux server have the feature of being able to define the pseudo root with
the use of the 'fsid=0' export option. A feature none of the other servers
have.
Except that when the other servers create a pseudo root, they don't
*also* expose that pseudo root. I'm fairly strongly of the opinion that
our NFS server should do the same thing: don't expose the pseudo root as
an actual mount.
Unfortunately, there was no forethought as to what happens when a
pseudo root is not defined, until recently... Patches in both the
F-12 kernel and rpc.mountd now dynamically allocate a pseudo root
when one is not defined... Basically meaning '/' becomes the pseudo
root when there is no fsid=0 export option.
And does this explicitly export the / filesystem? I would certainly
hope not as that could surprise the hell out of an admin when his /
filesystem is now exposed when it didn't use to be.
>
> My old /etc/exports is:
>
> /mirror *(ro,insecure,sync,mp,all_squash)
>
> So clients mount server:/mirror to see my /mirror directory's contents.
> No other /foo directory is exported or visible at all to clients, and
> that's how it should stay.
>
> How do I get the same results for v4 clients?
Use a F-12 server or added the '/ *(ro,fsid=0)' export entry like:
/ *(ro,fsid=0)
/mirror *(ro,insecure,sync,mp,all_squash)
I'm perfectly fine with adding the entry to the exports file, but I
think the fsid=0 export entry should be a non-functioning entry other
than setting the pseudo root. As you've described it so far, it also
happens to be a live export and I think that's wrong and should be fixed.
--
Doug Ledford <dledford(a)redhat.com>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
1:23 p.m.
On 11/02/2009 10:41 AM, Doug Ledford wrote:
On 10/29/2009 11:17 AM, Steve Dickson wrote:
>
>
> On 10/28/2009 03:05 PM, Roland McGrath wrote:
>> It sounds like you are saying that there is no way to export the same
>> host filesystems with the same client-perceived names under v4 as was
>> being done before under v[23]. Is that really true?
> With Pre-F12 servers... Yeah...
>
> The V4 protocol requires a 'pseudo root' to be defined. Other servers simply
> make '/' the pseudo root which allows all exports just to work with all
versions.
> The Linux server have the feature of being able to define the pseudo root with
> the use of the 'fsid=0' export option. A feature none of the other servers
> have.
Except that when the other servers create a pseudo root, they don't
*also* expose that pseudo root. I'm fairly strongly of the opinion that
our NFS server should do the same thing: don't expose the pseudo root as
an actual mount.
I believe the F-12 kernel does the right thing... just like the
all the other servers do...
> Unfortunately, there was no forethought as to what happens when a
> pseudo root is not defined, until recently... Patches in both the
> F-12 kernel and rpc.mountd now dynamically allocate a pseudo root
> when one is not defined... Basically meaning '/' becomes the pseudo
> root when there is no fsid=0 export option.
And does this explicitly export the / filesystem? I would certainly
hope not as that could surprise the hell out of an admin when his /
filesystem is now exposed when it didn't use to be.
Well the fsid=0 is
documented in the man page but the answer
to your question is yes...
>>
>> My old /etc/exports is:
>>
>> /mirror *(ro,insecure,sync,mp,all_squash)
>>
>> So clients mount server:/mirror to see my /mirror directory's contents.
>> No other /foo directory is exported or visible at all to clients, and
>> that's how it should stay.
>>
>> How do I get the same results for v4 clients?
> Use a F-12 server or added the '/ *(ro,fsid=0)' export entry like:
>
> / *(ro,fsid=0)
> /mirror *(ro,insecure,sync,mp,all_squash)
I'm perfectly fine with adding the entry to the exports file, but I
think the fsid=0 export entry should be a non-functioning entry other
than setting the pseudo root. As you've described it so far, it also
happens to be a live export and I think that's wrong and should be fixed.
I'm not sure about this... Actually I like the fact we can define a
pseudo root other than '/'... which means you really want a live exported
directory with the fsid=0 option... If I am understanding what you are
saying...
steved.
2:02 p.m.
On Mon, 2009-11-02 at 14:23 -0500, Steve Dickson wrote:
I'm not sure about this... Actually I like the fact we can define
a
pseudo root other than '/'... which means you really want a live exported
directory with the fsid=0 option... If I am understanding what you are
saying...
No, that's not what he's saying. Even if you define a different psuedo
root other than /, it's likely more common to /not/ want that root
exported in whole, but rather smaller parts of it, just like you don't
want / exported in whole, you only want subdirectories exported.
I too see this as a major regression in NFS behavior.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
6:47 a.m.
On 11/02/2009 03:02 PM, Jesse Keating wrote:
On Mon, 2009-11-02 at 14:23 -0500, Steve Dickson wrote:
> I'm not sure about this... Actually I like the fact we can define a
> pseudo root other than '/'... which means you really want a live exported
> directory with the fsid=0 option... If I am understanding what you are
> saying...
No, that's not what he's saying. Even if you define a different psuedo
root other than /, it's likely more common to /not/ want that root
exported in whole, but rather smaller parts of it, just like you don't
want / exported in whole, you only want subdirectories exported.
Lets add some
context to this since I *really* do want to understand
what you guys are saying...
/export *(ro,fsid=0)
/export/home *(rw)
With the above exports the only part of the server's real root ('/')
that is exposed is the /export directory. So when a client does a
'mount -o v4 server:/ /mnt'
The client will only be able to see /mnt/home (or the /export/home
export).
So as far as exposure, being able to define the root the client
will see, I think, is good thing since it will protect (or hide)
the rest of server's real root directories...
So this is why I'm understanding why the '/export' of the
'/export *(ro,fsid=0)' should not be a live export directory?
steved.
8:53 a.m.
On 11/03/2009 07:47 AM, Steve Dickson wrote:
On 11/02/2009 03:02 PM, Jesse Keating wrote:
> On Mon, 2009-11-02 at 14:23 -0500, Steve Dickson wrote:
>> I'm not sure about this... Actually I like the fact we can define a
>> pseudo root other than '/'... which means you really want a live
exported
>> directory with the fsid=0 option... If I am understanding what you are
>> saying...
>
> No, that's not what he's saying. Even if you define a different psuedo
> root other than /, it's likely more common to /not/ want that root
> exported in whole, but rather smaller parts of it, just like you don't
> want / exported in whole, you only want subdirectories exported.
Lets add some context to this since I *really* do want to understand
what you guys are saying...
/export *(ro,fsid=0)
/export/home *(rw)
With the above exports the only part of the server's real root ('/')
that is exposed is the /export directory. So when a client does a
'mount -o v4 server:/ /mnt'
The client will only be able to see /mnt/home (or the /export/home
export).
So as far as exposure, being able to define the root the client
will see, I think, is good thing since it will protect (or hide)
the rest of server's real root directories...
So this is why I'm understanding why the '/export' of the
'/export *(ro,fsid=0)' should not be a live export directory?
I understand that, what I'm saying is that the setting of the pseudo
root and the setting of an export *NEED* to be two different things. In
the past, any NFS export was always a real export and the only pseudo
root was always the / filesystem, *BUT* just because the / filesystem
was the pseudo root did *NOT* mean that the / filesystem itself was
mountable by clients unless it was exported in a separate export line
(get the distinction here: pseudo root existed, but wasn't exported).
Now you are telling us to create a pseudo root entry in the exports
file, and that entry is indicated by fsid=0, but you are also telling us
that simply the act of setting that entry will then add *both* a pseudo
root and a live export of the pseudo root to the world. There are many
situations I can imagine where I need the pseudo root to be something I
don't actually export, the most common and immediate case being that I
serve both NFSv4 and NFSv{3,2} where their pseudo root is always / and I
want both to have the same namespace and therefore I need v4 to have a /
pseudo root.
So, what should an exports file look like if I want to have a shared
v2/v3/v4 exports? Let's say I actually *do* want my / filesystem to be
ro mountable, then it should look like this:
/ *(ro,fsid=0) # this to set the pseudo root for v4
/ *(ro) # this to export /
/home *(rw) # you get the point
If, on the other hand, I have v2/v3/v4 enabled and I want them to have
the same mount points, and / is not one of those mount points, it should
look like this:
/ *(ro,fsid=0) # again, this should set the pseudo root *only*
/home *(rw) # now all versions see this mount, and this mount only
Now, are you saying that we should just leave out setting the pseudo
root if we don't want / to be exported in this case and that will get us
the same thing because the default pseudo root will be / anyway? If so,
that's broken behavior (that leaving the pseudo root to be a default
will set the root but not export it while setting the root will cause
the root to be exported).
As another scenario consider this: I serve out files to Windows, Mac,
and Linux computers. The files are all located under /srv. It would be
reasonable for me to define /srv as my pseudo root, especially as I have
multiple linux specific directories immediately under /srv (/srv/Linux,
/srv/Fedora, /srv/RHEL*, /srv/koji). However, I also have /srv/OS-X and
/srv/Windows. So let's say I create the exports file as such:
/srv *(ro,fsid=0)
/srv/Linux *(rw)
/srv/Fedora *(ro)
/srv/RHEL4 *(ro)
/srv/RHEL5 *(ro)
/srv/koji *(ro)
What I want out of this is on all of my clients, I want (expect) the
following command to fail:
mount server:/ /srv
I want the following command to succeed:
mount server:/Linux /srv/Linux
So, my point in all of this is that for the entire existence of the
pseudo root to date, it has always existed without also being exported
unless explicitly exported aside from being set. You can not now change
that so that setting the pseudo root also exports it. This would be a
massive regression. More importantly though, there are any number of
perfectly valid scenarios where one might want to set the pseudo root
without also exporting it. Forcing those two acts to be one and the
same more or less renders the whole feature so broken as to be
impractical to use, by design.
--
Doug Ledford <dledford(a)redhat.com>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
5:42 p.m.
> If, for whatever reason, I need to export a file system that
doesn't
> live in /export, would I still be able to mount it?
With the '/ *(ro,fsid=0)' entry, Yes, you would be able to mount other
exported directories..
With the '/export *(ro,fsid=0)' entry, No, the client will only see
directories under '/export'. The rest of the filesystem would not be
seen...
I suppose you could bind mount that other directory to be inside of
/export though and expose it that way?
I hope this helps...
steved.
9:58 a.m.
On 10/28/2009 06:42 PM, Ray Van Dolson wrote:
>> If, for whatever reason, I need to export a file system that
doesn't
>> live in /export, would I still be able to mount it?
> With the '/ *(ro,fsid=0)' entry, Yes, you would be able to mount other
> exported directories..
>
> With the '/export *(ro,fsid=0)' entry, No, the client will only see
> directories under '/export'. The rest of the filesystem would not be
> seen...
I suppose you could bind mount that other directory to be inside of
/export though and expose it that way?
I guess... but then you might have to had
the crossmnt export option..
steved.
1:35 p.m.
On 10/26/2009 10:34 AM, Steve Dickson wrote:
[With the next nfs-utils rawhide build, I will be flipping the ]
[switch that will cause all NFS client mounts to try NFS v4 first ]
[At the bottom of this email has the workarounds if this change does ]
[indeed cause pain ]
As part of the https://fedoraproject.org/wiki/Features/NFSv4Default feature
I am one commit away from changing the default protocol version NFS will
be using (or at least trying to use).
What does this means to you? Hopefully nothing! In theory this should
be a very seamless transition but with all new technology there
will be (and are) some rough spots.
Why are make the change? See the NFSv4Default wiki for details,
but in a nutshell:
* Better performance - V4 is now a stateful protocol. Meaning the server keeps
state on all the clients access a particular file or directory. This
allows the server to give out delegations (or leases) which in turn
allows the client to aggressive cache both data and meta data locally
* Firewall Friendly- With v4 only one port is used 2049 for all traffic
including mounting and file locking.
* Finally it enables us use upcoming minor releases of the the protocol.
NFS version 4.1 and pNFS are two example of upcoming minor releases.
FYI, V4 was introduced in Fedora Core 2 so it has been around for a while. I
personally have been using it for my home directory for a couple years now..
For more of the nitty gritty details see
http://www.iaps.com/NFSv4-new-features.html
That's the good news... Here is the bad....
Because the mount command will try NFS v4 first, mounts to older Linux servers
will start failing like:
# mount linux-server:/export /mnt
mount.nfs: mounting linux-server:/export failed, reason given by server:
No such file or directory
This is due to a defect in the Linux server exporting code, which is fixed
in F-12, *but* there are a number of workarounds
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.
On the client, go back to v3 mounts by doing one of the following:
* Add -o v3 to command line, similar to:
mount linux-server:/export /mnt
* Change the default mount version in the new /etc/nfsmount.conf file by
uncommenting the Nfsvers=3 setting in the 'NFSMount_Global_Options'
section.
See nfsmount.conf(5) man page for details. The diff would look like:
--- /etc/nfsmount.conf.orig 2009-10-26 09:30:21.000000000 -0400
+++ /etc/nfsmount.conf 2009-10-26 10:31:30.227443686 -0400
@@ -31,7 +31,7 @@
# Protocol Version [2,3,4]
# This defines the default protocol version which will
# be used to start the negotiation with the server.
-# Defaultvers=4
+Defaultvers=3
#
# Setting this option makes it mandatory the server supports the
# given version. The mount will fail if the given version is
Update...
With Build http://koji.fedoraproject.org/koji/taskinfo?taskID=1783028
the mount command will first try to do a v4 mount and then fall back
to v3/v2 mounts if v4 is not support. This fall back will also happen
if the server returns ENOENT, which will be the case with legacy Linux
servers and possible Netapp servers...
I hope to get the ENOENT-patch into F-12 as soon as it bakes a while
in rawhide and once F-12 stabilizes...
Thanks for all the input!!!
steved.
2:33 p.m.
Steve Dickson <SteveD(a)redhat.com> writes:
[...]
With Build http://koji.fedoraproject.org/koji/taskinfo?taskID=1783028
the mount command will first try to do a v4 mount and then fall back
to v3/v2 mounts if v4 is not support. This fall back will also happen
if the server returns ENOENT, which will be the case with legacy Linux
servers and possible Netapp servers...
[...]
Thank you! This looks like the Right Thing To Do(tm).
- FChE
5282
days inactive
5290
days old
36 comments
14 participants
participants (14)
-
Andrew Haley -
Doug Ledford -
Ewan Mac Mahon -
Frank Ch. Eigler -
Gregory Maxwell -
James Laska -
Jason L Tibbitts III -
Jesse Keating -
Ralf Ertzinger -
Ray Van Dolson -
Ric Wheeler -
Roland McGrath -
Steve Dickson -
Tom Lane