> On Jan 20, 2019, at 5:42 AM, Mathieu Arnold <m...@freebsd.org> wrote: > > On Sat, Jan 19, 2019 at 07:50:45PM -0500, Dan Langille wrote: >> Mat, >> >> I encountered an odd situation where my stats file kept changing >> permissions. With every reinstall of bind911, >> the permissions on var/run/named/stats change to chown root:bind which >> prevents bind from updating the file. >> >> This is what I need: >> >> $ ls -l /var/run/named/stats >> -rw-r--r-- 1 bind bind 11507 Jan 20 00:45 /var/run/named/stats >> >> Could that change be carried out by this file? >> >> >> https://svnweb.freebsd.org/ports/head/dns/bind911/files/BIND.chroot.dist?view=markup#l24 >> >> I don't see a reference to /var/run/named/stats in BIND.chroot.dist but >> can't help but wonder if it's something similar. >> >> I have been using these options: >> >> directory "/usr/local/etc/namedb/working"; >> pid-file "/var/run/named/pid"; >> dump-file "/var/dump/named_dump.db"; >> statistics-file "/var/run/named/stats"; >> zone-statistics yes; >> >> When researching this tonight, I noticed the sample configuration uses >> /var/run/named.stats. Perhaps I'm doing this wrong. >> I am happy to change my configuration, but first I write in case the script >> is doing something unexpected. > > I do not think anything in the BIND9 ports would change the file permissions. > > The mtree file only touches the directories to make sure they have the > correct permissions, so it is not it. Moreover the mtree file is ONLY > used when using named_chrootdir to chroot named, which does not appear > to be your case. > The BIND9 ports have not had a pkg-install script for years, so it's not > it either. > The rc file does not chown anything, so it's not it doing it either. > > Side note, the sample configuration uses /var/stats/named.stats, not > /var/run/named.stats. And it was ever since it was added to the base > system named.conf file back in 2004 (in src r135918).
Noted. Thank you. > So I'd say something else on your system "fixes" the file's permissions. It seems to be upon system start up. I did a test in a jail. # From the host, verify the file in the jail exists: [dan@knew:~] $ ls -l /iocage/jails/toiler/root/var/run/named/stats -rw-r--r-- 1 bind bind 1 Jan 20 16:30 /iocage/jails/toiler/root/var/run/named/stats [dan@knew:~] $ sudo iocage stop toiler * Stopping toiler + Running prestop OK + Stopping services OK + Refusing to remove protected devfs_ruleset: 7 + Removing jail process OK + Running poststop OK [dan@knew:~] $ ls -l /iocage/jails/toiler/root/var/run/named/stats -rw-r--r-- 1 bind bind 1 Jan 20 16:30 /iocage/jails/toiler/root/var/run/named/stats [dan@knew:~] $ sudo iocage start toiler * Starting toiler + Started OK + Using devfs_ruleset: 7 + Starting services OK [dan@knew:~] $ ls -l /iocage/jails/toiler/root/var/run/named/stats ls: /iocage/jails/toiler/root/var/run/named/stats: No such file or directory [dan@knew:~] $ The file soon gets created: [dan@knew:~] $ ls -l /iocage/jails/toiler/root/var/run/named/stats -rw-r--r-- 1 root bind 1 Jan 20 16:35 /iocage/jails/toiler/root/var/run/named/stats Presumably by this: 20-Jan-2019 16:35:12.819 received control channel command 'stats' 20-Jan-2019 16:35:12.819 could not open statistics dump file '/var/run/named/stats': permission denied 20-Jan-2019 16:35:12.819 dumpstats failed: permission denied I will keep looking. Thank you. -- Dan Langille - BSDCan / PGCon d...@langille.org
signature.asc
Description: Message signed with OpenPGP
