statd: statd_matchhostname() doesn't handle localhost properly The job of statd_matchhostname() is to work hard at matching two hostnames or presentation IP addresses that may refer to the same host. statd_matchhostname() turns the hostname of the local system into a list of addresses containing only the loopback address. The actual DNS registered address of the system does not appear in that list. Presentation IP addresses, on the other hand, are soundly ignored by the AI_CANONNAME option of getaddrinfo(3). The ai_canonname string that is returned is just the same presentation IP address. And the resulting list of addresses contains just that IP address. So if the DNS registered IP address of the local host is passed in as one argument, and the local hostname is passed as the other argument, statd_matchhostname() whiffs and believes there is no match. To fix this, the logic needs to be smarter about deriving a hostname from an IP address. This appears to cause no end of trouble: monitor records pile up in /var/lib/nfs/sm and sm.bak, notifications are missed, and so on. This has likely been around since commit cbd3a131 "statd: Introduce statd version of matchhostname()" (Jan 14, 2010). Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Steve Dickson <steved@redhat.com>
nfs-utils: Remove all uses of AI_ADDRCONFIG It was reported that, if only "lo" is up, mount.nfs 127.0.0.1:/export /mount fails with "Name or service not known". "man 3 getaddrinfo" says this: If hints.ai_flags includes the AI_ADDRCONFIG flag, then IPv4 addresses are returned in the list pointed to by res only if the local system has at least one IPv4 address configured, and IPv6 addresses are only returned if the local system has at least one IPv6 address configured. The man page oversimplifies here. A review of glibc shows that getaddrinfo(3) explicitly ignores loopback addresses when deciding whether an IPv4 or IPv6 address is configured. This behavior around loopback is a problem not just for mount.nfs, but also for RPC daemons that have to start up before a system's networking is fully configured and started. Given the history of other problems with AI_ADDRCONFIG and the unpredictable behavior it introduces, let's just remove it everywhere in nfs-utils. This fix addresses: https://bugzilla.linux-nfs.org/show_bug.cgi?id=191 Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Steve Dickson <steved@redhat.com>
statd: statd fails to monitor if no reverse mapping of mon_name exists Commit 8ce130c4 switched in the new statd_canonical_name() function that constructs a "unique" name statd can use to uniquely identify a monitor record. The legacy statd would monitor a client that sent an IP address with no reverse map as its caller_name. To remain bug-for-bug compatible, allow this case in the new statd. This shouldn't be a problem: statd_canonical_name() needs to create a unique name for the monitored host so it can keep track of monitor requests from the same remote. The IP address itself should work as well as the host's canonical name, in case there is no reverse mapping. We still enforce the requirement that a mon_name that is a DNS name must have a forward map to an IP address. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Steve Dickson <steved@redhat.com>
statd: Add API to canonicalize mon_names Provide a shared function to generate canonical names that statd uses to index its on-disk monitor list. This function can resolve DNS hostnames, and IPv4 and IPv6 presentation addresses. Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
statd: add nsm_present_address() API Add an API to convert a socket address to a presentation address string. This is used for displaying error messages and the like. We prefer getnameinfo(3) over inet_?to?(3) as it supports IPv6 scope IDs. Since statd has to continue to build correctly on systems whose glibc does not have getnameinfo(3), an inet_?to?(3) version is also provided. Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
statd: Introduce statd version of matchhostname() For the near future, statd will support IPv6 but exportfs will not. Thus statd will need a version of matchhostname() that can deal properly with IPv6 remotes. To reduce the risk of breaking exportfs, introduce a separate version of matchhostname() for statd to use while exportfs continues to use the existing AF_INET-only implementation. Note that statd will never send matchhostname() a hostname string containing export wildcards, so is_hostame() is not needed in the statd version of matchhostname(). This saves some computational expense when comparing hostnames. A separate statd-specific implementation of matchhostname() allows some flexibility in the long term, as well. We might want to enrich the matching heuristics of our SM_NOTIFY, for example, or replace them entirely with a heuristic that is not dependent upon DNS. Signed-off-by: Chuck Lever <chuck.lever@oracle.com>