No subject

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.