Bug 4524 - Caching-nameserver does not work out-of-the-box
Summary: Caching-nameserver does not work out-of-the-box
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: caching-nameserver
Version: 6.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: David Lawrence
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 1999-08-14 23:26 UTC by kyle
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 1999-08-27 15:18:43 UTC

Attachments (Terms of Use)

Description kyle 1999-08-14 23:26:12 UTC
After installing the bind, bind-utils, and
caching-nameserver rpms, the nameserver fails to cache,
because /etc/resolv.conf does not have a entry.
I think it would be helpful to include a post-install script
in the caching-nameserver rpm, which would

(1) cp -p /etc/resolv.conf /etc/resolv.conf.old
(2) add "nameserver" before any other nameserver
	lines in /etc/resolv.conf

Thanks for your support.

Comment 1 kyle 1999-08-14 23:47:59 UTC
Ok, I see this was reported previously as bug 2806, to whihc I found
the following reply:

// begin included text

------- Additional Comments From jbj  05/15/99 16:23
The installer (and ultimately the user) is responsible for
configuring the DNS client. Assuming that there is a nameserver
running on localhost is not the Right Thing To Do.

// end included text

I respectfully agree AND disagree.

Assuming that a DNS is running on local host is the Wrong Thing.  But
ignoring the possibility is also wrong, and not not particularly
helpful.  The Right Thing To Do is handle it.  It is emminently
reasonable to expect that someone installing "caching-nameserver" has
also installed "bind."  But, you say, what if they didn't?  Easy.  The
post-install scripts of *both* "caching-nameserver" and "bind" check
for the pre-existence of the other.  If either finds the other and
does not find "" in /etc/resolve.conf, then it edits
resolv.conf (after making a copy).

There might be a pathological case I havn't considered, in which case
the post-install script(s) should at least write a diagnostic to
/var/log/install (or similar) to alert the semi-savvy admin that he
needs to do something.

I'm reasonably experienced at this (pre-RedHat days, but still not a
self-proclaimed expert) and it took me more time than needed to figure
out what was wrong when my connects were slow.  I consider this a
user-acceptance issue.  I'm persistent.  But as Linux reaches for the
mainstream, we all need to be aware that some people have a low
threshold for frustration that *seems* unnecessary.  Networking issues
may be a bit much for a newbie to bite off, so we should help them
whenever possible.

Again, thanks for your support.

Comment 2 Jeff Johnson 1999-08-27 15:18:59 UTC
While I agree with all that you are saying, I do not believe that
rpm scriptlets can be written robustly enough to handle the myriad
problems that have to be handled to do the Right Thing. For starters,
consider that the insaller environment in which the scriptlets run
is chroot'ed w/o any running daemons.

So, for now, let's just say that we're not gonna be able to address
the problem.

Note You need to log in before you can comment on or make changes to this bug.