On 03/09/2010 10:16:37 AM, David Sommerseth wrote:
> > Over-automating things will cause people headaches.
> > You don't want to willy-nilly startup a dhcp client
> > and have all your interfaces configured with dhcp without
> > your consent.
>
> Exactly! Which again moves it more in the direction of some built-in
> DHCP client in OpenVPN, but as stated earlier - that mostly solves
> the
> core DHCP issues - but not the resolv.conf issue.
I'm not at all sure it solves the core issues, which is that
an already running dhcp client won't have auto-detected
the tap interface that OpenVPN creates -- iff OpenVPN is
started after the dhcp client.
This is the
core issue, right? Otherwise it would just work so long
as dhcp is turned on. I think we need to decide where
the problem really is before we decide how to fix it.
If you build a dhcp client into openvpn you push the problem in
the other direction. Now you've, potentially, got
multiple dhcp clients running and you need to do
something to keep them from interfering with each other.
You can't rely on processes being started and stopped
in boot-time order because the sysadmin might start
and stop services as needed to maintain the system
and you don't want surprising things to happen.
(The principle of least surprise is a good one.)
You may as well just statically configure your existing
dhcp client so that it knows to go looking for the
tap device.
I think the only way to go is to integrate with
anything that the local admin may decide to use
for dhcp/resolv.conf/etc.
Karl <k...@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
