Re: Adding openresolv to base

[Roy Marples <roy%marples.name@localhost>]

Michael van Elst wrote:
> On Wed, Mar 25, 2009 at 11:25:14AM +0000, Roy Marples wrote:
> > Michael van Elst wrote:
> > > Then I maybe should repeat what was stripped:
> > >
> > > For a qualified decision on how to handle multiple, possibly
> > > conflicting, configurations, you can (and have to) supply some
> > > intelligence in form of a shell script. And since this
> > > mechanism isn't limited to resolv.conf entries, it can be
> > > used to handle other configuration options.
> > Do you know of any link auto-configuration mechanisms other than DHCP  
> > that provide information beyond what goes into resolv.conf?
>
> Most other protocols provide network information, like routes
> or mobile-ip addresses or information about protocols other than IPv4.
>
> Most such mechanisms allow additional scripting to configure
> things beyond the protocol, e.g. web proxies, smtp gateways,
> NTP servers...  Don't forget that your packet filters may require
> reconfiguration too. All this is part of the auto-configuration.
>
> N.B. currently I generate such configuration files from m4 templates,
> e.g (from my current (*) 'pppd' link auto-configuraton mechanism):
>
> #!/bin/sh
> #IFNAME TTY SPEED ADDRESS DESTINATION
> /sbin/route add default $5
> echo "define(UPLINKIP,\`"$4"')dnl" >/etc/ipuplink.m4
> ns1=`pppoectl -n 1 "$1"`
> ns2=`pppoectl -n 2 "$1"`
> if test -r /etc/resolv.m4; then
>         m4 -DNS1="$ns1" -DNS2="$ns2" /etc/resolv.m4 >/etc/resolv.conf
> fi
> touch /etc/*.m4
> /etc/rc.d/ipfilter reload
> /etc/rc.d/ipnat reload
> /etc/rc.d/ipsec reload
> /etc/rc.d/altqd reload
> ( sleep 30; /etc/rc.d/vtund onerestart; /etc/rc.d/ntpd restart; /etc/rc.d/named 
> restart ) &
> /sbin/ifconfig gif0 up
> /sbin/ifconfig gif1 up
> /usr/sbin/ipfstat -aoi | /usr/bin/logger -t "IP-UP ACCOUNTING"
>
> (*) I'm cheating, the machine currently has only fixed IPSEC configuration.

Assume for the time being that you're running a daemon that handles the 
automation of default routes to PtP destinations for you.

That leaves the DNS servers going into resolv.conf as the only other 
data obtained from the link configuration. Everything else is a user 
defined action based on the link going up and cannot by definition be 
automated, except by the user in a script such as this. I don't propose 
changing that, and I'm pretty sure you're not either.

> Lets say, I'd have another mechanism (like a VPN over a separate link)
> that wants to change the configuration. I can surely use openresolv
> to manage /etc/resolv.conf, but this would only be a small part
> of the configuration and I would still need some intelligence
> (aka scripting) to decide which entries should be used. Maybe
> I want the nameservers on the other side of the VPN if it is used
> exclusively but don't want to lose the internet nameservers when
> the main link is up? What about a road-warrior configuration
> where I rely on my 'home nameserver' to resolv everything, including
> the VPN names but require the 'VPN nameservers' when I'm somewhere
> else?

openresolv can mark interface resolv.conf for privacy and process them 
in a customisable order. The default simplistic processing order is 
loopback, VPN, PPP, everything else. So you can say "I want VPN, home 
then PPP nameservers" or chop and change it how you will. nameservers 
are not "lost" as openresolv keeps a record of each interfaces 
resolv.conf and uses this to generate /etc/resolv.conf

privacy requires a local resolver like named or dnsmasq, and can 
configure it so that the name servers are ONLY used to resolve domains 
matching the domain search list. Very useful for VPNs.

Using these features, you should be able to configure resolvconf 
accordingly to meet your above requirements.

Thanks

Roy