FreeBSD 7.0-RELEASE-p12 bind9 log files not found
mel.flynn+fbsd.questions at mailing.thruhere.net
Sat May 30 15:36:16 UTC 2009
On Saturday 30 May 2009 17:01:17 Prokofyev Vladislav wrote:
> > The named running chrooted has no clue about /var/named. You can either
> > use ducttape:
> > cd /var/named/var && sudo ln -s .. named
> > or just strip /var/named from your config file, hence use
> > /var/log/xfer.log.
> > --
> > Mel
> This helped, thank you a lot.
> So, if I think in a right way, /usr/sbin/named with -t start option don't
> effect on any symlinks etc.
Erm, yes or ... no. I suggest you read up on chroot.
The short answer is that relative symlinks within the chroot environment work
while absolute ones should take into the account the new filesystem root.
> I didn't pay attention to this cause named(8)
> -t directory
> Chroot to directory after processing the command line arguments,
> but before reading the configuration file.
and have a look at what /etc/namedb really is:
# ls -l /etc/namedb
lrwxr-xr-x 1 root wheel 21 May 21 06:24 /etc/namedb ->
And this demonstrates chroot a bit:
# cp /rescue/ls /var/named/
# chroot /var/named /ls -l /etc/namedb
drwxr-xr-x 2 53 0 512 Feb 28 05:57 dynamic
drwxr-xr-x 2 0 0 512 May 15 13:42 master
-rw-r--r-- 1 0 0 11714 May 15 14:40 named.conf
-rw-r--r-- 1 0 0 2956 May 15 13:42 named.root
-rw------- 1 53 0 97 Apr 18 10:29 rndc.key
drwxr-xr-x 2 53 0 512 May 30 11:21 slave
> Warning: This option should be used in conjunction with the
> -u option, as chrooting a process running as root doesn't
> enhance security on most systems; the way chroot(2) is
> defined allows a process with root privileges to escape a
> chroot jail.
> And I thought that all actions for proper work are made by named :)
They are, you just need reference the right path, the one without /var/named,
or use relative paths where the working directory is /etc/namedb. So one would
get to /var/log using:
More information about the freebsd-questions