Network configuration future

[Denys Vlasenko]

On 08/29/2012 01:58 PM, Olaf Kirch wrote:
> Your feedback is very much welcome!
> 
> Regards,
> Olaf

		Why Did You Do This?!

Do we really need yet another network management thing?
=======================================================

No, not really. We already have the good old ifup/ifdown scripts, which
are doing their job nicely.

*** No they don't.


If you don't strain them too much or try to
teach them new tricks (like integrating with systemd). Of all the
tunables and knobs the kernel supports for each network interface, we're
covering maybe 10%, but what was good enough for grandpa should be
good enough for me as well, right?

We've got udev messing around with network interface names, because
users don't like it when what's called eth0 today is called eth15
on the next boot. Which works nicely except when it fails, for one
or the other weird reason.

We've got Network Manager, which is also doing it's job nicely and won't
give you any headaches if you prevent it from stepping on anybody else's
toes. Or try to make it manage a thousand devices, like on System z.

*** Network Manager is just another daemon created for a task
which historically often did not need any daemons. It's almost as if
the new generation of Unix hackers wants to redo everything -
in x10 or x100 times bloated and more complex way than it was done
before. Yes, guys, old stuff has problems and limitations. But
switching into high gear and writing a ton of stuff is not a solution
I like. Can you *think it through* and fix/improve stuff WITHOUT
increasing its complexity tenfold as a minimum? Yes, I do realize
that elegant solution is harder to do than coding spree solution,
but I still hope...


Then we've got libvirt and netcf, which do kind of an okay job if you
manage to frob netcf enough that it deals with configuration files other
than RedHat's, and as long as your network configuration doesn't get too
complicated. Which happens quickly in a virtualization environment.

Beyond these, there are things like openvswitch, which is crucial in
a cloud environment but not at all integrated with any of the other
components.

So no, we don't really need yet another network management thingy.

We need a management thingy that replaces a lot of this stuff.



Yeah, but it kind of works, why should we mess with it
======================================================

Quick, using any of the existing frameworks, can you tell me how to...

 - ... disable IPv6 on a specific interface?
 - ... set up an interface for DHCPv4 and DHCPv6?
 - ... change the link speed on an Ethernet interface?
 - ... reconfigure a bonding device without bringing it down?
 - ... set up a bridge using two bonded NICs as one of its ports?
 - ... the same as above, with VLAN tagging?
 - ... change the firewall rules on your UMTS modem?
 - ... set up 802.1x authentication for your Ethernet NIC?
 - ... set up persistent names for your System z devices?

If you could answer all of them at the snap of a finger, please send me your CV.

*** I would rather send you a few URLs:

http://busybox.net/~vda/no_ifup.txt
http://git.busybox.net/busybox/tree/examples/var_service/README



So, what properties should a new network management framework have?
===================================================================

Obviously, there are a number of aspects of the existing systems that
make them useful to people; retaining these is worthwhile.

For instance, having a command line interface is crucial to many
people. You need to be able to change your network settings from an ssh
session; and you want to be able to script network management tasks, too.

Similarly, people like NetworkManager because it allows them to set up
network interfaces in response to various events, and it does so more
or less automatically, and without the user having to be root.