Re: resolvconf, modularity, componentization, ifupdown2 backend, libwpasupplicant.so, extensible software

[Karl Hegbloom <hegbloom pdx edu>]

> Q: What if ifupdown had explicit support for working co-operatively with
> NM, or was rolled into it's own backend style with appropriate
> extensions and modifications?  It really is a very powerful system, and
> such a nice program design.  I like the way he wrote a little language
> for the various network setup methods.  It's really worth a week's
> study.  I will certainly be revisiting it as I study languages and
> compilers in the future.  Extensible software is where it's at.

I just had a few more ideas on this...  I can't quite see the whole
picture yet.  Maybe some of you could fit a few pieces into place for
me.

What if the 'iproute' ("ip") command and others such as the bridge
control tools, etc. are separated into shared object libraries so that
other software can use them more directly?

The advantage of 'ifupdown' is it's extensibility and configure-ability.
It supports both "canned" methods for interface configuration, such as
DHCP or static IP, as well as a "manual" method, pre and post commands,
and the ability to add arbitrary configuration directives that become
environment variables to the hook scripts.  

It can be given new and potentially dynamic behaviors via mappings and
the hook scripts it runs.  For instance, a hook is run that has
'fetchmail' do it's thing when the network comes on line.  Another could
deal with DynDNS, and one could modify iptables depending on what
network you happen to click into.  (We're not all experts and we're not
all beginners.)  This all seems confusing and certainly an end-user
interface may need to restrict the choices somewhat (and should respect
custom changes made by a systems administrator).

One of the problems I've experienced with the 'ifupdown' system was the
iptables and route management problems that can happen when you have
multiple interfaces and interactions between them where you don't know
what order the interfaces will come up or go down and more than one
interface (lan, vpn, ip6 tunnel, tun/tap) is expected to be up at any
given time.

It can be complicated and confusing.  As far as I understand it, NM is
to be an over-seer and co-ordinator, and not necessarily as the thing
that performs the lower level network interface configuration, IP
routing table, and netfilter configuration (and co-ordination?) tasks.

For example, I was hired by a client to set up his Internet gateway
computer so that it was connected to the Internet by both a DSL modem
and a cable modem at the same time.  The DSL had narrower bandwidth but
a static IP, and the cable modem had a faster link and dynamic IP.  So
the thing was to route downloads and so forth over the cable modem,
while incoming connections always get routed back out over the DSL.  The
difficulty was that some services are inside, with DNAT bringing them
into the LAN DMZ.  By default, a connection would come in, and the reply
would get routed over the wrong link and be lost.

It was not easy to figure out, and didn't really work the way I thought
it should.  I had to be careful about making sure the routes worked
right no matter what order the interfaces are brought up and down in so
that everything keeps working properly with no special rules about what
interface has to be brought up first and so forth.  Of course on a
typical desktop or laptop, it won't ever get that complicated right?  

It seems to me that when you add VPN to the picture, it can get this
difficult, but the user should never have to monkey with it.  So maybe
there needs to be a routing (and iptables) manager of some kind?  It
would probably not need to be a daemon; perhaps 'ip' already is it.  Is
that NM's job?  Where does this belong, as a component or sub-system?

-- 
Karl Hegbloom <hegbloom pdx edu>