Bug 125097
| Summary: | bind package does not ship/create suitable default named.conf | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Bishop Clark <bishop> |
| Component: | bind | Assignee: | Daniel Walsh <dwalsh> |
| Status: | CLOSED NOTABUG | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 2 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-06-09 18:42:58 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
See the caching-nameserver RPM. Caching-nameserver contains these files. 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. |
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.