Re: Adding openresolv to base

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

Michael van Elst wrote:
>> If we eliminate the task of the user having to script the writing of
>> resolv.conf AND supply configurable knobs to ensure a valid resolv.conf
>> persists when interface X goes up and down
> 
> Then we will still have the user writing scripts to do all the other
> tasks.

Yes, but there are tasks that cannot in any way or form be automated by
information from PPP. Whereas the automation of DNS can be.

>> It was meant to show that you don't need to learn $language to do a get
>> a PPP link up with persistent DNS across multpile links provided that
>> reasonable default scripts are supplied.
> 
> The 'reasonable default scripts' can do the same without another tool.

I disagree as you've already stated there are no default PPP scripts and
you've yet to demonstrate any tool that handles a sane resolv.conf when
multiple interfaces go up and down.

> 
>> Lets take your PPP example still.
>> Network parameters - IP address added to the interface, check
> 
> that's obvious.
> 
>> routes - dhcpcd-5 can handle adding default routes to PtP destinations,
>> check
> 
> It probably can't unless you have one interface and one route. Same
> as ISC dhclient without custom scripting.

Actually it can - it's setup like this

interface pppoe0
destination routers domain_name_servers

This instructs dhcpcd to assign a default route via the destination
address on pppoe0. It also enters the destination address as a
domain_name_server for the scripts to configure. It works because dhcpcd
listens to kernel messages when addresses and routes are
added/deleted/changed and can react accordingly.

Then it's handled in the same way that multiple interfaces are handles
with default routes - lowest metric wins. Of course the metric is itself
configurable and gives an easy way of saying "I want to prefer wired
over wireless over PPP" regardless of which link actually comes up
first. It's also trivial to add an option to say "link up first whens -
when that goes down lowest metric next".

>> DNS servers - added to resolvconf, check.
> 
>> Web proxy and mail gateway settings - where are these obtained from the
>> PPP link?
> 
> DHCP can deliver service information. I'm not aware of a PPP option
> that does.

And this is entirely my point :)
dhcpcd CAN handle it all WHEN there is a DHCP server at the other end.
dhcpcd-5 CAN be configured to support this

interface pppoe0
inform

There - nice and simple. But not many PPP servers also support DHCP
INFORM. In this case the only extra information is DNS servers.
Hence resolvconf - it handles the missing gap that no DHCP client or
equivalent can fill when a link configuration tool (PPP, VPN, etc) only
supplies DNS.

>> The reason why my tools don't care about your web proxy and mail gateway
>> is this - they are not part of the auto-configuration of the interface
>> from the supplied data.
> 
> see RFC 2132 for details what can be supplied as part of the
> auto-configuration of 'the interface'. Very few people use it
> that way, because there isn't one accepted standard, one reason
> why you have to be flexible.

dhcpcd is flexible.
It mirrors the dhclient variables fully for RFC2132 and other RFCs also.
It has a mini version of resolvconf (for libc resolver only) and has a
similar setup for handling setups for ntpd, openntp and yp (linux only).
There are done via hook scripts for each configuration file so it's very
extensible.

> The latest attempt at a standard way for this is zeroconf.

dhcpcd is also a zeroconf client, supplying the IPv4LL part. It's fully
RFC conformant and passes Apples Bonjour conformance testing suite for
the IPv4LL tests. Infact it's used on equipment branded as such :)

avahi, which supplies the rest of the zeroconf stack supports
resolvconf. Why does it support resolvconf? Because it is a defined way
of injecting your DNS information that's more friendly than just
stamping on a file many processes contend for.

Now, taking dhollands idea of a resolv.conf directory that libc can use
- well resolvconf is STILL the solution here because applications that
call it don't need to know about the include directory only NetBSD
supports. They just add it to resolvconf.

Thanks

Roy