Hi Linus,
Please pull from the "nfs-for-3.3" branch of the repository at
git pull git://git.linux-nfs.org/projects/trondmy/linux-nfs.git nfs-for-3.3
This will update the following files through the appended changesets.
Cheers,
Trond
----
Documentation/kernel-parameters.txt | 17 ++-
fs/nfs/callback_proc.c | 2 +-
fs/nfs/client.c | 12 ++-
fs/nfs/file.c | 4 +-
fs/nfs/idmap.c | 83 ++++++++++++++++
fs/nfs/inode.c | 2 +
fs/nfs/internal.h | 2 +
fs/nfs/nfs4_fs.h | 3 +
fs/nfs/nfs4filelayout.c | 9 +-
fs/nfs/nfs4proc.c | 177 ++++++++++++++++++-----------------
fs/nfs/nfs4state.c | 104 ++++++++++++++++----
fs/nfs/nfs4xdr.c | 137 ++++++++++++++-------------
fs/nfs/objlayout/objio_osd.c | 3 +-
fs/nfs/objlayout/objlayout.c | 4 +
fs/nfs/pnfs.c | 42 ++++++++-
fs/nfs/pnfs.h | 1 +
fs/nfs/super.c | 43 ++++-----
fs/nfs/write.c | 27 +-----
fs/nfsd/nfs4callback.c | 2 +-
include/linux/nfs_fs_sb.h | 1 +
include/linux/nfs_idmap.h | 8 ++
include/linux/nfs_xdr.h | 22 ++++-
include/linux/sunrpc/auth.h | 3 +-
include/linux/sunrpc/auth_gss.h | 2 +-
include/linux/sunrpc/xdr.h | 2 +
init/do_mounts.c | 35 ++++++-
net/sunrpc/auth_generic.c | 6 +-
net/sunrpc/auth_gss/auth_gss.c | 40 +++++----
net/sunrpc/xdr.c | 3 +-
29 files changed, 525 insertions(+), 271 deletions(-)
commit 074b1d12fe2500d7d453902f9266e6674b30d84c
Author: Trond Myklebust <[email protected]>
Date: Mon Jan 9 13:46:26 2012 -0500
NFSv4: Change the default setting of the nfs4_disable_idmapping parameter
Now that the use of numeric uids/gids is officially sanctioned in
RFC3530bis, it is time to change the default here to 'enabled'.
By doing so, we ensure that NFSv4 copies the behaviour of NFSv3 when we're
using the default AUTH_SYS authentication (i.e. when the client uses the
numeric uids/gids as authentication tokens), so that when new files are
created, they will appear to have the correct user/group.
It also fixes a number of backward compatibility issues when migrating
from NFSv3 to NFSv4 on a platform where the server uses different uid/gid
mappings than the client.
Note also that this setting has been successfully tested against servers
that do not support numeric uids/gids at several Connectathon/Bakeathon
events at this point, and the fall back to using string names/groups has
been shown to work well in all those test cases.
Signed-off-by: Trond Myklebust <[email protected]>
commit 6926afd1925a54a13684ebe05987868890665e2b
Author: Trond Myklebust <[email protected]>
Date: Sat Jan 7 13:22:46 2012 -0500
NFSv4: Save the owner/group name string when doing open
...so that we can do the uid/gid mapping outside the asynchronous RPC
context.
This fixes a bug in the current NFSv4 atomic open code where the client
isn't able to determine what the true uid/gid fields of the file are,
(because the asynchronous nature of the OPEN call denies it the ability
to do an upcall) and so fills them with default values, marking the
inode as needing revalidation.
Unfortunately, in some cases, the VFS will do some additional sanity
checks on the file, and may override the server's decision to allow
the open because it sees the wrong owner/group fields.
Signed-off-by: Trond Myklebust <[email protected]>
commit e2fecb215b321db0e4a5b2597349a63c07bec42f
Author: Trond Myklebust <[email protected]>
Date: Fri Jan 6 08:57:46 2012 -0500
NFS: Remove pNFS bloat from the generic write path
We have no business doing any this in the standard write release path.
Get rid of it, and put it in the pNFS layer.
Also, while we're at it, get rid of the completely bogus unlock/relock
semantics that were present in nfs_writeback_release_full(). It is
not only unnecessary, but actually dangerous to release the write lock
just in order to take it again in nfs_page_async_flush(). Better just
to open code the pgio operations in a pnfs helper.
Signed-off-by: Trond Myklebust <[email protected]>
commit fe0fe83585f88346557868a803a479dfaaa0688a
Author: Boaz Harrosh <[email protected]>
Date: Fri Jan 6 09:31:20 2012 +0200
pnfs-obj: Must return layout on IO error
As mandated by the standard. In case of an IO error, a pNFS
objects layout driver must return it's layout. This is because
all device errors are reported to the server as part of the
layout return buffer.
This is implemented the same way PNFS_LAYOUTRET_ON_SETATTR
is done, through a bit flag on the pnfs_layoutdriver_type->flags
member. The flag is set by the layout driver that wants a
layout_return preformed at pnfs_ld_{write,read}_done in case
of an error.
(Though I have not defined a wrapper like pnfs_ld_layoutret_on_setattr
because this code is never called outside of pnfs.c and pnfs IO
paths)
Without this patch 3.[0-2] Kernels leak memory and have an annoying
WARN_ON after every IO error utilizing the pnfs-obj driver.
[This patch is for 3.2 Kernel. 3.1/0 Kernels need a different patch]
CC: Stable Tree <[email protected]>
Signed-off-by: Boaz Harrosh <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
commit 5c0b4129c07b902b27d3f3ebc087757f534a3abd
Author: Boaz Harrosh <[email protected]>
Date: Fri Jan 6 09:28:12 2012 +0200
pnfs-obj: pNFS errors are communicated on iodata->pnfs_error
Some time along the way pNFS IO errors were switched to
communicate with a special iodata->pnfs_error member instead
of the regular RPC members. But objlayout was not switched
over.
Fix that!
Without this fix any IO error is hanged, because IO is not
switched to MDS and pages are never cleared or read.
[Applies to 3.2.0. Same bug different patch for 3.1/0 Kernels]
CC: Stable Tree <[email protected]>
Signed-off-by: Boaz Harrosh <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
commit 0aaaf5c424c7ffd6b0c4253251356558b16ef3a2
Author: Chuck Lever <[email protected]>
Date: Tue Dec 6 16:13:48 2011 -0500
NFS: Cache state owners after files are closed
Servers have a finite amount of memory to store NFSv4 open and lock
owners. Moreover, servers may have a difficult time determining when
they can reap their state owner table, thanks to gray areas in the
NFSv4 protocol specification. Thus clients should be careful to reuse
state owners when possible.
Currently Linux is not too careful. When a user has closed all her
files on one mount point, the state owner's reference count goes to
zero, and it is released. The next OPEN allocates a new one. A
workload that serially opens and closes files can run through a large
number of open owners this way.
When a state owner's reference count goes to zero, slap it onto a free
list for that nfs_server, with an expiry time. Garbage collect before
looking for a state owner. This makes state owners for active users
available for re-use.
Now that there can be unused state owners remaining at umount time,
purge the state owner free list when a server is destroyed. Also be
sure not to reclaim unused state owners during state recovery.
This change has benefits for the client as well. For some workloads,
this approach drops the number of OPEN_CONFIRM calls from the same as
the number of OPEN calls, down to just one. This reduces wire traffic
and thus open(2) latency. Before this patch, untarring a kernel
source tarball shows the OPEN_CONFIRM call counter steadily increasing
through the test. With the patch, the OPEN_CONFIRM count remains at 1
throughout the entire untar.
As long as the expiry time is kept short, I don't think garbage
collection should be terribly expensive, although it does bounce the
clp->cl_lock around a bit.
[ At some point we should rationalize the use of the nfs_server
->destroy method. ]
Signed-off-by: Chuck Lever <[email protected]>
[Trond: Fixed a garbage collection race and a few efficiency issues]
Signed-off-by: Trond Myklebust <[email protected]>
commit 414adf14cd3b52e411f79d941a15d0fd4af427fc
Author: Chuck Lever <[email protected]>
Date: Tue Dec 6 16:13:39 2011 -0500
NFS: Clean up nfs4_find_state_owners_locked()
There's no longer a need to check the so_server field in the state
owner, because nowadays the RB tree we search for state owners
contains owners for that only server.
Make nfs4_find_state_owners_locked() use the same tree searching logic
as nfs4_insert_state_owner_locked().
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
commit bf118a342f10dafe44b14451a1392c3254629a1f
Author: Andy Adamson <[email protected]>
Date: Wed Dec 7 11:55:27 2011 -0500
NFSv4: include bitmap in nfsv4 get acl data
The NFSv4 bitmap size is unbounded: a server can return an arbitrary
sized bitmap in an FATTR4_WORD0_ACL request. Replace using the
nfs4_fattr_bitmap_maxsz as a guess to the maximum bitmask returned by a server
with the inclusion of the bitmap (xdr length plus bitmasks) and the acl data
xdr length to the (cached) acl page data.
This is a general solution to commit e5012d1f "NFSv4.1: update
nfs4_fattr_bitmap_maxsz" and fixes hitting a BUG_ON in xdr_shrink_bufhead
when getting ACLs.
Fix a bug in decode_getacl that returned -EINVAL on ACLs > page when getxattr
was called with a NULL buffer, preventing ACL > PAGE_SIZE from being retrieved.
Cc: [email protected]
Signed-off-by: Andy Adamson <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
commit 3476f114addb7b96912840a234702f660a1f460b
Author: Chris Metcalf <[email protected]>
Date: Thu Aug 11 13:54:28 2011 -0700
nfs: fix a minor do_div portability issue
This change modifies filelayout_get_dense_offset() to use the functions
in math64.h and thus avoid a 32-bit platform compile error trying to
use do_div() on an s64 type.
Signed-off-by: Chris Metcalf <[email protected]>
Reviewed-by: Boaz Harrosh <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
commit 0b1c8fc43c1f9fcde2d18182988f05eeaaae509b
Author: Andy Adamson <[email protected]>
Date: Wed Nov 9 13:58:26 2011 -0500
NFSv4.1: cleanup comment and debug printk
Signed-off-by: Andy Adamson <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
commit aabd0b40b327d5c6518c8c908819b9bf864ad56a
Author: Andy Adamson <[email protected]>
Date: Wed Nov 9 13:58:22 2011 -0500
NFSv4.1: change nfs4_free_slot parameters for dynamic slots
Signed-off-by: Andy Adamson <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
commit aacd5537270a752fe12a9914a207284fc2341c6d
Author: Andy Adamson <[email protected]>
Date: Wed Nov 9 13:58:21 2011 -0500
NFSv4.1: cleanup init and reset of session slot tables
We are either initializing or resetting a session. Initialize or reset
the session slot tables accordingly.
Signed-off-by: Andy Adamson <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
commit 61f2e5106582d02f30b6807e3f9c07463c572ccb
Author: Andy Adamson <[email protected]>
Date: Wed Nov 9 13:58:20 2011 -0500
NFSv4.1: fix backchannel slotid off-by-one bug
Cc:[email protected]
Signed-off-by: Andy Adamson <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
commit 8a0d551a59ac92d8ff048d6cb29d3a02073e81e8
Author: Jeff Layton <[email protected]>
Date: Tue Dec 20 06:57:45 2011 -0500
nfs: fix regression in handling of context= option in NFSv4
Setting the security context of a NFSv4 mount via the context= mount
option is currently broken. The NFSv4 codepath allocates a parsed
options struct, and then parses the mount options to fill it. It
eventually calls nfs4_remote_mount which calls security_init_mnt_opts.
That clobbers the lsm_opts struct that was populated earlier. This bug
also looks like it causes a small memory leak on each v4 mount where
context= is used.
Fix this by moving the initialization of the lsm_opts into
nfs_alloc_parsed_mount_data. Also, add a destructor for
nfs_parsed_mount_data to make it easier to free all of the allocations
hanging off of it, and to ensure that the security_free_mnt_opts is
called whenever security_init_mnt_opts is.
I believe this regression was introduced quite some time ago, probably
by commit c02d7adf.
Cc: [email protected]
Signed-off-by: Jeff Layton <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
commit 2edb6bc3852c681c0d948245bd55108dc6407604
Author: NeilBrown <[email protected]>
Date: Wed Nov 16 11:46:31 2011 +1100
NFS - fix recent breakage to NFS error handling.
From c6d615d2b97fe305cbf123a8751ced859dca1d5e Mon Sep 17 00:00:00 2001
From: NeilBrown <[email protected]>
Date: Wed, 16 Nov 2011 09:39:05 +1100
Subject: [PATCH] NFS - fix recent breakage to NFS error handling.
commit 02c24a82187d5a628c68edfe71ae60dc135cd178 made a small and
presumably unintended change to write error handling in NFS.
Previously an error from filemap_write_and_wait_range would only be of
interest if nfs_file_fsync did not return an error. After this commit,
an error from filemap_write_and_wait_range would mean that (the rest of)
nfs_file_fsync would not even be called.
This means that:
1/ you are more likely to see EIO than e.g. EDQUOT or ENOSPC.
2/ NFS_CONTEXT_ERROR_WRITE remains set for longer so more writes are
synchronous.
This patch restores previous behaviour.
Cc: [email protected]
Cc: Josef Bacik <[email protected]>
Cc: Jan Kara <[email protected]>
Cc: Al Viro <[email protected]>
Signed-off-by: NeilBrown <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
commit 43717c7daebf10b43f12e68512484b3095bb1ba5
Author: Chuck Lever <[email protected]>
Date: Mon Dec 5 15:40:30 2011 -0500
NFS: Retry mounting NFSROOT
Lukas Razik <[email protected]> reports that on his SPARC system,
booting with an NFS root file system stopped working after commit
56463e50 "NFS: Use super.c for NFSROOT mount option parsing."
We found that the network switch to which Lukas' client was attached
was delaying access to the LAN after the client's NIC driver reported
that its link was up. The delay was longer than the timeouts used in
the NFS client during mounting.
NFSROOT worked for Lukas before commit 56463e50 because in those
kernels, the client's first operation was an rpcbind request to
determine which port the NFS server was listening on. When that
request failed after a long timeout, the client simply selected the
default NFS port (2049). By that time the switch was allowing access
to the LAN, and the mount succeeded.
Neither of these client behaviors is desirable, so reverting 56463e50
is really not a choice. Instead, introduce a mechanism that retries
the NFSROOT mount request several times. This is the same tactic that
normal user space NFS mounts employ to overcome server and network
delays.
Signed-off-by: Lukas Razik <[email protected]>
[ cel: match kernel coding style, add proper patch description ]
[ cel: add exponential back-off ]
Signed-off-by: Chuck Lever <[email protected]>
Tested-by: Lukas Razik <[email protected]>
Cc: [email protected] # > 2.6.38
Signed-off-by: Trond Myklebust <[email protected]>
commit 68c97153fb7f2877f98aa6c29546381d9cad2fed
Author: Trond Myklebust <[email protected]>
Date: Tue Jan 3 13:22:46 2012 -0500
SUNRPC: Clean up the RPCSEC_GSS service ticket requests
Instead of hacking specific service names into gss_encode_v1_msg, we should
just allow the caller to specify the service name explicitly.
Signed-off-by: Trond Myklebust <[email protected]>
Acked-by: J. Bruce Fields <[email protected]>
--
Trond Myklebust
Linux NFS client maintainer
NetApp
[email protected]
http://www.netapp.com
On Tue, 2012-01-10 at 01:49 +0100, Wolfgang Walter wrote:
> On Monday 09 January 2012, Trond Myklebust wrote:
> > On Mon, 2012-01-09 at 14:28 -0800, Myklebust, Trond wrote:
> > > > -----Original Message-----
> > > Please read the changelog and documentation:
> > >
> > > If your server doesn’t support numeric uids/gids, then you will see _no_
> > > change in behaviour.
>
> Hmm, what does that mean exactly? Does a linux nfs4-server support numeric
> uids/gids? If yes, by default or do I need do set an option?
The patch requires no changes to a configuration that is already
working. That's the whole point I've been trying to get across.
> > >
> > > If your server does support numeric uids/gids, and has the same mapping
> between numeric uids/gids and username/groupname as your clients, then you
> will see _no_ change in behaviour.
> > >
> > > If your server does support numeric uids/gids, but the mapping between
> > > numeric uids/gids and username/groupname differs between server and client
> > > (e.g.. uid=20 maps to different users on the client and server) then you
> > > already had a problem in that creating the file using NFSv4 would result
> > > in you seeing the wrong owner and/or group. If this case, and this case
> > > only, the change to nfs4_disable_idmapper will result in you now seeing
> > > the correct owner/group for these files (just as if you were using NFSv3).
>
> The only thing I can say is that in the moment client and server are using
> rpc.idmapd and it works perfectly well.
Then why are you complaining?
"This patch does nothing for me is NOT a reason to stop others from
benefiting from it"
> > >
> > > IOW: the only people who will want to use the old setting are those with
> > > broken servers that return incorrect errors when confronted with a numeric
> > > uid/gid. We have found no evidence that any such servers exist during the
> > > last full year of testing.
> >
> > Actually, let me amend that last statement.
> >
> > The only broken server we found was the Linux server, which was
> > returning NFS4ERR_BADNAME in a situation where the protocol specified
> > that it should be returning NFS4ERR_BADOWNER. This is why we have the
> > little comment "The following works around a Linux server bug!" in the
> > client code.
> > Commit f6af99ec1b261e21219d5eba99e3af48fc6c32d4 (nfsd4: name->id mapping
> > should fail with BADOWNER not BADNAME) fixed that server bug exactly one
> > year ago, and the fix was subsequently pushed to [email protected]...
> >
> > IOW: unless you find something earth-shattering when you enable the
> > option in your existing clients (the option has existed since 2.6.39),
> > I'd prefer to change the default as soon as possible in order to fix the
> > existing brokenness for those people running NFSv4 without the benefit
> > of an ldap/nis/yp server to ensure a homogeneous uid/gid name space...
>
> I always thought that the idmapper with its translation were exactly for that
> case. If I have a homogenous uid/gid name space why would I want to use names
> and translate anyway?
For RPCSEC_GSS authentication. That's the only case that the original
RFC3530 cared about. The problems arise when people use AUTH_SYS, and
this protocol change+patch is the solution.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
[email protected]
http://www.netapp.com
Am Dienstag, 10. Januar 2012 schrieb Trond Myklebust:
> On Tue, 2012-01-10 at 11:53 +0100, Wolfgang Walter wrote:
> > Am Dienstag, 10. Januar 2012 schrieb Trond Myklebust:
> > > On Tue, 2012-01-10 at 01:49 +0100, Wolfgang Walter wrote:
> > > > On Monday 09 January 2012, Trond Myklebust wrote:
> > > > > On Mon, 2012-01-09 at 14:28 -0800, Myklebust, Trond wrote:
> > > > > > > -----Original Message-----
> > > > > >
> > > > > > Please read the changelog and documentation:
> > > > > >
> > > > > > If your server doesn’t support numeric uids/gids, then you will
> > > > > > see _no_ change in behaviour.
> > > >
> > > > Hmm, what does that mean exactly? Does a linux nfs4-server support
> > > > numeric uids/gids? If yes, by default or do I need do set an option?
> > >
> > > The patch requires no changes to a configuration that is already
> > > working. That's the whole point I've been trying to get across.
> >
> > So if user foo has uid 500 on the server and uid 600 on the client that
> > will still work with AUTH_SYS:
> >
> > client: uid 500 => foo@REALM
> > server: foo@REALM => uid 600
>
> No. In the scenario you describe above, it will be
Sorry. Of course.
>
> client: uid 600 <=> foo@REALM
> server: foo@REALM <=> uid 500
>
> > and vice-versa?
>
> The above _not_ work properly in the existing code... This kind of
> situation is the whole reason for wanting to change the existing code.
>
> With the existing code, the client will send numeric uid 600 as part of
> the rpc-level AUTH_SYS authentication, and so the server will create
> files with uid 600 irrespective of the foo@REALM idmapping at the NFSv4
> level.
> When the client later attempts to do a GETATTR on that file, the server
> will then translate that uid 600 using the idmapper
>
> server uid 600 => bar@REALM
> client bar@REALM => uid 213412
>
> IOW: This is exactly the situation where we want to use numeric uids
> everywhere, so that the server returns a numeric uid 600 in the GETATTR.
> In addition, if the client does a 'chown foo', it should send uid 600 in
> the SETATTR request, which matches the uid 600 in the AUTH_SYS
> authentication.
We are using AUTH_SYS for exporting read-only.
The uid (and gids) of the users accessing the filesystem (that is our
idenitities used with SYS_AUTH) are synced. But there are other identities
which are not. Debian i.e. allocates some system uids and gids dynamically.
With this change access to files and directories will not break but i.e. if
you use cp as root cp will behave differently. I.e. as part of our
installation process we once mounted a filesystem ro and cloned it with
cp -a .... This would break.
>
> Or again: If I'm using AUTH_SYS, then I'm transmitting numeric uids/gids
> as my authentication token, and so I want to use the same numeric
> uids/gids to label my file ownership. The idmapper doesn't affect the
> AUTH_SYS authentication token, and so mapping the NFS ownership to
> trond@REALM is not useful and may instead result in wrong behaviour such
> as in the situation described above.
So this basically says that idmapper will not be used for AUTH_SYS any more
and behaves exactly as NFSv3?
>
> When I use KerberosV principals ('kinit trond@REALM') as my
> authentication token in an RPCSEC_GSS session, then I want to use the
> same _string_ user trond@REALM to label my file ownership. The idmapper
> is then used to map the abstract trond@REALM into a uid/gid that the
> kernel can understand (and the actual value on the client/server is
> irrelevant as long as it matches whatever the authentication token maps
> to).
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29sZmdhbmcgV2FsdGVy
IFttYWlsdG86d29sZmdhbmcud2FsdGVyQHN0d20uZGVdDQo+IFNlbnQ6IFR1ZXNkYXksIEphbnVh
cnkgMTAsIDIwMTIgMTI6MjIgUE0NCj4gVG86IE15a2xlYnVzdCwgVHJvbmQNCj4gQ2M6IExpbnVz
IFRvcnZhbGRzOyBsaW51eC1uZnNAdmdlci5rZXJuZWwub3JnOyBsaW51eC1rZXJuZWxAdmdlci5r
ZXJuZWwub3JnDQo+IFN1YmplY3Q6IFJlOiBbR0lUIFBVTExdIFBsZWFzZSBwdWxsIE5GUyBjbGll
bnQgYnVnZml4ZXMgYW5kIGNsZWFudXBzDQo+IA0KPiBBbSBEaWVuc3RhZywgMTAuIEphbnVhciAy
MDEyIHNjaHJpZWIgVHJvbmQgTXlrbGVidXN0Og0KPiA+IE9uIFR1ZSwgMjAxMi0wMS0xMCBhdCAx
MTo1MyArMDEwMCwgV29sZmdhbmcgV2FsdGVyIHdyb3RlOg0KPiA+ID4gQW0gRGllbnN0YWcsIDEw
LiBKYW51YXIgMjAxMiBzY2hyaWViIFRyb25kIE15a2xlYnVzdDoNCj4gPiA+ID4gT24gVHVlLCAy
MDEyLTAxLTEwIGF0IDAxOjQ5ICswMTAwLCBXb2xmZ2FuZyBXYWx0ZXIgd3JvdGU6DQo+ID4gPiA+
ID4gT24gTW9uZGF5IDA5IEphbnVhcnkgMjAxMiwgVHJvbmQgTXlrbGVidXN0IHdyb3RlOg0KPiA+
ID4gPiA+ID4gT24gTW9uLCAyMDEyLTAxLTA5IGF0IDE0OjI4IC0wODAwLCBNeWtsZWJ1c3QsIFRy
b25kIHdyb3RlOg0KPiA+ID4gPiA+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+
ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IFBsZWFzZSByZWFkIHRoZSBjaGFuZ2Vsb2cgYW5k
IGRvY3VtZW50YXRpb246DQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IElmIHlvdXIgc2Vy
dmVyIGRvZXNu4oCZdCBzdXBwb3J0IG51bWVyaWMgdWlkcy9naWRzLCB0aGVuIHlvdQ0KPiA+ID4g
PiA+ID4gPiB3aWxsIHNlZSBfbm9fIGNoYW5nZSBpbiBiZWhhdmlvdXIuDQo+ID4gPiA+ID4NCj4g
PiA+ID4gPiBIbW0sIHdoYXQgZG9lcyB0aGF0IG1lYW4gZXhhY3RseT8gRG9lcyBhIGxpbnV4IG5m
czQtc2VydmVyDQo+ID4gPiA+ID4gc3VwcG9ydCBudW1lcmljIHVpZHMvZ2lkcz8gSWYgeWVzLCBi
eSBkZWZhdWx0IG9yIGRvIEkgbmVlZCBkbyBzZXQgYW4NCj4gb3B0aW9uPw0KPiA+ID4gPg0KPiA+
ID4gPiBUaGUgcGF0Y2ggcmVxdWlyZXMgbm8gY2hhbmdlcyB0byBhIGNvbmZpZ3VyYXRpb24gdGhh
dCBpcyBhbHJlYWR5DQo+ID4gPiA+IHdvcmtpbmcuIFRoYXQncyB0aGUgd2hvbGUgcG9pbnQgSSd2
ZSBiZWVuIHRyeWluZyB0byBnZXQgYWNyb3NzLg0KPiA+ID4NCj4gPiA+IFNvIGlmIHVzZXIgZm9v
IGhhcyB1aWQgNTAwIG9uIHRoZSBzZXJ2ZXIgYW5kIHVpZCA2MDAgb24gdGhlIGNsaWVudA0KPiA+
ID4gdGhhdCB3aWxsIHN0aWxsIHdvcmsgd2l0aCBBVVRIX1NZUzoNCj4gPiA+DQo+ID4gPiBjbGll
bnQ6IHVpZCA1MDAgPT4gZm9vQFJFQUxNDQo+ID4gPiBzZXJ2ZXI6IGZvb0BSRUFMTSA9PiB1aWQg
NjAwDQo+ID4NCj4gPiBOby4gSW4gdGhlIHNjZW5hcmlvIHlvdSBkZXNjcmliZSBhYm92ZSwgaXQg
d2lsbCBiZQ0KPiANCj4gU29ycnkuIE9mIGNvdXJzZS4NCj4gDQo+ID4NCj4gPiBjbGllbnQ6IHVp
ZCA2MDAgPD0+IGZvb0BSRUFMTQ0KPiA+IHNlcnZlcjogZm9vQFJFQUxNIDw9PiB1aWQgNTAwDQo+
ID4NCj4gPiA+IGFuZCB2aWNlLXZlcnNhPw0KPiA+DQo+ID4gVGhlIGFib3ZlIF9ub3RfIHdvcmsg
cHJvcGVybHkgaW4gdGhlIGV4aXN0aW5nIGNvZGUuLi4gVGhpcyBraW5kIG9mDQo+ID4gc2l0dWF0
aW9uIGlzIHRoZSB3aG9sZSByZWFzb24gZm9yIHdhbnRpbmcgdG8gY2hhbmdlIHRoZSBleGlzdGlu
ZyBjb2RlLg0KPiA+DQo+ID4gV2l0aCB0aGUgZXhpc3RpbmcgY29kZSwgdGhlIGNsaWVudCB3aWxs
IHNlbmQgbnVtZXJpYyB1aWQgNjAwIGFzIHBhcnQNCj4gPiBvZiB0aGUgcnBjLWxldmVsIEFVVEhf
U1lTIGF1dGhlbnRpY2F0aW9uLCBhbmQgc28gdGhlIHNlcnZlciB3aWxsDQo+ID4gY3JlYXRlIGZp
bGVzIHdpdGggdWlkIDYwMCBpcnJlc3BlY3RpdmUgb2YgdGhlIGZvb0BSRUFMTSBpZG1hcHBpbmcg
YXQNCj4gPiB0aGUgTkZTdjQgbGV2ZWwuDQo+ID4gV2hlbiB0aGUgY2xpZW50IGxhdGVyIGF0dGVt
cHRzIHRvIGRvIGEgR0VUQVRUUiBvbiB0aGF0IGZpbGUsIHRoZQ0KPiA+IHNlcnZlciB3aWxsIHRo
ZW4gdHJhbnNsYXRlIHRoYXQgdWlkIDYwMCB1c2luZyB0aGUgaWRtYXBwZXINCj4gPg0KPiA+IHNl
cnZlciAgdWlkIDYwMCA9PiBiYXJAUkVBTE0NCj4gPiBjbGllbnQgIGJhckBSRUFMTSA9PiB1aWQg
MjEzNDEyDQo+ID4NCj4gPiBJT1c6IFRoaXMgaXMgZXhhY3RseSB0aGUgc2l0dWF0aW9uIHdoZXJl
IHdlIHdhbnQgdG8gdXNlIG51bWVyaWMgdWlkcw0KPiA+IGV2ZXJ5d2hlcmUsIHNvIHRoYXQgdGhl
IHNlcnZlciByZXR1cm5zIGEgbnVtZXJpYyB1aWQgNjAwIGluIHRoZSBHRVRBVFRSLg0KPiA+IElu
IGFkZGl0aW9uLCBpZiB0aGUgY2xpZW50IGRvZXMgYSAnY2hvd24gZm9vJywgaXQgc2hvdWxkIHNl
bmQgdWlkIDYwMA0KPiA+IGluIHRoZSBTRVRBVFRSIHJlcXVlc3QsIHdoaWNoIG1hdGNoZXMgdGhl
IHVpZCA2MDAgaW4gdGhlIEFVVEhfU1lTDQo+ID4gYXV0aGVudGljYXRpb24uDQo+IA0KPiBXZSBh
cmUgdXNpbmcgQVVUSF9TWVMgZm9yIGV4cG9ydGluZyByZWFkLW9ubHkuDQo+IA0KPiBUaGUgdWlk
IChhbmQgZ2lkcykgb2YgdGhlIHVzZXJzIGFjY2Vzc2luZyB0aGUgZmlsZXN5c3RlbSAodGhhdCBp
cyBvdXIgaWRlbml0aXRpZXMNCj4gdXNlZCB3aXRoIFNZU19BVVRIKSBhcmUgc3luY2VkLiBCdXQg
dGhlcmUgYXJlIG90aGVyIGlkZW50aXRpZXMgd2hpY2ggYXJlDQo+IG5vdC4gRGViaWFuIGkuZS4g
YWxsb2NhdGVzIHNvbWUgc3lzdGVtIHVpZHMgYW5kIGdpZHMgZHluYW1pY2FsbHkuDQo+IA0KPiBX
aXRoIHRoaXMgY2hhbmdlIGFjY2VzcyB0byBmaWxlcyBhbmQgZGlyZWN0b3JpZXMgd2lsbCBub3Qg
YnJlYWsgYnV0IGkuZS4gaWYgeW91DQo+IHVzZSBjcCBhcyByb290IGNwIHdpbGwgYmVoYXZlIGRp
ZmZlcmVudGx5LiBJLmUuIGFzIHBhcnQgb2Ygb3VyIGluc3RhbGxhdGlvbg0KPiBwcm9jZXNzIHdl
IG9uY2UgbW91bnRlZCBhIGZpbGVzeXN0ZW0gcm8gYW5kIGNsb25lZCBpdCB3aXRoIGNwIC1hIC4u
Li4gVGhpcw0KPiB3b3VsZCBicmVhay4NCg0KWW91IHdpbGwgZ2V0IGFuIGV4YWN0IHJlcGxpY2Eg
b2YgdGhlIHNlcnZlciBmaWxlc3lzdGVtLCBqdXN0IGFzIGlmIHlvdSBoYWQgdXNlZCBORlN2My4N
Cg0KPiA+IE9yIGFnYWluOiBJZiBJJ20gdXNpbmcgQVVUSF9TWVMsIHRoZW4gSSdtIHRyYW5zbWl0
dGluZyBudW1lcmljDQo+ID4gdWlkcy9naWRzIGFzIG15IGF1dGhlbnRpY2F0aW9uIHRva2VuLCBh
bmQgc28gSSB3YW50IHRvIHVzZSB0aGUgc2FtZQ0KPiA+IG51bWVyaWMgdWlkcy9naWRzIHRvIGxh
YmVsIG15IGZpbGUgb3duZXJzaGlwLiBUaGUgaWRtYXBwZXIgZG9lc24ndA0KPiA+IGFmZmVjdCB0
aGUgQVVUSF9TWVMgYXV0aGVudGljYXRpb24gdG9rZW4sIGFuZCBzbyBtYXBwaW5nIHRoZSBORlMN
Cj4gPiBvd25lcnNoaXAgdG8gdHJvbmRAUkVBTE0gaXMgbm90IHVzZWZ1bCBhbmQgbWF5IGluc3Rl
YWQgcmVzdWx0IGluIHdyb25nDQo+ID4gYmVoYXZpb3VyIHN1Y2ggYXMgaW4gdGhlIHNpdHVhdGlv
biBkZXNjcmliZWQgYWJvdmUuDQo+IA0KPiBTbyB0aGlzIGJhc2ljYWxseSBzYXlzIHRoYXQgaWRt
YXBwZXIgd2lsbCBub3QgYmUgdXNlZCBmb3IgQVVUSF9TWVMgYW55IG1vcmUNCj4gYW5kIGJlaGF2
ZXMgZXhhY3RseSBhcyBORlN2Mz8NCg0KWWVzDQotICBORlN2MyBnb3QgdGhlIGJlaGF2aW91ciB3
aXRoIEFVVEhfU1lTIHJpZ2h0LCBidXQgUlBDU0VDX0dTUyBpcyBicm9rZW4uDQotIFRoZSBvcmln
aW5hbCBORlN2NCBwcm90b2NvbCB0ZXh0IGdvdCB0aGUgYmVoYXZpb3VyIHdpdGggUlBDU0VDX0dT
UyByaWdodCwgYnV0IEFVVEhfU1lTIGlzIGJyb2tlbi4NCg0KVGhpcyBjaGFuZ2UgbWVhbnMgdGhh
dCBORlN2NCBmaW5hbGx5IGdldHMgYm90aCBBVVRIX1NZUyBfYW5kXyBSUENTRUNfR1NTIHJpZ2h0
LiBJdCBtYWtlIHRoZSBORlMgcHJvdG9jb2wgdXNlIHByaW5jaXBhbC1saWtlIG5hbWVzIHdoZW4g
cHJpbmNpcGFscyBhcmUgdXNlZCBhcyB0aGUgYmFzaXMgZm9yIGF1dGhlbnRpY2F0aW9uLCBhbmQg
bnVtZXJpYyB1aWQvZ2lkcyB3aGVuIHRob3NlIGFyZSB1c2VkIGFzIHRoZSBiYXNpcyBmb3IgYXV0
aGVudGljYXRpb24uIEl0IGVuc3VyZXMgdGhhdCBhY2xzIGFuZCBtb2RlIGJpdC1iYXNlZCBwZXJt
aXNzaW9ucyBhbHdheXMgd29yayBhcyBleHBlY3RlZC4uLg0KDQpUcm9uZA0K
Am Dienstag, 10. Januar 2012 schrieb Trond Myklebust:
> On Tue, 2012-01-10 at 01:49 +0100, Wolfgang Walter wrote:
> > On Monday 09 January 2012, Trond Myklebust wrote:
> > > On Mon, 2012-01-09 at 14:28 -0800, Myklebust, Trond wrote:
> > > > > -----Original Message-----
> > > >
> > > > Please read the changelog and documentation:
> > > >
> > > > If your server doesn’t support numeric uids/gids, then you will see
> > > > _no_ change in behaviour.
> >
> > Hmm, what does that mean exactly? Does a linux nfs4-server support
> > numeric uids/gids? If yes, by default or do I need do set an option?
>
> The patch requires no changes to a configuration that is already
> working. That's the whole point I've been trying to get across.
So if user foo has uid 500 on the server and uid 600 on the client that will
still work with AUTH_SYS:
client: uid 500 => foo@REALM
server: foo@REALM => uid 600
and vice-versa?
> > I always thought that the idmapper with its translation were exactly for
> > that case. If I have a homogenous uid/gid name space why would I want to
> > use names and translate anyway?
>
> For RPCSEC_GSS authentication. That's the only case that the original
> RFC3530 cared about. The problems arise when people use AUTH_SYS, and
> this protocol change+patch is the solution.
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
Abteilungsleiter IT
Leopoldstraße 15
80802 München
Tel: +49 89 38196 276
Fax: +49 89 38196 150
Email: [email protected]
http://www.studentenwerk-muenchen.de/
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBXb2xmZ2FuZyBXYWx0ZXIgW21h
aWx0bzp3b2xmZ2FuZy53YWx0ZXJAc3R3bS5kZV0NCj4gU2VudDogTW9uZGF5LCBKYW51YXJ5IDA5
LCAyMDEyIDU6MTUgUE0NCj4gVG86IE15a2xlYnVzdCwgVHJvbmQNCj4gQ2M6IExpbnVzIFRvcnZh
bGRzOyBsaW51eC1uZnNAdmdlci5rZXJuZWwub3JnOyBsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwu
b3JnDQo+IFN1YmplY3Q6IFJlOiBbR0lUIFBVTExdIFBsZWFzZSBwdWxsIE5GUyBjbGllbnQgYnVn
Zml4ZXMgYW5kIGNsZWFudXBzDQo+IA0KPiBPbiBNb25kYXkgMDkgSmFudWFyeSAyMDEyLCBUcm9u
ZCBNeWtsZWJ1c3Qgd3JvdGU6DQo+ID4gSGkgTGludXMsDQo+ID4NCj4gPiBQbGVhc2UgcHVsbCBm
cm9tIHRoZSAibmZzLWZvci0zLjMiIGJyYW5jaCBvZiB0aGUgcmVwb3NpdG9yeSBhdA0KPiA+DQo+
ID4gICAgZ2l0IHB1bGwgZ2l0Oi8vZ2l0LmxpbnV4LW5mcy5vcmcvcHJvamVjdHMvdHJvbmRteS9s
aW51eC1uZnMuZ2l0DQo+ID4gbmZzLQ0KPiBmb3ItMy4zDQo+ID4NCj4gPiBUaGlzIHdpbGwgdXBk
YXRlIHRoZSBmb2xsb3dpbmcgZmlsZXMgdGhyb3VnaCB0aGUgYXBwZW5kZWQgY2hhbmdlc2V0cy4N
Cj4gPg0KPiA+ICAgQ2hlZXJzLA0KPiA+ICAgICBUcm9uZA0KPiA+DQo+ID4NCj4gPiBjb21taXQg
MDc0YjFkMTJmZTI1MDBkN2Q0NTM5MDJmOTI2NmU2Njc0YjMwZDg0Yw0KPiA+IEF1dGhvcjogVHJv
bmQgTXlrbGVidXN0IDxUcm9uZC5NeWtsZWJ1c3RAbmV0YXBwLmNvbT4NCj4gPiBEYXRlOiAgIE1v
biBKYW4gOSAxMzo0NjoyNiAyMDEyIC0wNTAwDQo+ID4NCj4gPiAgICAgTkZTdjQ6IENoYW5nZSB0
aGUgZGVmYXVsdCBzZXR0aW5nIG9mIHRoZSBuZnM0X2Rpc2FibGVfaWRtYXBwaW5nDQo+IHBhcmFt
ZXRlcg0KPiA+DQo+ID4gICAgIE5vdyB0aGF0IHRoZSB1c2Ugb2YgbnVtZXJpYyB1aWRzL2dpZHMg
aXMgb2ZmaWNpYWxseSBzYW5jdGlvbmVkIGluDQo+ID4gICAgIFJGQzM1MzBiaXMsIGl0IGlzIHRp
bWUgdG8gY2hhbmdlIHRoZSBkZWZhdWx0IGhlcmUgdG8gJ2VuYWJsZWQnLg0KPiA+DQo+ID4gICAg
IEJ5IGRvaW5nIHNvLCB3ZSBlbnN1cmUgdGhhdCBORlN2NCBjb3BpZXMgdGhlIGJlaGF2aW91ciBv
ZiBORlN2Mw0KPiA+IHdoZW4NCj4gd2UncmUNCj4gPiAgICAgdXNpbmcgdGhlIGRlZmF1bHQgQVVU
SF9TWVMgYXV0aGVudGljYXRpb24gKGkuZS4gd2hlbiB0aGUgY2xpZW50IHVzZXMgdGhlDQo+ID4g
ICAgIG51bWVyaWMgdWlkcy9naWRzIGFzIGF1dGhlbnRpY2F0aW9uIHRva2VucyksIHNvIHRoYXQg
d2hlbiBuZXcgZmlsZXMgYXJlDQo+ID4gICAgIGNyZWF0ZWQsIHRoZXkgd2lsbCBhcHBlYXIgdG8g
aGF2ZSB0aGUgY29ycmVjdCB1c2VyL2dyb3VwLg0KPiA+ICAgICBJdCBhbHNvIGZpeGVzIGEgbnVt
YmVyIG9mIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgaXNzdWVzIHdoZW4gbWlncmF0aW5nDQo+ID4g
ICAgIGZyb20gTkZTdjMgdG8gTkZTdjQgb24gYSBwbGF0Zm9ybSB3aGVyZSB0aGUgc2VydmVyIHVz
ZXMgZGlmZmVyZW50DQo+IHVpZC9naWQNCj4gPiAgICAgbWFwcGluZ3MgdGhhbiB0aGUgY2xpZW50
Lg0KPiA+DQo+ID4gICAgIE5vdGUgYWxzbyB0aGF0IHRoaXMgc2V0dGluZyBoYXMgYmVlbiBzdWNj
ZXNzZnVsbHkgdGVzdGVkIGFnYWluc3Qgc2VydmVycw0KPiA+ICAgICB0aGF0IGRvIG5vdCBzdXBw
b3J0IG51bWVyaWMgdWlkcy9naWRzIGF0IHNldmVyYWwNCj4gQ29ubmVjdGF0aG9uL0Jha2VhdGhv
bg0KPiA+ICAgICBldmVudHMgYXQgdGhpcyBwb2ludCwgYW5kIHRoZSBmYWxsIGJhY2sgdG8gdXNp
bmcgc3RyaW5nIG5hbWVzL2dyb3VwcyBoYXMNCj4gPiAgICAgYmVlbiBzaG93biB0byB3b3JrIHdl
bGwgaW4gYWxsIHRob3NlIHRlc3QgY2FzZXMuDQo+ID4NCj4gPiAgICAgU2lnbmVkLW9mZi1ieTog
VHJvbmQgTXlrbGVidXN0IDxUcm9uZC5NeWtsZWJ1c3RAbmV0YXBwLmNvbT4NCj4gPg0KPiANCj4g
DQo+IERvZXMgdGhpcyBtZWFuIHRoYXQgb25lIGhhcyB0byBtb2RpZnkgYWxsIG9uZSdzIGNsaWVu
dHMgdG8gZ2V0IHRoZSBvbGQNCj4gYmVoYXZpb3VyPw0KPiANCj4gSSdtIG5vdCBzdXJlIGlmIHRo
aXMgaXMgYSByZWFsbHkgZ29vZCBpZGVhLiBJIGRvbid0IHNlZSB0aGUgYWR2YW50YWdlLiBUaGlz
IHdpbGwNCj4gYnJlYWsgYSBsb3Qgb2YgZXhpc3RpbmcgaW5zdGFsbGF0aW9ucyB3aGVuIHVwZ3Jh
ZGluZyB0byA+PTMuMy4gQW5kIHNvbWVvbmUNCj4gbWlncmF0aW5nIGZyb20gTkZTdjMgdG8gTkZT
djQgaGFzIHRvIGdpdmUgc29tZSB0aG91Z2h0cyB0byBpdCBhbnl3YXkuDQoNClBsZWFzZSByZWFk
IHRoZSBjaGFuZ2Vsb2cgYW5kIGRvY3VtZW50YXRpb246DQoNCklmIHlvdXIgc2VydmVyIGRvZXNu
4oCZdCBzdXBwb3J0IG51bWVyaWMgdWlkcy9naWRzLCB0aGVuIHlvdSB3aWxsIHNlZSBfbm9fIGNo
YW5nZSBpbiBiZWhhdmlvdXIuDQoNCklmIHlvdXIgc2VydmVyIGRvZXMgc3VwcG9ydCBudW1lcmlj
IHVpZHMvZ2lkcywgYW5kIGhhcyB0aGUgc2FtZSBtYXBwaW5nIGJldHdlZW4gbnVtZXJpYyB1aWRz
L2dpZHMgYW5kIHVzZXJuYW1lL2dyb3VwbmFtZSBhcyB5b3VyIGNsaWVudHMsIHRoZW4geW91IHdp
bGwgc2VlIF9ub18gY2hhbmdlIGluIGJlaGF2aW91ci4NCg0KSWYgeW91ciBzZXJ2ZXIgZG9lcyBz
dXBwb3J0IG51bWVyaWMgdWlkcy9naWRzLCBidXQgdGhlIG1hcHBpbmcgYmV0d2VlbiBudW1lcmlj
IHVpZHMvZ2lkcyBhbmQgdXNlcm5hbWUvZ3JvdXBuYW1lIGRpZmZlcnMgYmV0d2VlbiBzZXJ2ZXIg
YW5kIGNsaWVudCAoZS5nLi4gdWlkPTIwIG1hcHMgdG8gZGlmZmVyZW50IHVzZXJzIG9uIHRoZSBj
bGllbnQgYW5kIHNlcnZlcikgdGhlbiB5b3UgYWxyZWFkeSBoYWQgYSBwcm9ibGVtIGluIHRoYXQg
Y3JlYXRpbmcgdGhlIGZpbGUgdXNpbmcgTkZTdjQgd291bGQgcmVzdWx0IGluIHlvdSBzZWVpbmcg
dGhlIHdyb25nIG93bmVyIGFuZC9vciBncm91cC4gSWYgdGhpcyBjYXNlLCBhbmQgdGhpcyBjYXNl
IG9ubHksIHRoZSBjaGFuZ2UgdG8gbmZzNF9kaXNhYmxlX2lkbWFwcGVyIHdpbGwgcmVzdWx0IGlu
IHlvdSBub3cgc2VlaW5nIHRoZSBjb3JyZWN0IG93bmVyL2dyb3VwIGZvciB0aGVzZSBmaWxlcyAo
anVzdCBhcyBpZiB5b3Ugd2VyZSB1c2luZyBORlN2MykuDQoNCklPVzogdGhlIG9ubHkgcGVvcGxl
IHdobyB3aWxsIHdhbnQgdG8gdXNlIHRoZSBvbGQgc2V0dGluZyBhcmUgdGhvc2Ugd2l0aCBicm9r
ZW4gc2VydmVycyB0aGF0IHJldHVybiBpbmNvcnJlY3QgZXJyb3JzIHdoZW4gY29uZnJvbnRlZCB3
aXRoIGEgbnVtZXJpYyB1aWQvZ2lkLiBXZSBoYXZlIGZvdW5kIG5vIGV2aWRlbmNlIHRoYXQgYW55
IHN1Y2ggc2VydmVycyBleGlzdCBkdXJpbmcgdGhlIGxhc3QgZnVsbCB5ZWFyIG9mIHRlc3Rpbmcu
DQoNClRyb25kDQo=
On Mon, 2012-01-09 at 14:28 -0800, Myklebust, Trond wrote:
> > -----Original Message-----
> > From: Wolfgang Walter [mailto:[email protected]]
> > Sent: Monday, January 09, 2012 5:15 PM
> > To: Myklebust, Trond
> > Cc: Linus Torvalds; [email protected]; [email protected]
> > Subject: Re: [GIT PULL] Please pull NFS client bugfixes and cleanups
> >
> > On Monday 09 January 2012, Trond Myklebust wrote:
> > > Hi Linus,
> > >
> > > Please pull from the "nfs-for-3.3" branch of the repository at
> > >
> > > git pull git://git.linux-nfs.org/projects/trondmy/linux-nfs.git
> > > nfs-
> > for-3.3
> > >
> > > This will update the following files through the appended changesets.
> > >
> > > Cheers,
> > > Trond
> > >
> > >
> > > commit 074b1d12fe2500d7d453902f9266e6674b30d84c
> > > Author: Trond Myklebust <[email protected]>
> > > Date: Mon Jan 9 13:46:26 2012 -0500
> > >
> > > NFSv4: Change the default setting of the nfs4_disable_idmapping
> > parameter
> > >
> > > Now that the use of numeric uids/gids is officially sanctioned in
> > > RFC3530bis, it is time to change the default here to 'enabled'.
> > >
> > > By doing so, we ensure that NFSv4 copies the behaviour of NFSv3
> > > when
> > we're
> > > using the default AUTH_SYS authentication (i.e. when the client uses the
> > > numeric uids/gids as authentication tokens), so that when new files are
> > > created, they will appear to have the correct user/group.
> > > It also fixes a number of backward compatibility issues when migrating
> > > from NFSv3 to NFSv4 on a platform where the server uses different
> > uid/gid
> > > mappings than the client.
> > >
> > > Note also that this setting has been successfully tested against servers
> > > that do not support numeric uids/gids at several
> > Connectathon/Bakeathon
> > > events at this point, and the fall back to using string names/groups has
> > > been shown to work well in all those test cases.
> > >
> > > Signed-off-by: Trond Myklebust <[email protected]>
> > >
> >
> >
> > Does this mean that one has to modify all one's clients to get the old
> > behaviour?
> >
> > I'm not sure if this is a really good idea. I don't see the advantage. This will
> > break a lot of existing installations when upgrading to >=3.3. And someone
> > migrating from NFSv3 to NFSv4 has to give some thoughts to it anyway.
>
> Please read the changelog and documentation:
>
> If your server doesn’t support numeric uids/gids, then you will see _no_ change in behaviour.
>
> If your server does support numeric uids/gids, and has the same mapping between numeric uids/gids and username/groupname as your clients, then you will see _no_ change in behaviour.
>
> If your server does support numeric uids/gids, but the mapping between numeric uids/gids and username/groupname differs between server and client (e.g.. uid=20 maps to different users on the client and server) then you already had a problem in that creating the file using NFSv4 would result in you seeing the wrong owner and/or group. If this case, and this case only, the change to nfs4_disable_idmapper will result in you now seeing the correct owner/group for these files (just as if you were using NFSv3).
>
> IOW: the only people who will want to use the old setting are those with broken servers that return incorrect errors when confronted with a numeric uid/gid. We have found no evidence that any such servers exist during the last full year of testing.
Actually, let me amend that last statement.
The only broken server we found was the Linux server, which was
returning NFS4ERR_BADNAME in a situation where the protocol specified
that it should be returning NFS4ERR_BADOWNER. This is why we have the
little comment "The following works around a Linux server bug!" in the
client code.
Commit f6af99ec1b261e21219d5eba99e3af48fc6c32d4 (nfsd4: name->id mapping
should fail with BADOWNER not BADNAME) fixed that server bug exactly one
year ago, and the fix was subsequently pushed to [email protected]...
IOW: unless you find something earth-shattering when you enable the
option in your existing clients (the option has existed since 2.6.39),
I'd prefer to change the default as soon as possible in order to fix the
existing brokenness for those people running NFSv4 without the benefit
of an ldap/nis/yp server to ensure a homogeneous uid/gid name space...
--
Trond Myklebust
Linux NFS client maintainer
NetApp
[email protected]
http://www.netapp.com
On Monday 09 January 2012, Trond Myklebust wrote:
> On Mon, 2012-01-09 at 14:28 -0800, Myklebust, Trond wrote:
> > > -----Original Message-----
> > Please read the changelog and documentation:
> >
> > If your server doesn’t support numeric uids/gids, then you will see _no_
> > change in behaviour.
Hmm, what does that mean exactly? Does a linux nfs4-server support numeric
uids/gids? If yes, by default or do I need do set an option?
> >
> > If your server does support numeric uids/gids, and has the same mapping
between numeric uids/gids and username/groupname as your clients, then you
will see _no_ change in behaviour.
> >
> > If your server does support numeric uids/gids, but the mapping between
> > numeric uids/gids and username/groupname differs between server and client
> > (e.g.. uid=20 maps to different users on the client and server) then you
> > already had a problem in that creating the file using NFSv4 would result
> > in you seeing the wrong owner and/or group. If this case, and this case
> > only, the change to nfs4_disable_idmapper will result in you now seeing
> > the correct owner/group for these files (just as if you were using NFSv3).
The only thing I can say is that in the moment client and server are using
rpc.idmapd and it works perfectly well.
> >
> > IOW: the only people who will want to use the old setting are those with
> > broken servers that return incorrect errors when confronted with a numeric
> > uid/gid. We have found no evidence that any such servers exist during the
> > last full year of testing.
>
> Actually, let me amend that last statement.
>
> The only broken server we found was the Linux server, which was
> returning NFS4ERR_BADNAME in a situation where the protocol specified
> that it should be returning NFS4ERR_BADOWNER. This is why we have the
> little comment "The following works around a Linux server bug!" in the
> client code.
> Commit f6af99ec1b261e21219d5eba99e3af48fc6c32d4 (nfsd4: name->id mapping
> should fail with BADOWNER not BADNAME) fixed that server bug exactly one
> year ago, and the fix was subsequently pushed to [email protected]...
>
> IOW: unless you find something earth-shattering when you enable the
> option in your existing clients (the option has existed since 2.6.39),
> I'd prefer to change the default as soon as possible in order to fix the
> existing brokenness for those people running NFSv4 without the benefit
> of an ldap/nis/yp server to ensure a homogeneous uid/gid name space...
I always thought that the idmapper with its translation were exactly for that
case. If I have a homogenous uid/gid name space why would I want to use names
and translate anyway?
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
On Tue, 2012-01-10 at 11:53 +0100, Wolfgang Walter wrote:
> Am Dienstag, 10. Januar 2012 schrieb Trond Myklebust:
> > On Tue, 2012-01-10 at 01:49 +0100, Wolfgang Walter wrote:
> > > On Monday 09 January 2012, Trond Myklebust wrote:
> > > > On Mon, 2012-01-09 at 14:28 -0800, Myklebust, Trond wrote:
> > > > > > -----Original Message-----
> > > > >
> > > > > Please read the changelog and documentation:
> > > > >
> > > > > If your server doesn’t support numeric uids/gids, then you will see
> > > > > _no_ change in behaviour.
> > >
> > > Hmm, what does that mean exactly? Does a linux nfs4-server support
> > > numeric uids/gids? If yes, by default or do I need do set an option?
> >
> > The patch requires no changes to a configuration that is already
> > working. That's the whole point I've been trying to get across.
>
> So if user foo has uid 500 on the server and uid 600 on the client that will
> still work with AUTH_SYS:
>
> client: uid 500 => foo@REALM
> server: foo@REALM => uid 600
No. In the scenario you describe above, it will be
client: uid 600 <=> foo@REALM
server: foo@REALM <=> uid 500
> and vice-versa?
The above _not_ work properly in the existing code... This kind of
situation is the whole reason for wanting to change the existing code.
With the existing code, the client will send numeric uid 600 as part of
the rpc-level AUTH_SYS authentication, and so the server will create
files with uid 600 irrespective of the foo@REALM idmapping at the NFSv4
level.
When the client later attempts to do a GETATTR on that file, the server
will then translate that uid 600 using the idmapper
server uid 600 => bar@REALM
client bar@REALM => uid 213412
IOW: This is exactly the situation where we want to use numeric uids
everywhere, so that the server returns a numeric uid 600 in the GETATTR.
In addition, if the client does a 'chown foo', it should send uid 600 in
the SETATTR request, which matches the uid 600 in the AUTH_SYS
authentication.
Or again: If I'm using AUTH_SYS, then I'm transmitting numeric uids/gids
as my authentication token, and so I want to use the same numeric
uids/gids to label my file ownership. The idmapper doesn't affect the
AUTH_SYS authentication token, and so mapping the NFS ownership to
trond@REALM is not useful and may instead result in wrong behaviour such
as in the situation described above.
When I use KerberosV principals ('kinit trond@REALM') as my
authentication token in an RPCSEC_GSS session, then I want to use the
same _string_ user trond@REALM to label my file ownership. The idmapper
is then used to map the abstract trond@REALM into a uid/gid that the
kernel can understand (and the actual value on the client/server is
irrelevant as long as it matches whatever the authentication token maps
to).
--
Trond Myklebust
Linux NFS client maintainer
NetApp
[email protected]
http://www.netapp.com
On Monday 09 January 2012, Trond Myklebust wrote:
> Hi Linus,
>
> Please pull from the "nfs-for-3.3" branch of the repository at
>
> git pull git://git.linux-nfs.org/projects/trondmy/linux-nfs.git nfs-
for-3.3
>
> This will update the following files through the appended changesets.
>
> Cheers,
> Trond
>
>
> commit 074b1d12fe2500d7d453902f9266e6674b30d84c
> Author: Trond Myklebust <[email protected]>
> Date: Mon Jan 9 13:46:26 2012 -0500
>
> NFSv4: Change the default setting of the nfs4_disable_idmapping
parameter
>
> Now that the use of numeric uids/gids is officially sanctioned in
> RFC3530bis, it is time to change the default here to 'enabled'.
>
> By doing so, we ensure that NFSv4 copies the behaviour of NFSv3 when
we're
> using the default AUTH_SYS authentication (i.e. when the client uses the
> numeric uids/gids as authentication tokens), so that when new files are
> created, they will appear to have the correct user/group.
> It also fixes a number of backward compatibility issues when migrating
> from NFSv3 to NFSv4 on a platform where the server uses different
uid/gid
> mappings than the client.
>
> Note also that this setting has been successfully tested against servers
> that do not support numeric uids/gids at several Connectathon/Bakeathon
> events at this point, and the fall back to using string names/groups has
> been shown to work well in all those test cases.
>
> Signed-off-by: Trond Myklebust <[email protected]>
>
Does this mean that one has to modify all one's clients to get the old
behaviour?
I'm not sure if this is a really good idea. I don't see the advantage. This
will break a lot of existing installations when upgrading to >=3.3. And
someone migrating from NFSv3 to NFSv4 has to give some thoughts to it anyway.
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts