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?