On Tue, Nov 04, 2008 at 01:53:17PM -0500, Brian J. Murrell wrote: > On Tue, 2008-11-04 at 13:00 -0500, William A. (Andy) Adamson wrote: > > Hi > > Hello, > > > In general, the instructions at the CITI web site will be useful. > > > > From http://www.citi.umich.edu/projects/nfsv4/linux/using-nfsv4.html: > > > > Mounting and exporting krb5 > > > > To mount a filesystem using krb5, provide the "-osec=krb5" option to mount. > > Indeed. > > > To export a filesystem using krb5, add the export option "sec=krb5". > > (Note: if your kernel is older than 2.6.23, or nfs-utils older than > > 1.1.1, you will instead need to export to a special client named > > "gss/krb5".) > > Ahhh. This, I did not know. > > > So instead of using the old "gss/krb5" which indeed did replace the > > ip/netmasks list, you can now specify the use of gssapi with an export > > option, and still set ip/netmasks. > > Cool. I think it's still useful to be able to provide some exports as > ro (i.e. forced ro by the server) to some machines (and rw to others) > even with gssapi, yes? You can still vary ro/rw based on machine or security flavor; e.g. /home foo(sec=krb5,ro) /home bar(sec=krb5,rw) or /home foo(ro,sec=krb5,rw) (readable by all users, writeable only by krb5 users). This should all be documented by "man exports". > I did notice the bit of text about the single pseudo filesystem. Given > that on my server, I exported a number of filesystems, including / to > privileged (I'm in a very small and trusted environment) clients, it > seemed natural to just set / to fsid 0. I also exported the few other > exports I wanted some nfs4 clients to mount as such: > > / gss/krb5i(rw,insecure,sync,wdelay,no_subtree_check,no_root_squash,fsid=0,crossmnt,anonuid=65534,anongid=65534) > /home gss/krb5i(rw,no_root_squash,sync,subtree_check,anonuid=65534,anongid=65534) > /mnt/data gss/krb5i(rw,sync,subtree_check,crossmnt,anonuid=65534,anongid=65534) > /mnt/data/photos gss/krb5i(rw,sync,subtree_check,anonuid=65534,anongid=65534) > > where those are all on different filesystems on the server. I'm > starting to feel like this is not how it's supposed to be done. That'll work--but do you really want "/" to be accessible (writeable, even!) over nfs? --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
