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

[Karl Hegbloom <hegbloom pdx edu>]

On Sun, 2005-10-09 at 14:08 -0400, Christopher Aillon wrote:
> Have we looked at using dnscache[1] for our caching nameserver?  It 
> seems more lightweight than using bind (without its track record even!) 
> and seems like exactly what we would want.  I haven't looked too much in 
> detail at it (or bind for that matter), but I think its worth 
> considering.  I wonder if we would get more widespread adoption for it.
> 
> [1] http://cr.yp.to/djbdns/

IIRC, there is some sort of funny licensing issue with that.  Debian
does not ship binaries, but instead a source package that creates
binaries you can install.

What about 'dnsmasq' or 'pdnsd', perhaps in combination with
'resolvconf'?  Was 'resovconf' thoroughly reviewed, or rejected with
prejudice an not even a cursory code view?

I really think it's a mistake not to go with 'resolvconf'.  I believe
the issue had to do with wanting to make it possible for the vpn support
to say that lookups within the vpn should only be asked to certain name
servers.  It would probably not be difficult to make resolvconf able to
do that, since each time you send information to it, you also specify
the interface that information is to be associated with.  There is an
"interface-order" file that lists the order in which interfaces DNS
information is to be used, so the VPN (perhaps on a tun* interface) can
take precedence, perhaps.  The lookup can go there first, be turned down
for non-VPN names, and go next to the eth* DNS in the normal recursive
DNS lookup fashion.  That happens once when the dns cache is empty.  

Oh, I see.  That takes only slightly longer, in the human time-frame, as
having the name server decide where to ask the lookup, unless the VPN
nameserver is down and we have to wait for the full time-out period.  At
that point, the lookup would cross untrusted networks attempting to
locate the name in global DNS.  So here, for some high-security
applications, you want the name server to make that decision
intelligently.  (IIRC, dnsmasq may have support for this; it's probably
not difficult to implement.)

It's the scripts in /etc/resolvconf/update.d etc that determine what is
done with that information.  The thing is that the nameserver installs a
script there that uses that information to build it's forwarders list,
and the actual resolv.conf file then contains only 127.0.0.1.  It
already does this now.  If the script for the particular name server or
DNS cache can write the right configuration for a name server that has
the capability for it, then all's well.  It's really not as complicated
and lawless as you might think, since to write a script for that, one
must review what the scripts that other packages install do.  Simply
find all packages depending on 'resolvconf', get the source, and read
them.  It's not difficult to play well with others in that fashion.

In my opinion, the more modular "unix style" componentization that
resolvconf provides is better than having NetworkManager do all the work
in it's own selfish way.  Why re-invent the wheel?  I can see using
other software on my laptop that also needs to update the resolv.conf
file.  PPPD, is one, dnsmasq is another (I use it's DHCP server on
occasion, for user-mode-linux and network booted Debian installer, and
love the way it uses /etc/hosts in such a simple way plus has dynamic
DNS for DHCP clients).

% apt-cache rdepends resolvconf
resolvconf
Reverse Depends:
  whereami
  vpnc
  udhcpc
  sendmail-base
  pump
  pdnsd
  netscript-2.4
  laptop-net
  gnome-ppp
  dnsmasq
  dnsmasq
  avahi-dnsconfd
  squid
  postfix
  fetchmail
  dhcp3-client


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.

Q: What if 'wpasupplicant' became a .so library that it's daemon uses
and that NM can also incorporate, perhaps as a dynamically loadable
plug-in?

NIH?  Don't accuse me of it!  Yes, there are only 24 hours in a day.

-- 
Karl Hegbloom <hegbloom pdx edu>