Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 18 Feb 2019 08:05:29 -0800 (PST)
From:      "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net>
To:        Rick Macklem <rmacklem@uoguelph.ca>
Cc:        FreeBSD Net <freebsd-net@freebsd.org>
Subject:   Re: correct IP# for NFS kernel upcall to userland daemon
Message-ID:  <201902181605.x1IG5T3I005915@pdx.rh.CN85.dnsmgr.net>
In-Reply-To: <QB1PR01MB35370C0E73521F76C2A87B62DD630@QB1PR01MB3537.CANPRD01.PROD.OUTLOOK.COM>

next in thread | previous in thread | raw e-mail | index | archive | help
> Hi,
> 
> I have been in a recent discussion about what the correct IP address to use for
> an upcall from the kernel to the NFS daemon nfsuserd (which maps between
> uids<->usernames and gids<->group names).
> 
> The code uses UDP for the upcall (I once committed a patch changing that to
> an AF_LOCAL socket, but it broke certain sites where the directory the socket
> was being created in was NFS mounted).
> 
> Currently the code uses a hardwired "127.0.0.1".
> Rodney Grimes feels that it would be better to do a name lookup on "localhost"
> to get the address to use.
> 
> In this case, I am concerned that the daemon will not be able to start up under
> conditions where the DNS service isn't yet functional. (This problem can mostly
> be avoided by specifying "localhost" in /etc/hosts and configuring the system to
> use that file before DNS, but I still don't like having this dependency on DNS for
> the daemon starting up.)
> Note that the upcall will work for any IP# that refers to the local machine and it
> does not need to be the one specified for "localhost" in the DNS.
> 
> So, do you think I should do a lookup for "localhost" at daemon startup or use
> a hardwired "127.0.0.1/::1"?
> 
> Thanks in advance for any comments, rick

Note that my main issue with this is hardcoding of a value in the
kernel that can not be changed, thus if I either have no lo0 or
have configured lo0 to be something other than 127.0.0.1 this hard
coded use by the kernel of 127.0.0.1 would fail and there would
be no way around it short of a recompile.

I see a few other hard coded localhost values in the kernel and
minimally these should be garbage collected into
#define	LOCALHOST	0x7f000001
and much beter would be to put these into a tunable,
and finally best of all would be to find ways to not
be depending on "optional lo0 && lo0 == 7f000001" in
the kernel or userland code.

I do believe that the some of the test software used for CI
is also having similiar issues, and suspect that hard coding
these values in places is eventually going to lead to testability
issues.
-- 
Rod Grimes                                                 rgrimes@freebsd.org



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201902181605.x1IG5T3I005915>