* Re: NFSv4 backchannel authentication
2012-08-09 15:53 ` Myklebust, Trond
@ 2012-08-09 16:28 ` Lukas Hejtmanek
2012-08-09 16:30 ` Myklebust, Trond
2012-08-09 16:50 ` J. Bruce Fields
2012-08-10 5:20 ` NFSv4 backchannel authentication NeilBrown
2 siblings, 1 reply; 18+ messages in thread
From: Lukas Hejtmanek @ 2012-08-09 16:28 UTC (permalink / raw)
To: Myklebust, Trond
Cc: J. Bruce Fields, Zdenek Salvet, linux-nfs@vger.kernel.org
On Thu, Aug 09, 2012 at 03:53:01PM +0000, Myklebust, Trond wrote:
> How is this any different to requiring that the user start rpc.statd
> before launching an NFSv3 mount? Just document the requirement if it
> isn't already clear enough, and we can move on.
>
> The other source of confusion here, was that the rpc.svcgssd was
> delivered through a nfs-kernel-server package, which indicates that we
> first and foremost need to educate the distro packagers.
hmm, if both rpc.gssd and rpc.svcgssd are needed on clients and servers, isn't
it worth of merging them into a single process?
--
Lukáš Hejtmánek
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: NFSv4 backchannel authentication
2012-08-09 16:28 ` Lukas Hejtmanek
@ 2012-08-09 16:30 ` Myklebust, Trond
2012-08-09 16:38 ` J. Bruce Fields
0 siblings, 1 reply; 18+ messages in thread
From: Myklebust, Trond @ 2012-08-09 16:30 UTC (permalink / raw)
To: Lukas Hejtmanek; +Cc: J. Bruce Fields, Zdenek Salvet, linux-nfs@vger.kernel.org
T24gVGh1LCAyMDEyLTA4LTA5IGF0IDE4OjI4ICswMjAwLCBMdWthcyBIZWp0bWFuZWsgd3JvdGU6
DQo+IE9uIFRodSwgQXVnIDA5LCAyMDEyIGF0IDAzOjUzOjAxUE0gKzAwMDAsIE15a2xlYnVzdCwg
VHJvbmQgd3JvdGU6DQo+ID4gSG93IGlzIHRoaXMgYW55IGRpZmZlcmVudCB0byByZXF1aXJpbmcg
dGhhdCB0aGUgdXNlciBzdGFydCBycGMuc3RhdGQNCj4gPiBiZWZvcmUgbGF1bmNoaW5nIGFuIE5G
U3YzIG1vdW50PyBKdXN0IGRvY3VtZW50IHRoZSByZXF1aXJlbWVudCBpZiBpdA0KPiA+IGlzbid0
IGFscmVhZHkgY2xlYXIgZW5vdWdoLCBhbmQgd2UgY2FuIG1vdmUgb24uDQo+ID4gDQo+ID4gVGhl
IG90aGVyIHNvdXJjZSBvZiBjb25mdXNpb24gaGVyZSwgd2FzIHRoYXQgdGhlIHJwYy5zdmNnc3Nk
IHdhcw0KPiA+IGRlbGl2ZXJlZCB0aHJvdWdoIGEgbmZzLWtlcm5lbC1zZXJ2ZXIgcGFja2FnZSwg
d2hpY2ggaW5kaWNhdGVzIHRoYXQgd2UNCj4gPiBmaXJzdCBhbmQgZm9yZW1vc3QgbmVlZCB0byBl
ZHVjYXRlIHRoZSBkaXN0cm8gcGFja2FnZXJzLg0KPiANCj4gaG1tLCBpZiBib3RoIHJwYy5nc3Nk
IGFuZCBycGMuc3ZjZ3NzZCBhcmUgbmVlZGVkIG9uIGNsaWVudHMgYW5kIHNlcnZlcnMsIGlzbid0
DQo+IGl0IHdvcnRoIG9mIG1lcmdpbmcgdGhlbSBpbnRvIGEgc2luZ2xlIHByb2Nlc3M/DQoNCllv
dSBkb24ndCBuZWVkIHJwYy5nc3NkIHRvIHVzZSBycGNzZWNfZ3NzIHdpdGggTkZTdjMsIG5vciBk
byB5b3UgbmVlZCBpdA0KaWYgeW91J3JlIG5vdCBpbnRlbmRpbmcgb24gdXNpbmcgZGVsZWdhdGlv
bnMgd2l0aCBORlN2NC4NCg0KLS0gDQpUcm9uZCBNeWtsZWJ1c3QNCkxpbnV4IE5GUyBjbGllbnQg
bWFpbnRhaW5lcg0KDQpOZXRBcHANClRyb25kLk15a2xlYnVzdEBuZXRhcHAuY29tDQp3d3cubmV0
YXBwLmNvbQ0KDQo=
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: NFSv4 backchannel authentication
2012-08-09 16:30 ` Myklebust, Trond
@ 2012-08-09 16:38 ` J. Bruce Fields
2012-08-09 16:49 ` Myklebust, Trond
0 siblings, 1 reply; 18+ messages in thread
From: J. Bruce Fields @ 2012-08-09 16:38 UTC (permalink / raw)
To: Myklebust, Trond
Cc: Lukas Hejtmanek, Zdenek Salvet, linux-nfs@vger.kernel.org
On Thu, Aug 09, 2012 at 04:30:53PM +0000, Myklebust, Trond wrote:
> On Thu, 2012-08-09 at 18:28 +0200, Lukas Hejtmanek wrote:
> > On Thu, Aug 09, 2012 at 03:53:01PM +0000, Myklebust, Trond wrote:
> > > How is this any different to requiring that the user start rpc.statd
> > > before launching an NFSv3 mount? Just document the requirement if it
> > > isn't already clear enough, and we can move on.
> > >
> > > The other source of confusion here, was that the rpc.svcgssd was
> > > delivered through a nfs-kernel-server package, which indicates that we
> > > first and foremost need to educate the distro packagers.
> >
> > hmm, if both rpc.gssd and rpc.svcgssd are needed on clients and servers, isn't
> > it worth of merging them into a single process?
>
> You don't need rpc.gssd to use rpcsec_gss with NFSv3, nor do you need it
^^^^^^^^
You meant rpc.svcgssd, unless you were thinking about the nfsd side.
> if you're not intending on using delegations with NFSv4.
Though the default should be to support delegations.
--b.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: NFSv4 backchannel authentication
2012-08-09 16:38 ` J. Bruce Fields
@ 2012-08-09 16:49 ` Myklebust, Trond
0 siblings, 0 replies; 18+ messages in thread
From: Myklebust, Trond @ 2012-08-09 16:49 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Lukas Hejtmanek, Zdenek Salvet, linux-nfs@vger.kernel.org
T24gVGh1LCAyMDEyLTA4LTA5IGF0IDEyOjM4IC0wNDAwLCBKLiBCcnVjZSBGaWVsZHMgd3JvdGU6
DQo+IE9uIFRodSwgQXVnIDA5LCAyMDEyIGF0IDA0OjMwOjUzUE0gKzAwMDAsIE15a2xlYnVzdCwg
VHJvbmQgd3JvdGU6DQo+ID4gT24gVGh1LCAyMDEyLTA4LTA5IGF0IDE4OjI4ICswMjAwLCBMdWth
cyBIZWp0bWFuZWsgd3JvdGU6DQo+ID4gPiBPbiBUaHUsIEF1ZyAwOSwgMjAxMiBhdCAwMzo1Mzow
MVBNICswMDAwLCBNeWtsZWJ1c3QsIFRyb25kIHdyb3RlOg0KPiA+ID4gPiBIb3cgaXMgdGhpcyBh
bnkgZGlmZmVyZW50IHRvIHJlcXVpcmluZyB0aGF0IHRoZSB1c2VyIHN0YXJ0IHJwYy5zdGF0ZA0K
PiA+ID4gPiBiZWZvcmUgbGF1bmNoaW5nIGFuIE5GU3YzIG1vdW50PyBKdXN0IGRvY3VtZW50IHRo
ZSByZXF1aXJlbWVudCBpZiBpdA0KPiA+ID4gPiBpc24ndCBhbHJlYWR5IGNsZWFyIGVub3VnaCwg
YW5kIHdlIGNhbiBtb3ZlIG9uLg0KPiA+ID4gPiANCj4gPiA+ID4gVGhlIG90aGVyIHNvdXJjZSBv
ZiBjb25mdXNpb24gaGVyZSwgd2FzIHRoYXQgdGhlIHJwYy5zdmNnc3NkIHdhcw0KPiA+ID4gPiBk
ZWxpdmVyZWQgdGhyb3VnaCBhIG5mcy1rZXJuZWwtc2VydmVyIHBhY2thZ2UsIHdoaWNoIGluZGlj
YXRlcyB0aGF0IHdlDQo+ID4gPiA+IGZpcnN0IGFuZCBmb3JlbW9zdCBuZWVkIHRvIGVkdWNhdGUg
dGhlIGRpc3RybyBwYWNrYWdlcnMuDQo+ID4gPiANCj4gPiA+IGhtbSwgaWYgYm90aCBycGMuZ3Nz
ZCBhbmQgcnBjLnN2Y2dzc2QgYXJlIG5lZWRlZCBvbiBjbGllbnRzIGFuZCBzZXJ2ZXJzLCBpc24n
dA0KPiA+ID4gaXQgd29ydGggb2YgbWVyZ2luZyB0aGVtIGludG8gYSBzaW5nbGUgcHJvY2Vzcz8N
Cj4gPiANCj4gPiBZb3UgZG9uJ3QgbmVlZCBycGMuZ3NzZCB0byB1c2UgcnBjc2VjX2dzcyB3aXRo
IE5GU3YzLCBub3IgZG8geW91IG5lZWQgaXQNCj4gCQkgXl5eXl5eXl4NCj4gDQo+IFlvdSBtZWFu
dCBycGMuc3ZjZ3NzZCwgdW5sZXNzIHlvdSB3ZXJlIHRoaW5raW5nIGFib3V0IHRoZSBuZnNkIHNp
ZGUuDQoNClllcy4NCg0KPiA+IGlmIHlvdSdyZSBub3QgaW50ZW5kaW5nIG9uIHVzaW5nIGRlbGVn
YXRpb25zIHdpdGggTkZTdjQuDQo+IA0KPiBUaG91Z2ggdGhlIGRlZmF1bHQgc2hvdWxkIGJlIHRv
IHN1cHBvcnQgZGVsZWdhdGlvbnMuDQoNClJpZ2h0LCBidXQgdGhhdCBpc24ndCBhIGp1c3RpZmlj
YXRpb24gZm9yIG1ha2luZyBpdCBpbXBvc3NpYmxlIHRvIHJ1bg0Kd2l0aG91dCBycGMuc3ZjZ3Nz
ZCBpZiB5b3UgZG9uJ3QgbmVlZCBpdC4NCg0KLS0gDQpUcm9uZCBNeWtsZWJ1c3QNCkxpbnV4IE5G
UyBjbGllbnQgbWFpbnRhaW5lcg0KDQpOZXRBcHANClRyb25kLk15a2xlYnVzdEBuZXRhcHAuY29t
DQp3d3cubmV0YXBwLmNvbQ0KDQo=
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: NFSv4 backchannel authentication
2012-08-09 15:53 ` Myklebust, Trond
2012-08-09 16:28 ` Lukas Hejtmanek
@ 2012-08-09 16:50 ` J. Bruce Fields
2012-08-09 17:58 ` Zdenek Salvet
2012-08-09 18:01 ` [PATCH] README: note gssd/svcgssd may be needed on both sides J. Bruce Fields
2012-08-10 5:20 ` NFSv4 backchannel authentication NeilBrown
2 siblings, 2 replies; 18+ messages in thread
From: J. Bruce Fields @ 2012-08-09 16:50 UTC (permalink / raw)
To: Myklebust, Trond
Cc: Zdenek Salvet, Lukas Hejtmanek, linux-nfs@vger.kernel.org
On Thu, Aug 09, 2012 at 03:53:01PM +0000, Myklebust, Trond wrote:
> On Thu, 2012-08-09 at 10:45 -0400, J. Bruce Fields wrote:
> > On Thu, Aug 09, 2012 at 10:06:42AM +0200, Zdenek Salvet wrote:
> > > On Wed, Aug 08, 2012 at 01:18:09PM +0000, Myklebust, Trond wrote:
> > > > > We don't see any hard failures because NFS protocol does
> > > > > not depend on working callback RPCs, but no delegations are granted
> > > > > (we had nfs-kernel-server package installed on clients before which masked
> > > > > the bug).
> > > >
> > > > So your gripe that you object to us requiring you to run rpc.svcgssd in
> > > > order to obtain server features such as NFSv4 callbacks?
> > >
> > > Absolutely not! Just thinking why we did not notice the problem earlier ...
> >
> > I wonder if there's anything we could do to make this more automatic,
> > though: e.g., perhaps whichever scripts are launching one of the gss
> > daemons should be replaced by one that launches both, since that's
> > generally what you'll want for NFSv4.0. (Not necessary for other
> > versions, but it doesn't hurt much.)
> >
> > Or perhaps they could be started on demand somehow.
>
> How is this any different to requiring that the user start rpc.statd
> before launching an NFSv3 mount? Just document the requirement if it
> isn't already clear enough, and we can move on.
That's good enough, but it's always nice if there's some configuration
we can skip. (Not that I'm volunteering.)
> The other source of confusion here, was that the rpc.svcgssd was
> delivered through a nfs-kernel-server package, which indicates that we
> first and foremost need to educate the distro packagers.
Yes, that's a mistake. The nfs-utils README is where we've been
documenting daemon startup--I'll work on a patch. (And see if the man
pages could use something too.) And somebody should ping Debian
(nfs-kernel-server sounds like a Debian thing.)
--b.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: NFSv4 backchannel authentication
2012-08-09 16:50 ` J. Bruce Fields
@ 2012-08-09 17:58 ` Zdenek Salvet
2012-08-09 18:01 ` [PATCH] README: note gssd/svcgssd may be needed on both sides J. Bruce Fields
1 sibling, 0 replies; 18+ messages in thread
From: Zdenek Salvet @ 2012-08-09 17:58 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Myklebust, Trond, Lukas Hejtmanek, linux-nfs@vger.kernel.org
On Thu, Aug 09, 2012 at 12:50:35PM -0400, J. Bruce Fields wrote:
> > The other source of confusion here, was that the rpc.svcgssd was
> > delivered through a nfs-kernel-server package, which indicates that we
> > first and foremost need to educate the distro packagers.
>
> Yes, that's a mistake. The nfs-utils README is where we've been
> documenting daemon startup--I'll work on a patch. (And see if the man
> pages could use something too.) And somebody should ping Debian
> (nfs-kernel-server sounds like a Debian thing.)
I sent bug report to Debian Bug Tracking System. Other distributions
may need a notice too, at least SLES<=11.1 and RHEL<=6.3 did not figure
it out themselves AFAICT ...
Best regards,
Zdenek Salvet salvet@ics.muni.cz
Institute of Computer Science of Masaryk University, Brno, Czech Republic
and CESNET, z.s.p.o., Prague, Czech Republic
Phone: ++420-549 49 6534 Fax: ++420-541 212 747
----------------------------------------------------------------------------
Teamwork is essential -- it allows you to blame someone else.
^ permalink raw reply [flat|nested] 18+ messages in thread* [PATCH] README: note gssd/svcgssd may be needed on both sides
2012-08-09 16:50 ` J. Bruce Fields
2012-08-09 17:58 ` Zdenek Salvet
@ 2012-08-09 18:01 ` J. Bruce Fields
1 sibling, 0 replies; 18+ messages in thread
From: J. Bruce Fields @ 2012-08-09 18:01 UTC (permalink / raw)
To: steved
Cc: Myklebust, Trond, Zdenek Salvet, Lukas Hejtmanek,
linux-nfs@vger.kernel.org
From: "J. Bruce Fields" <bfields@redhat.com>
Administrators and distributors have been confused about this.
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
---
README | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/README b/README
index e55b2dd..9bb69d7 100644
--- a/README
+++ b/README
@@ -71,18 +71,21 @@ scripts can be written to work correctly.
A/ mount -t nfsd /proc/fs/nfsd
- This filesystem needs to be mount before most daemons,
+ This filesystem needs to be mounted before most daemons,
particularly exportfs, mountd, svcgssd, idmapd.
It could be mounted once, or the script that starts each daemon
could test if it is mounted and mount it if not.
- B/ svcgssd ; idmapd
+ B/ svcgssd ; gssd; idmapd
These supply services to nfsd and so should be started before
rpc.nfsd. Where they come between mounting the nfsd filesystem
and starting the nfsd server is not important.
idmapd is only needed for NFSv4 support.
- svcgssd is only needed if exportfs NFS filesystem with crypto-
- security (Kerberos).
+ svcgssd is needed to export filesystems with Kerberos.
+ gssd should also be started to support granting delegations to
+ NFSv4.0 clients using Kerberos. However, if it is not started
+ this will only mean that delegations will not be granted. This
+ will not prevent NFSv4.0 clients from functioning normally.
C/ exportfs -av ; rpc.mountd
It is important that exportfs be run before mountd so that
@@ -148,10 +151,15 @@ scripts can be written to work correctly.
filesystems can be mounted with "-o nolock" before sm-notify.
This is appropriate for '/', '/usr', and '/var'.
- B/ gssd ; idmapd
+ B/ gssd ; svcgssd; idmapd
idmapd should be started before mounting any NFSv4 filesystems.
gssd should be started before mounting any NFS filesystems
securely (with Kerberos).
+ Before mounting any NFSv4.0 filesystems with Kerberos, svcgssd should
+ also be started to support the callbacks required for delegations.
+ However, a failure to start svcgssd will only mean that delegations
+ are turned off, and will not prevent such a mount from working
+ correctly.
C/ statd should be run before any NFSv2 or NFSv3 filesystem is
mounted with remote locking (i.e. without -o nolock).
--
1.7.9.5
^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: NFSv4 backchannel authentication
2012-08-09 15:53 ` Myklebust, Trond
2012-08-09 16:28 ` Lukas Hejtmanek
2012-08-09 16:50 ` J. Bruce Fields
@ 2012-08-10 5:20 ` NeilBrown
2012-08-10 17:23 ` J. Bruce Fields
2 siblings, 1 reply; 18+ messages in thread
From: NeilBrown @ 2012-08-10 5:20 UTC (permalink / raw)
To: Myklebust, Trond
Cc: J. Bruce Fields, Zdenek Salvet, Lukas Hejtmanek,
linux-nfs@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 2090 bytes --]
On Thu, 9 Aug 2012 15:53:01 +0000 "Myklebust, Trond"
<Trond.Myklebust@netapp.com> wrote:
> On Thu, 2012-08-09 at 10:45 -0400, J. Bruce Fields wrote:
> > On Thu, Aug 09, 2012 at 10:06:42AM +0200, Zdenek Salvet wrote:
> > > On Wed, Aug 08, 2012 at 01:18:09PM +0000, Myklebust, Trond wrote:
> > > > > We don't see any hard failures because NFS protocol does
> > > > > not depend on working callback RPCs, but no delegations are granted
> > > > > (we had nfs-kernel-server package installed on clients before which masked
> > > > > the bug).
> > > >
> > > > So your gripe that you object to us requiring you to run rpc.svcgssd in
> > > > order to obtain server features such as NFSv4 callbacks?
> > >
> > > Absolutely not! Just thinking why we did not notice the problem earlier ...
> >
> > I wonder if there's anything we could do to make this more automatic,
> > though: e.g., perhaps whichever scripts are launching one of the gss
> > daemons should be replaced by one that launches both, since that's
> > generally what you'll want for NFSv4.0. (Not necessary for other
> > versions, but it doesn't hurt much.)
> >
> > Or perhaps they could be started on demand somehow.
>
> How is this any different to requiring that the user start rpc.statd
> before launching an NFSv3 mount? Just document the requirement if it
> isn't already clear enough, and we can move on.
'mount.nfs' checks if statd is running and will start it if it isn't ....
which will probably annoy systemd as it likes to keep daemons in their own
little box. I guess systemd can be configured to register as statd and
auto-start it on the first 'are you there' request.
Could the same thing be done with rpc.svcgssd? Get it to auto-start either
by mount.nfs checking and running something, or by systemd pre-registering
the RPC port or something?
NeilBrown
>
> The other source of confusion here, was that the rpc.svcgssd was
> delivered through a nfs-kernel-server package, which indicates that we
> first and foremost need to educate the distro packagers.
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: NFSv4 backchannel authentication
2012-08-10 5:20 ` NFSv4 backchannel authentication NeilBrown
@ 2012-08-10 17:23 ` J. Bruce Fields
0 siblings, 0 replies; 18+ messages in thread
From: J. Bruce Fields @ 2012-08-10 17:23 UTC (permalink / raw)
To: NeilBrown
Cc: Myklebust, Trond, Zdenek Salvet, Lukas Hejtmanek,
linux-nfs@vger.kernel.org
On Fri, Aug 10, 2012 at 03:20:39PM +1000, NeilBrown wrote:
> On Thu, 9 Aug 2012 15:53:01 +0000 "Myklebust, Trond"
> <Trond.Myklebust@netapp.com> wrote:
>
> > On Thu, 2012-08-09 at 10:45 -0400, J. Bruce Fields wrote:
> > > On Thu, Aug 09, 2012 at 10:06:42AM +0200, Zdenek Salvet wrote:
> > > > On Wed, Aug 08, 2012 at 01:18:09PM +0000, Myklebust, Trond wrote:
> > > > > > We don't see any hard failures because NFS protocol does
> > > > > > not depend on working callback RPCs, but no delegations are granted
> > > > > > (we had nfs-kernel-server package installed on clients before which masked
> > > > > > the bug).
> > > > >
> > > > > So your gripe that you object to us requiring you to run rpc.svcgssd in
> > > > > order to obtain server features such as NFSv4 callbacks?
> > > >
> > > > Absolutely not! Just thinking why we did not notice the problem earlier ...
> > >
> > > I wonder if there's anything we could do to make this more automatic,
> > > though: e.g., perhaps whichever scripts are launching one of the gss
> > > daemons should be replaced by one that launches both, since that's
> > > generally what you'll want for NFSv4.0. (Not necessary for other
> > > versions, but it doesn't hurt much.)
> > >
> > > Or perhaps they could be started on demand somehow.
> >
> > How is this any different to requiring that the user start rpc.statd
> > before launching an NFSv3 mount? Just document the requirement if it
> > isn't already clear enough, and we can move on.
>
> 'mount.nfs' checks if statd is running and will start it if it isn't ....
> which will probably annoy systemd as it likes to keep daemons in their own
> little box. I guess systemd can be configured to register as statd and
> auto-start it on the first 'are you there' request.
>
> Could the same thing be done with rpc.svcgssd? Get it to auto-start either
> by mount.nfs checking and running something, or by systemd pre-registering
> the RPC port or something?
I wonder how hard it would be to teach systemd to do the
socket-activation trick with the cache upcalls: so, open the channel
file, wait till its readable, then kick off svcgssd and hand off the
file descriptor to it.
--b.
^ permalink raw reply [flat|nested] 18+ messages in thread