We're at the point now with the NFSv4 project that we'd like to publish
the user daemons that are necessary to support the existing client in
the 2.6.0 kernel.
Would it make sense to add these to the existing nfs-utils package?
There are basically 2 daemons required on the client side:
- Idmapper resolves NFSv4 over-the-wire names into uids/gids that can
be understood by the kernel.
- rpc.gssd sets up RPCSEC_GSS sessions to allow secure RPC negotiation
between the client and server. Initial support is for Kerberos 5, but
SPKM3 is in the pipeline too.
Both these two daemons have equivalents on the server side (but I'll
leave it to CITI/Neil to work out who wants to take responsability for
publishing those).
Cheers,
Trond
-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Thu, 2004-01-08 at 19:34, Trond Myklebust wrote:
> We're at the point now with the NFSv4 project that we'd like to publish
> the user daemons that are necessary to support the existing client in
> the 2.6.0 kernel.
>
> Would it make sense to add these to the existing nfs-utils package?
>
>
What type of stability have you seen from these?
Do you think these might be in a place to benefit from some wider use?
Thanks
-sv
-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
P=E5 to , 08/01/2004 klokka 22:41, skreiv seth vidal:
> On Thu, 2004-01-08 at 19:34, Trond Myklebust wrote:
> > We're at the point now with the NFSv4 project that we'd like to publish
> > the user daemons that are necessary to support the existing client in
> > the 2.6.0 kernel.
> >=20
> > Would it make sense to add these to the existing nfs-utils package?
> >=20
> >=20
>=20
> What type of stability have you seen from these?
> Do you think these might be in a place to benefit from some wider use?
The idmapper in particular is essential if you want to use NFSv4.
Without it, all your files will appear to be owned by nobody:nogroup,
and you will be unable to do anything to change the ownership.
rpc.gssd is necessary if you want to use strong authentication (for
NFSv2/v3 as well as for NFSv4).
The basic design of these 2 daemons has been stable for over a year now,
so they have been fairly well tested in the lab and among the NFSv4
beta-testers.
There are no known bugs in the daemons themselves, however until I'm
done merging the patches to Linus+Andrew, people who wish to actually
use NFSv4 should patch their client kernels with 2.6.1-NFS4_ALL from my
usual site.
Cheers,
Trond
-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Trond Myklebust wrote:
>Would it make sense to add these to the existing nfs-utils package?
>
>
Yes.. I think so... Since NFS will be the only one using them
I think is makes a lot of sense to put them in nfs-utils...
SteveD.
-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Thu, 8 Jan 2004, Trond Myklebust wrote:
> The idmapper in particular is essential if you want to use NFSv4.
Is there already a well agreed way and place (init scripts) to start/stop
these daemons ?
--
Bogdan Costescu
IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: [email protected]
-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
> On Thu, 8 Jan 2004, Trond Myklebust wrote:
>
>> The idmapper in particular is essential if you want to use NFSv4.
>
> Is there already a well agreed way and place (init scripts) to
> start/stop these daemons ?
Chuck Lever has written an init script for the daemons. About the only
thing that might be a subject of debate is the default mountpoint for the
pseudofs that the NFS client uses to communicate with the daemons. The
consensus at CITI is that it should be /var/lib/nfs/rpc_pipefs. I have no
strong feelings if people have alternative preferences, but note that this
is in any case configurable via the configuration files.
Cheers,
Trond
-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
We would like to publish the server side daemons at the same time as the
client side daemons, they have been developed in tandum, and share a good deal
of code.
-->Andy Adamson
>
> We're at the point now with the NFSv4 project that we'd like to publish
> the user daemons that are necessary to support the existing client in
> the 2.6.0 kernel.
>
> Would it make sense to add these to the existing nfs-utils package?
>
>
> There are basically 2 daemons required on the client side:
>
> - Idmapper resolves NFSv4 over-the-wire names into uids/gids that can
> be understood by the kernel.
>
> - rpc.gssd sets up RPCSEC_GSS sessions to allow secure RPC negotiation
> between the client and server. Initial support is for Kerberos 5, but
> SPKM3 is in the pipeline too.
>
> Both these two daemons have equivalents on the server side (but I'll
> leave it to CITI/Neil to work out who wants to take responsability for
> publishing those).
>
> Cheers,
> Trond
-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Thu, 8 Jan 2004, Trond Myklebust wrote:
> rpc.gssd is necessary if you want to use strong authentication (for
> NFSv2/v3 as well as for NFSv4).
Does this implement data stream encryption? (rpcsec as opposed to rpc
auth? (possibly getting my jargon wrong here))
> Cheers,
> Trond
regards,
--
Paul Jakma [email protected] [email protected] Key ID: 64A2FF6A
warning: do not ever send email to [email protected]
Fortune:
To thine own self be true. (If not that, at least make some money.)
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Fri, Jan 23, 2004 at 02:54:36PM +0000, Paul Jakma wrote:
> On Thu, 8 Jan 2004, Trond Myklebust wrote:
> > rpc.gssd is necessary if you want to use strong authentication (for
> > NFSv2/v3 as well as for NFSv4).
>
> Does this implement data stream encryption? (rpcsec as opposed to rpc
> auth? (possibly getting my jargon wrong here))
There are three levels levels of protection provided by rpcsec_gss, from
weakest to strongest:
authentication only: the header of each rpc request is signed, so you
who sent the request.
integrity: the body of each packet is also signed, so you know
the request itself hasn't been tampered with.
privacy: the body of each packet is encrypted, to prevent
eavesdropping.
In the krb5 case, these are selected using mount options (sec=krb5,
sec=krb5i, or sec=krb5p). Mainline 2.6 currently supports the first of
these. Patches in -mm support integrity. But privacy hasn't been
implemented yet (it's been done before, there's bits and pieces of code
still lying around, it just needs some time and effort).
--Bruce Fields
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Fri, 23 Jan 2004, J. Bruce Fields wrote:
> There are three levels levels of protection provided by rpcsec_gss, from
> weakest to strongest:
>
> authentication only: the header of each rpc request is signed, so you
> who sent the request.
> integrity: the body of each packet is also signed, so you know
> the request itself hasn't been tampered with.
> privacy: the body of each packet is encrypted, to prevent
> eavesdropping.
Ah, good.
> In the krb5 case, these are selected using mount options (sec=krb5,
> sec=krb5i, or sec=krb5p). Mainline 2.6 currently supports the
> first of these. Patches in -mm support integrity.
So we'll have strong authorisation and integrity checks for NFS^WRPC
soon in 2.6. Excellent news!
> But privacy hasn't been implemented yet (it's been done before,
> there's bits and pieces of code still lying around, it just needs
> some time and effort).
Ok. But its on the horizon at least? Would be really nice to have
this, esp if it can use some of the stronger algorithms supported by
Krb5 (eg DES3 and/or AES).
Anyway, future looks bright! Thanks!
> --Bruce Fields
regards,
--
Paul Jakma [email protected] [email protected] Key ID: 64A2FF6A
warning: do not ever send email to [email protected]
Fortune:
Political history is far too criminal a subject to be a fit thing to
teach children.
-- W.H. Auden
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs