I'm trying to set up a system to be an NFS client only, there is no need for any NFS server processes on it. It doesn't look like there is a way to do that. I upgraded to the latest unstable net-fs/nfs-utils-1.1.0, which appears to have the following init scripts: /etc/init.d/rpc.gssd -- this script starts both rpc.gssd (needed for secure NFS clients) and rpc.svcgssd (needed only on the server). It also loads the NFS server kernel module, which is not needed on the client. (It also does not mount the RPC pipefs, so if this script is run before any of the others the daemons fail to start) /etc/init.d/rpc.idmapd -- this script starts rpc.idmapd, which is needed on both client and server but only if running NFSv4. However, it as well loads the NFS server kernel module, which is not needed on a client. /etc/init.d/nfsmount -- this script appears to mount all NFS filesystems. However, it also loads the server kernel module, which is not needed on a client. It also seems to require rpc.idmapd and rpc.gssd if any nfs4 filesystems are present. However, rpc.gssd would also be required if any nfs3 filesystems are mounted with krb security. /etc/init.d/nfs -- this script appears to start the server. I want to run a basic NFSv4 client supporting Kerberos security. I need the rpc.gssd and rpc.idmapd processes running, but do not need rpc.svcgssd nor the NFS server kernel module. I prefer not to run extraneous processes/modules, one of the things I like about Gentoo is the capability of being minimalist. I'd like to request that the NFS startup scripts support client only operation. From a general design point of view, do the gss and idmapd services really need their own separate init script? I can't think of any reason they would ever be run other than in the context of an NFS client/server. Rather than all of the separate scripts, how about one /etc/init.d/nfs script controlled by /etc/conf.d/nfs? The configuration file could contain variables such as "SERVER=yes" or "SERVER=no" to control whether or not to start server processes, and "CLIENT=yes"/"CLIENT=no" to control client processes. Another variable such as "SECURE=yes" would control whether or not to start the gss processes, and perhaps "NFS4=yes" to determine whether or not to start idmapd. This approach would seem simpler and more configurable, allowing initialization of only the necessary components. If desired, there could still be two scripts, one for the server and one for the client, but I like the one script approach. What do you think? Thanks...
Any feedback on this? At this point, I think I am just going to start the necessary client components in local.start, not ideal, but preferable to me than running unnecessary server components. Thanks...
what've you said is probably largely correct ... the trouble is i dont run any nfs4 stuff so i dont really have a way of testing it i'll post updated ebuilds in a bit you can test
This fell off my radar for a bit, we were evaluating a NetApp appliance and it didn't work out. However, we're about to prototype a Solaris ZFS file server, so I'm going to be digging into NFSv4 clients again. Any thoughts/progress on a new init setup with better NFSv4 support? I'd be willing to implement something as long as there was a general consensus on an acceptable approach and a reasonable chance of it being incorporated into the official tree. Thanks...
i think most of the points you've raised have been addressed since rpc.gssd: - still needs to be split up into rpc.svcgssd and rpc.gssd - nfsd is not loaded - pipefs is mounted rpc.idmapd: - only gets pulled in by nfs/nfsmount as needed by exportfs/fstab - nfsd is not loaded nfsmount: - nfsd is not loaded - only pulls in idmapd when nfs4 is used and gssd when security is used the gss/idmapd were split because the combo init.d scripts were growing too large and maintaining the same code in the same init.d scripts was undesirable. we had 1 large script. it didnt work. i dont want to go back to that.
I think once rpc.gssd is split up into rpc.svcgssd and rpc.gssd things will work ok for me. I'm actually going to use the automounter, so the automatic detection in nfsmount won't pick up gss or idmapd, but I can manually add them to the default runlevel to get that going. Any thoughts on how soon the rpc.gssd split might happen? I hate running extra stuff on my boxes :)... Thanks...
should be split in cvs now
