From owner-freebsd-net@freebsd.org Mon Feb 18 16:05:32 2019 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B3D2614E0866 for ; Mon, 18 Feb 2019 16:05:32 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 812F56E48E for ; Mon, 18 Feb 2019 16:05:31 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x1IG5TLi005916; Mon, 18 Feb 2019 08:05:29 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id x1IG5T3I005915; Mon, 18 Feb 2019 08:05:29 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201902181605.x1IG5T3I005915@pdx.rh.CN85.dnsmgr.net> Subject: Re: correct IP# for NFS kernel upcall to userland daemon In-Reply-To: To: Rick Macklem Date: Mon, 18 Feb 2019 08:05:29 -0800 (PST) CC: FreeBSD Net X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 812F56E48E X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.22 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.89)[0.888,0]; NEURAL_HAM_LONG(-0.30)[-0.301,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.76)[0.760,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: pdx.rh.CN85.dnsmgr.net]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-0.01)[ip: (0.02), ipnet: 69.59.192.0/19(0.01), asn: 13868(-0.01), country: US(-0.07)] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 16:05:32 -0000 > 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