Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Lars Ellenberg wrote:
>
> / 2004-03-15 10:52:58 -0500
> \ Todd Denniston:
> > I think a good deal of my confusion comes from that script not being overtly
> > available for comparison with what redhat has. The way it is used in the
> > documentation it looks like the person writing it thought everyone had a copy,
> > so I believe it is from a particular distribution which I happen not to be
> > using.
>
> As alreaqy stated, the referred to "nfsserver" is
> /etc/init.d/nfsserver (for example on SuSE), and if this happens
> to be called /etc/init.d/nfs on RH (and derivatives), this is
> perfectly ok.
>
Yes, that would be perfectly ok, however because there was nothing saying this
was a suse script there was no way for me to see if what it did was the same
as redhat for all I knew it was something on the ha list that was not in
heartbeat.
after more poking around I found
http://216.239.37.104/search?q=cache:6e9zYEyEB7sJ:rpmfind.net/linux/RPM/suse/8.2/i386/suse/i586/nfs-server-2.2beta51-39.i586.html+nfsserver+suse+init.d&hl=en&ie=UTF-8
grabbed the source rpm and opened it.
assuming nfsserver.init is renamed /etc/rc.d/init.d/nfsserver, it looks like
redhat starts rpc.nfsd and rpc.mountd in a different order than SUSE and
redhat bothers with something it calls "lockd ports" and SUSE completely
ignores them.
There is still a problem (from a documentation point of view).... the DRBD
HOWTO "drbd/documentation/HOWTO/DRBD-HOWTO.sgml" 1) does not tell the user
that "nfsserver" is SUSE's script that "starts and stops the programs
rpc.mountd & rpc.nfsd", and 2) does not address statd&lockd at all.
> Also note that distributors may have updated their resource
> scripts since the hostname issue with statd became obvious.
>
> As you already found out, your Fedora resource scripts seem to
> support the hostname parameter to nfsd. In SuSE this is in
> /etc/sysconfig/nfs
> #
> # you can specify a hostname for statd, which makes sense for
> # some ha nfs-server setups
> #
> STATD_HOSTNAME=""
>
> If I understand you correctly, your problem seems to be that you
> found a HowTo which refers to problems you do not have, because
> your resource scripts take care of them already.
>
My problem is that in finishing up the setup for my systems (following
"drbd/documentation/HOWTO/DRBD-HOWTO.sgml", I was looking through
redhat-config-services[1] I see among the configured to be up services
'nfslock'[2] and think `woow, I'm setting up an nfs server better figure out
if this thing is correctly configured for what I am doing.`. When I went
looking on the net about [nfslock||statd||lockd] &&
[drbd||fallover||heartbeat] I found some old notes about it (see my first
email in this Thread for links), but none of them seemed to come to conclusion
online.
As I would like to have a system with as few surprises as possible when it
replaces the aging system (a solaris 2.6 system with a physically big disk
array), and I do not know all the in and outs of nfs (protocol level), I
wanted advice from the sages however the sages had not answered the question
in forms that I was asking it, if at all.
> So then, why not just be happy?
because I do not understand the correctness of the situation...
it is working, but is it working correctly? have I got a stick hut in the
sandy tidal zone of the ocean, or do I have a shotgun shack on some nice Miami
beach frontage and I'm ok until a hurricane shows up [the slope seems kind of
shallow out to that salty water]?
The online references I had in the first email indicate rcp.statd needs to be
up (even in HA situations), but is it ok for it to be up all the time or
should it be touched as the cluster manager changes services from one node to
the other?
> Or did I get you wrong?
I kind of expect to send you some diffs to the HOWTO when I get this figured
out, so I need to know if I have a good or bad config on it before making
HOWTO changes. :)
>
> Lars Ellenberg
[1]redhat-config-services
man page excerpt
"DESCRIPTION
This is a graphical tool for enabling and disabling services (including
xinetd services). Functionality to start, stop, and restart services is
also included."
I assume YAST has a similar service configuration capability.
[2] nfslock
Description from redhat-config-services
"NFS is a popular protocol for file sharing across TCP/IP networks. This
service provides NFS file locking functionality."
--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter