Missing chroot for dns/bind9{9,10}?
The removal of BIND from base in stable/10 left us with the option of running BIND from ports either in a jail, or as an ordinary service. The old BIND in base was able to run in a chroot environment, isolated from the rest of the system.
Some of us believe a chroot is a good compromise between running BIND as an unisolated service or in a jail. I personally believe the removal of /etc/namedb
and /var/named
as part of make delete-old
is premature, as most of us would like to continue keeping all BIND related files in /var/named/etc/namedb
.
Harald Schmalzbauer has been kind enough to recreate a chroot environment for dns/bind910
. I guess the same patches can be used for dns/bind99
with some minor tweaking.
Take a look at Harald’s contribution if you feel a jail is too much work for a simple service like DNS.
Here’s what I have discovered and done:
Place the mtree-addition.patch
and named.in_chroot-autochroot.patch
files in /usr/ports
, and run:
cd /usr/ports patch < named.in_chroot-autochroot.patch
If you run stable/10 or above, then you also need this patch:
cd /usr/ports patch < mtree-addition.patch
Subversion may complain about uncommitted local changes to the affected files while synchronising your ports tree. You should revert these changes, and patch the required files again.
Make sure you have good backups of /usr/local/etc/namedb
and /var/named
before running BIND from ports for the first time. If you use ZFS and /var/named
is a ZFS dataset, then the proper use of snapshots along the way gives you the benefit of a online safety net.
Simply add these two lines to /etc/rc.conf
, if you run stable/8, stable/9, stable/10, or head:
named_enable="YES" named_chrootdir="/var/named"
If you run stable/8 or stable/9, then you should probably stick to the BIND in base, but otherwise you need to add a third line to /etc/rc.conf
:
named_program="/usr/local/sbin/named"
If you use ZFS on stable/10 and above, and /usr/local/etc/namedb
is a separate ZFS dataset, then you must:
- move all files away from
/usr/local/etc/namedb
, - destroy the dataset,
- recreate
/usr/local/etc/namedb
as a directory, and - move the files back into place.
On stable/10 and above, the startup script will move all files from /usr/local/etc/namedb
to ${named_chrootdir}/etc/namedb
, and turn /usr/local/etc/namedb
into a symlink pointing to ${named_chrootdir}/etc/namedb
. The latter is the reason for destroying any ZFS dataset mounted at /usr/local/etc/namedb
.