Re: Adding openresolv to base

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

Michael van Elst wrote:
> roy%marples.name@localhost (Roy Marples) writes:
>
> > That leaves the DNS servers going into resolv.conf as the only other 
> > data obtained from the link configuration.
>
> Automated configuration does many things and you agree that
> this requires some custom script handling. Except for resolv.conf.
> This should be handled differently with your tool which adds
> complexity to what was previously just writing a file.
>
> You also require that any policy you want to apply to
> resolv.conf data has to be applied by your tool.
>
> For what reason? Because DNS configuration is the only thing
> shared between your different link configuration protocols?
> Except for default routes?

I agree that you need your custom scripts to handle your custom needs 
(such as restarting NAT, etc). I disagree that custom scripts should be 
a requirement to apply DNS in this day and age.

"Just writing a file" is all well and good when systems only had one 
interface. When you have more than one up at the same time, just writing 
a file doesn't cut it when some interfaces are up and some are down.

I am just proposing the addition of a tool to allow DNS configuration to 
be centralised so that state data is not lost by things overwriting this 
one file. It is not required to be used.

> As I have shown, the configuration is delivered by many
> 'configuration protocols' and something like resolv.conf
> can be created with standard tools. I don't see any
> reason to reinvent the wheel.

You have shown that PPP can supply DNS and you have custom m4 scripts to 
generate /etc/resolv.conf from this.

You have not demonstrated a standard tool to allow multiple interfaces 
to manage this. Instead you propose each user writes custom scripts to 
handle this. Maybe each user should be forced to write their own 
dhclient-script like for ppp? I think not.

I would propose these default ppp scripts

#!/bin/sh
#/etc/ppp/ip-up
sig="# Generated by ppp for $1\n"
ns1=`/sbin/pppoectl -n 1 "$1"`
ns2=`/sbin/pppoectl -n 2 "$1"`
ns1="${ns1:+nameserver }${ns1}${$ns1:+\n}"
ns2="${ns2:+nameserver }${ns2}${$ns2:+\n}"
if [ -n "${ns1}" -o -n "${ns2}" ]; then
        printf "${sig}${ns1}${ns2}" | /sbin/resolvconf -a "$1"
fi

#!/bin/sh
#/etc/ppp/ip-down
/sbin/resolvconf -d "$1"

The above allows us to create a simple GUI for configuring PPPoE with 
these boxes

interface: re0
auth: chap
username: joebloggs%someisp.net@localhost
password: sekrit
router: yes

Admittedly that does require dhcpcd-5 to handle the adding the route part.

> Except for one thing.
>
> All solutions seem to require to distinguish between the
> working configuration and some original data or template
> that is expanded or augmented by the link configuration
> data (and maybe other).
>
> That's where you can think about where and how to
> store templates, how to provide a unique mechanism
> for 'expanding and augmenting'. Something that applies
> to all configuration files. Something like newbtconf()
> but much smarter and not only for bootstrap :)
>
> And unlike other kinds of meta-configuration (ODM, /etc/sysconfig ?)
> you don't have to use it. Providing the framework for
> those who do is enough.

Maybe it's me, but I'm really missing the bit where your telling me what 
this other information obtained from the link is.

Thanks

Roy