Re: Handy script for generating /etc/resolv.conf
Really though I don't think named in a caching configuration is too bad of a pig on ram, and there are high performance/low ram alternatives that just do caching. I'm using pdnsd here, wich also has the capability to periodically check the DNS servers it forwards to and mark them as up/down depending on the result (so if a server is marked as down due to a query timeout, after a configuarble interval it's recheked and marked up if it responds). In many cases I think this might be a better solution (than dynamically updating resolv.conf) to the problem of multiple occasionally unreliable name servers. My guess is that there are leaner DNS proxies using less resources than pdnsd, with less flexibility, as well that can do this. (Maybe dnsmasq can, I don't know...) Regards /Jonas -- Jonas Eckerman, FSDB Fruktträdet http://whatever.frukt.org/ http://www.fsdb.org/ http://www.frukt.org/
Re: Handy script for generating /etc/resolv.conf
Aaron Wolfe wrote: On Sun, Aug 31, 2008 at 10:59 PM, RobertH [EMAIL PROTECTED] wrote: It was explained somewhere earlier in the thread that he sometimes has to reboot his central dns servers and he apparently doesn't run local caching servers on the individual MX/SA nodes. I have to say (as others have mentioned in this thread and elsewhere) that running a local caching nameserver on any busy MX or SA server seems to solve this issue quite well without needing any scripts. If you are rsyncing any zones from zen, etc. having the zone served up locally is awesome for quick lookups too. -Aaron Maybe my situation is unique. I'm running about 35 virtual servers and rather than run named in each one I have 3 virtual servers dedicated to doing caching DNS. One main one with 4 gigs allocated so that it caches for all of them and 2 backups in case something happens to the main one.
Re: Handy script for generating /etc/resolv.conf
On Mon, Sep 1, 2008 at 3:43 AM, Marc Perkel [EMAIL PROTECTED] wrote: Aaron Wolfe wrote: On Sun, Aug 31, 2008 at 10:59 PM, RobertH [EMAIL PROTECTED] wrote: It was explained somewhere earlier in the thread that he sometimes has to reboot his central dns servers and he apparently doesn't run local caching servers on the individual MX/SA nodes. I have to say (as others have mentioned in this thread and elsewhere) that running a local caching nameserver on any busy MX or SA server seems to solve this issue quite well without needing any scripts. If you are rsyncing any zones from zen, etc. having the zone served up locally is awesome for quick lookups too. -Aaron Maybe my situation is unique. I'm running about 35 virtual servers and rather than run named in each one I have 3 virtual servers dedicated to doing caching DNS. One main one with 4 gigs allocated so that it caches for all of them and 2 backups in case something happens to the main one. I think it's just a memory use vs. performance thing.. running a nameserver in each instance might give you better performance and stability, but of course it will use more ram. Really though I don't think named in a caching configuration is too bad of a pig on ram, and there are high performance/low ram alternatives that just do caching. I have a caching name server running on my home router (a linksys thing that runs linux) and it has only 16MB ram total for the whole system. The nameserver used there is called dnsmasq and it appears to use about 51`2k of ram in caching only mode. Might be something to consider since even with your script running every minute, you still have (up to 60 sec)+(the time the script takes to run)+(the time it takes everything to use the new resolv.conf) seconds of downtime that could be avoided.
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. 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.
RE: Handy script for generating /etc/resolv.conf
-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... 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.
Re: Handy script for generating /etc/resolv.conf
On 31 Aug 2008, Giampaolo Tomassoni stated: 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... Have you ever seen an implementation that does that? I haven't. glibc doesn't do it, unless I misread the code severely. Solaris doesn't do it. Does anything? -- `Not even vi uses vi key bindings for its command line.' --- PdS
RE: Handy script for generating /etc/resolv.conf
-Original Message-
From: Nix [mailto:[EMAIL PROTECTED]
Sent: Sunday, August 31, 2008 6:18 PM
To: Giampaolo Tomassoni
Cc: 'Marc Perkel'; users@spamassassin.apache.org
Subject: Re: Handy script for generating /etc/resolv.conf
On 31 Aug 2008, Giampaolo Tomassoni stated:
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...
Have you ever seen an implementation that does that? I haven't. glibc
doesn't do it, unless I misread the code severely. Solaris doesn't do
it. Does anything?
Uff!
Stock glibc v.2.6.1, source file resolv/res_libc.c, line#167:
if (stat (_PATH_RESCONF, statbuf) == 0 last_mtime !=
statbuf.st_mtime) {
_PATH_RESCONF is /etc/resolv.conf; last_mtime is the last modify time (the
previous modify time) of the /etc/resolv.conf file.
I don't know which glibc version you have, but trust me this code had been
there by long time.
I you have a twisted version of glibc, please share: it is free software
and you have to publish any change to it... :)
Giampaolo
--
`Not even vi uses vi key bindings for its command line.' --- PdS
RE: Handy script for generating /etc/resolv.conf
-Original Message-
From: Nix [mailto:[EMAIL PROTECTED]
Sent: Sunday, August 31, 2008 6:18 PM
To: Giampaolo Tomassoni
Cc: 'Marc Perkel'; users@spamassassin.apache.org
Subject: Re: Handy script for generating /etc/resolv.conf
On 31 Aug 2008, Giampaolo Tomassoni stated:
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...
Have you ever seen an implementation that does that? I haven't. glibc
doesn't do it, unless I misread the code severely. Solaris doesn't do
it. Does anything?
Uff!
Stock glibc v.2.6.1, source file resolv/res_libc.c, line#167:
if (stat (_PATH_RESCONF, statbuf) == 0 last_mtime !=
statbuf.st_mtime) {
_PATH_RESCONF is /etc/resolv.conf; last_mtime is the last modify time (the
previous modify time) of the /etc/resolv.conf file.
I don't know which glibc version you have, but trust me this code had been
there by long time.
I you have a twisted version of glibc, please share: it is free software
and you have to publish any change to it... :)
Giampaolo
--
`Not even vi uses vi key bindings for its command line.' --- PdS
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. most resolver implementations don't do that. and even then, not all applications will obey that (the mozilla family is known to play bad games here). 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. 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). 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?
RE: Handy script for generating /etc/resolv.conf
-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?
Re: Handy script for generating /etc/resolv.conf
On 31 Aug 2008, Giampaolo Tomassoni outgrape:
Uff!
Stock glibc v.2.6.1, source file resolv/res_libc.c, line#167:
if (stat (_PATH_RESCONF, statbuf) == 0 last_mtime !=
statbuf.st_mtime) {
_PATH_RESCONF is /etc/resolv.conf; last_mtime is the last modify time (the
previous modify time) of the /etc/resolv.conf file.
Er, um, resolv/res_libc.c in glibc 2.6.1 (and the very latest 2.8: the
file is unchanged) is only 152 lines long. There is no reference to
st_mtime anywhere under resolv/.
Are you sure that's stock?
I don't know which glibc version you have, but trust me this code had been
there by long time.
Not in my universe :)
I you have a twisted version of glibc, please share: it is free software
and you have to publish any change to it... :)
May I second that motion? Are you *sure* yours doesn't have any distro patches
applied? (Mine is straight from upstream CVS.)
This is something I can understand a distro vendor patching, and also
something I can see Ulrich rejecting, because banging stat()s on that
file with every name lookup seems expensive. (Doing it every minute or
so would be acceptable to me, but IIRC Ulrich turned that down as
well...)
--
`Not even vi uses vi key bindings for its command line.' --- PdS
RE: Handy script for generating /etc/resolv.conf
-Original Message-
From: Nix [mailto:[EMAIL PROTECTED]
Sent: Sunday, August 31, 2008 10:54 PM
To: Giampaolo Tomassoni
Cc: 'Giampaolo Tomassoni'; 'Marc Perkel'; users@spamassassin.apache.org
Subject: Re: Handy script for generating /etc/resolv.conf
On 31 Aug 2008, Giampaolo Tomassoni outgrape:
Uff!
Stock glibc v.2.6.1, source file resolv/res_libc.c, line#167:
if (stat (_PATH_RESCONF, statbuf) == 0 last_mtime !=
statbuf.st_mtime) {
_PATH_RESCONF is /etc/resolv.conf; last_mtime is the last modify time
(the
previous modify time) of the /etc/resolv.conf file.
Er, um, resolv/res_libc.c in glibc 2.6.1 (and the very latest 2.8: the
file is unchanged) is only 152 lines long. There is no reference to
st_mtime anywhere under resolv/.
Are you sure that's stock?
Darn gentoo!
I forgot the ebuild unpack applies paches. Sorry, my fail.
--- libc/resolv/res_libc.c
+++ libc/resolv/res_libc.c
@@ -22,6 +22,7 @@
#include arpa/nameser.h
#include resolv.h
#include bits/libc-lock.h
+#include sys/stat.h
/* The following bit is copied from res_data.c (where it is #ifdef'ed
@@ -101,6 +102,20 @@
__res_maybe_init (res_state resp, int preinit)
{
if (resp-options RES_INIT) {
+ static time_t last_mtime, last_check;
+ time_t now;
+ struct stat statbuf;
+
+ time (now);
+ if (now != last_check) {
+ last_check = now;
+ if (stat (_PATH_RESCONF, statbuf) == 0
last_mtime != statbuf.st_mtime) {
+ last_mtime = statbuf.st_mtime;
+ atomicinclock (lock);
+ atomicinc (__res_initstamp);
+ atomicincunlock (lock);
+ }
+ }
if (__res_initstamp != resp-_u._ext.initstamp) {
if (resp-nscount 0) {
__res_nclose (resp);
Ok, you're right: in stock 2.7 this code is missing.
I don't know which glibc version you have, but trust me this code had
been
there by long time.
Not in my universe :)
Well, in mine (not stock, you're right: gentoo suse) it is. I believe it
is in many others, anyway: it doesn't make sense to me to restart
applications to commit changes in the resolv.conf file.
I you have a twisted version of glibc, please share: it is free
software
and you have to publish any change to it... :)
May I second that motion? Are you *sure* yours doesn't have any distro
patches
applied? (Mine is straight from upstream CVS.)
This is something I can understand a distro vendor patching, and also
something I can see Ulrich rejecting, because banging stat()s on that
file with every name lookup seems expensive. (Doing it every minute or
so would be acceptable to me, but IIRC Ulrich turned that down as
well...)
SuSE Gentoo do that at most once per second (see? now != last_check).
If you're issuing tons of requests per second, it isn't that bad anyway.
Giampaolo
--
`Not even vi uses vi key bindings for its command line.' --- PdS
Re: Handy script for generating /etc/resolv.conf
Well, the code works for me. If someone has a better solution I'll switch to yours. I just created it because I needed it and thought I'd share it with others who might need it. But if any of you want to improve it or replace it with something better I'm always looking for new tricks.
RE: Handy script for generating /etc/resolv.conf
Well, the code works for me. If someone has a better solution I'll switch to yours. I just created it because I needed it and thought I'd share it with others who might need it. But if any of you want to improve it or replace it with something better I'm always looking for new tricks. Marc and list... Im confused... Why are you losing DNS in the first place where you would even have to worry about this? - rh
Re: Handy script for generating /etc/resolv.conf
On Sun, Aug 31, 2008 at 10:59 PM, RobertH [EMAIL PROTECTED] wrote: Well, the code works for me. If someone has a better solution I'll switch to yours. I just created it because I needed it and thought I'd share it with others who might need it. But if any of you want to improve it or replace it with something better I'm always looking for new tricks. Marc and list... Im confused... Why are you losing DNS in the first place where you would even have to worry about this? It was explained somewhere earlier in the thread that he sometimes has to reboot his central dns servers and he apparently doesn't run local caching servers on the individual MX/SA nodes. I have to say (as others have mentioned in this thread and elsewhere) that running a local caching nameserver on any busy MX or SA server seems to solve this issue quite well without needing any scripts. If you are rsyncing any zones from zen, etc. having the zone served up locally is awesome for quick lookups too. -Aaron
Re: Handy script for generating /etc/resolv.conf
Marc Perkel wrote: Here's something I threw together to make sure the /etc/resolv.conf points to a working nameserver. I run this once a minute. 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. #!/bin/bash # This program is run once a minute and automatically generates the /etc/resolv.conf file DEFAULTSERVERS=65.49.42.30 65.49.42.31 65.49.42.33 69.50.231.141 # If default isn't optimum then read /etc/sysconfig/local-servers for list [ -f /etc/sysconfig/local-nameservers ] . /etc/sysconfig/local-nameservers echo # Automatically generated by $0 /etc/resolv.tmp echo /etc/resolv.tmp echo domain ctyme.com /etc/resolv.tmp echo /etc/resolv.tmp for ns in $LOCALNAMESERVERS $DEFAULTSERVERS; do /usr/bin/nc -w 3 -z $ns 53 | cut -d \ -f 3 | sed -e 's/^.*$/nameserver \0/' /etc/resolv.tmp done # resolv.conf only allows 3 nameservers so truncate list to 7 lines head -n 7 /etc/resolv.tmp /etc/resolv.conf rm /etc/resolv.tmp OH - and the /etc/sysconfig/local-nameservers file looks like this: LOCALNAMESERVERS=127.0.0.1 67.201.12.11
Re: Handy script for generating /etc/resolv.conf
On Thu, 28 Aug 2008, Marc Perkel wrote: echo/etc/resolv.tmp That space between the s is going to cause problems. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ [EMAIL PROTECTED]FALaholic #11174 pgpk -a [EMAIL PROTECTED] key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Look at the people at the top of both efforts. Linus Torvalds is a university graduate with a CS degree. Bill Gates is a university dropout who bragged about dumpster-diving and using other peoples' garbage code as the basis for his code. Maybe that has something to do with the difference in quality/security between Linux and Windows. -- anytwofiveelevenis on Y! SCOX --- Today: Exercise Your Rights day
Re: Handy script for generating /etc/resolv.conf
On Thu, 28 Aug 2008, John Hardin wrote: On Thu, 28 Aug 2008, Marc Perkel wrote: echo/etc/resolv.tmp That space between the s is going to cause problems. ...WTF? Never mind, PINE betrayed me by reformatting those lines for some reason. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ [EMAIL PROTECTED]FALaholic #11174 pgpk -a [EMAIL PROTECTED] key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Look at the people at the top of both efforts. Linus Torvalds is a university graduate with a CS degree. Bill Gates is a university dropout who bragged about dumpster-diving and using other peoples' garbage code as the basis for his code. Maybe that has something to do with the difference in quality/security between Linux and Windows. -- anytwofiveelevenis on Y! SCOX --- Today: Exercise Your Rights day
Re: Handy script for generating /etc/resolv.conf
On 28.08.08 08:41, Marc Perkel wrote: Here's something I threw together to make sure the /etc/resolv.conf points to a working nameserver. do you have problems with nameservers? Do you run own one? I guess that setting timeout, rotate and attempts options in resolv.conf could help you more than such script -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Microsoft dick is soft to do no harm
Re: Handy script for generating /etc/resolv.conf
* Matus UHLAR - fantomas [EMAIL PROTECTED]: I guess that setting timeout, rotate and attempts options in resolv.conf could help you more than such script Nice tip, but there's no option that will back off from a dead DNS. Of course timeout/attempts and rotate will help a bit. -- Ralf Hildebrandt (i.A. des IT-Zentrums) [EMAIL PROTECTED] Charite - Universitätsmedizin BerlinTel. +49 (0)30-450 570-155 Gemeinsame Einrichtung von FU- und HU-BerlinFax. +49 (0)30-450 570-962 IT-Zentrum Standort CBF I'm looking for a job!
RE: Handy script for generating /etc/resolv.conf
Marc So what happens if you run a local nameserver in caching mode? You may find this reduces the DNS related query time (and for that matter overall SA processing) dramitcally). -- Martin Hepworth Snr Systems Administrator Solid State Logic Tel: +44 (0)1865 842300 -Original Message- From: Marc Perkel [mailto:[EMAIL PROTECTED] Sent: 28 August 2008 16:41 To: users@spamassassin.apache.org Subject: Handy script for generating /etc/resolv.conf Here's something I threw together to make sure the /etc/resolv.conf points to a working nameserver. I run this once a minute. 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. #!/bin/bash # This program is run once a minute and automatically generates the /etc/resolv.conf file DEFAULTSERVERS=65.49.42.30 65.49.42.31 65.49.42.33 69.50.231.141 # If default isn't optimum then read /etc/sysconfig/local-servers for list [ -f /etc/sysconfig/local-nameservers ] . /etc/sysconfig/local-nameservers echo # Automatically generated by $0 /etc/resolv.tmp echo /etc/resolv.tmp echo domain ctyme.com /etc/resolv.tmp echo /etc/resolv.tmp for ns in $LOCALNAMESERVERS $DEFAULTSERVERS; do /usr/bin/nc -w 3 -z $ns 53 | cut -d \ -f 3 | sed -e 's/^.*$/nameserver \0/' /etc/resolv.tmp done # resolv.conf only allows 3 nameservers so truncate list to 7 lines head -n 7 /etc/resolv.tmp /etc/resolv.conf rm /etc/resolv.tmp ** Confidentiality : This e-mail and any attachments are intended for the addressee only and may be confidential. If they come to you in error you must take no action based on them, nor must you copy or show them to anyone. Please advise the sender by replying to this e-mail immediately and then delete the original from your computer. Opinion : Any opinions expressed in this e-mail are entirely those of the author and unless specifically stated to the contrary, are not necessarily those of the author's employer. Security Warning : Internet e-mail is not necessarily a secure communications medium and can be subject to data corruption. We advise that you consider this fact when e-mailing us. Viruses : We have taken steps to ensure that this e-mail and any attachments are free from known viruses but in keeping with good computing practice, you should ensure that they are virus free. Red Lion 49 Ltd T/A Solid State Logic Registered as a limited company in England and Wales (Company No:5362730) Registered Office: 25 Spring Hill Road, Begbroke, Oxford OX5 1RU, United Kingdom **
Re: Handy script for generating /etc/resolv.conf
Matus UHLAR - fantomas wrote: On 28.08.08 08:41, Marc Perkel wrote: Here's something I threw together to make sure the /etc/resolv.conf points to a working nameserver. do you have problems with nameservers? Do you run own one? I guess that setting timeout, rotate and attempts options in resolv.conf could help you more than such script The problem is that there's so many DNS calls that if the first nameserver in the list isn't working then it's just too slow and email backs up, fills memory, things time out, and it isn't pretty. My name servers are generally reliable but if I need to reboot a server or something crashes I need everything to switch over automatically. So I run 3 caching name servers in my main cluster because I'm a redundancy freak and triple redundancy works. I'm not that into rotating because the caching works best for speed if they are al hitting one nameserver first. The others just sit there unless they are needed. I'm using OpenVZ for everything now so running some extra caching name servers is easy to do.
Re: Handy script for generating /etc/resolv.conf
* Matus UHLAR - fantomas [EMAIL PROTECTED]: I guess that setting timeout, rotate and attempts options in resolv.conf could help you more than such script On 28.08.08 18:05, Ralf Hildebrandt wrote: Nice tip, but there's no option that will back off from a dead DNS. Of course timeout/attempts and rotate will help a bit. I think that proper timeout and setting those two should cause maximum timeout timeout per one dead server, e.g. 1-2 seconds, which should be OK. I have also asked if there are problems with nameservers and my main point wa if something couldn't be there. We have 4 DNS servers behind L3 switch that monitors DNS servers... -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. To Boot or not to Boot, that's the question. [WD1270 Caviar]
Re: Handy script for generating /etc/resolv.conf
Matus UHLAR - fantomas wrote: We have 4 DNS servers behind L3 switch that monitors DNS servers... This script is a poor man's L3 switch. :)
Re: Handy script for generating /etc/resolv.conf
Ralf Hildebrandt wrote: * Matus UHLAR - fantomas [EMAIL PROTECTED]: I guess that setting timeout, rotate and attempts options in resolv.conf could help you more than such script Nice tip, but there's no option that will back off from a dead DNS. Of course timeout/attempts and rotate will help a bit. You missed it - there is: nc -w 0 -z $ns 53 | cut -d \ -f 3 | sed -e 's/^.*$/nameserver \0/' /etc/resolv.conf This only creates a line IF the nameserver is working. The idea is that it automatically culls out the dead servers.
Re: Handy script for generating /etc/resolv.conf
* Marc Perkel [EMAIL PROTECTED]: Ralf Hildebrandt wrote: * Matus UHLAR - fantomas [EMAIL PROTECTED]: I guess that setting timeout, rotate and attempts options in resolv.conf could help you more than such script Nice tip, but there's no option that will back off from a dead DNS. Of course timeout/attempts and rotate will help a bit. You missed it - there is: nc -w 0 -z $ns 53 | cut -d \ -f 3 | sed -e 's/^.*$/nameserver \0/' /etc/resolv.conf I wasn't talking about your script. This only creates a line IF the nameserver is working. The idea is that it automatically culls out the dead servers. Of course. -- Ralf Hildebrandt (i.A. des IT-Zentrums) [EMAIL PROTECTED] Charite - Universitätsmedizin BerlinTel. +49 (0)30-450 570-155 Gemeinsame Einrichtung von FU- und HU-BerlinFax. +49 (0)30-450 570-962 IT-Zentrum Standort CBF I'm looking for a job!
Re: Handy script for generating /etc/resolv.conf
On 28.08.08 08:41, Marc Perkel wrote: Here's something I threw together to make sure the /etc/resolv.conf points to a working nameserver. Matus UHLAR - fantomas wrote: do you have problems with nameservers? Do you run own one? I guess that setting timeout, rotate and attempts options in resolv.conf could help you more than such script On 28.08.08 09:09, Marc Perkel wrote: The problem is that there's so many DNS calls that if the first nameserver in the list isn't working then it's just too slow and email backs up, fills memory, things time out, and it isn't pretty. if 1s timeout in resolv.conf (and thus 1s timeout for each dead DNS server) causes this problem, it's time to upgrade your machine... -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Micro$oft random number generator: 0, 0, 0, 4.33e+67, 0, 0, 0...
Re: Handy script for generating /etc/resolv.conf
On Thu, 2008-08-28 at 08:41 -0700, Marc Perkel wrote: Here's something I threw together to make sure the /etc/resolv.conf points to a working nameserver. I run this once a minute. 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. Cool. I get the same effect by running a private DNS service on my SA host. Its prime use is to centralise host naming for my LAN and to act as a local DNS cache. It forwards name requests it can't satisfy to (currently) three external DNS servers, so I think it achieves the same DNS resilience as your script as well as speeding up access to frequently accessed blacklisting sites. Martin
