Tim:
>> Also, how have you got SELinux set?
Tom Horsley:
> Nah, selinux gets turned off first thing.
I'd recommend using it with any public services. And even on private
networks, where you might have rogue clients.
But I have to ask, did you actually disable it, or just put it into
permissive mode? It's been found that it still does block some things
in permissive mode. I don't recall what the reported /things/ were,
though.
> I didn't have the /var/named/chroot/var/named/data
> directory, but I created it, and I still see it
> writing .jnl files in /var/named/chroot/var/named
I just listed some samples. My main server is still on Fedora Core 4,
though I've dabbled with slave servers on up to Fedora 9, I think.
Looking at my old notes, I'd see error messages like:
dumping master file: tmp-XXXXMkOQYs: open: permission denied
transfer of 'example.com/IN' from 192.168.0.1#53: failed while receiving responses: permission denied
But everything looked like it should be working correctly.
Later I found out that slave records should be written into a slaves
subdirectory. As I recall, there wasn't any instructions about that
*HAVING* to be done.
And I had to change SELinux rule settings, so that the master name
server can change master records, this was necessary as my DHCP server
would update my DNS records, but the default settings disallow that for
security reasons. I seem to recall that there was a later change about
placing dynamic master files in a different directory, as well, somewhat
like how the slaves subdirectory is used.
One thing that gets you while testing is that the server doesn't write
changes to the zone files immediately, it caches things for a few
minutes (15, back in the days I was setting up mine), then writes them.
That way it only does one write every 15 minutes, rather than every time
some details change - which could be a lot on a big LAN.
When I moved from running BIND on Red Hat Linux to Fedora, I had to
change a named.conf setting about allowing updates. It used to be more
allowing, and you could allow things by IP. Later, you had to use a
shared key file (e.g. /etc/rndc.key") as the authenticator.
Some snippets from my /etc/named.conf file:
# Let only the local machine control the server:
controls {
inet 127.0.0.1 allow { localhost; } keys { rndckey; };
};
include "/etc/rndc.key";
zone "example.com" {
type master;
file "example.com.zone";
allow-update { key "rndckey"; };
allow-transfer { 192.168.0/24; };
notify yes;
};
zone "0.168.192.in-addr.arpa" {
type master;
file "0.168.192.in-addr.arpa.zone";
allow-update { key "rndckey"; };
allow-transfer { 192.168.0/24; };
notify yes;
};
This was a chrooted server, and those paths refer to inside the chroot
jail. I had symlinks in the real /etc pointing to the chrooted files,
so that any configuration tools did actually play with the right files.
But, in the end, I gave up on using configuration tools, they were too
limiting, and often broken.
> Maybe I just have a old named.conf file that has
> been ported from one fedora to another for several
> releases and I didn't notice some change made
> to the default directories.
That sort of thing does happen. I tend to customise newer installs by
modifying the configuration files that come with them, rather than
hoping they'll work with an older version's file. I find I have less
problems, that way.
--
[tim@localhost ~]$ uname -r
2.6.27.25-78.2.56.fc9.i686
Don't send private replies to my address, the mailbox is ignored. I
read messages from the public lists.
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
