On Wed, Dec 31, 2003 at 04:33:25PM -0500, Andrew Brown wrote:
> >> > How about stat'ing /etc/resolv.conf, opening the kqueue on it *and* /etc
> >> > always and checking the stat values on every kqueue event? 
> >> >
> >> > Seems like that way all failure modes discussed so far could be easily
> >> > detected.
> >> 
> >> resolv.conf is symlinked to /etc/sites/foo/resolv.conf
> >> 
> >> someone does an mv /etc/sites/foo/resolv.conf to
> >> /etc/sites/foo/resolv.conf.new and then creates a new
> >> /etc/sites/foo/resolv.conf
> >> 
> >> I don't think that would be detected.
> >
> >It would with kqueue, because it will monitor /etc/sites/foo/resolv.conf (open
> >follows the symlink) and a rename is a one of the events monitored.
> 
> fine, then i'll do this:
> 
> 	# mv /etc/sites/foo /etc/sites/bar
> 	# mv /etc/sites/baz /etc/sites/foo
> 
> or...this:
> 
> 	# mount -t null /etc/sites/bar /etc/sites/foo
> 
> kqueue can't catch that...can it?

No, it won't.

> 
> i think that for whatever you can decide to watch, i can invent a
> scheme that will "accidentally" bypass it.  we either need to decide

Yes

> what the basic requirements are, or decide that doing:
> 
> 	fd = open("/etc/resolv.conf", O_RDONLY);
> 	fstat(fd, &st);
> 	<compare new st_dev/st_ino/st_size/st_mtime/st_ctime with
> 	recorded st_dev/st_ino/st_size/st_mtime/st_ctime>
> 
> or something like that.  and then smack a sticker on it saying that we
> done our best.

Once we've done the open, we can as well reread the file, I suspect
it'll be as fast as doing the fstat().
stat() may be faster, tough.
The question is about the cost. The kqueue way of doing this is fast.
stat() requires a NAMEI lookup for each DNS call. We need to decide if this
is acceptable or not.

I suspect the cost of stat() is really small compared to the RTT to the name
server.

> 
> personally, i *like* that i can stuff something into /etc/resolv.conf,
> start one thing, and then restuff /etc/resolv.conf for everything
> else.  if the resolver would look at environment variables as well as
> /etc/resolv.conf (for a path or nameservers or something), then that'd
> be good too, but that's not on the menu.  we don't even consider
> cooking that here.

I though about adding a environement variable for this as well, to allow
a user to use its own resolv.conf (I'd like to be able to have a different
search than the site-wide one). But it may be better to have env variables
to override parts of resolv.conf. This needs more thoughs.
> 
> -- 
> |-----< "CODE WARRIOR" >-----|
> codewarrior@daemon.org             * "ah!  i see you have the internet
> twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
> werdna@squooshy.com       * "information is power -- share the wealth."
-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 24 ans d'experience feront toujours la difference
--