future of sysctls?

future of sysctls?

[Ludwig Nussel]

Hi,

I'm currently struggling to find a sane way to set
net.ipv6.conf.default.use_tempaddr.
Traditionally at some point during boot "sysctl -e -q -p /etc/sysctl.conf" is
called. That doesn't really work out anymore. The aforementioned setting needs
to be applied after the ipv6 module is loaded (could be compiled into the
kernel too though) otherwise it wouldn't apply. It needs to be set before a
network driver is loaded though as the default value is copied to
interfaces specific settings at interface creation time. On top of
that there are also network interface specific sysctls that need to
be applied after an interface is created (e.g.
net.ipv6.conf.eth0.use_tempaddr).
Are there any plans to better deal with that?
Like e.g. emitting events when some part of the kernel registers a sysctl so
userspace can override the compiled in default value?
Or just offer sysfs attributes instead of sysctls?

cu
Ludwig

-- 
 (o_   Ludwig Nussel
 //\
 V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) 

Re: future of sysctls?

[Lennart Poettering]

On Thu, 12.05.11 17:41, Ludwig Nussel (ludwig.nussel@suse.de) wrote:

> Hi,
> 
> I'm currently struggling to find a sane way to set
> net.ipv6.conf.default.use_tempaddr.
> Traditionally at some point during boot "sysctl -e -q -p /etc/sysctl.conf" is
> called. That doesn't really work out anymore. The aforementioned setting needs
> to be applied after the ipv6 module is loaded (could be compiled into the
> kernel too though) otherwise it wouldn't apply. It needs to be set before a
> network driver is loaded though as the default value is copied to
> interfaces specific settings at interface creation time. On top of
> that there are also network interface specific sysctls that need to
> be applied after an interface is created (e.g.
> net.ipv6.conf.eth0.use_tempaddr).

Something like this is kinda broken anyway, since it is racy: you can
apply the sysctl only after the interface is already available.

Might be a good idea to just ignore these kinds of settings. Or if this
is not possible, then set them from NM or whatever controls the network.

> Are there any plans to better deal with that?
> Like e.g. emitting events when some part of the kernel registers a sysctl so
> userspace can override the compiled in default value?
> Or just offer sysfs attributes instead of sysctls?

In a systemd world the ipv6 module is loaded very early and hence the
sysctl should always be available, no special setup needed. If the same
problem appears in real life with other modules too, then we could order
sysctl setting after module loading and fix things by this.

Can't tell you though what to do in a non-systemd world however.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

Re: future of sysctls?

[Ludwig Nussel]

Lennart Poettering wrote:
> On Thu, 12.05.11 17:41, Ludwig Nussel (ludwig.nussel@suse.de) wrote:
> > I'm currently struggling to find a sane way to set
> > net.ipv6.conf.default.use_tempaddr.
> > Traditionally at some point during boot "sysctl -e -q -p /etc/sysctl.conf" is
> > called. That doesn't really work out anymore. The aforementioned setting needs
> > to be applied after the ipv6 module is loaded (could be compiled into the
> > kernel too though) otherwise it wouldn't apply. It needs to be set before a
> > network driver is loaded though as the default value is copied to
> > interfaces specific settings at interface creation time. On top of
> > that there are also network interface specific sysctls that need to
> > be applied after an interface is created (e.g.
> > net.ipv6.conf.eth0.use_tempaddr).
> 
> Something like this is kinda broken anyway, since it is racy: you can
> apply the sysctl only after the interface is already available.

Exactly.

> Might be a good idea to just ignore these kinds of settings. Or if this
> is not possible, then set them from NM or whatever controls the network.

That's that hack that's currently in place. Network scripts grep
/etc/sysctl.conf for interface specific settings...

> > Are there any plans to better deal with that?
> > Like e.g. emitting events when some part of the kernel registers a sysctl so
> > userspace can override the compiled in default value?
> > Or just offer sysfs attributes instead of sysctls?
> 
> In a systemd world the ipv6 module is loaded very early and hence the
> sysctl should always be available, no special setup needed. If the same
> problem appears in real life with other modules too, then we could order
> sysctl setting after module loading and fix things by this.

Grepping for register_sysctl in the kernel sources shows quite a few modules
that use sysctls. A prominent one is nfs.
If you apply sysctl setttings after module loading, specifically network
drivers, the ipv6 setting won't have any effect anymore though.

cu
Ludwig

-- 
 (o_   Ludwig Nussel
 //\
 V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) 

Re: future of sysctls?

[Lennart Poettering]

On Tue, 17.05.11 09:15, Ludwig Nussel (ludwig.nussel@suse.de) wrote:

