Subject: Re: delay needed after started named?
To: Martin Husemann <martin@duskware.de>
From: Steven M. Bellovin <smb@research.att.com>
List: netbsd-users
Date: 05/04/2004 18:31:06
In message <20040504214930.GB16973@drowsy.duskware.de>, Martin Husemann writes:
>On Tue, May 04, 2004 at 01:16:09PM -0700, Wolfgang S. Rupprecht wrote:
>> Before my portable walked out my back door I used dhcpd as a
>> on-network detector. If the main interface didn't look like it had a
>> valid address I bypassed the startup for all sorts of daemons.
>
>I would realy like some easy mechanism to have dhcpclient results select
>a file with rc.conf settings that override parts of /etc/rc.conf. Even
>to the extend that if I get a dhcp lease for a know network where I don't
>use dhcp to set things like
>
>auto_ifconfig=NO
>net_interfaces="cs0"
>ifconfig_cs0="inet 192.168.XXX.XX netmask 255.255.255.0 mediaopt full-duplex"
>defaultroute=....
>dhcpclient=NO
>
>If this would be implemented as a regulary rc.d script, it would need a way
>to restart rcorder and the whole rc.d execution, this time passing the
>selected configuration as a parameter and avoiding a second dhcpclient
>run.
>
I very much agree. Let me think aloud for a bit...
What we want is a network centered view of things, or perhaps a network
interface-centered view. From that perspective, running certain
scripts shouldn't be done from rc; rather, they should be run as
interfaces go up or down. named and ntpd definitely fall in this
category; not only might the targets change because of firewalls and
the like, the latter at least binds itself to all available interface
addresses explicitly. Other things may change -- smart-host forwarding
for a mailer, for example -- or which daemons are running. There are
sufficiently many possibilities that having rc.fxp0.d or the like is
too cumbersome. That in turn suggests that we want a table-driven
mechanism, probably keyed by a value different than YES or NO in
rc.conf. Maybe it's a filename, where the file has triples of the form
interface-pattern address-pattern YES/NO
though we'd have to make sure that the pattern was recognizable without
/usr mounted. We might want an optional fourth field, for a script to
run after the /etc/rc.conf.d entry. (Aside: /etc/rc.conf.d/cmd is read for
each rc.d script; such a script could, I suppose, look at network
interfaces to decide what to do.)
It shouldn't be too hard to implement. ifwatchd could run all scripts
that say "# KEYWORD: interface" or some such. That would bring in all
forms of network interfaces, handle things appearing and disappearing,
etc. The newest version of dhclient is supposed to have working omapi
support (Ted, I haven't tried it yet); that should handle appearing and
disappearing interfaces..
As I said, I'm thinking aloud here. I'm quite prepared to be told that
my ideas won't work, or that there's a cleaner way to do it. But let's
think about what we want to do.
--Steve Bellovin, http://www.research.att.com/~smb