[sf-lug] resolver problem

[Michael Paoli]

So ... continue divide & conquer ...

What about if the misbehaving browser is launched fresh under another
user on the host - one that's not launched that browser before, or
has had all user configuration saved state stuff from the browser
totally removed first?  Does that other user experience the same
problem, or not?

If that user doesn't get same problem, then it's likely limited to
user state/configuration information stored by the browser.

If other user gets same problem, and it's continuing to work in
one browser, but not the other, how 'bout use of tcpdump to look at
DNS traffic, http traffic, and https traffic.  Most notably when
the browser attempts are made, how to the two differ in what they
do/don't attempt to retrieve from DNS (and other resolver bits before
that), and what they do and don't attempt to connect to (or if they
fail prior to that due to failure to resolve).

What about the git command that's failing?  Same failure if run by
another user on the same host?

Also, when you boot from the (I presume it's actually DVD) Ubuntu
14.04[.x] ISO, what does it have for configuration data in /etc/resolv.conf
and what does it have for hosts in /etc/nsswitch.conf ?

Also, check on the host, in recent system logs - anything particularly
unusual or indicative of a problem?  Likewise look at the output of
dmesg - most notably at/towards the tail end of it, for anything that
may be indicative of a problem.

If it works with one user, and not the other, one may also want to inspect
various environment and configuration settings. especially if the difference
between working and not extends beyond per-user saved browser state file
data - e.g. if also git fails for one user, but works for the other user.

https://en.wikipedia.org/wiki/Divide_and_conquer_algorithms

> From: "Alex Kleider" <akleider at sonic.net>
> Subject: Re: [sf-lug] resolver problem
> Date: Wed, 06 Apr 2016 16:22:05 +0000
>
> I shutdown, removed the hard drive and booted from the ubuntu CD:
> everything works as expected-
> I assume it is safe to say that what ever the problem is, it's to do with
> something wrong on my hard drive- presumable some configuration somewhere,
> not a hardware issue.
>
> Before doing the above, I checked firefox vs chromium again
> and the exact same urls complete with he protocol part at the beginning
> were resolved by the latter, not by the former.