> On Feb 22, 2016, at 1:59 PM, Reco <[email protected]> wrote: > > No, that's not how you check it. Every Debian system has those records. > I meant something like 'ls -alZ /'.
drwxr-xr-x 25 root root ? 4096 Jun 6 2014 . drwxr-xr-x 25 root root ? 4096 Jun 6 2014 .. drwxr-xr-x 2 root root ? 4096 Feb 19 10:26 bin drwxr-xr-x 3 root root ? 4096 Jan 7 21:40 boot drwxr-xr-x 14 root root ? 3380 Feb 22 02:34 dev drwxr-xr-x 127 root root ? 12288 Feb 22 14:12 etc drwxr-xr-x 3 root root ? 4096 Aug 31 00:42 home lrwxrwxrwx 1 root root ? 30 Oct 11 2013 initrd.img -> /boot/initrd.img-3.2.0-4-amd64 drwxr-xr-x 15 root root ? 4096 Mar 17 2014 lib drwxr-xr-x 2 root root ? 4096 Feb 17 07:36 lib64 drwx------ 2 root root ? 16384 Oct 11 2013 lost+found drwxr-xr-x 3 root root ? 4096 Oct 11 2013 media drwxr-xr-x 2 root root ? 4096 Jun 2 2013 mnt drwxr-xr-x 2 root root ? 4096 Oct 11 2013 opt dr-xr-xr-x 149 root root ? 0 Feb 22 02:33 proc drwxr-xr-x 3 root root ? 4096 Jun 6 2014 project drwx------ 23 root root ? 4096 Feb 21 20:24 root drwxr-xr-x 22 root root ? 960 Feb 22 14:12 run drwxr-xr-x 2 root root ? 4096 Feb 22 14:12 sbin drwxr-xr-x 2 root root ? 4096 Jun 10 2012 selinux drwxr-xr-x 3 root root ? 4096 Oct 11 2013 srv drwxr-xr-x 13 root root ? 0 Feb 22 02:34 sys drwxrwxrwx 4 nobody nogroup ? 4096 Apr 2 2014 tftpboot drwxrwxrwt 7 root root ? 4096 Feb 22 14:17 tmp drwxr-xr-x 11 root root ? 4096 Oct 11 2013 usr drwxr-xr-x 14 root root ? 4096 Feb 8 2014 var lrwxrwxrwx 1 root root ? 26 Oct 11 2013 vmlinuz -> boot/vmlinuz-3.2.0-4-amd64 > First, what does contents of /etc/default/bind9 look like? # run resolvconf? RESOLVCONF=yes # startup options for the server ### OPTIONS="-u bind" OPTIONS=" -4 -u bind" > Second, can you install auditd please Selecting previously unselected package auditd. (Reading database ... 72472 files and directories currently installed.) Unpacking auditd (from .../auditd_1%3a1.7.18-1.1_amd64.deb) ... Processing triggers for man-db ... Setting up auditd (1:1.7.18-1.1) ... > and run > 'auditctl -w /var/cache/bind/slaves/ -p wa' afterward? > A contents of /var/log/audit/audit.log type=DAEMON_START msg=audit(1456174952.726:9009): auditd start, ver=1.7.18 format=raw kernel=3.2.0-4-amd64 auid=4294967295 pid=18137 res=success type=CONFIG_CHANGE msg=audit(1456174952.825:2): audit_backlog_limit=320 old=64 auid=4294967295 ses=4294967295 res=1 type=LOGIN msg=audit(1456174953.225:3): login pid=18158 uid=0 old auid=4294967295 new auid=118 old ses=4294967295 new ses=1 type=LOGIN msg=audit(1456174953.301:4): login pid=18183 uid=0 old auid=4294967295 new auid=118 old ses=4294967295 new ses=2 type=LOGIN msg=audit(1456174981.336:5): login pid=18250 uid=0 old auid=4294967295 new auid=1 old ses=4294967295 new ses=3 type=CONFIG_CHANGE msg=audit(1456174992.612:6): auid=4294967295 ses=4294967295 op="add rule" key=(null) list=4 res=1 > it would be also required for > bind to fail to dump a zone at least once. I hadn't read that part until after I ran auditctl. I think there'd been several failed dumps before then, so I looked at the logs in hopes of giving you proof, but auditctl kept saying "Error sending add rule data request (Rule exists)". So I uninstalled --purge'ed it (and deleted it's log) and reinstalled it and ran 'date ; auditctl -w /var/cache/bind/slaves/ -p wa'. That printed the date and nothing else. I ran auditctl again, by itself, and it repeated the error statement. The logs say there have been many dump failures, so I'm pretty sure auditctl was run after a failed dump. I can't prove it, though. -- Glenn English
