It looks like a screw-up when parsing /etc/named,conf because its
complaining about a mal-formed shell script comparison.
Am 15.06.2023 um 17:39:47 Uhr schrieb Martin Gregorie:
It looks like a screw-up when parsing /etc/named,conf because its
complaining about a mal-formed shell script comparison.
Please post the exact error message.
zone "7.168.192.in-addr.arpa." /* in */^^^^^^^^^^^^^^^^^^^^^^^^^^
{
type primary;
file "named.gregorie.lan";
Martin Gregorie <martin@mydomain.invalid> writes:
zone "7.168.192.in-addr.arpa." /* in */^^^^^^^^^^^^^^^^^^^^^^^^^^
{
type primary;
file "named.gregorie.lan";
Does this file exist and if so what is its full path?
Yes it does: its full path name is /var/named/gregorie.lan.zone and
you'll see that in /etc/named.conf that 'directory' is defined as
/var/named and the zone file 'gregorie.lan' is referred to as 'gregorie.lan.zone'
On Sun, 18 Jun 2023 11:54:15 +0100, Richard Kettlewell wrote:
Martin Gregorie <martin@mydomain.invalid> writes:
zone "7.168.192.in-addr.arpa." /* in */^^^^^^^^^^^^^^^^^^^^^^^^^^
{
type primary;
file "named.gregorie.lan";
Does this file exist and if so what is its full path?
Yes it does: its full path name is /var/named/gregorie.lan.zone and you'll see that in /etc/named.conf that 'directory' is defined as /var/named and
the zone file 'gregorie.lan' is referred to as 'gregorie.lan.zone'
On Sat, 17 Jun 2023 11:05:31 +0200, Marco Moock wrote:
Am 15.06.2023 um 17:39:47 Uhr schrieb Martin Gregorie:
It looks like a screw-up when parsing /etc/named,conf because its
complaining about a mal-formed shell script comparison.
Please post the exact error message.
Here's whar I found:
[...]
Jun 14 20:49:51 zoogz.gregorie.lan bash[2334682]: zone 7.168.192.in- addr.arpa/IN: not loaded due to errors.
Jun 14 20:49:51 zoogz.gregorie.lan bash[2334682]: _default/7.168.192.in- addr.arpa./IN: file not found
[...]
The really odd thing about this is tha filename being objected to, _default/7.168.192.in-addr.arpa./IN is not mentioned in either named.conf
or the zone file, gregorie.lan.zone
[...]
// We are the primary server for gregorie.lan
zone "gregorie.lan"
{
type primary;
file "gregorie.lan.zone";
notify yes;
};
zone "7.168.192.in-addr.arpa." /* in */
{
type primary;
file "named.gregorie.lan";
};
[...]
----------------------------------------------------
Here's the zone file
====================================================
; Base zone file for gregorie.lan
$TTL 3h
$ORIGIN gregorie.lan
@ IN SOA zoogz.gregorie.lan. zoogz.gregorie.lan.
(
2002040300 ; serial
3h ; refresh
15m ; update retry
1w ; expiry
1h ; minimum
)
; Nameserver for the domain
IN NS zoogz.gregorie.lan.
; Mailserver for the domain
3w IN MX 10 zoogz.gregorie.lan.
hellsgate IN A 192.168.7.1
zoogz IN A 192.168.7.2
cretin IN A 192.168.7.3
pc IN A 192.168.7.4
zappa IN A 192.168.7.5
touch IN A 192.168.7.100
rpi IN A 192.168.7.101
lj5 IN A 192.168.7.201
Firstly, I see your post was made on Saturday evening. So it's possible
you might have solved it by now. If so, please post and say so, in order
that people don't expend time composing suggestions if they are no
longer needed.
Firstly, I see your post was made on Saturday evening. So it's possible
you might have solved it by now. If so, please post and say so, in order
that people don't expend time composing suggestions if they are no
longer needed.
If the problem is still unresolved, happy to help.
On Mon, 19 Jun 2023 11:20:29 +0000 (UTC), Tony Mountifield wrote:
Firstly, I see your post was made on Saturday evening. So it's possible
you might have solved it by now. If so, please post and say so, in order that people don't expend time composing suggestions if they are no
longer needed.
If the problem is still unresolved, happy to help.
Its still grinding along, I'm afraid. Here's the latest state of play. Apologies for its size,
but at least I've turned off lie wrapping, so it should be a bit more legible. There seen to be
two issues
(1) there's a syntactic problem in the 'start' script used by systemd to launch named
(2) there may still be a missing "_default/Zone file" but here I'm baffled since the
currently published version of the official named manual does not include and references to
either '_default' or 'default' in any context including as oart of a zone file name.
Avyway, here's what I've seen:
Here are my latest test results: thanks to you guys for your help so far. =========================================================================
As you can see, named-checkconf says
the configuration is fine:
$ sudo named-checkconf -l
0.0.127.in-addr.arpa IN _default primary
gregorie.lan IN _default primary
localhost.localdomain IN _default primary
localhost IN _default primary 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 _default primary
1.0.0.127.in-addr.arpa IN _default primary
0.in-addr.arpa IN _default primary
**** and here's what the items it thinks are significant ****
$ sudo named-checkconf -p
logging {
channel "debug" {
file "data/named.run";
};
};
options {
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
geoip-directory "/usr/share/GeoIP";
listen-on port 53 {
127.0.0.0/24;
192.168.7.0/24;
!82.71.205.14/32;
};
listen-on-v6 port 53 {
"none";
};
managed-keys-directory "/var/named/dynamic";
memstatistics-file "/var/named/data/named_mem_stats.txt";
pid-file "/run/named/named.pid";
session-keyfile "/run/named/session.key";
statistics-file "/var/named/data/named_stats.txt";
disable-algorithms "." {
"RSAMD5";
"DSA";
};
disable-ds-digests "." {
"GOST";
};
dnssec-validation yes;
recursion no;
allow-query {
192.168.7.0/24;
};
};
trust-anchors {
"." initial-ds 20326 8 2 "E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D";
};
zone "0.0.127.in-addr.arpa" {
type primary;
file "localhost.rev";
notify no;
};
zone "gregorie.lan" IN {
type primary;
file "gregorie.lan";
notify yes;
};
zone "localhost.localdomain" IN {
type primary;
file "named.localhost";
allow-update {
"none";
};
};
zone "localhost" IN {
type primary;
file "named.localhost";
allow-update {
"none";
};
};
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 {
type primary;
file "named.loopback";
allow-update {
"none";
};
};
zone "1.0.0.127.in-addr.arpa" IN {
type primary;
file "named.loopback";
allow-update {
"none";
};
};
zone "0.in-addr.arpa" IN {
type primary;
file "named.empty";
allow-update {
"none";
};
};
========================================
Here's what happens I try to start named
with the 'named' systemd service:
========================================
$ sudo systemctl start named
Job for named.service failed because the control process exited with error code.
See "systemctl status named.service" and "journalctl -xeu named.service" for details.
*******
and notice that the preceeding bash command appears to be missing a closing double
quote, which is what I suspect is causing the 'systemctl 'start named' command to
fail.
*******
*******
Here's what 'systemctl status named' has to say about the failure to start *******
$ sudo systemctl status named
× named.service - Berkeley Internet Name Domain (DNS)
Loaded: loaded (/usr/lib/systemd/system/named.service; enabled; preset: disabled)
Active: failed (Result: exit-code) since Tue 2023-06-20 17:37:45 BST; 17s ago
Process: 812270 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/bin/named-checkconf -z "$NAM>
CPU: 11ms
17:37:45 zoogz.gregorie.lan bash[812271]: zone gregorie.lan/IN: not loaded due to errors.
Jun 20 17:37:45 zoogz.gregorie.lan bash[812271]: _default/gregorie.lan/IN: file not found
Jun 20 17:37:45 zoogz.gregorie.lan bash[812271]: zone localhost.localdomain/IN: loaded serial 0
Jun 20 17:37:45 zoogz.gregorie.lan bash[812271]: zone localhost/IN: loaded serial 0
Jun 20 17:37:45 zoogz.gregorie.lan bash[812271]: 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/I>
Jun 20 17:37:45 zoogz.gregorie.lan bash[812271]: zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0
Jun 20 17:37:45 zoogz.gregorie.lan bash[812271]: zone 0.in-addr.arpa/IN: loaded serial 0
Jun 20 17:37:45 zoogz.gregorie.lan systemd[1]: named.service: Control process exited, code=exited, status=1/FAILURE
Jun 20 17:37:45 zoogz.gregorie.lan systemd[1]: named.service: Failed with result 'exit-code'.
Jun 20 17:37:45 zoogz.gregorie.lan systemd[1]: Failed to start named.service - Berkeley Internet Name Domain (DNS).
$
*******
As I've said before, I'm totally baffled why this version of named should barf when fed a
configuration that is passed as error free by named-checkconf and yes, before you ask,
named-checkconf says its version 9.18.15: the same as the named version I'm running.
However, The current named online BIND manual version is:
BIND 9 Administrator Reference Manual
Release 9.19.13-dev
which doesn't have *any* references to '_default' at all, or as part of
zone file names of of any names similar to "_default/gregorie.lan/IN"
If I run my current copy of named with the -v option its reports:
"BIND 9.18.15 (Extended Support Version) <id:"
and is using as its default paths:
named configuration: /etc/named.conf
rndc configuration: /etc/rndc.conf
DNSSEC root key: /etc/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
geoip-directory: /usr/share/GeoIP
...though it seems a bit odd to publish a manual for version
9.19.3 as 'current' when a fairly cutting edge Linux version
like Fedora 37 is still on 9.18.15
--
Martin | martin at
Gregorie | gregorie dot org
On Mon, 19 Jun 2023 11:20:29 +0000 (UTC), Tony Mountifield wrote:
Firstly, I see your post was made on Saturday evening. So it's possible
you might have solved it by now. If so, please post and say so, in order that people don't expend time composing suggestions if they are no
longer needed.
If the problem is still unresolved, happy to help.
Its still grinding along, I'm afraid. Here's the latest state of play. Apologies for its size,
but at least I've turned off lie wrapping, so it should be a bit more legible. There seen to be
two issues
options {...
directory "/var/named";
Jun 20 17:37:45 zoogz.gregorie.lan bash[812271]: zone gregorie.lan/IN: not loaded due to errors....
Jun 20 17:37:45 zoogz.gregorie.lan bash[812271]: _default/gregorie.lan/IN: file not found
However, The current named online BIND manual version is:
BIND 9 Administrator Reference Manual
Release 9.19.13-dev
which doesn't have *any* references to '_default' at all, or as part of
zone file names of of any names similar to "_default/gregorie.lan/IN"
zone "gregorie.lan" IN {
type primary;
file "gregorie.lan";
notify yes;
};
zone "gregorie.lan" IN {
type primary;
file "/etc/named/gregorie.lan";
notify yes;
};
[...]
17:37:45 zoogz.gregorie.lan bash[812271]: zone gregorie.lan/IN: not loaded due to errors.
Jun 20 17:37:45 zoogz.gregorie.lan bash[812271]: _default/gregorie.lan/IN: file not found
On Mon, 19 Jun 2023 11:20:29 +0000 (UTC), Tony Mountifield wrote:
Firstly, I see your post was made on Saturday evening. So it's possibleIts still grinding along, I'm afraid. Here's the latest state of play. Apologies for its size,
you might have solved it by now. If so, please post and say so, in order
that people don't expend time composing suggestions if they are no
longer needed.
If the problem is still unresolved, happy to help.
but at least I've turned off lie wrapping, so it should be a bit more legible. There seen to be
two issues
(1) there's a syntactic problem in the 'start' script used by systemd to launch named
zone "gregorie.lan" IN {
type primary;
file "gregorie.lan";
notify yes;
};
Martin Gregorie <martin@mydomain.invalid> wrote:grammar
options {...
directory "/var/named";
Jun 20 17:37:45 zoogz.gregorie.lan bash[812271]: zone gregorie.lan/IN:...
not loaded due to errors.
Jun 20 17:37:45 zoogz.gregorie.lan bash[812271]:
_default/gregorie.lan/IN: file not found
However, The current named online BIND manual version is:
BIND 9 Administrator Reference Manual Release 9.19.13-dev
which doesn't have *any* references to '_default' at all, or as part of
zone file names of of any names similar to "_default/gregorie.lan/IN"
According to: https://bind9.readthedocs.io/en/stable/reference.html#options-block-
<quote>
directory
Grammar: directory <quoted_string>;
Blocks: options Tags: server
Sets the server’s working directory.
This sets the working directory of the server. Any non-absolute pathnames in the configuration file are taken as relative to this
directory.
The default location for most server output files (e.g., named.run) is
this directory. If a directory is not specified, the working directory defaults to ".", the directory from which the server was started. The directory specified should be an absolute path, and must be writable by
the effective user ID of the named process.
The option takes effect only at the time that the configuration
option
is parsed; if other files are being included before or after specifying
the new directory, the directory option must be listed before any other directive (like include) that can work with relative files. The safest
way to include files is to use absolute file names.
</quote>
Are your config files in /var/named, ie /var/named/gregorie.lan or are
they in /etc? Or symlinks from one to the other?
I think it's somehow not finding the zone files. What if you change:
zone "gregorie.lan" IN {
type primary;
file "gregorie.lan";
notify yes;
};
to:
zone "gregorie.lan" IN {
type primary;
file "/etc/named/gregorie.lan";
notify yes;
};
if that is the correct path for it?
I'm wondering if, in the absence of any config to the contrary, running
named as a different user, or with some flags that override the options, causes the config location to change (eg maybe _default is used in the complete lack of any setting)?
In article <u6sqma$2e3d3$1@dont-email.me>,
Martin Gregorie <martin@mydomain.invalid> wrote:
[...]
17:37:45 zoogz.gregorie.lan bash[812271]: zone gregorie.lan/IN: not
loaded due to errors.
Jun 20 17:37:45 zoogz.gregorie.lan bash[812271]:
_default/gregorie.lan/IN: file not found
I've had a look at a bit of the Bind source code. I think that when it
says _default/gregorie.lan/IN, that is NOT a filename, but rather a name
of a view.
It seems to be reporting the internal view for which it could not load
the zone file, but without actually reporting the name of the file that failed.
It is possible to have multiple views set up within Bind, so that
different views can be served to different networks or clients, but if
you don't set up any views, as most setups don't need to, it seems that
all the zones are added to an internal view called _default. So it's a
bit of a red herring.
See my other post too, offering to take a look.
In article <u6sqma$2e3d3$1@dont-email.me>,
Martin Gregorie <martin@mydomain.invalid> wrote:
On Mon, 19 Jun 2023 11:20:29 +0000 (UTC), Tony Mountifield wrote:
Firstly, I see your post was made on Saturday evening. So it'sIts still grinding along, I'm afraid. Here's the latest state of play.
possible you might have solved it by now. If so, please post and say
so, in order that people don't expend time composing suggestions if
they are no longer needed.
If the problem is still unresolved, happy to help.
Apologies for its size, but at least I've turned off lie wrapping, so
it should be a bit more legible. There seen to be two issues
One more possibility: Do you have a directory called /var/named/chroot?
Martin Gregorie <martin@mydomain.invalid> writes:
On Mon, 19 Jun 2023 11:20:29 +0000 (UTC), Tony Mountifield wrote:
Firstly, I see your post was made on Saturday evening. So it'sIts still grinding along, I'm afraid. Here's the latest state of play.
possible you might have solved it by now. If so, please post and say
so, in order that people don't expend time composing suggestions if
they are no longer needed.
If the problem is still unresolved, happy to help.
Apologies for its size, but at least I've turned off lie wrapping, so
it should be a bit more legible. There seen to be two issues
(1) there's a syntactic problem in the 'start' script used by systemd
to launch named
I don’t see any evidence for that. It’s quoting a bit of shell script in the logs, but it’s obviously managing to run named-checkconf, since that’s what’s producing the rest of the log messages.
zone "gregorie.lan" IN {
type primary;
file "gregorie.lan";
notify yes;
};
Your previous posts have shown considerable confusion about what the
zone files are actually called (and the details seem to have varied over time). I suspect that’s the root of the problem.
With that in mind, what’s the output from:
ls -l /var/named
On Tue, 20 Jun 2023 23:49:37 +0100, Richard Kettlewell wrote:
I don’t see any evidence for that. It’s quoting a bit of shell scriptIts hadr to see: I've previously missed it too. In the following (grabbed from the "systemttl status named" output) look at the last line:
in the logs, but it’s obviously managing to run named-checkconf,
since that’s what’s producing the rest of the log messages.
Process: 812270 ExecStartPre=/bin/bash -c if [ !
"$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/bin/named-checkconf -z
"$NAM>
The double quote at the start of that line should be matched by one
between '$NAM' and '>'. Its absence crashes the bash script before it
tries to launch named. I've double checked by inspecting the "systemctl status" output and its missing there too.
Look out for that tomorrow.
On Wed, 21 Jun 2023 00:14:27 -0000 (UTC), Martin Gregorie wrote:
Look out for that tomorrow.
Here's the current contents of /var/named:
# sudo ls -l /var/named
total 32
-rw-r--r--. 1 root root 698 Jun 20 14:28 7.168.192.in-addr.arpa.zone drwxrwx---. 1 named named 162 Jun 18 00:00 data
drwxrwx---. 1 named named 76 May 18 19:59 dynamic
-rw-r--r--. 1 root root 620 Jun 14 20:47 gregorie.lan.zone
-rw-r--r--. 1 root root 604 Jun 14 19:38 gregorie.lan.zone.unmodded -rw-r-----. 1 root named 3312 May 18 20:00 named.ca
-rw-r-----. 1 root named 152 May 18 20:00 named.empty
-rw-r--r--. 1 root root 469 Jun 19 11:58 named.gregorie.lan
-rw-r-----. 1 root named 152 May 18 20:00 named.localhost
-rw-r-----. 1 root named 168 May 18 20:00 named.loopback
drwxrwx---. 1 named named 0 May 18 19:59 slaves
The gregorie.lan.zone.unmodded should be ignored.
zone "gregorie.lan" IN {
type primary;
file "gregorie.lan";
notify yes;
};
On Tue, 20 Jun 2023 22:03:04 +0000 (UTC), Tony Mountifield wrote:
In article <u6sqma$2e3d3$1@dont-email.me>,I'll have a look tomorrow (FWIW,without named running nothing on my LAN
Martin Gregorie <martin@mydomain.invalid> wrote:
On Mon, 19 Jun 2023 11:20:29 +0000 (UTC), Tony Mountifield wrote:
Firstly, I see your post was made on Saturday evening. So it'sIts still grinding along, I'm afraid. Here's the latest state of play.
possible you might have solved it by now. If so, please post and say
so, in order that people don't expend time composing suggestions if
they are no longer needed.
If the problem is still unresolved, happy to help.
Apologies for its size, but at least I've turned off lie wrapping, so
it should be a bit more legible. There seen to be two issues
One more possibility: Do you have a directory called /var/named/chroot?
can talk to its peers, so I'm handling NNTP from a laptop downstairs and running named on my house server upstairs and (when I must) moving files between them on an SD card. Works, but id definitely not the quickest way
of doing stuff.
Here's the current contents of /var/named:
# sudo ls -l /var/named
total 32
-rw-r--r--. 1 root root 698 Jun 20 14:28 7.168.192.in-addr.arpa.zone drwxrwx---. 1 named named 162 Jun 18 00:00 data
drwxrwx---. 1 named named 76 May 18 19:59 dynamic
-rw-r--r--. 1 root root 620 Jun 14 20:47 gregorie.lan.zone
-rw-r--r--. 1 root root 604 Jun 14 19:38 gregorie.lan.zone.unmodded -rw-r-----. 1 root named 3312 May 18 20:00 named.ca
-rw-r-----. 1 root named 152 May 18 20:00 named.empty
-rw-r--r--. 1 root root 469 Jun 19 11:58 named.gregorie.lan
-rw-r-----. 1 root named 152 May 18 20:00 named.localhost
-rw-r-----. 1 root named 168 May 18 20:00 named.loopback
drwxrwx---. 1 named named 0 May 18 19:59 slaves
The gregorie.lan.zone.unmodded should be ignored.
zone "gregorie.lan" IN {
type primary;
file "gregorie.lan";
notify yes;
};
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 10:04:20 |
| Calls: | 10,389 |
| Calls today: | 4 |
| Files: | 14,061 |
| Messages: | 6,416,850 |
| Posted today: | 1 |