tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Adding openresolv to base

Michael van Elst wrote: (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

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"

/sbin/resolvconf -d "$1"

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

interface: re0
auth: chap
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.



Home | Main Index | Thread Index | Old Index