Network configuration future
Dan Williams
dcbw at redhat.com
Fri Sep 7 18:37:09 UTC 2012
On Wed, 2012-08-29 at 15:17 +0200, Denys Vlasenko wrote:
> 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...
Historically it didn't require daemons, but these days networking is a
lot more complex, and people often run multiple interfaces, and
something gets to mediate between multiple interfaces. I often argue
that the *old* system of a ton of shellscripts and many different
processes (dhcp, ppp, vpn, wpa_supplicant, ipsec, etc) all doing their
own thing and being loosely tied together via a bunch of
cobbled-together shellscripts is *more* complex, because:
1) error handling and reporting is very hard to get right in shell
2) there's about 10x more cracks for things to fall through and problems
to occur in a loosely tied together system like this
3) each tool has it's own configuration format and it's own
command/control format, and none of these are anything like the others
4) handling events from these tools often requires a daemon-type process
anyway
5) half or more of the effort goes into making all these tools work
together and talk reliably and to provide a consistent interface on top
of all of them, instead of actually making the networking system better
There's no reason *why* a system like NetworkManager should be as
complex as you think it is, and I'd argue that it's not. Certianly not
10x as complex as the old system. I'm not acutally sure what a "more
elegant" setup that you envision would be; any chance you can share some
thoughts?
Dan
>
> 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.
>
> From a maintenance perspective, extensibility and debugging are critical,
> too. While shell scripts are certainly not the latest in Software Engineering,
>
> *** shell scripts are time tested tools. Before you disparage them,
> collect at least ten years of successful usage under your tool's belt.
>
> it is certainly easy to extend an existing script (provided you understand
> what it's doing), and to insert debug output, etc.
>
> *** exactly. Do the same to XML? I don't think so.
>
>
> Beyond such aspects, there are a number of desirable properties.
>
> One, a modern network management framework should run as a service. The
> kernel offers a plethora of notifications via rtnetlink, and increasingly
> expects user space to react to these (for instance in the IPv6 area).
> Running a network management daemon allows us to track the state, detect
> changes, and react to them appropriately.
>
> Two, a modern network management framework should be layered - both in
> its implementation, and its configuration. One of the reasons why the
> existing ifcfg files are such a mess are the inherent limitations of
> shell scripts and shell variables dealing with complex types.
>
> BOOTPROTO='static'
> STARTMODE='auto'
> NAME='82566DM-2 Gigabit Network Connection'
> ETHTOOL_OPTIONS=''
> USERCONTROL='no'
> IPADDR='1.2.3.4/24'
> IPADDR_0='1.2.8.17/24'
>
> This mixes - in random order - address configuration, hardware configuration,
> behavior control, and UI information. And things will become worse the moment
> you start to support additional parameters for your network devices - because
> you will quickly end up with VERY_LONG_VARIABLE_NAMES_NOBODY_WILL_EVER_REMEMBER.
>
> *** You honestly think XML is more readable? If not, then this particular
> point about VERY_LONG_VARIABLE_NAMES_NOBODY_WILL_EVER_REMEMBER is invalid.
> But yes, the general point stands.
>
> And some things are just tough to do using shell variables (while still maintaining
> a certain level of sanity), so that auxiliary file formats had to be invented -
> viz the ifcfg-routes file in opensuse.
>
> Ideally, the configuration file format should structure options into logical
> units - having syntactic groups for lumps of data that belong together;
> being able to organize several instances of the same type of data (such
> as say a static route) into a list; etc.
>
> Layering is also crucial for the implementation, because it makes sure you
> support a uniform set of features across all types of devices. Today, setting
> up a firewall on a serial PPP device is very different from doing it on an Ethernet
> interface, and that again is very different from doing it on a UMTS PPP session
> started by NetworkManager.
>
> Three, a modern network management framework should support a way to identify
> network devices by means other than their name. That name is really secondary;
> and tools should not rely on it. Instead, the management framework should provide
> naming facilities that allow you to identify interfaces by a set of attributes -
> for instance, it should be possible to identify a UMTS stick by the IMEI of
> its GSM card. Or it should be possible to identify a hotplug Ethernet card
> by the PCI ID of its enclosure, which ensures that when you replace the card,
> the new one will receive the same configuration as the old one.
>
> Four, a modern network management framework should model interface dependencies.
> Consider a bridge sitting on top of a VLAN built on a pair of bonded NICs.
> Before bringing up any of these, the management framework should bring up the
> lower-layer device. This doesn't really happen with today's scripts.
>
> Five, a modern network management framework should provide triggers for all sorts
> of things. For instance, if you have an NFS mount, wouldn't it be nice if you
> could tell the management framework to notify you as soon as the server's host
> name can be resolved, and the address is known to be reachable?
>
>
> Why don't you use tool XYZ?
> ===========================
>
> We looked at all of the available tools, but we didn't come across anything
> that had similar goals to the ones above. Some went a long way, but they were
> either very much focused on a desktop-like use case with few devices (mostly
> Ethernet, WLAN and UMTS), or they were focused on the Enterprise end of the
> spectrum with little support for the needs of the single end user.
>
> So, I started to work on something I called wicked initially, which was a REST
> based service. If you haven't guess so far, I have a passion for really cheesy
> puns - REST for the wicked was something I couldn't pass up.
>
> The thing evolved quite a bit over time, moving from REST to a dbus
> based transport, among others - and it keeps evolving. Among other
> things, it'll probably change its name in the not too distant future,
> because people keep confusing wicked with WICD. I just need to come up
> with another cheesy pun.
>
>
> Basic architecture
> ==================
>
> The basic architecture of the whole service is rather simple. There's
> a daemon process, wickedd, passively monitoring all interfaces, without
> touching any of them unless told otherwise.
>
> It offers a view of these devices via DBus, with a number of DBus
> interfaces attached to each of them.
>
> Clients can talk to this service and request a specific operation on any
> such device.
>
> *** How do you set up network parameters? IOW: does wickedd
> reimplement such tools like ip, ethtool, iwconfig, dhcpc client,
> ppp?
>
> *** Can you show the ldd and size output on your wickedd binary?
>
>
> There is a command line client called wicked whose main purpose it is
> to act as a backend to ifup and ifdown. This client can configure any
> number of interfaces in parallel, and also takes care of dependencies
> between interfaces.
>
> There is another application called network-nanny, which tries to do what
> NetworkManager is currently doing, using the Wicked service. It is fairly
> tightly integrated with the other components of management framework,
> and shares a significant amount of code with the command line client.
>
>
>
>
>
> The same, but showing the layering at work:
>
> <interface>
> <name>eth0</name>
>
> <control>
> <mode>boot</mode>
> <link-detection>
> <timeout>60</timeout>
> <require-link />
> </link-detection>
> </control>
>
> <ethernet>
> <port-type>tp</port-type>
> <link-speed>1000</link-speed>
> <offload>
> <tso>disable</tso>
> </offload>
> </ethernet>
>
> <link>
> <mtu>8000</mtu>
> <txqlen>50</txqlen>
> </link>
>
> <firewall>
> <zone>secure</zone>
> </firewall>
>
> <ipv4:dhcp>
> <enabled>true</enabled>
> <acquire-timeout>15</acquire-timeout>
> </ipv4:dhcp>
> </interface>
>
> As you can see, options specific to the physical device are grouped in
> one XML element, generic link-layer options in another, and firewall
> settings in yet another element.
>
> *** Firewall configuration often has nothing to do with particular
> interface. It also can be arbitrarily complex. Dumbing it down
> to per-interface setting is extremely limiting.
More information about the devel
mailing list