Bug 125097 - bind package does not ship/create suitable default named.conf
bind package does not ship/create suitable default named.conf
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: bind (Show other bugs)
2
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-06-02 14:10 EDT by Bishop Clark
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-06-09 14:42:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Bishop Clark 2004-06-02 14:10:05 EDT
Description of problem:
The bind package does not ship or create a suitable named.conf file. 
Far from the minor book-keeping probelm where apparently no package
owns the config file on the system instead of just not verifying the
contents as it should, the RPM just doens't even seem to care if a
config file is put into place on installation, and doesn't signal the
lack with more than siliently not starting.

Version-Release number of selected component (if applicable):
bind-9.2.3-13

How reproducible:
always

Steps to Reproduce:
1.  apt-get install bind
2.  service bind start
3.  
  
Actual results:
nothing.

Expected results:
named starting a caching-only config

Additional Housecleaning info/gripes:
/etc/named.conf maybe should have an owning package, so when people
start to care about the verification aspect of RPM this low-hanging
fruit is already solved.

rpm -q --qf "%{distribution}" bind-9.2.3 produces the text "Red hat
Linux", while I (at least) was anticipating "Fedora Core 2"

A set of tools for configuring bind that didn't require shiny happy
clicky GUIs is always, always enjoyed by those of us viewing the
machine from more than 3 feet away or without a mouse, btw, but maybe
my burry eyes just are missing the obvious.
Comment 1 Ben Lentz 2004-06-08 09:54:03 EDT
See the caching-nameserver RPM.
Comment 2 Daniel Walsh 2004-06-09 14:42:58 EDT
Caching-nameserver contains these files.
Comment 3 Bishop Clark 2004-06-19 04:54:22 EDT
Anaconda seems to be setting the /etc/sysconfig/named to include a
ROOTDIR= .  This, of course, rendered the caching-nameserver files
obsolete.  I say 'seems' because I have only two sample machines (FC1
and FC2) to check, but both were installed by non-guru types who will
have chosen default options as presented to them.  In both cases, the
/etc/sysconfig/named file contained an identical configuration
ROOTDIR=/var/named/chroot directive.  It's far too small a sample set
to draw any conclusions, but the coincidence is suspicious.

Either the caching-namesever needs to deliver duplicate files to
/var/named/chroot/ , or the cause of the strange chroot addition to
the sysconfig is unexpected.  It doesn't seem to be sneaking in on a
%post of bind, and I'm only assuming it's got to be happening in
anaconda because I can't think of another source of this coincidental
addition.  I know the machine owners didn't spontaneously make the
same mod!

Additionally, the %verify for /etc/rndc.key and  /etc/sysconfig/named
files should be altered so they don't cause false positives on rpm-V
of bind.

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