Hide Forgot
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
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
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.
Your proposal change makes sence. I will fix this in 5.2 Adam
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.
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
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; :;
I'm unable to re-open the bug. Could someone please do it for me, or should I clone it?