Re: DNS/apparmor problem
On Mon, 13 Aug 2012 15:11:58 -0600, Glenn English wrote:
> On Aug 13, 2012, at 10:27 AM, Camaleón wrote:
>> The only thing I can think that can be causing these erros is that by
>> default, and IIRC, Bind9 comes chrooted in Debian
>
> I may be wrong, but I don't think the Debian Bind9 install on lenny is
> chrooted. All its configs are in plain old /etc (the domain files are in
> /var/cache/bind). It's owned and run by user bind, not root, that's
> all...
I may have consufed bind9 with postfix or another server application, but
true is that I remember a usual service that came chrooted as a Debian
default that I had to un-chroot to make it to work with less headaches.
Okay, let's assume then that your Bind9 installation is not being run
inside a jail :-)
>> How does your DNS server configuration look like?
>
> It looks like a mixture of Webmin and vim editing. Would you like it
> (them) posted? I'd be glad to do that if you do. I've already grep'ed
> for apparmor. It found nothing in /etc/bind/*.
AppArmour is not a variable I would take into account unlsss you manually
installed and configured it. Debian does not ship AA by default and even
if so, no profile is enabled so I would discard a problem coming from
here (unless, of course, you did something that trigered the AA
installation which enabled a profile...).
>> Are you using a special
>> setup
>
> Define 'special' :-)
"Special" is a configuration which differs from the default package
install which simply enables a local DNS caching server for the host and
usually works out of the box with no more tweaks :-)
> There are 2 DNS servers on the DMZ. One, non-cacheing, non-recursive,
> limited in the domains it will provide, and running only slave zone
> files, is facing the Internet. The other is wide open and available to
> the LAN and the Internet facing DNS server. All the master zones are on
> the LAN facing server.
Mmm, master, slave and zone transfers between them? If there's any
interelation between both servers it can be indeed an "out of sync"
timing issue (remember the error started with "refresh:" operation).
Are the time of both servers accurately set (e.g., by means of nntpd)?
>> or did you recently changed something on your side?
>
> Not that I can remember.
>
> I edited the AppArmor profile file, but after the errors.
Uh? What AA profile? :-?
> It said, as best I understand it, that everything in /etc/bind was read
> only by the owner. I changed that to rw (because there was a write
> problem and I thought I'd try something trivial), and the errors seem
> to have stopped (or maybe they just haven't started yet today). That
> makes very little sense to me because the files complained about in the
> logs weren't in /etc/bind.
Mmm... AA should be unexistant in your system and of course no service
should up and running (if AA is not started, profles are not read and
thus not executed, or at least that's how it was at the times I was using
openSUSE which had enabled AA by default with some profiles "on").
> If you, or anyone else, has any idea how AppArmor, nary a byte of whose
> executables are on the machine, can have any effect whatsoever, I'd sure
> like to know about it. I hesitate to simply delete the profile file
> because I don't understand yet what's going on -- something put it there
> and is using it somehow...
Well, that's of course something you should discover as soon as possible.
AA can be very useful but of course it has to be fine tweaked before
because it can cause services from working properly.
> BTW, /etc/apparmor.d/use.sbin.named is the only AppArmor file of any
> kind I can find on the machine.
Weird but I'd say harmless unless AA is running. Anyway, time to run
"locate apparmor", juts in case... :-)
Greetings,
--
Camaleón
Reply to: