From: Jeff Layton <jeff.layton@primarydata.com>
To: "David Härdeman" <david@hardeman.nu>
Cc: Jeff Layton <jeff.layton@primarydata.com>,
linux-nfs@vger.kernel.org, SteveD@redhat.com,
dhowells@redhat.com
Subject: Re: [PATCH 00/19] gssd improvements
Date: Wed, 10 Dec 2014 09:34:05 -0500 [thread overview]
Message-ID: <20141210093405.23ffc328@tlielax.poochiereds.net> (raw)
In-Reply-To: <cdaf61315d77361a379e3eb1d4eaac1e@hardeman.nu>
On Wed, 10 Dec 2014 15:31:34 +0100
David Härdeman <david@hardeman.nu> wrote:
> On 2014-12-10 15:17, Jeff Layton wrote:
> > On Wed, 10 Dec 2014 15:08:40 +0100
> > David Härdeman <david@hardeman.nu> wrote:
> >> I'm not sure I follow completely...first of all, rpc.gssd is also not
> >> namespace-aware, is it? I mean, sure, it could be run in a given
> >> namespace, but there can still only be one rpc.gssd running?
> >>
> >
> > gssd isn't namespace aware, but it doesn't have to be since it gets
> > started in userland. In principle you could run a gssd per
> > container[1].
> > As long as each container has its own net namespace, each gssd would
> > have its own set of rpc_pipefs pipes.
> >
> > request-key is different. The kernel spawns a thread that execs the
> > program, but there's no support in that infrastructure for doing so
> > within a particular container.
>
> This thread might be interesting:
> https://lkml.org/lkml/2014/11/24/885
>
Nice. I wasn't aware that Ian was working on this. I'll take a look.
> >> Also...the nfsidmap binary (the request-key helper) isn't
> >> namespace-aware...is it?
> >>
> >
> > No it's not. I'd consider that a bug as well.
>
> So basically, a request-key based gssd would be possible if that "bug"
> in the request-key infrastructure is fixed, right?
>
Yes, I don't see why not.
--
Jeff Layton <jlayton@primarydata.com>
next prev parent reply other threads:[~2014-12-10 14:34 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-09 5:40 [PATCH 00/19] gssd improvements David Härdeman
2014-12-09 5:40 ` [PATCH 01/19] nfs-utils: cleanup daemonization code David Härdeman
2014-12-09 5:40 ` [PATCH 02/19] nfs-utils: gssd - merge gssd_main_loop.c and gssd.c David Härdeman
2014-12-09 5:40 ` [PATCH 03/19] nfs-utils: gssd - simplify some option handling David Härdeman
2014-12-09 5:41 ` [PATCH 04/19] nfs-utils: gssd - remove arbitrary GSSD_MAX_CCACHE_SEARCH limitation David Härdeman
2014-12-09 5:41 ` [PATCH 05/19] nfs-utils: gssd - simplify topdirs path David Härdeman
2014-12-09 5:41 ` [PATCH 06/19] nfs-utils: gssd - move over pipfs scanning code David Härdeman
2014-12-09 5:41 ` [PATCH 07/19] nfs-utils: gssd - simplify client dir " David Härdeman
2014-12-09 5:41 ` [PATCH 08/19] nfs-utils: gssd - use libevent David Härdeman
2014-12-09 5:41 ` [PATCH 09/19] nfs-utils: gssd - remove "close me" code David Härdeman
2014-12-09 5:41 ` [PATCH 10/19] nfs-utils: gssd - make the client lists per-topdir David Härdeman
2014-12-09 5:41 ` [PATCH 11/19] nfs-utils: gssd - keep the rpc_pipefs dir open David Härdeman
2014-12-09 5:41 ` [PATCH 12/19] nfs-utils: gssd - use more relative paths David Härdeman
2014-12-09 5:41 ` [PATCH 13/19] nfs-utils: gssd - simplify topdir scanning David Härdeman
2014-12-09 5:41 ` [PATCH 14/19] nfs-utils: gssd - simplify client scanning David Härdeman
2014-12-09 5:41 ` [PATCH 15/19] nfs-utils: gssd - cleanup read_service_info David Härdeman
2014-12-09 5:42 ` [PATCH 16/19] nfs-utils: gssd - change dnotify to inotify David Härdeman
2014-12-09 5:42 ` [PATCH 17/19] nfs-utils: gssd - further shorten some pathnames David Härdeman
2014-12-09 5:42 ` [PATCH 18/19] nfs-utils: gssd - improve inotify David Härdeman
2014-12-09 5:42 ` [PATCH 19/19] nfs-utils: gssd - simplify handle_gssd_upcall David Härdeman
2014-12-09 13:09 ` [PATCH 00/19] gssd improvements Jeff Layton
2014-12-09 13:52 ` David Härdeman
2014-12-09 14:58 ` Jeff Layton
2014-12-09 15:07 ` Simo Sorce
2014-12-09 19:55 ` David Härdeman
2014-12-10 11:52 ` Jeff Layton
2014-12-10 14:08 ` David Härdeman
2014-12-10 14:17 ` Jeff Layton
2014-12-10 14:31 ` David Härdeman
2014-12-10 14:34 ` Jeff Layton [this message]
2014-12-10 16:03 ` David Howells
2014-12-10 19:03 ` Jeff Layton
2014-12-10 20:55 ` David Härdeman
2014-12-10 23:44 ` Ian Kent
2014-12-10 23:21 ` Benjamin Coddington
2014-12-11 0:12 ` Ian Kent
2014-12-11 1:54 ` Benjamin Coddington
2014-12-11 3:21 ` Ian Kent
2014-12-11 11:45 ` Jeff Layton
2014-12-11 12:55 ` Ian Kent
2014-12-11 13:46 ` Jeff Layton
2014-12-11 22:31 ` Ian Kent
2014-12-11 19:32 ` J. Bruce Fields
2014-12-11 19:50 ` Jeff Layton
2014-12-11 19:55 ` J. Bruce Fields
2014-12-11 20:11 ` Jeff Layton
2014-12-11 20:38 ` J. Bruce Fields
2014-12-11 22:20 ` Ian Kent
2014-12-09 16:39 ` Steve Dickson
2014-12-09 20:22 ` David Härdeman
2014-12-09 21:13 ` Steve Dickson
2014-12-10 14:20 ` David Härdeman
2014-12-10 20:35 ` J. Bruce Fields
2014-12-10 20:49 ` David Härdeman
2014-12-10 21:07 ` J. Bruce Fields
2015-01-28 21:29 ` Steve Dickson
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=20141210093405.23ffc328@tlielax.poochiereds.net \
--to=jeff.layton@primarydata.com \
--cc=SteveD@redhat.com \
--cc=david@hardeman.nu \
--cc=dhowells@redhat.com \
--cc=linux-nfs@vger.kernel.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