> -----Original Message----- > From: mouss [mailto:[EMAIL PROTECTED] > Sent: Sunday, August 31, 2008 7:23 PM > Cc: users@spamassassin.apache.org > Subject: Re: Handy script for generating /etc/resolv.conf > > Giampaolo Tomassoni wrote: > >> -----Original Message----- > >> From: Nix [mailto:[EMAIL PROTECTED] > >> Sent: Sunday, August 31, 2008 5:12 PM > >> To: Marc Perkel > >> Cc: users@spamassassin.apache.org > >> Subject: Re: Handy script for generating /etc/resolv.conf > >> > >> On 28 Aug 2008, Marc Perkel told this: > >> > >>> Here's something I threw together to make sure the /etc/resolv.conf > >>> points to a working nameserver. I run this once a minute. > >> How do you arrange that all the existing programs that have already > >> sucked in resolv.conf note the change? They're generally not going > to > >> unless you restart them: nothing polls resolv.conf looking for > changes > >> to it as far as I know, that would be far too inefficient. > > > > Depending on the specific implementation of the resolver library, the > > application may check for changes in the resolv.conf file. Maybe they > don't > > check at every and each resolv request, however: they may instead > check for > > changes every, say, 10 secs or maybe every 1.000 requests. This way, > looking > > for changes in the /etc/resolv.conf file is not that much > inefficient... > > > > as you say, this is generally inefficient.
No, I'm saying the exact opposite: I'm saying that the brute implementation may be inefficient. I'm also saying that, due to this, many implementations don't adopt a brute approach to the problem. Finally, restarting a whole set of apps just because the /etc/resolv.conf file changed actually *IS* inefficient. > most resolver > implementations > don't do that. No, come on: most do. At least by when Internet started to be a mass-market: most connections where dialup ones with dynamic IPs, and NAT routers were expensive. You didn't have to restart all your running apps once connected just because the /etc/resolv.conf was modified by pppd implementation... > and even then, not all applications will obey that (the > mozilla family is known to play bad games here). I don't know about mozilla, but please note that special apps may borrow their own special implementation of the resolv library. While perhaps Mozilla is one of them, I don't believe its own resolv library doesn't pay care to changes in the /etc/resolv.conf content. Is mozilla involved in this, anyway? > It is better to run a dns server on the machine and do all your stuff > there. you can restart it, reload the zone, ... without caring for > resolver or application specific behaviour. This also "conforms" to > modularity as was seen in plan9: let servers do the job. Right, I agree with you in this. This is a much more flexible and polite solution, but it is not easy to implement by everybody: you need to know what is a "zone" and a "reverse zone", how to configure it, some basic knowledge of DNS server setup and, finally, even what is a DNS server... :) Please note a lot of Linux distributions do provide some mean to dynamically update the /etc/resolv.conf file. They don't impose the use of a local DNS server. And the reason to me is to avoid burdening the user with (unneeded) complexity. > and by the way, the proposed script is not portable nor robust: > - it requires /bin/bash > - it requires that netcat is installed as /usr/bin/nc > > It does no sanity check before overriting /etc/resolv.conf. not even > check that it can run /usr/bin/nc. not even check that resolv.tmp is > "coherent" (race condition). It can be tuned and maybe somebody will find it useful. But, again, I don't see why a Linux host run by a single user with no enterprise networks around would need to run a local DNS server. Yes, it is more flexible. It may even be attractive for someone, I don't mean it doesn't. But why that single user would have to call its wizard friend to have its list of NS resolving servers up-to-date for its tiny mailbox of maybe 50 incoming mails/day? It is like shooting to birds with a cannon, don't you agree? Giampaolo > > Giampaolo > > > >>> It checks to > >>> see what name servers are up and creates /etc/resolv.conf. As you > all > >>> know SA and mail servers need the first nameserver to always be > >>> working. > >> But these are both root-owned daemons and you're not restarting any > >> of them. > > there are many long running programs such as X, firefox, thunderbird, > ... that will not "re-initialize" the resolver, unless you have a > resolver that forces reinit at each query or that watches resolv.conf > change, but as said above, this is inefficient. I don't want my system > to stat /etc/resolv.conf every minute, do you?
