Bug 247486 - bind-chroot does not modify /etc/logrotate.d/named
bind-chroot does not modify /etc/logrotate.d/named
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: bind (Show other bugs)
5.0
All Linux
low Severity low
: ---
: ---
Assigned To: Adam Tkac
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-09 11:57 EDT by Zenon Panoussis
Modified: 2013-04-30 19:36 EDT (History)
1 user (show)

See Also:
Fixed In Version: RHSA-2008-0300
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-21 10:17:32 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 Zenon Panoussis 2007-07-09 11:57:32 EDT
Description of problem:
The standard named log rotation script points to /var/log/named.log . The (not
exactly included, but yet) default named.conf sends the logs to that file too.
If bind-chroot is installed, the logs end up in
/var/named/chroot/var/log/named.log. Therefore, the chroot package should create
 chroot/var/log and replace logrotate.d/named accordingly. 


Version-Release number of selected component (if applicable):
9.3.3-8.el5
Comment 1 Adam Tkac 2007-07-17 04:41:52 EDT
First about creating var/named/log directory in chroot - definitely not because
log file could be located everywhere (and someone else could want create
var/named/logs/, someone var/log etc).

And about changing logrotate.d/named. This is only template, /var/log/named.log
doesn't exist in default configuration so if you create in (in chroot or not)
you have to configure all other things accordingly.

I should simply change /var/log/* to /var/named/chroot/var/log/* in
/etc/logrotate.d/named when bind-chroot is installed but I don't think this
change makes sence. What's your opinion about this?

Adam
Comment 2 Zenon Panoussis 2007-07-17 17:24:57 EDT
I suspect that nine out of ten times someone installs bind for the first time,
he grabs the default named.conf that comes with the package, adds some domains
to it and is up and running. Therefore, since the default named.conf sends the
log to /var/log/named.log, that's where it will be in most systems. 

/etc/logrotate.d/named comes with the bind package and points to the default
logfile. There is some crisp logic in that: if the admin changes the log
location, he should change it everywhere, and if he doesn't change anything,
logs and log rotation should work out of the box. 

There is no reason why this logic should be lost if bind-chroot gets installed. 
The problem now is that the chroot package seems to take care of everything
needed, but actually it does not. The stressed/sloppy/distracted admin sees
everything working and doesn't realise that bind isn't logging at all because
the directory /var/named/chrooot/var/log is missing. He only finds out there is
no log when he needs the log and goes looking for it. So then he creates the
directories and forgets the rotation, until a full partitition some time later
reminds him of that. 

Is it the distro's job to compensate the sloppiness of the admin? Perhaps not.
But at least the distro shouldn't create traps for the sloppy admin to fall
into. If the bind-chroot pachage keeps the logic from the base bind package,
everything will work out of the box if the admin changes nothing. If, on the
other hand, the admin does change something, he will know that he needs to
change it everywhere. 

For these reasons I still think that bind-chroot should create the directories
/var/named/chroot/var/log and point the logorate script to
/var/named/chroot/var/log/named.log . Besides, this is a zero-cost/zero-risk
change; it would spare some people some trouble but it wouldn't cause anyone
else any new trouble. 
Comment 3 Adam Tkac 2007-07-18 04:37:10 EDT
Your proposal change makes sence. I will fix this in 5.2

Adam
Comment 5 RHEL Product and Program Management 2007-10-15 23:55:10 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 11 errata-xmlrpc 2008-05-21 10:17:32 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2008-0300.html
Comment 12 Zenon Panoussis 2010-09-07 16:03:57 EDT
I just noticed, this has reverted back to its pre-fix behaviour. 

The fix in RHSA-2008:0300-16 was

* the default named log rotation script did not work correctly when using
the bind-chroot package. In these updated packages, installing
bind-chroot creates the symbolic link "/var/log/named.log", which points
to "/var/named/chroot/var/log/named.log", which resolves this issue.

However, 

rpm -q bind-chroot
bind-chroot-9.3.6-4.P1.el5_4.2

rpm -q --scripts bind-chroot
postinstall scriptlet (using /bin/sh):
if [ "$1" -gt 0 ]; then
   /usr/sbin/bind-chroot-admin --enable > /dev/null 2>&1;
fi;
:;
preuninstall scriptlet (using /bin/sh):
if [ "$1" -eq 0 ]; then
   /usr/sbin/bind-chroot-admin --disable > /dev/null 2>&1;
fi
:;
posttrans scriptlet (using /bin/sh):
if [ -x /usr/sbin/selinuxenabled ] && /usr/sbin/selinuxenabled && \
   [ -x /sbin/restorecon ]; then
        /sbin/restorecon /var/named/chroot/dev/* > /dev/null 2>&1;
fi;
:;
Comment 13 Zenon Panoussis 2010-09-07 16:05:13 EDT
I'm unable to re-open the bug. Could someone please do it for me, or should I clone it?

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