FW: Kerberized NFS (GSS-API) problem with multiple-IP Address and single hostname

[sandeep patil]

Thanks all for your suggestions.

Warload - well the problem is having one - name.example.com results in multiple IP Addresses. As rightly pointed out by frank.

> You did make me think of another solution.  Force the use of TCP.  That
> won't be 100% reliable (depends on client implementation) but it might
> be good enough.

Why would forcing it to TCP help ? Any Clue/advice ..

>>The typical way to handle this is with the automounter.  With automounted
>>NFS filesystems,  you can specify multiple NFS servers per mount, and
>>the client picks one and sticks with it.
This may not work as even if we are able to have an NFS client stick to a single NFS server, the kerberized part of NFS which inturn calls
GSS-API internally does a host lookup (almost everytime) and contacts the DNS for an IP and ends up with a new IP each time. :-(

>>Or instead of a load balancer it could be a load
>>balanced DNS server (gives only a single IP address but a different
>>one per client).
This could work but will need enhancements at the DNS server side unless its inherently supported by DNS, no clue there . Any input ?

-S


> Date: Tue, 4 Jan 2011 11:42:17 -0800
> From: frank+krb at linetwo.net
> To: warlord at mit.edu; san_patil at hotmail.com
> CC: krbdev at mit.edu
> Subject: Re: Kerberized NFS (GSS-API) problem with multiple-IP Address and single hostname
> 
> On 1/4/11 8:54 AM -0500 Derek Atkins wrote:
> > Hi,
> >
> > sandeep patil <san_patil at hotmail.com> writes:
> >
> >> To be specific;
> >> I have kerberized NFS server running on 3 separate machine (exporting
> >> the same share) where ever machine has a different IP address but the
> >> same hostname (In other words the hostname is associated with 3
> >> IP-address- for general load balancing using DNS). Now when I acquire
> >> kerberos credentials from a client machine and mount the NFS share
> >> against the hostname ,it fails. The reason it seems to fail is because
> >> when the gss-api handshake takes place between the NFS client and NFS
> >> server , the kerberos/gss-api library always tends to resolve the
> >> hostname to ipaddress and in this case ends up getting different IP
> >> address.  So looks like when we mount NFS, the first part of the gss-api
> >> handshake takes place with one machine and in the next iteration it goes
> >> to a different machine ( where there is no gss-api context) and hence it
> >> fails.
> >
> > I don't think the problem is that name.example.com results in multiple
> > IP Addresses.  I think the problem is that the reverse-resolution of the
> > IP Addresses result in 3 different names!  I suspect it's trying to use
> > the reverse-resolution to find the name to use for kerberos.
> 
> No, as Sandeep explained, when an NFS request goes to an IP that wasn't
> the IP the host mounted from, that new machine doesn't have a GSSAPI
> context.  NFS doesn't use the raw Kerberos session key, it establishes
> a context, which is server-specific state.
> 
> Even if it could just use the raw session key, you wouldn't want that
> because you wouldn't be able to detect replay.
> 
> If the reverse's didn't match it wouldn't work but the symptoms would
> be different.
> 
> You did make me think of another solution.  Force the use of TCP.  That
> won't be 100% reliable (depends on client implementation) but it might
> be good enough.