Re: BIND problem
> On Feb 22, 2016, at 1:59 PM, Reco <recoverym4n@gmail.com> 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
Reply to: