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