Bugzilla Bug 186037

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