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
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
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
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
Steve Dickson ste...@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
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
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
On 10/29/2009 11:17 AM, Gregory Maxwell wrote:
On Mon, Oct 26, 2009 at 1:13 PM, Steve Dickson ste...@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).
On 10/27/2009 05:06 PM, Jason L Tibbitts III wrote:
SD == Steve Dickson ste...@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
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
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 ste...@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
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
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
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?
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
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
On 10/26/2009 04:06 PM, Frank Ch. Eigler wrote:
Steve Dickson ste...@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
SD == Steve Dickson ste...@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
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
[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
Steve Dickson ste...@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
Steve Dickson ste...@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...)
regards, tom lane
--
Hi.
On Mon, 26 Oct 2009 12:39:07 -0400, Tom Lane wrote:
Steve Dickson ste...@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
On 10/26/2009 12:06 PM, Frank Ch. Eigler wrote:
Steve Dickson ste...@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
On 10/26/2009 12:39 PM, Tom Lane wrote:
Steve Dickson ste...@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...)
Steve Dickson ste...@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
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
On 10/26/2009 01:34 PM, Frank Ch. Eigler wrote:
Steve Dickson ste...@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?
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
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
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
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 ste...@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
Steve Dickson ste...@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
33 matches
Mail list logo