> 
> Lennart Poettering wrote:
> > On Thu, 12.05.11 17:41, Ludwig Nussel (ludwig.nussel@suse.de) wrote:
> > > I'm currently struggling to find a sane way to set
> > > net.ipv6.conf.default.use_tempaddr.
> > > Traditionally at some point during boot "sysctl -e -q -p /etc/sysctl.conf" is
> > > called. That doesn't really work out anymore. The aforementioned setting needs
> > > to be applied after the ipv6 module is loaded (could be compiled into the
> > > kernel too though) otherwise it wouldn't apply. It needs to be set before a
> > > network driver is loaded though as the default value is copied to
> > > interfaces specific settings at interface creation time. On top of
> > > that there are also network interface specific sysctls that need to
> > > be applied after an interface is created (e.g.
> > > net.ipv6.conf.eth0.use_tempaddr).
> > 
> > Something like this is kinda broken anyway, since it is racy: you can
> > apply the sysctl only after the interface is already available.
> 
> Exactly.
> 
> > Might be a good idea to just ignore these kinds of settings. Or if this
> > is not possible, then set them from NM or whatever controls the network.
> 
> That's that hack that's currently in place. Network scripts grep
> /etc/sysctl.conf for interface specific settings...

Urks. What we could do to make this nicer is add a simple prefix match
logic to our sysctl apply tool, so that it is easy to apply a subtree of
sysctls when the time comes.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

Re: future of sysctls?

[Ludwig Nussel]

Lennart Poettering wrote:
> On Tue, 17.05.11 09:15, Ludwig Nussel (ludwig.nussel@suse.de) wrote:
> > Lennart Poettering wrote:
> > > On Thu, 12.05.11 17:41, Ludwig Nussel (ludwig.nussel@suse.de) wrote:
> > > > I'm currently struggling to find a sane way to set
> > > > net.ipv6.conf.default.use_tempaddr.
> > > > Traditionally at some point during boot "sysctl -e -q -p /etc/sysctl.conf" is
> > > > called. That doesn't really work out anymore. The aforementioned setting needs
> > > > to be applied after the ipv6 module is loaded (could be compiled into the
> > > > kernel too though) otherwise it wouldn't apply. It needs to be set before a
> > > > network driver is loaded though as the default value is copied to
> > > > interfaces specific settings at interface creation time. On top of
> > > > that there are also network interface specific sysctls that need to
> > > > be applied after an interface is created (e.g.
> > > > net.ipv6.conf.eth0.use_tempaddr).
> > > 
> > > Something like this is kinda broken anyway, since it is racy: you can
> > > apply the sysctl only after the interface is already available.
> > 
> > Exactly.
> > 
> > > Might be a good idea to just ignore these kinds of settings. Or if this
> > > is not possible, then set them from NM or whatever controls the network.
> > 
> > That's that hack that's currently in place. Network scripts grep
> > /etc/sysctl.conf for interface specific settings...
> 
> Urks. What we could do to make this nicer is add a simple prefix match
> logic to our sysctl apply tool, so that it is easy to apply a subtree of
> sysctls when the time comes.

I've sent a patch to the procps maintainer but he has yet to
respond. It's not a real solution anyways. It just makes a dirty
hack a little more efficient.

cu
Ludwig

-- 
 (o_   Ludwig Nussel
 //\
 V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) 

Re: future of sysctls?

[Lennart Poettering]

On Wed, 18.05.11 09:03, Ludwig Nussel (ludwig.nussel@suse.de) wrote:

> > > > Might be a good idea to just ignore these kinds of settings. Or if this
> > > > is not possible, then set them from NM or whatever controls the network.
> > > 
> > > That's that hack that's currently in place. Network scripts grep
> > > /etc/sysctl.conf for interface specific settings...
> > 
> > Urks. What we could do to make this nicer is add a simple prefix match
> > logic to our sysctl apply tool, so that it is easy to apply a subtree of
> > sysctls when the time comes.
> 
> I've sent a patch to the procps maintainer but he has yet to
> respond. It's not a real solution anyways. It just makes a dirty
> hack a little more efficient.

Note that systemd does not use the procps' implementation of sysctl, but
our own one since the upstream version does not support /etc/sysctl.d/
or anything like this.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

Re: future of sysctls?

[Karel Zak]

On Wed, May 18, 2011 at 07:32:30PM +0200, Lennart Poettering wrote:
> On Wed, 18.05.11 09:03, Ludwig Nussel (ludwig.nussel@suse.de) wrote:
> 
> > > > > Might be a good idea to just ignore these kinds of settings. Or if this
> > > > > is not possible, then set them from NM or whatever controls the network.
> > > > 
> > > > That's that hack that's currently in place. Network scripts grep
> > > > /etc/sysctl.conf for interface specific settings...
> > > 
> > > Urks. What we could do to make this nicer is add a simple prefix match
> > > logic to our sysctl apply tool, so that it is easy to apply a subtree of
> > > sysctls when the time comes.
> > 
> > I've sent a patch to the procps maintainer but he has yet to
> > respond. It's not a real solution anyways. It just makes a dirty
> > hack a little more efficient.
> 
> Note that systemd does not use the procps' implementation of sysctl, but
> our own one since the upstream version does not support /etc/sysctl.d/
> or anything like this.

 procps project has been forked, ML:

    http://www.freelists.org/list/procps

 The upstream is active and maintained by people from Fedora, Suse
 and Debian.  So, it would be better to contribute to this project
 than maintain and distribute systemd specific stuff... :-)

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com