On Mon, 4 Jan 2010, Ed Greshko wrote:
> Robert P. J. Day wrote:
> > On Mon, 4 Jan 2010, Ed Greshko wrote:
> >
> >
> >> http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.4/html/Deployment_Guide/ch-nfs.html
> >>
> >> States....
> >>
> >> |rpc.mountd| — This process receives mount requests from NFS
> >> clients and verifies the requested file system is currently
> >> exported. This process is started automatically by the |nfs|
> >> service and does not require user configuration. This is not used
> >> with NFSv4.
> >
> > and if that's truly the case, then the NFS start script
> > /etc/init.d/nfs should not try to invoke rpc.mountd (or rpc.statd
> > for that matter) when it's obvious that you're trying to run
> > exclusively with NFSv4, no? if that's the case, i can bugzilla
> > that as well but i want to make sure that it's really an error
> > first.
> >
> I suppose a case could be made for that either way. Seems rather
> minor to me.
>
> I've not yet had time to look a this stuff. However, is there any
> downside from starting rpc.mountd even if it isn't going to be used?
i don't know. and it's not only rpc.mountd. as i read it,
rpc.statd *also* becomes superfluous. and if there's no reason to run
a daemon, i see no point in running it. why waste the cycles?
also, the fact that you're (unnecessarily) running rpc.mountd and
rpc.statd might, in some weird way, support NFSv3 operations. if
you're not running those, it's pretty much a *guarantee* that you're
supporting only NFSv4, no? think of it as a sanity check. (and
remember my earlier bit where someone claimed that you *do* need to be
running them, they just don't need to be available to the outside
world so you don't need to allow them through the firewall.)
in any event, i just want to clarify the situation since i've seen
two apparently differing explanations.
rday
p.s. just FYI, i didn't plan on this discussion getting quite so
animated. :-) i figured getting a simple NFSv4 example running on
f12 would be a piece of cake. apparently, not quite.
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Kernel Pedantry.
Web page: http://crashcourse.ca
Twitter: http://twitter.com/rpjday
========================================================================--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
