sysctl behavior for docker-io

[Lennart Poettering]

On Fri, 04.10.13 16:04, Matthew Miller (mattdm at fedoraproject.org) wrote:

> On Fri, Oct 04, 2013 at 02:15:07PM -0500, Lokesh Mandvekar wrote:
> > So, IP forwarding seems to be disabled by default in Fedora. docker-io
> > requires IP forwarding enabled
> > 
> > With respect to packaging, we'd like to have docker-io installation set
> > sysctl values to enable IPv4 and IPv6 forwarding:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1011680
> > 
> > I was told on #fedora-devel that changing sysctl values during installation
> > would spell trouble from a sysadmin's POV, so my plan was to install
> > 80-docker.conf into /usr/lib/sysctl.d but not have the IP forwarding sysctl
> > values take effect at install time. Would this be the right approach?
> 
> I agree that they shouldn't be changed at RPM install time. However, I'm
> also not sure that we should drop something into sysctl.d, because
> 
> a) that doesn't take effect with the case of "yum install docker-io;
>    systemctl start docker", so that's confusing for users
> 
> b) having docker _installed_ isn't really hte case where we need this --
>    it's when docker is running.
> 
> So, my first suggestion is to put the configuration into the systemd service
> file.
> 
> But, I have a question: What does libvirt do? Both as an example, and as a
> possible solution -- will this problem go away when we convert to using
> that, because libvirt will just take care of that?

This is the general problem that IP forwarding is no local setting, and
that the global setting has no inherent concept of ownership or
refcounting. I am pretty sure it would suck if docker-io decides to take sole
ownership of this setting, but I am not convinced that libvirt would be
a much better owner. Given that this is a network related setting I have
the suspicion that if something should take sole ownership of this
setting then it probably should be some networking package, alas we have
so many of those, and at least two are competing to be the one
implementation that people use on servers to setup the network.

Given the lack of an ownership concept, and thus no chance that the
sysctl is dynamically reset to off as soon as no running service is
requiring it anymore, I'd probably not bother at all with trying to do
that, hence the best thing we could currently do is simply turn it on
statically on install of each package that needs it (by dropping in
individual tmpfiles in /usr/sysctl.d/ for each package that needs it),
and documenting how the admin can reset it temporarily (with echo > to
/proc/sys), or statically (by symlinking the tmpfiles snippets under
identical names in /etc/sysctl.d/ to /dev/null).

Or in other words: I don't think it makes much sense to turn this on
only at runtime inside the service file as matthew suggests, as it hides
the fact that the setting is made, makes it hard for admins to discover
and override it, and creates the assumption that the package would turn
off the setting safely again after the daemon exited, but which it
doesn't and can't since it doesn't know if anything else still requires
it.

Hope that makes some sense,

Lennart

-- 
Lennart Poettering - Red Hat, Inc.