I may be way off base here, but ... I'm rebuilding my firewall system. That system runs a bind DNS server and a DHCP server. I haven't done this for a couple of years, so obviously bind has changed a bit in that time. I expected that. I have to modify named.conf to include the source files for my LAN subnet and forwarder information for my ISP's DNS servers for everything else. However, as installed, the /etc/named.conf from the bind package refers to a whole bunch of files that bind looks for in the /var/lib/named chroot which simply don't exist. And named-checkconf doesn't like this. Examples are a bunch of named.xxx files, such as named.localhost, named.loopback, and so forth which are named in the named.conf as database files backing the various zones defined in named.conf. Among these is named.ca, which is supposed to be the list of root servers. Also, named.conf refers to a logging file with a relative path of data/named.run. Not only does the file not exist, the data directory hasn't been created either. I got this to work eventually by going through my old firewall bind configuration and figuring out a mapping from the names used there to the names used in the new named.conf. But the fact is, all of those files were provided by the bind package I installed when I last built the firewall, and they're not there now. Anybody setting up a bind server ought to know what they're doing, but the package we provide, *whatever* it's configured to do, should at least start the server correctly out-of-the-box for whatever that is. It's not reasonable to require bind users to have to figure out what you really wanted in named.localhost or named.empty. Reproducible: Steps to Reproduce:
Assignee: bugsquad => guillomovitch
[root@test ~]# urpmi bind http://192.168.10.101/distrib/cauldron/x86_64/media/core/release/bind-9.9.2.P1-5.mga3.x86_64.rpm installing bind-9.9.2.P1-5.mga3.x86_64.rpm from /var/cache/urpmi/rpms Preparing... ############################################################################### 1/1: bind ############################################################################### [root@test ~]# systemctl start named.service [root@test ~]# nslookup mageia.org 127.0.0.1 Server: 127.0.0.1 Address: 127.0.0.1#53 Non-authoritative answer: Name: mageia.org Address: 217.70.188.116 Looks like it's working to me.
CC: (none) => davidwhodgins
Could you check your /etc/named.conf, and see if it references a bunch of named.*** files, and if, in fact, they exist ?
Created attachment 3598 [details] Patch for /etc/named.conf While it doesn't seem to stop named from working, the named.conf does specify files that are not found. such as named.localhost. When /lib/systemd/system/named.service runs /usr/sbin/setup-named-chroot.sh, /var/named, which contains named.localhost is bind mounted to /var/lib/named/var/named. As /var/lib/named/etc/named.conf (bind mounted from /etc/named.conf) references file "named.localhost";, named will (as I understand it) be looking for /var/lib/named/named.localhost, not /var/lib/named/var/named/named.localhost. In /etc/named.conf, I think 'file "named.localhost";' should be changed to file "/var/named/named.localhost";
I should have mentioned that the system I'm running this on is at *secure* level. That may account for why named-checkconf is run (and fails because of the missing files) at bind startup, and prevents bind from starting. And, at least in *secure*, the chroot under which "named.localhost" is looked for is /var/lib/named/var/named. That's where I had to put the missing files to pass the named-checkconf tests. If desired, I can attach the files I copied from an older version that got things working. I did make one change to named.conf. As installed from cauldron, named.conf made the localhost zones specific to 127.0.0.1 and 1::0...0... In the older files I copied forward, those zones were opened to 127.0.0.x and 0::0...
The configuration patch won't change much, as file location in bind configuration is computed relatively to the 'directory' directive if not starting with a / character. All the files referenced by the default named configuration files are installed under /var/named (on the actual filesystem), and automatically bind mounted inside the /var/lib/named chroot when running /usr/sbin/setup-named-chroot.sh script. If you run named-checkconf with the -t argument, without actually populating the chroot through the script, a failure is indeed expectable. That's also true for the data directory: it is created by package installation as /var/named/data, and then bind mounted in the chroot when starting the service. This is indeed quite different from previous setup, where all files where actually installed directly within the chroot. I suspect some file upgrade issue in your case, as you're mentionning updating from an earlier version. Or an issue with hardcoded file locations in msec configuration files, as you also mention a specific security level.
Status: NEW => ASSIGNED
(In reply to Guillaume Rousse from comment #5) > > This is indeed quite different from previous setup, where all files where > actually installed directly within the chroot. I suspect some file upgrade > issue in your case, as you're mentionning updating from an earlier version. > Or an issue with hardcoded file locations in msec configuration files, as > you also mention a specific security level. No, there's no update involved. This is a fresh install, but I migrated the database files from an older one, and created the missing files from their older counterparts. The named.service file has: ExecStartPre=/usr/sbin/setup-named-chroot.sh /var/lib/named on ExecStartPre=/usr/sbin/named-checkconf -t /var/lib/named -z /etc/named.conf ExecStart=/usr/sbin/named -u named -t /var/lib/named $OPTIONS That's where the named-checkconf comes from.
Indeed, I missed it. If that's a fresh install, can you check the output of rpm --verify bind ? It should protest about missing files.
I'm not sure about the integrity of this, given that I've supplied the missing files, but : [root@ftgfw ftg]# rpm --verify bind S.5....T. c /etc/named.conf S.5....T. c /etc/rndc.key .....UG.. /var/lib/named/var/named [root@ftgfw ftg]# I can check this in a fresh system if you like. The aim of this exercise is to update a post-install set of scripts which customize the firewall system and several VBox VMs which run on it so that they are pretty much turnkey installs (until the next time package changes break them, anyway :-) ), so I have a few more iterations of starting from scratch to go, and I can easily do tests on a vanilla install before the scripts run.
I just installed it myself on a fresh system, I couldn't reproduce the issue.
Interesting. I'll run a full reinstall tomorrow, but stop before my post-install script. When you say you couldn't reproduce the issue, exactly what is your test case ? I'd assume it's starting bind successfully in a *secure* system profile, but I'd like to be sure we're on the same page here.
As said earlier, if your problem comes from a msec or an installer setting, you'd better report it as an msec or installer bug, as the problem doesn't come from bind package. It's not just "not my problem", rather than I have no clue what they do and how they are configurable.
I re-did the fresh install in a VM. The install itself does not install bind, and both prior to (checked from rescue) and after the first boot, no /var/lib/named directory existed (as expected). I then disabled msec, and installed bind, but did not start it. At that point, /var/lib/named and its subdirectories had been created by the rpm install, but none of the files were present: ******************************************************** [root@localhost ftg]# cd /var/lib/named [root@localhost named]# ls -lR .: total 16 drwxr-xr-x 2 root root 4096 Mar 20 10:16 dev/ drwxr-xr-x 4 root root 4096 Mar 20 10:16 etc/ drwxr-xr-x 3 root root 4096 Mar 20 10:16 usr/ drwxr-xr-x 6 root root 4096 Mar 20 10:16 var/ ./dev: total 0 crw-r--r-- 1 root root 1, 3 Mar 20 10:16 null crw-r--r-- 1 root root 1, 8 Mar 20 10:16 random crw-r--r-- 1 root root 1, 5 Mar 20 10:16 zero ./etc: total 12 -rw-r--r-- 1 root root 3519 Mar 20 10:16 localtime drwxr-xr-x 2 root root 4096 Feb 26 13:16 named/ drwxr-xr-x 3 root root 4096 Mar 20 10:16 pki/ ./etc/named: total 0 ./etc/pki: total 4 drwxr-xr-x 2 root root 4096 Feb 26 13:16 dnssec-keys/ ./etc/pki/dnssec-keys: total 0 ./usr: total 4 drwxr-xr-x 4 root root 4096 Mar 20 10:16 lib64/ ./usr/lib64: total 8 drwxr-xr-x 2 root root 4096 Feb 26 13:16 bind/ drwxr-xr-x 2 root root 4096 Feb 26 13:16 openssl/ ./usr/lib64/bind: total 0 ./usr/lib64/openssl: total 0 ./var: total 16 drwxr-xr-x 2 named named 4096 Feb 26 13:16 log/ drwxr-xr-x 2 root root 4096 Feb 26 13:16 named/ drwxr-xr-x 3 root root 4096 Mar 20 10:16 run/ drwxr-xr-x 2 named named 4096 Feb 26 13:16 tmp/ ./var/log: total 0 ./var/named: total 0 ./var/run: total 4 drwxr-xr-x 2 named named 4096 Feb 26 13:16 named/ ./var/run/named: total 0 ./var/tmp: total 0 [root@localhost named]# ************************************************************* I then started bind, and it started fine. Looking again at /var/lib/named: ************************************************************** [root@localhost named]# ls -lR .: total 16 drwxr-xr-x 2 root root 4096 Mar 20 10:16 dev/ drwxr-xr-x 4 root root 4096 Mar 20 10:30 etc/ drwxr-xr-x 3 root root 4096 Mar 20 10:16 usr/ drwxr-xr-x 6 root root 4096 Mar 20 10:16 var/ ./dev: total 0 crw-r--r-- 1 root root 1, 3 Mar 20 10:16 null crw-r--r-- 1 root root 1, 8 Mar 20 10:16 random crw-r--r-- 1 root root 1, 5 Mar 20 10:16 zero ./etc: total 28 -rw-r--r-- 1 root root 3519 Mar 20 10:16 localtime drwxr-xr-x 2 root root 4096 Feb 26 13:16 named/ -rw-r--r-- 1 root root 1505 Feb 26 13:16 named.conf -rw-r--r-- 1 root named 2389 Feb 26 13:16 named.iscdlv.key -rw-r--r-- 1 root named 487 Feb 26 13:16 named.root.key drwxr-xr-x 3 root root 4096 Mar 20 10:16 pki/ -rw-r----- 1 root named 259 Mar 20 10:16 rndc.key ./etc/named: total 0 ./etc/pki: total 4 drwxr-xr-x 2 root root 4096 Feb 26 13:16 dnssec-keys/ ./etc/pki/dnssec-keys: total 0 ./usr: total 4 drwxr-xr-x 4 root root 4096 Mar 20 10:16 lib64/ ./usr/lib64: total 8 drwxr-xr-x 2 root root 4096 Feb 26 13:16 bind/ drwxr-xr-x 3 root root 4096 Mar 20 09:02 openssl/ ./usr/lib64/bind: total 0 ./usr/lib64/openssl: total 4 drwxr-xr-x 3 root root 4096 Mar 20 09:02 1.0.1e/ ./usr/lib64/openssl/1.0.1e: total 4 drwxr-xr-x 2 root root 4096 Mar 20 09:02 engines/ ./usr/lib64/openssl/1.0.1e/engines: total 312 -rwxr-xr-x 1 root root 20416 Feb 12 02:26 lib4758cca.so* -rwxr-xr-x 1 root root 20680 Feb 12 02:26 libaep.so* -rwxr-xr-x 1 root root 16328 Feb 12 02:26 libatalla.so* -rwxr-xr-x 1 root root 6808 Feb 12 02:26 libcapi.so* -rwxr-xr-x 1 root root 25192 Feb 12 02:26 libchil.so* -rwxr-xr-x 1 root root 24776 Feb 12 02:26 libcswift.so* -rwxr-xr-x 1 root root 6808 Feb 12 02:26 libgmp.so* -rwxr-xr-x 1 root root 103152 Feb 12 02:26 libgost.so* -rwxr-xr-x 1 root root 16232 Feb 12 02:26 libnuron.so* -rwxr-xr-x 1 root root 6808 Feb 12 02:26 libpadlock.so* -rwxr-xr-x 1 root root 24976 Feb 12 02:26 libsureware.so* -rwxr-xr-x 1 root root 20608 Feb 12 02:26 libubsec.so* ./var: total 16 drwxr-xr-x 2 named named 4096 Feb 26 13:16 log/ drwxr-xr-x 5 root root 4096 Mar 20 10:16 named/ drwxr-xr-x 3 root root 4096 Mar 20 10:16 run/ drwxr-xr-x 2 named named 4096 Feb 26 13:16 tmp/ ./var/log: total 0 ./var/named: total 28 drwxr-xr-x 2 named named 4096 Mar 20 10:30 data/ drwxr-xr-x 2 named named 4096 Mar 20 10:30 dynamic/ -rw-r--r-- 1 root root 1892 Feb 26 13:16 named.ca -rw-r--r-- 1 root root 152 Feb 26 13:16 named.empty -rw-r--r-- 1 root root 152 Feb 26 13:16 named.localhost -rw-r--r-- 1 root root 168 Feb 26 13:16 named.loopback drwxr-xr-x 2 named named 4096 Feb 26 13:16 slaves/ ./var/named/data: total 4 -rw-r--r-- 1 named named 1037 Mar 20 10:30 named.run ./var/named/dynamic: total 8 -rw-r--r-- 1 named named 1227 Mar 20 10:30 managed-keys.bind -rw-r--r-- 1 named named 512 Mar 20 10:30 managed-keys.bind.jnl ./var/named/slaves: total 0 ./var/run: total 4 drwxr-xr-x 2 named named 4096 Mar 20 10:30 named/ ./var/run/named: total 8 -rw-r--r-- 1 named named 5 Mar 20 10:30 named.pid -rw------- 1 named named 102 Mar 20 10:30 session.key ./var/tmp: total 0 [root@localhost named]# ************************************************************** and this time: ************************************************************** Mar 20 10:30:01 localhost.localdomain named-checkconf[2919]: zone localhost.localdomain/IN: loaded serial 0 Mar 20 10:30:01 localhost.localdomain named-checkconf[2919]: zone localhost/IN: loaded serial 0 Mar 20 10:30:01 localhost.localdomain named-checkconf[2919]: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 0 Mar 20 10:30:01 localhost.localdomain named-checkconf[2919]: zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0 Mar 20 10:30:01 localhost.localdomain named-checkconf[2919]: zone 0.in-addr.arpa/IN: loaded serial 0 Mar 20 10:30:01 localhost.localdomain named[2925]: starting BIND 9.9.2-P1 -u named -t /var/lib/named ************************************************************** I'm closing this for now as INVALID. I'll re-run the full install with my post-install script as soon as USB keyboards work again, and take it from there if the error recurs. Sorry for the noise.
Status: ASSIGNED => RESOLVEDResolution: (none) => INVALID