Warning, I have no clue as to what I am doing.

Had to no-op include "/var/lib/named/etc/logging.conf"
    no permission to write to /var/log/security.log   :(
No idea how it worked in Mageia 1 or Mandriva 2011.

Following are the workaround changes I made:

# cd /var/lib/named/etc/
# diff -bBw named.conf_vinstall named.conf


21c21
< include "/etc/trusted_networks_acl.conf";
---
> include "/var/lib/named/etc/trusted_networks_acl.conf";
24c24
< include "/etc/logging.conf";
---
> // include "/var/lib/named/etc/logging.conf";
33,37c33,37
<     directory "/var/named";
<     managed-keys-directory "/var/named/dynamic";
<     dump-file "/var/tmp/named_dump.db";
<     pid-file "/var/run/named.pid";
<     statistics-file "/var/tmp/named.stats";
---
> directory "/var/lib/named/var/named/";
> managed-keys-directory "/var/lib/named/var/named/dynamic";
> dump-file "/var/lib/named/var/named/data/named_dump.db";
> pid-file "/var/lib/named/var/run/named.pid";
> statistics-file "/var/lib/named/var/named/data/named.stats";



Change in /lib/systemd/system/named.service
#PIDFile=/run/named/named.pid
PIDFile=/var/lib/named/var/run/named.pid

Bug confirmed, due to the failure to setup the chroot environment
properly in the service files.

Temporary workaround that does work ...
mv /lib/systemd/system/named.* /root
systemctl --system daemon-reload
service named start
chkconfig named on

CC: (none) => davidwhodgins
Summary: 2_b1: /etc/trusted_networks_acl.conf: file not found => 2_b1: named fails to start due to lack of chroot setup

The fedora package actually ships two different systemd services:
- named.service
- named-chroot.service

Only the later takes cares of running the server in a chroot, using a dedicated script (currently missing in the package, I'm taking care of it). As the mageia mandriva package sofar made chroot usage mandatory, I wonder if it's worth having both of them first, and even if true, if that's a good idea to have the non-chroot one used by default.

Status: NEW => ASSIGNED

(In reply to comment #2)
> Bug confirmed, due to the failure to setup the chroot environment
> properly in the service files.

So, are you saying nothing needs to be changed in named.conf if running chrooted?


(In reply to comment #3)
> As the mageia mandriva package sofar made chroot usage mandatory, 
> I wonder if it's worth having both of them first, and even if true, 
> if that's a good idea to have the non-chroot one used by default.

My guess is it will not run well non-chroot when trying to log anything into security_channel file found in /var/lib/named/etc/logging.conf   :(
or we are missing an acl to allow write access.

(In reply to comment #4)
> (In reply to comment #2)
> > Bug confirmed, due to the failure to setup the chroot environment
> > properly in the service files.
> 
> So, are you saying nothing needs to be changed in named.conf if running
> chrooted?

Correct.
 
> (In reply to comment #3)
> > As the mageia mandriva package sofar made chroot usage mandatory, 
> > I wonder if it's worth having both of them first, and even if true, 
> > if that's a good idea to have the non-chroot one used by default.
> 
> My guess is it will not run well non-chroot when trying to log anything into
> security_channel file found in /var/lib/named/etc/logging.conf   :(
> or we are missing an acl to allow write access.

The problem when it doesn't run chrooted, is that it's trying
to write to /var/log, which it doesn't have write permission
for, instead of to /var/lib/named/var/log, where it does have
permission, as named is the owner of that directory.

I just submitted a new release, which should fix the issue, and still enforce the chroot setup used sofar, to avoid drastic changes just before the release.

However the fedora way of dealing with this issue is much elegant, by keeping the original files in the expected places in the system, and remounting then with bind option in the chroot environment only if needed. It's probably the way to go, for next release.

(In reply to comment #6)
> I just submitted a new release, which should fix the issue, and still enforce
> the chroot setup used sofar, to avoid drastic changes just before the release.

With bind-9.9.0-2.mga2 I had to make a slight change to
/lib/systemd/system/named.service

from: PIDFile=/var/lib/named/var/run/named/named.pid
to:   PIDFile=/var/lib/named/var/run/named.pid

Created attachment 1702 [details]
Patch to fix /var/lib/named/dev/urandom minor

I've also noticed that bug 3028 has been copied into the chroot setup.
The attached patch will fix the issue.

Does anyone think the bind post install scriptlet should add
$AddUnixListenSocket /var/lib/named/dev/log
to /etc/rsyslog.conf ?

I know I missed appending it until I read about in /lib/systemd/system/named.service   :(

(In reply to comment #9)
> Does anyone think the bind post install scriptlet should add
> $AddUnixListenSocket /var/lib/named/dev/log
> to /etc/rsyslog.conf ?
> 
> I know I missed appending it until I read about in
> /lib/systemd/system/named.service   :(

Good point, but instead of modifying /etc/rsyslog.conf, the package
should create a /etc/rsyslog.d/named.conf with that line.

I just fixed the two first issues (pid file path and urandom device minor number), and used %_post_syslogadd %_preun_syslogdel macros to handle syslog management.

The pid path is now correct.

The syslogadd doesn't seem to be working as far as I can see.

The minor node od /var/lib/named/dev/urandom is now correct for
a new install, but won't fix an existing installation.

I'm not sure if that can be fixed in a scriptlet (as it can't
be done while named is running) or if it has to be done in the
setup chroot script.

(In reply to comment #12)

> I'm not sure if that can be fixed in a scriptlet (as it can't
> be done while named is running) or if it has to be done in the
> setup chroot script.

Since bug is not resolved, maybe it is still being tested. 
I assume Test procedure contains update and clean install test steps.  :)

# urpmi --auto bind

    ftp://mirrors.kernel.org/mageia/distrib/cauldron/x86_64/media/core/release/bind-9.9.0-3.mga2.x86_64.rpm
installing bind-9.9.0-3.mga2.x86_64.rpm from /var/cache/urpmi/rpms                                                         
Preparing...                     ####################
      1/1: bind                  ####################
invalid facility '%{2}' at /usr/share/rpm-helper/add-syslog line 40.
warning: %post(bind-9.9.0-3.mga2.x86_64) scriptlet failed, exit status 255



Maybe dev is looking into bug 3836.

Please keep in mind that systemd has already everything needed to do the chroot stuff : http://0pointer.de/blog/projects/changing-roots.html

With bind-9.9.0-4.mga2.src.rpm the syslog file
/etc/rsyslog.d/named.conf looks good.

Deleting the /var/lib/named/dev/urandom when it has
a minor of 8 works when I installed the update in
a chroot.

I still have to test to see if it will work if named
is actually running, or if that will fail with a device
in use.

I'll test that later tonight.

The other problem I see is the addition of yet another
arbitrary timeout, that I see no justification for.

grep Timeout /lib/systemd/system/named.service
TimeoutSec=25

Why is this being added, overriding the existing default
of 90 seconds.

On my real hardware, "time systemctl start named.service" shows
it's taking 17 seconds.  In a virtualbox guest, I expect that
to be at least doubled, so the arbitrary timeout will make the
service unusable in that environment.

I'm using a celeron.  Imagine the poor guy still using a pentium.

(In reply to comment #15)
> With bind-9.9.0-4.mga2.src.rpm the syslog file
> /etc/rsyslog.d/named.conf looks good.

clean install still bites.

# urpmi --auto bind


    ftp://mirrors.kernel.org/mageia/distrib/cauldron/x86_64/media/core/release/bind-9.9.0-3.mga2.x86_64.rpm
installing bind-9.9.0-3.mga2.x86_64.rpm from /var/cache/urpmi/rpms                                                         
Preparing...                     #######################
      1/1: bind                  ########################
invalid facility '%{2}' at /usr/share/rpm-helper/add-syslog line 40.
warning: %post(bind-9.9.0-3.mga2.x86_64) scriptlet failed, exit status 255

(In reply to comment #16)
> (In reply to comment #15)
> > With bind-9.9.0-4.mga2.src.rpm the syslog file
> > /etc/rsyslog.d/named.conf looks good.
  
> ftp://mirrors.kernel.org/mageia/distrib/cauldron/x86_64/media/core/release/bind-9.9.0-3.mga2.x86_64.rpm
> installing bind-9.9.0-3.mga2.x86_64.rpm from /var/cache/urpmi/rpms
                        *

You need to run urpmi.update -a to get 9.9.0-4 or wait
for the mirror to sync.

Btw, kernel.org tends to be slow to sync.  It's ok for stable, but not
really good for testing recent cauldron changes, or qa testing Mageia 1
updates.

For cauldron, I'm currently using ftp://ftp.LinuxCabal.org, and for
Mageia 1, http://twiska.zarb.org

While transfers are slower than kernel.org for North American users,
they sync with Mageia main mirrors more often the kernel.org.

(In reply to comment #18)
> Btw, kernel.org tends to be slow to sync.  It's ok for stable, but not
> really good for testing recent cauldron changes, or qa testing Mageia 1
> updates.

Opps. I had seen I needed to get new index, but did not check what was downloaded.
My bad. New and improved failure follows.

# urpmi --auto bind
    ftp://mirrors.kernel.org/mageia/distrib/cauldron/x86_64/media/core/release/bind-9.9.0-4.mga2.x86_64.rpm
installing bind-9.9.0-4.mga2.x86_64.rpm from /var/cache/urpmi/rpms                                                         
Preparing...                     ################
      1/1: bind                  #################
ls: cannot access /var/lib/named/dev/urandom: No such file or directory
/var/tmp/rpm-tmp.c6OvZ1: line 6: [: -eq: unary operator expected

bind-9.9.0-5.mga2.src.rpm installed with no errors and seems to be working.

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED