Bug 511223 - Improve bind logging functionality
Improve bind logging functionality
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: bind (Show other bugs)
5.3
All Linux
medium Severity medium
: rc
: ---
Assigned To: Adam Tkac
qe-baseos-daemons
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-14 06:31 EDT by David Kovalsky
Modified: 2014-03-31 19:45 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-09-21 10:25:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Kovalsky 2009-07-14 06:31:46 EDT
Today I was surprised why bind doesn't answer queries for my zone. It turned out to be bad ownership of file in /var/named/chroot/var/named.

If the file has ownership+perms of root.named (-rw-r-----), then it's correctly read. If it has ownership of root.root (-rw-r-----), then even though bind restarts without any warnings, an attempt to query fails (nothing logged). 

I suggest that bind emits a warning that file 'foo' can't be read. 

Reproducer:
1) Add domain into to named.conf
zone "my-domain.org" IN {
        type master;
        file "my-domain.org.zone";
}

2) Create my-domain.org.zone file in /var/named/chroot/var/named. If you're root, the default ownership+perms are root.root (-rw-r-----)

3) service named restart

4) # host my-domain.org 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:

Host my-domain.org not found: 2(SERVFAIL)

5) chown root.named /var/named/chroot/var/named/my-domain.org ; service named restart ; 

6) # host my-domain.org 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:

my-domain.org has address 1.2.3.4


Results:
bind logs nothing if it can't read it's configuration

Expected:
bind logs 'cannot read file my-domain.org.zone', or anything meaninful. Ideally at the time of the restart, as a service configuration, where part of the files are not readable, is meaningless. 

bind-9.3.4-10.P1.el5_3.1
Comment 1 Adam Tkac 2009-07-16 07:11:36 EDT
Please check your logs carefully. BIND writes message like

"Jul 16 13:04:23 rhel5 named[2812]: zone 0.0.127.in-addr.arpa/IN/localhost_resolver: loading master file named.local: permission denied"

to the system log (/var/log/messages). This is considered as non fatal error in all BIND versions. Closing as notabug.
Comment 2 David Kovalsky 2009-08-03 08:42:32 EDT
Hi Adam, 

you're right :-) I missed it in the logs - I was "eye grepping" for FAILED, but missed "permission denied". 

I think the bug is still valid though - the point is that bind should not start just like that if it's not fully functional. 
If some of the configuration files can not be read, the app cannot work as expected, and it should either:
 - bail out, report [FAILED], return non-zero return code and print an error
 or at least
 - print a warning during the startup to stderr. This is the way apache HTTP server works, btw.

It's very hard to debug (and do any changes!) if after every restart you carefully have to grep /var/log/messages to check if bind is actually doing what it should.
Comment 3 RHEL Product and Program Management 2009-11-06 13:54:06 EST
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".
Comment 4 Adam Tkac 2010-06-28 07:49:30 EDT
This kind of errors can be handled via "named-checkconf" utility which is executed in initscript to verify the configuration is correct. The named-checkconf utility will be extended by a new parameter which will allow it to run under "named" user to catch this kind of errors.

I'm currently waiting for response from upstream if this new option is acceptable for them, without their approval it can't be added.
Comment 5 David Kovalsky 2010-06-30 05:38:22 EDT
Sounds like a good plan, thanks Adam!
Comment 6 Ondrej Vasik 2010-09-21 03:45:27 EDT
Upstream is not responding to that bugzilla, therefore I'm setting dev_nack instead of conditional nack. Fork is not a good idea here.

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