On Sun, Apr 20, 2008 at 08:49:52PM -0400, Janne Karhunen wrote:
> On Sun, Apr 20, 2008 at 8:02 PM, J. Bruce Fields <[email protected]> wrote:
>
> > > I didn't get the idea. So the idea is to use multiple sockets,
> > > one bound to LOOPBACK and one to external interface?
> >
> > I suppose so. One socket would be for communication for the local
> > kernel nfsd, one for communication with statd peers.
>
> Ok, but that's really quite intrusive - my goal with that
> patch was to minimize the amount of changes. Sure,
> we can rework larger part of it if you think is better
> that way.
Yes. Hopefully it's not too bad....
> > > Complicated and unclean in my opinion: one address
> > > should suffice.
> >
> > The advantage is that it would require no changes to the kernel or
> > kernel interfaces, and would also solve the problem for people that
> > don't want to upgrade their kernels.
>
> Right, but that's hardly an issue with Linux. You need
> to do that twice per week anyway ;)
>
>
> > The "rpc over lo" interface to the kernel's lockd is simple enough, and
> > I'd rather not replace it with "rpc over either lo or the interface
> > specified via sysctl" unless there's a really clear advantage.
> >
> > (Also, would your patch mean lockd could accept requests that could have
> > spoofed source addresses?)
>
> Yes, but loopback can also be spoofed.
Is that true? I thought the kernel discarded packets from interfaces
other than lo claiming to be from 127.*.*.*.
--b.
On Sun, 20 Apr 2008 22:11:53 -0400
"J. Bruce Fields" <[email protected]> wrote:
> On Sun, Apr 20, 2008 at 08:49:52PM -0400, Janne Karhunen wrote:
> > On Sun, Apr 20, 2008 at 8:02 PM, J. Bruce Fields <[email protected]> wrote:
> >
> > > > I didn't get the idea. So the idea is to use multiple sockets,
> > > > one bound to LOOPBACK and one to external interface?
> > >
> > > I suppose so. One socket would be for communication for the local
> > > kernel nfsd, one for communication with statd peers.
> >
> > Ok, but that's really quite intrusive - my goal with that
> > patch was to minimize the amount of changes. Sure,
> > we can rework larger part of it if you think is better
> > that way.
>
> Yes. Hopefully it's not too bad....
>
> > > > Complicated and unclean in my opinion: one address
> > > > should suffice.
> > >
> > > The advantage is that it would require no changes to the kernel or
> > > kernel interfaces, and would also solve the problem for people that
> > > don't want to upgrade their kernels.
> >
> > Right, but that's hardly an issue with Linux. You need
> > to do that twice per week anyway ;)
> >
> >
> > > The "rpc over lo" interface to the kernel's lockd is simple enough, and
> > > I'd rather not replace it with "rpc over either lo or the interface
> > > specified via sysctl" unless there's a really clear advantage.
> > >
> > > (Also, would your patch mean lockd could accept requests that could have
> > > spoofed source addresses?)
> >
> > Yes, but loopback can also be spoofed.
>
> Is that true? I thought the kernel discarded packets from interfaces
> other than lo claiming to be from 127.*.*.*.
>
I think that's the case only if you have rp_filter turned on. It
usually is these days, but there are some situations where it doesn't
do what's expected (vlans, for instance), and has to be disabled.
--
Jeff Layton <[email protected]>
On Apr 20, 2008, at 10:11 PM, J. Bruce Fields wrote:
> On Sun, Apr 20, 2008 at 08:49:52PM -0400, Janne Karhunen wrote:
>> On Sun, Apr 20, 2008 at 8:02 PM, J. Bruce Fields <[email protected]
>> > wrote:
>>
>>>> I didn't get the idea. So the idea is to use multiple sockets,
>>>> one bound to LOOPBACK and one to external interface?
>>>
>>> I suppose so. One socket would be for communication for the local
>>> kernel nfsd, one for communication with statd peers.
>>
>> Ok, but that's really quite intrusive - my goal with that
>> patch was to minimize the amount of changes. Sure,
>> we can rework larger part of it if you think is better
>> that way.
>
> Yes. Hopefully it's not too bad....
My two pfennigs worth:
I think creating a separate loopback listener in the "-n" case is a
reasonable thing to do, and probably won't be terribly complex. This
isn't a performance path, so you can probably get away with a select
on multiple sockets.
Alternately, you could create separate rpc.statd daemons -- one would
listen only for loopback.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
On Mon, Apr 21, 2008 at 11:01 AM, Chuck Lever <[email protected]> wrote:
> I think creating a separate loopback listener in the "-n" case is a
> reasonable thing to do, and probably won't be terribly complex. This isn't
> a performance path, so you can probably get away with a select on multiple
> sockets.
I'm currently experimenting this by adding it a
statd_get_nlm_socket() and going through the
code to catch which socket should be used
and when..
--
// Janne