> 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 rgri...@freebsd.org _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
