[sf-lug] resolver problem

[Rick Moen]

Quoting Alex Kleider (akleider at sonic.net):
> On 2016-04-08 08:11, Bobbie Sellers wrote:
> 
> > Well since you are talking re-install then I will toss in my 2
> > cents worth.  Have you tried un-installing and re-installing Firefox?
> 
> I have not.  My assumption is that Firefox couldn't be causing a
> problem that would make ping succeed and curl fail to resolve an IP
> address- does that seem valid (or not?)

Your instincts seem sound.  It doesn't seem likely.

On the other side of that, you _should_ be able to test by just doing
apt-get --purge remove [package]
apt-get install [package]

(As you're on Ubuntu and probably use sudo, prepend sudo to those.
Old-school, one su's to user root to do such things.)

Point is, it's an easy thing to test, even if it seems unlikely.

A reminder, though:  User dotfiles can also do mischief.  (By that, I refer
to per-user program configuration files and directories in the user
homedir that are characteristically[1] 'hidden' by their names starting
with a dot.  A 'hidden' file is omitted from the ls command but included 
when ls has the '-a' flag.)  

Per-user dotfiles in the user's homedir override (for that one user)
system-wide configuration files in /etc.  For example, the editor vim 
obeys system-wide configuration file /etc/vim/vimrc .  An individual
user wanting to customise that can create ~/.vimrc, at his/her option 
either basing it on /etc/vim/vimrc or writing a totally new one.

Programs often update dotfile conffiles and directories on the user's
behalf, e.g., if you store a bookmark in Firefox, it will get written to
a bookmarks.html file inside directory tree ~/.firefox or ~/.mozilla or
somewhere like that.

Anyway, there is always a chance that one's dotfile configuration state 
has somehow sabotaged a program _as run by that user_.  Therefore, if in
doubt about this, it's userful to create a new scratch user, one that
impliedly starts with a blank slate for user configuration files, and
double-check the program.

I'll stress that I've never seen user dotfiles, no matter how badly
mangled, sabotage a program by making its DNS access no longer work.
However, when I worked at Cadence Design Systems in the 2000s and the
firm was trying to use the GNOME desktop on Linux for a standard
workstation, it was extremely common for GNOME to so mangle the user's
four directories of GNOME settings in the user's homedir that GNOME
would crash on login and log the user back out.  Removing those four
conffile directories in the user's homedir always fixed the immediate
problem (but of course reverted the user's GNOME desktop to defaults).

Before doing so, we would sometimes create a scratch user to ensure that
GNOME _generically_ was still OK, and that was always the case.  Only
the one user's GNOME was bollixed, on account of corruption to GNOME's
settings in the per-user conffiles.  (It turned out that GNOME could not
manage its dotfiles because the user homedir was on NFS, and GNOME did
an incompetent job on interacting with NFS locking.)


[1] Old-school, all program configuration files and directories in a
user's homedir reliably had names starting with a dot, hence were
'hidden'.  Some new-school programs fail to follow this convention.  For
example, last I checked, two of the per-user conffile directories for
GNOME had non-'hidden' names.  It's unclear why the GNOME devs made that
silly decision, but they did.  Anyway, the name 'dotfile' has a long
Unix history of implying 'any per-user conffile or conffile directory',
so when I say 'dotfile' these days, I include by extension ones that
don't begin with a dot (period) character, but ought to.