On Wed, 2012-08-29 at 16:48 +0100, Steven Whitehouse wrote:
Hi,
I wonder if one way to deal with the network configuration issue is to
try and help different configuration systems work with each other,
rather than to try and create one system which does everything. Last
time I looked into this there were various things which could be done to
allow peaceful coexistence of various configuration tools, but which
were missing.
Obviously we can add a couple of abstraction layers to avoid making hard
choices and continue to funnel effort into multiple competing projects.
That provides choice, but also increases complexity and the number of
gaps that things fall through and that problems are caused by.
One of these is related to routing. Routes can be tagged with an
originator protocol (/etc/iproute2/rt_protos) with the default being
"kernel" for routes which are generated automatically, say on interface
being brought up. This means that utilities which do some form of
dynamic routing (and I include NetworkManager, dhcp clients, etc in
this) should only remove or change routes which are either marked
"kernel" or which are marked with their own protocol id. I brought this
issue up some time ago (I did look for a reference but didn't find one
immediately), but without seeing much enthusiasm for resolving it.
I think mainly becuase it's orthogonal to the problem. NM already
doesn't touch routes on interfaces it doesn't manage
The real problem is the *default* route, and that's a shared resource.
Tagging doesn't help here because only one thing (whatever that is)
really should be handling the default route, precisely because it's a
shared resource.
It wouldn't be nice to create a higher priority default route than the
one created by tool A, just like it wouldn't be nice for tool A to
create a higher priority default route than that created by tool B. How
do you mediate between them? We attempted to make NetworkManager that
thing, but obviously that's incomplete since it doesn't have knowledge
of all the interface on the system in some cases.
But the thing that handles the default route and DNS priority *does*
need to have a pretty good knowledge of all interfaces on the system,
and their relative priority.
Dan
My point is not so much that this particular issue should be fixed
(and
maybe it has been since it is a while since I last checked) but that by
careful use of the available functions (and maybe with the odd extension
here and there) it should be possible to allow many different tools to
cooperate with each other. I'm just using the route issue as an example.
Obviously there needs to be some coordination when it comes to dealing
with an interface coming up and which particular tool will deal with the
set up, but there is still scope for allowing multiple tools to
cooperate too. That way we can have specialist tools to deal with the
less common situations without needing to clutter up those tools dealing
with the more common case with more advanced features.
So my take on the problem is to consider how it would be possible to
have different tools cooperating in the same space, and then maybe to
extract the common functions which allow this into a small library which
could then be used by each tool.
I'm not sure if this is useful in the context of the original post, but
it is what it brought to mind while I was reading it,
Steve.