Re: mountd, rpc.lockd and rpc.statd patches for testing

On Thu, Apr 19, 2012 at 08:44:37PM -0400, Rick Macklem wrote:
> Andrey Simonenko wrote:
> > 
> > 1. What is the sense to try to use the same port number for all
> > supported netconfigs if specific port number is not given in
> > a command line option?
> > 
> Well, there was a discussion of this on one of the mailing lists
> at the time. I started with a much simpler patch that didn't try and
> make all 4 <udp/tcp, ip4/ip6> combinations use the same port#, but
> others felt that was important. (Something about tracking what port#
> were in use, but I can't quite recall. If you want to know the reasoning,
> look for the thread that would have been shortly before the commit.)

That discussion was in stable_at_ mailing list under the subject
"statd/lockd startup failure" started at February 2011.  That discussion
had two reasons to use one port for all netconfigs: 1) tracking network
connections and 2) firewall configurations.

If specific port number is not given in a command line, then this port
number should be taken from rpcinfo output for example, so it should be
taken manually or by some script.  Anyway it will require some work to
obtain a port number before using it in tcpdump or in firewall settings.

I checked rpcinfo output for mountd on Solaris and NetBSD, on both
systems mountd can use different ports for different netconfigs.

> > 2. What is the sense of specifying specific IP addresses for mountd
> > and
> > similar RPC programs that do not have predefined port numbers?
> > 
> I'm not sure what you are asking here? (Are you referring to the "-h"
> command line option?)

Yes, about the -h command line option.

Such option works for nfsd, since it has predefined port number,
but it will not work correctly for other RPC programs when specific
port number is not given.  Bigger number of specific addresses given
in this option will increase probability that mountd will fail.
There are several attempts to select one random port number for all
netconfigs (and for all specified addresses), but these attempts do not
guaranty that mountd will not fail.

Several systems do not have -h like option for nfsd, mountd, etc.

Looks like that when this option was proposed for mountd, rpc.statd and
rpc.lockd it was not considered that using non wildcard address for RPC
programs with not predefined port numbers does not fit with the RPC port
mapper logic.  (BTW rpc.lockd uses random port numbers for all netconfigs
on 10-CURRENT and 9-STABLE).

If the -h option (address) is really needed, then I would require to
specify the -p option (port number) as well, at least one will know
port number and can use it in firewall settings, but specifying unused
port number is required for all combinations of netconfigs and addresses.
Otherwise, successful start of mountd depends on number of -h options and
network activity of other programs.