
I was really happy a few years back, when
Martin announced he'd start working
on
netconf. Not just
because I agreed with his assessment that ifupdown needed replacement;
also because I had been thinking about a good way to implement such a
thing, and had been planning to start writing 'soon'. With Martin's
announcement, I made a few suggestions to give him some input, and then
put my plans away I had more important things to take care of,
anyway.
Unfortunately, netconf did not manage to reach the ambitious goals
that Martin set out, mainly due to lack of contributors. I wanted to
help out; I really did. But Martin's choice of python to implement a
'prototype' which then had to be reimplemented in C or C++ didn't get me
very thrilled. Not just because I have a severe dislike of python; also
because implementing something twice is, in my humble opinion, not quite
the best way to do something like this.
But hey, who am I, if I don't put my code out there.
Never the less, I tried helping. I really did. During debconf8 at Mar
del Plata, I approached Martin with the suggestion that I start
reimplementing those bits that were unlikely to change anymore in C, as
a first step toward something that could be in the base system.
Unfortunately, that didn't happen. After trying for about two weeks, I
just gave up. I
thought I could read python code and
reimplement that so that it would work the same way, but I couldn't. I
thought I could implement python modules in C without knowing
python, but as it turns out that's a laughable idea.
For several months then, I didn't think about it anymore. In March of
this year, however, I got a little bored. And what does one do when they
get bored? Right, you find something to do. I my case, that was 'figure
out how bison works'. I'd of course known about parser generators for
quite a while, but just never had the time to dive in deep and figure
out how they work. When I needed to do a config file for
nbd, I instead hand-wrote my
parser and used a lexer from libglib. But I wanted to learn how to do
things properly, so I sat down.
Long story short, when I had to choose something somewhat more
complex to implement, I thought 'how about a hypothetical config file
for a network configuration utility', and I started implementing that.
It turned out to be fun, so I didn't stop after I knew enough about
bison. And just last week, for the first time I successfully used it to
bring up my wired interface using DHCP -- and bring it down again. It
can also already manage static interfaces through netlink, though it
isn't quite able to the equivalent of 'ip addr flush' yet.
Fun.
The system is quite flexible. It has a plugin interface (which
needed some refinement that I did using some help on IRC just today),
which should allow developers to implement extra functionality by just
dropping a shared object in the right directory. In fact, I'm working on
the wireless support (hence my
blog post of last
week) as a plugin.
Obviously the code isn't remotely ready yet. The wireless code has a
long way to go. The firewall module needs to be started. It will
probably crash and burn if put to the test. But even so, it already has
one feature that ifupdown, in its 10 years of existence, never acquired:
it will
not try to DHCP off an interface if it finds out that
there is no cable connected to it unless you wrote a configuration
that asks you to do so.
I wanted things to be as simple as possible, and therefore the
minimal valid configuration file that will do something useful is the
following:
That's right, it's empty. This will cause the system to bring up the
'lo' interface at bootup, and do nothing else. If you say 'ifup eth0',
where eth0 is a valid and existing interface, it will first check
whether there is a link, and if so, DHCP off of it.
There's much to do still, but I have now reached a point where I feel
the system is ready to meet all challenges it should be able to meet (or
so I hope), and where it might be nice if interested people check it
out.
The code is in a git repository that's mirrored on
git.debian.org,
github.com, and my own
git.grep.be. The latter
is my --mirror repository, but is not available for cloning to anyone
else. If you're interested in checking it out, you may want to start
with doc/tech.txt, and/or examples/ipcfg.cfg. I updated the former just
yesterday, so it's quite up-to-date. On the other hand, while the latter
shows the direction I would like the system to take, the code is a far
cry from implementing everything shown there, and it has been a while
since I last checked that file out, so the comments in there are, in
some cases, somewhat outdated. But that's good, because I want to keep
the file as a reference of the goals that I originally had, before I'd
written this whole corpus of code, so that I can go back at some
undefined point in the future and fix things.
Comments are (more than) welcome.