Re: configuring interface & configuring MTA time out
On 06/16/2012 01:24 PM, Tom H wrote:
> On Sat, Jun 16, 2012 at 10:42 AM, Camaleón <noelamac@gmail.com> wrote:
>> On Fri, 15 Jun 2012 19:56:59 -0400, Gilbert Sullivan wrote:
>>> On 06/15/2012 12:58 PM, Camaleón wrote:
>>
>>>>> Thank you for your ideas, and I'll return to this thread when I have
>>>>> any kind of information.
>>>>
>>>> Ok, keep us informed. I feel curious about what's going on here :-)
>>>>
>>> Just a note about an observation. Just for grins -- even though name
>>> resolution was working fine -- I checked the contents of
>>> /etc/resolv.conf. They are listed below:
>>>
>>> ----------------------------8<----------------------------
>>> # Dynamic resolv.conf(5) file for glibc resolver(3) generated by
>>> resolvconf(8)
>>> # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
>>> nameserver 127.0.0.1
>>> search wp.comcast.net
>>> ----------------------------8<----------------------------
>>>
>>> This is with the system connected at a location that does use Comcast as
>>> its ISP. But the contents of this file are not at all what I'd expect. I
>>> tried adding
>>>
>>> dns-nameservers 208.67.222.222 208.67.220.220
>>>
>>> to /etc/network/interfaces. Rebooting made no difference in the contents
>>> of /etc/resolv.conf. Is that because something weird is going on, or
>>> because the changes in netscript that happened at the time of the update
>>> have changed the way resolvconf works? I suspect the latter due to other
>>> information available.
>>
>> If you are using the "resolvconf" package I bet you have to trust what
>> the "/etc/revolv.conf" file warning says in uppercase about do not
>> editing the file because is dynamically changed ;-)
>
> Since you have "nameserver 127.0.0.1" in "/etc/resolv.conf", I'd guess
> that you have dnsmasq running and that it forwards your queries to
> 208.67.222.222 and 208.67.220.220 when you specify them in
> "/etc/network/interfaces".
>
> If you are running dnsmasq, "ps ax o cmd | grep dnsmasq" should give
> you the full command that launched it as well as the file that has the
> "external" dns servers (that's what I used on a new Ubuntu 12.04
> desktop install on which resolvconf and dnsmasq are installed by
> default; the server's been spared dnsmasq...).
>
>
Oh, shucks. I've changed things. Before seeing your reply I removed
resolvconf. Now that I did that, the /etc/resolv.conf file looks a
little more like what I'm used to seeing.
I am running dnsmasq, as it was one of aptitude's "suggested" packages
(along with resolvconf) for netscript, and I installed those yesterday
in hopes of resolving the problems with boot delays I figured were being
caused by netscript.
In case anyone is interested, the delays only happen on networks where
I've set the Wicd profile to use a fixed IP address. Oddly enough, those
delays look exactly like what I would expect from a system that is
trying (and failing) to get a DHCP lease from a non-functioning / absent
server -- two 60 sec. delays, one while configuring the interface, and
the other when starting the MTA. Oddly enough, I can ping this system
from another system on one of these networks (fixed IP), and the system
is using the specified fixed IP address by the time it gets to the login
prompt.
FWIW, I tried the command you suggested and got:
$ ps ax o cmd | grep dnsmasq
/usr/sbin/dnsmasq -x /var/run/dnsmasq/dnsmasq.pid -u dnsmasq -7
/etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new
grep dnsmasq
I suspect that it would have looked different if I had known to run it
before I removed resolvconf. At any rate, the current contents of
/etc/resolv.conf (at a location where DHCP is used) are:
$ cat /etc/resolv.conf
domain wp.comcast.net
search wp.comcast.net
nameserver 208.67.222.222
nameserver 208.67.220.220
nameserver 192.168.1.1
That's more like what I'm used to seeing. Name resolution is working
much better now, but there is the unfortunate coincidence that -- while
I was working on all of this -- the name resolution from the ISP was
messed up, and a signal they sent my modem switched it out of bridge
mode. I got that straightened out with them in a phone call this
morning, but it's kind of hard to tell just which problem was doing what
to my system. It's worth noting, however, that none of the other systems
(that don't have virtualbox installed and which aren't using netscript)
was having trouble with Internet connection or name resolution this morning.
Thank you for your suggestion. I took a quick look into some man pages
as a result, and it looks like I may have some interesting reading and
figuring to do over the next few days.
In the meantime, I'm kind of concerned that it may have been
counterproductive for me to file a bug report against netscript because
of the boot delays. I guess the maintainers are pretty busy these days
trying to deal with bugs before the freeze.
I appreciate your help in starting to get some idea of what's going on.
If you have suggestions about making this more of a learning experience
for me -- or if you have suggestions about what I should do about that
bug report -- please let me know. I'm a little bit at sea right now.
Best regards,
Gilbert
Reply to: