> On Tue, 2014-04-08 at 10:39 -0700, Frank Filz wrote: > > > > If you mount by IP do you really care about krb5 ? Probably not, > > > > maybe that's a clue we should not even try ... > > > > > > > > > > It's certainly possible that someone passes in an IP address but > > > then says > > "-o > > > sec=krb5". It has worked in the past, so it's hard to know whether > > > and how many people actually depend on it. > > > > Mount by ip is sometimes used with clustered servers, especially when > > they have all their IP addresses in the DNS record. Even using a FQDN > > that just specifies that one IP address probably won't work then > > (since it probably is NOT the hostname used in the server credential). > > I do not understand this, using an IP address or a name that resolve to said IP > address is the same. But a name can resolve to a set of IP addresses, often in round-robin fashion. It would cause havoc with NFS server on a cluster if a v3 client had locks on 192.168.0.10 (resolved from server.mycompany.com), and then rebooted, and resolved to 192.168.0.9 and sent SM_NOTIFY there). At least that isn't an issue with v4... Or worse, tcp connection is dropped due to inactivity, and new connection is made to a different server node. But this could still be an issue with v4... The workaround has been to specify specific IP address. Now I haven't done enough with krb5 recently to know how well that works... I guess I'm just offering one reason IP addresses might have been specified on mount... > As long as the server has a keytab with a key in that name it should just work > fine, even if the hostname on the actual machine is different. > > If this does not work it is a bug in rpc.svcgssd/gss-proxy, and should be fixed, > not something to try to work around using IP addresses. Frank -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
