Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Wouter Verhelst <wouter@debian.org>]

On Fri, Aug 31, 2012 at 09:56:27AM +0200, Josselin Mouette wrote:
> Le jeudi 30 août 2012 à 22:19 +0200, Wouter Verhelst a écrit : 
> > On Fri, Aug 24, 2012 at 10:44:11AM +0200, Andrew Shadura wrote:
> > > How do you suppose it's possible to undo arbitrary network
> > > configuration done by arbitrary set of tools when there's no central
> > > place to hold such information (and can't possibly be)?
> > 
> > Actually, the kernel holds that information. Any tool can just query the
> > kernel for information, and decide what to do with what's returned.
> 
> Yes it does, but does it hold it in a meaningful, structured way?

Yes.

> In complex setups, for example, there might be no certain way to say
> which interface is related to which route.

wouter@carillon:~$ ip route sh
default via 192.168.64.1 dev wlan0 
169.254.0.0/16 dev tap0  scope link  metric 1000 
172.28.119.2 dev tap0  proto kernel  scope link  src 172.28.119.1 
192.168.10.6 dev tap4  proto kernel  scope link  src 192.168.10.5 
192.168.64.0/24 dev wlan0  proto kernel  scope link  src 192.168.64.184 
wouter@carillon:~$ sudo ip route add 192.168.14.0/24 via 192.168.10.6
wouter@carillon:~$ ip route sh
default via 192.168.64.1 dev wlan0 
169.254.0.0/16 dev tap0  scope link  metric 1000 
172.28.119.2 dev tap0  proto kernel  scope link  src 172.28.119.1 
192.168.10.6 dev tap4  proto kernel  scope link  src 192.168.10.5 
192.168.14.0/24 via 192.168.10.6 dev tap4 
192.168.64.0/24 dev wlan0  proto kernel  scope link  src 192.168.64.184 

As you can see, each and every one of those entries contains a "dev"
line saying which interface the route relates to, even when you add a
route without specifying an interface.

Since you said "complex setup", however, I might miss something. Did you
have something specific in mind?

> Or to tell which low-level interface another interface depends on
> (think tunnels managed by userland tools).

That indeed is slightly more complex. However, provided you know what
the endpoint of the tunnel is, it's not impossible to figure out:

wouter@carillon:~$ ip route get 192.168.14.1
192.168.14.1 via 192.168.10.6 dev tap4  src 192.168.10.5 
    cache 

> Actually if there was at least a *standard*, low-level (or in-kernel)
> tool to return structured information about the current network
> configuration,

It's called "netlink", as Ben already pointed out as well.

> maybe high-level network tools (such as ifupdown and NM) could be
> redesigned in a completely different, much more compatible, way.

Really, there's nothing stopping that from happening right now. NM does
use netlink; ifupdown does not. Unfortunately that means ifupdown would
need to be pretty much rewritten; in addition to rewriting the backend
so that it uses netlink, its concepts are way too far away from the
dynamicity that would be required to do the kind of stuff I'm
describing.

Such a rewrite is pretty much what I've started to do with ipcfg, fwiw.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a