From: Wolfgang Walter <wolfgang.walter@stwm.de>
To: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [GIT PULL] Please pull NFS client bugfixes and cleanups
Date: Tue, 10 Jan 2012 11:53:50 +0100 [thread overview]
Message-ID: <201201101153.51438.wolfgang.walter@stwm.de> (raw)
In-Reply-To: <1326160381.13527.4.camel@lade.trondhjem.org>
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: wolfgang.walter@stwm.de
http://www.studentenwerk-muenchen.de/
next prev parent reply other threads:[~2012-01-10 10:53 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-09 20:57 Trond Myklebust
2012-01-09 22:15 ` Wolfgang Walter
2012-01-09 22:28 ` Myklebust, Trond
[not found] ` <A4C37DBDA23D504B9F8F6ED1AD1F4F3245A40D11@SACMVEXC2-PRD.hq.netapp.com>
2012-01-09 22:50 ` Trond Myklebust
2012-01-10 0:49 ` Wolfgang Walter
2012-01-10 1:53 ` Trond Myklebust
2012-01-10 10:53 ` Wolfgang Walter [this message]
2012-01-10 13:38 ` Trond Myklebust
2012-01-10 17:22 ` Wolfgang Walter
2012-01-10 17:47 ` Myklebust, Trond
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201201101153.51438.wolfgang.walter@stwm.de \
--to=wolfgang.walter@stwm.de \
--cc=Trond.Myklebust@netapp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®