Janne Karhunen wrote:
> On Fri, Apr 18, 2008 at 1:36 PM, J. Bruce Fields <[email protected]> wrote:
>
>
>> > Apparently lockd does not expect statd to be used with -n
>> > switch: statd is expected to bind loopback, always. Attached
>> > patches show one (IPv4 specific) way of fixing it. Comments?
>>
>> Maybe statd really should always bind to the loopback interface? Is
>> there any reason not to?
>>
>
> In my case I used -n to push NSM/NLM comms to
> clusters specific NFS service address (that just
> happens to migrate all around). -n is the only way
> to do this: otherwise it will bind to INADDR_ANY
> on node that has gazillion interfaces/addresses..
>
>
What happens on systems with more than one network interface?
Thanx...
ps
> That, and the original reasoning for the option is
> said in statd code:
>
> /*
> * If a local hostname is given (-n option to statd), bind to
> the address
> * specified. This is required to support clients that ignore
> the mon_name in
> * the statd protocol but use the source address from the
> request packet.
> */
>
>
>
>> From a quick look at the current nfs-utils code: it looks like the -n
>> option only affects the operation of the sm-notify program that's called
>> on boot to notify peer statd's? I'm a little confused. (What version
>> of nfs-utils are you working from?)
>>
>
> Right. 1.0.8 -> 1.0.12, it's valid for all.
>
>
>
On Fri, Apr 18, 2008 at 4:22 PM, Peter Staubach <[email protected]> wrote:
> > In my case I used -n to push NSM/NLM comms to
> > clusters specific NFS service address (that just
> > happens to migrate all around). -n is the only way
> > to do this: otherwise it will bind to INADDR_ANY
> > on node that has gazillion interfaces/addresses..
> >
>
> What happens on systems with more than one network interface?
Using -n breaks and without it it uses loopback
at least on this system - but that's just luck I
guess. And, of course, without -n it's bound to
ANY which leaves ports wide open all around.
--
// Janne