On Wednesday 05 December 2007, Allen Weiner wrote: > Regarding your suggested changes to /etc/resolv.conf: I was not > previously aware that a necessary step in converting to static IP is to > manually edit /etc/resolv.conf.
Yep -- required. > I wonder where the GUI stored the DNS server addresses I gave it. It probably should have modified /etc/resolv.conf. > I did a search in Google books of "resolv.conf". From "Linux > Administration Handbook" p420 (chapter on DNS): "Earlier versions of > BIND used the "domain" directive in resolv.conf instead of the "search" > directive.....We recommend replacing "domain" directives with "search" > directives. Okay; I won't disagree with that, but it's not what I do at least for boxes with static IP addresses. > So, it's clear to me that I should put the DNS server addresses > in /etc/resolv.conf. It's not clear at this time that the "domain" line > is the right way to go. Well, here's the thing: right now your search line in /etc/resolv.conf is a partially valid domain name [myhome.westell.com]; westell.com is a public domain name that exists and has DNS servers that resolve queries for it, even though the subdomain myhome.westell.com does not exist. DNS resolution is done by first looking up the .com root name server and asking what DNS server is authoratative for westell.com, then that name server is queried for what DNS server is authoratative for myhome.westell.com, which then fails since that subdomain does not exist. Those queries are going to a remote DNS server, they're unnecessary, and take time. I'm guessing that sequence will happen every time you try to access any DNS name that isn't fully qualified. You could change the domain name that the search line points to to some completely non-existant domain like "fake.bogus" which should be faster since there's no root name server for .bogus -- or I suppose you could remove the search line entirely. > On my most recent connection loss, I issued "service network stop" > instead of "service network restart". The message "shutting down > interface eth0" was displayed, the eth0 monitor on gkrellm disappeared, > and then the command hung. > So my next troubleshooting step is to find out where in "service network > stop" the hang occurs. I viewed the script of the "service network" > command and I don't understand the code. Although I've been reading > "Advanced Bash Scripting Guide", I expect it will be a while before I > understand the "service network" script. It takes time, sure. > If you have access to the > Fedora scripts, could you possibly direct me to the first script invoked > by "service network stop" in which I should place an "echo" statement? I don't run Fedora. Last I ran Red Hat (years ago), I believe 'service network stop' would actually run '/etc/init.d/network stop' if I remember correctly, so /etc/init.d/network is probably the script to start with. ['stop' in this case is the first argument that goes into the shell variable $1.] Best I can suggest at the moment is to experiment in placing echo statements within that file after backing it up. I think this is something that is best done by you locally on your box to get immediate feedback. > I was not aware that iptables and/or Firestarter can dynamically change > rules upon occurrence of undesired connection attempts. Could you > suggest a Google search term I could use to find out more about this? There are several types of programs that can dynamically make iptables rules, such as fail2ban, portsentry, psad, etc. I don't think iptables dynamically makes rules for itself, and I'm not familar with Firestarter, so I don't know if it does that or not. The description for Firestarter on includes "The real-time hit monitor shows attackers probing your machine" which inicates that it can at least detect "attackers". > I posted to the dslreports.com Verizon forum about the numerous > connection attempts to port 80 I'm getting. I got a reply from one of > the forum regulars. He says Verizon isn't strict about enforcing the > no-server rule, so he doubts that is what I'm getting. He has no idea as > to what it might be. Hmm. Okay. -- Chris -- Chris Knadle [EMAIL PROTECTED] _______________________________________________ Mid-Hudson Valley Linux Users Group http://mhvlug.org http://mhvlug.org/cgi-bin/mailman/listinfo/mhvlug Upcoming Meetings (6pm - 8pm) MHVLS Auditorium Dec 5 - Open Source Show and Tell Jan 2 - TBD Feb 6 - DBUS Mar 5 - Setting up a platform-independent home/small office network using Linux
