After upgrade from 15.3 to 15.4 DNS failure (also occurs with 15.3 Package update and 15.3 to 15.5 upgrade)

English Install/Boot/Login
1

My apologies that this is going to be a long winded post. It may not provide exactly what you need, but please be patient. My hope is that the solution to this issue is going to be simple, but I am prepared for the worst.

I have a caching DNS setup on my system for my home network. My system also does IPV4 NAT for my network among other things. It has been working perfectly for probably 10+ years. When I upgraded from Leap 15.3 to Leap 15.4, all DNS queries from my pcs in my home network fail. On the Leap system itself, only some queries fail, for instance, the queries (done through Firefox) for search.opensuse.org succeed, but the query for bing.com fails.

Prior to this, I also upgraded to 15.5 from 15.3, and the same thing happens. (After reading the upgrade instructions, I found out jumping a release is not recommended, so I restored an image backup for 15.3 and went back to upgrading from 15.3 to 15.4 thinking the the jump over 15.4 might be the problem.)

With 15.4, though I cannot make any DNS queries from PCs (all Windows 10 PCs) in my network, I can ping the IP address of www.yahoo.com - 74.6.143.26 with no problem from these same PCs, so my assumption is that NAT is still working without problems. Also, I have a samba server with file shares setup on the Leap system, and I am able to access these shares from the windows PC in my network without problems.

Having missed the upgrade instruction (yes, I know, my bad) to install the latest updates for 15.3, I restored an image backup, then applied the latest, for my Leap 15.3 system, patches, and the same thing happens.

I am primarily a windows person with well over 20-years of experience professionally programming windows applications some of which are very complicated (FEA for instance), and I have managed over the years to find my way through getting this linux system to do what I wanted including resolving problems with the kind help from the community.

It seems to me that there is something in my current list of patches that is causing the problem (it makes sense to me given that after applying the patches DNS is broken) and I hope that someone or someones in the community will be able to help me figure out what it is and submit a bug report - if its not, somehow, my configuration.

Unfortunately, I did not find a means to export just the “needed patches” from the YaST online update app, so I’ll be brief and type them out. Note that I applied all of the patches I am listing here.

The following are security updates:

  1. xorg-x11-server
  2. wireshark
  3. tiff
  4. samba
  5. java-1_8_0-openjdk
  6. ceph
  7. busybox
  8. MozillaFirefox

The following are recommended updates:

  1. yast2-bootloader
  2. yast2 packages
  3. tar
  4. sudo
  5. rsyslog
  6. openssh
  7. libxslt
  8. libteam
  9. hplip
  10. gnutls
  11. avahi

The following is an optional update

  1. wicked

Obviously, I know that not all of these would be causing the problem. However, if someone is willing to be patient with me, I am willing to go through trying to figure out what is causing the problem. Please note that if you need more information, I am willing to provide it, and I do know “enough about Linux to be dangerous”, but I am far from a Linux expert - so I may need to ask for clarification on some things.

I have an image backup for the 15.4 system that is not working, and I am able to easily apply any or all patches and make an image backup of the result for debugging - while maintaining an image backup of my working 15.3 system for obvious reasons.

If anyone has an idea of which of these updates might be the best place to start looking for the cause of the issue, I would be grateful for the help.

To summarize, DNS queries from other PCs in my NAT’d network fail and only some DNS queries on the Leap system succeed after applying the above list of updates and upgrading from Leap 15.3 to either Leap 15.4 or Leap 15.5

Thanks in advance for your help and your patience.

2

Show

ls -l /etc/resolv.conf
cat /etc/resolv.conf
1 Like
3

Thank you so much for your reply.

At the risk of providing too much information, I am providing output of each command for the working, patched and not working, and 15.4 not working configurations.

These are from the working 15.3 system

lrwxrwxrwx 1 root root 30 Feb 27  2021 /etc/resolv.conf -> /var/run/netconfig/resolv.conf

### /etc/resolv.conf is a symlink to /run/netconfig/resolv.conf
### autogenerated by netconfig!
#
# Before you change this file manually, consider to define the
# static DNS configuration using the following variables in the
# /etc/sysconfig/network/config file:
#     NETCONFIG_DNS_STATIC_SEARCHLIST
#     NETCONFIG_DNS_STATIC_SERVERS
#     NETCONFIG_DNS_FORWARDER
# or disable DNS configuration updates via netconfig by setting:
#     NETCONFIG_DNS_POLICY=''
#
# See also the netconfig(8) manual page and other documentation.
#
### Call "netconfig update -f" to force adjusting of /etc/resolv.conf.
nameserver 127.0.0.1

These are from the patched, but not working, 15.3 system

lrwxrwxrwx 1 root root 30 Feb 27  2021 /etc/resolv.conf -> /var/run/netconfig/resolv.conf

### /etc/resolv.conf is a symlink to /run/netconfig/resolv.conf
### autogenerated by netconfig!
#
# Before you change this file manually, consider to define the
# static DNS configuration using the following variables in the
# /etc/sysconfig/network/config file:
#     NETCONFIG_DNS_STATIC_SEARCHLIST
#     NETCONFIG_DNS_STATIC_SERVERS
#     NETCONFIG_DNS_FORWARDER
# or disable DNS configuration updates via netconfig by setting:
#     NETCONFIG_DNS_POLICY=''
#
# See also the netconfig(8) manual page and other documentation.
#
### Call "netconfig update -f" to force adjusting of /etc/resolv.conf.
nameserver 127.0.0.1

And finally, these are from the non-working 15.3 to 15.4 upgraded system

lrwxrwxrwx 1 root root 30 Dec 14 16:38 /etc/resolv.conf -> /var/run/netconfig/resolv.conf

### /etc/resolv.conf is a symlink to /run/netconfig/resolv.conf
### autogenerated by netconfig!
#
# Before you change this file manually, consider to define the
# static DNS configuration using the following variables in the
# /etc/sysconfig/network/config file:
#     NETCONFIG_DNS_STATIC_SEARCHLIST
#     NETCONFIG_DNS_STATIC_SERVERS
#     NETCONFIG_DNS_FORWARDER
# or disable DNS configuration updates via netconfig by setting:
#     NETCONFIG_DNS_POLICY=''
#
# See also the netconfig(8) manual page and other documentation.
#
### Call "netconfig update -f" to force adjusting of /etc/resolv.conf.
nameserver 127.0.0.1

Just to be clear, these are all from the same hardware system. I made image backups of each.

Thanks again.

4

So you must have some program that serves as local DNS server. What program are you using? ss -lunp | grep 53 may give some hint.

1 Like
5

Thanks for your reply.

Yes, I do have bind 9.16.6-150300.22.21.2 installed according to the YaST software manager.

Here’s the output of the command on the working 15.3 system.

UNCONN    0         0            192.168.1.201:53               0.0.0.0:*        users:(("named",pid=1951,fd=43))                                               
UNCONN    0         0            192.168.1.201:53               0.0.0.0:*        users:(("named",pid=1951,fd=46))                                               
UNCONN    0         0            192.168.1.201:53               0.0.0.0:*        users:(("named",pid=1951,fd=45))                                               
UNCONN    0         0            192.168.1.201:53               0.0.0.0:*        users:(("named",pid=1951,fd=44))                                               
UNCONN    0         0                127.0.0.1:53               0.0.0.0:*        users:(("named",pid=1951,fd=37))                                               
UNCONN    0         0                127.0.0.1:53               0.0.0.0:*        users:(("named",pid=1951,fd=38))                                               
UNCONN    0         0                127.0.0.1:53               0.0.0.0:*        users:(("named",pid=1951,fd=39))                                               
UNCONN    0         0                127.0.0.1:53               0.0.0.0:*        users:(("named",pid=1951,fd=40))                                               
UNCONN    0         0                  0.0.0.0:5353             0.0.0.0:*        users:(("avahi-daemon",pid=978,fd=11))                                         
UNCONN    0         0                     [::]:5353                [::]:*        users:(("avahi-daemon",pid=978,fd=12))

Unfortunately, my time is limited today and tomorrow (Sunday the 18th), otherwise, I would run the same command on the non-working configurations.

On Monday, I expect that I will have substantial time to devote to this.

Please let me know if you would like me to run the command on the non-working configurations, too, or if there is anything else you would like me to run that may help.

Thanks again.

6

Yes, I would. As well as full example of non-working name resolution on this system.

1 Like
7

Thanks for your help, replies, time, and patience.

This is definitely a step in the right direction -

On the patched 15.3 system where the DNS is not working the output is

UNCONN    0         0                  0.0.0.0:5353             0.0.0.0:*        users:(("avahi-daemon",pid=981,fd=11))                                         
UNCONN    0         0                     [::]:5353                [::]:*        users:(("avahi-daemon",pid=981,fd=12))                                         ```
And the version of bind is the same - Bind 9.16.6-150300.22.21.2

On the 15.4 DNS not working upgraded system the output is

UNCONN 0 0 0.0.0.0:5353 0.0.0.0:* users:((“avahi-daemon”,pid=764,fd=11))
UNCONN 0 0 [::]:5353 [::]:* users:((“avahi-daemon”,pid=764,fd=12))

And the bind version is Bind 9.16.33.150400.5.11.1

If I had paid closer attention, I would have notice that on running the YaST DNS configuration tool, that on both of the non-working systems, the status of the bind was listed as "not active". :blush:

After noticing in the DNS configuration tool in YaST that on both of the non-working systems the DNS was inactive, on the startup tab, I changed the setting "After Writing Configuration" to "restart". During that process on both systems, I received an error message that said the equivalent of "Failed to write configuration".

I can see that as a possibility on the 15.4 system with the updated version of bind, but why I would get the "Failed to write configuration" error on the 15.3 patched system is not clear to me.

Just to note that "allow query" is set to 192.168.1.201/24 and 127.0.0.1 and "listen on" is set to the same values on all the systems - according to the YaST DNS Configuration tool.

I think if we can figure out why it is failing to write the DNS configuration files, that might get it working again, or at least, be another step in the right direction. Do you  have any ideas as to why the YaST DNS configuration tool is failing to write the configuration files?

Once again, thank you for your help, replies, time, and patience.
8

Just to be clear, I am running the YaST DNS config tool as root.

9

One last thing I neglected to mention is that on all of the systems, the DNS is configured to start at boot time. Obviously, for some reason, the two non-working systems are not starting at boot time even though they are configured to start at boot time.

10

I realize this thread has basically died out. However, I’ve done some more troubleshooting, and I think there may be at least two different bugs. I am posting mainly to make a record of what I have discovered so that on making bug reports, I can reference this post/thread in the bug reports as logs/summaries of what I have done troubleshooting wise. Hopefully, this information will be useful for anyone either experiencing a similar problem and/or trying to troubleshoot the issue.

For both systems, I looked at /var/log/boot.log and noticed a failure message when the system tries to start the service named. On both systems, there is a message in the boot.log file to run

systemctl status named.service

On the non-working 15.3 system (with the above the previously mentioned patches applied), the output of

systemctl status named.service

is as follows:

â—Ź named.service - Berkeley Internet Name Domain (DNS)
     Loaded: loaded (/usr/lib/systemd/system/named.service; enabled; vendor preset: disabled)
    Drop-In: /usr/lib/systemd/system/named.service.d
             └─26-samba-dlz.conf
     Active: failed (Result: exit-code) since Tue 2022-12-20 11:06:22 EST; 2min 18s ago
    Process: 10539 ExecStart=/usr/sbin/named.init start (code=exited, status=226/NAMESPACE)

Dec 20 11:06:22 waterbear systemd[1]: Starting Berkeley Internet Name Domain (DNS)...
Dec 20 11:06:22 waterbear systemd[10539]: named.service: Failed to set up mount namespacing: /run/systemd/unit-root/run/named: No such file or directory
Dec 20 11:06:22 waterbear systemd[10539]: named.service: Failed at step NAMESPACE spawning /usr/sbin/named.init: No such file or directory
Dec 20 11:06:22 waterbear systemd[1]: named.service: Control process exited, code=exited, status=226/NAMESPACE
Dec 20 11:06:22 waterbear systemd[1]: named.service: Failed with result 'exit-code'.
Dec 20 11:06:22 waterbear systemd[1]: Failed to start Berkeley Internet Name Domain (DNS).

I checked to see if /usr/sbin/named.init existed and it does. For this message, I’m making a guess that the systemctl message is not referring to named.init itself, but something named.init is referring to, but I don’t know what is causing the “No such file or directory” message.

However, if I open a terminal in KDE and then cd to /usr/sbin and execute the following command as root

./named.init start

named starts and everything works perfectly - including being able to query the DNS from all my Windows PCs on the network. I want named to start at boot time, so it would be an annoyance to have to log in on every boot (I shutdown every night and my wife, usually, restarts in the morning) and restart the service. Any kind of work-around, IMO, would not be a permanent fix though it would definitely be a work-around.

I then decided to individually apply the patches from the list of available patches and see if I could find one patch that causes the failure, and my hunch paid off.

I applied the following patches individually rebooting after each one:

  1. autoyast2-installation 4.3.104-150300.3.52.1

  2. yast2-bootloader 4.3.31-150300.3.8.2

  3. xorg-X11-server 1.20.3-150200.22.5.63.1

  4. wireshark 3.6.10-150000.22.5.63.1

  5. tiff 4.0.9-150000.45.22.1

  6. samba 4.15.12+git7750e5c95ef-150300.3.43.1

After the samba update, named failed to start and the output of systemctl status named.service was exactly the same as above. I’m guessing that this indicates a possible bug with this update. Obviously, I have no idea why an update to samba would cause this error, however, it does appear to do so.

Onto the broken 15.4 system

The output of systemctl status named.service on the broken 15.4 system follows:

Ă— named.service - Berkeley Internet Name Domain (DNS)
     Loaded: loaded (/usr/lib/systemd/system/named.service; enabled; vendor preset: disabled)
     Active: failed (Result: exit-code) since Tue 2022-12-20 18:05:26 EST; 2min 35s ago
    Process: 7890 ExecStartPre=/usr/lib/bind/named.prep (code=exited, status=6)

Dec 20 18:05:26 waterbear systemd[1]: Starting Berkeley Internet Name Domain (DNS)...
Dec 20 18:05:26 waterbear systemd[1]: named.service: Control process exited, code=exited, status=6/NOTCONFIGURED
Dec 20 18:05:26 waterbear systemd[1]: named.service: Failed with result 'exit-code'.
Dec 20 18:05:26 waterbear systemd[1]: Failed to start Berkeley Internet Name Domain (DNS).

Since, to me anyway it makes no sense that the service is not configured as it was working on my 15.3 system, I tried to manually start the named service as I did above, however, this time it failed with the following output:

Starting name server BIND /etc/named.conf:4: change directory to '/var/lib/named' failed: file not found

/etc/named.conf:4: parsing failed: file not found

Although there is no indication of which file the named service failed to find, I carefully looked at named.conf and found that /var/lib/named does exist, and as far as I can tell, every file that is referenced in named.conf does exist on my system.

At this point, I am not sure there is anything else that I can do. Note that for some reason, the YaST2 DNS configuration tool fails to write the configuration files. I did note that there is a release note about updating the configuration for Bind 9.16.33.150400.5.11.1, however, I have, so far, not found the referenced readme file, and other than manually making the changes (or completely redoing the configuration), there is no avenue for me to proceed since the YaST2 DNS configuration tool presently fails to write the configuration files as I previously mentioned.

FWIW - I’m off to make at least one bug report - probably no later than Friday, December 23, 2022.

Thanks for the patience and for listening.

11

Since named doesn’t work you may check for (inadvertent) changes to the package containing it:

 leap154:~ # rpm -V bind
.M....G..  g /run/named
.....U...    /var/lib/named
.....UG..    /var/lib/named/master
.M.......  g /var/lib/named/named.conf.include
leap154:~ #

Show also:

leap154:~ # systemctl cat named
# /usr/lib/systemd/system/named.service
[Unit]
Description=Berkeley Internet Name Domain (DNS)
After=network.target
After=time-set.target
Wants=nss-lookup.target
Wants=time-set.target

[Service]
Type=forking
KillMode=process
EnvironmentFile=/etc/sysconfig/named
ExecStartPre=+/usr/lib/bind/named.prep
ExecStart=/usr/sbin/named -u named $NAMED_ARGS
ExecReload=/usr/bin/kill -HUP $MAINPID
ProtectSystem=strict
ReadWritePaths=/var/lib/named /run/named /var/log
PrivateDevices=yes
PrivateTmp=yes
ProtectHome=yes
ProtectHostname=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
ProtectKernelLogs=yes
RestrictNamespaces=yes
RestrictRealtime=yes
RestrictSUIDSGID=yes

[Install]
WantedBy=multi-user.target
leap154:~ #

Named worked here out of the box:

leap154:~ # systemctl status named
â—Ź named.service - Berkeley Internet Name Domain (DNS)
     Loaded: loaded (/usr/lib/systemd/system/named.service; enabled; vendor preset: disabled)
     Active: active (running) since Thu 2022-12-22 06:00:31 CET; 15min ago
    Process: 3884 ExecStartPre=/usr/lib/bind/named.prep (code=exited, status=0/SUCCESS)
    Process: 3893 ExecStart=/usr/sbin/named -u named $NAMED_ARGS (code=exited, status=0/SUCCESS)
   Main PID: 3894 (named)
      Tasks: 26 (limit: 4915)
     CGroup: /system.slice/named.service
             └─ 3894 /usr/sbin/named -u named

Dec 22 06:00:31 leap154 named[3894]: command channel listening on ::1#953
Dec 22 06:00:31 leap154 named[3894]: managed-keys-zone: loaded serial 0
Dec 22 06:00:31 leap154 named[3894]: zone 0.0.127.in-addr.arpa/IN: loaded serial 42
Dec 22 06:00:31 leap154 named[3894]: zone 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 42
Dec 22 06:00:31 leap154 named[3894]: zone localhost/IN: loaded serial 42
Dec 22 06:00:31 leap154 named[3894]: all zones loaded
Dec 22 06:00:31 leap154 named[3894]: running
Dec 22 06:00:31 leap154 systemd[1]: Started Berkeley Internet Name Domain (DNS).
Dec 22 06:00:31 leap154 named[3894]: managed-keys-zone: Initializing automatic trust anchor management for zone '.'; DNSKEY ID 20326 is now trusted, waiving the normal 30-day waiting period.
Dec 22 06:00:31 leap154 named[3894]: resolver priming query complete
leap154:~ #

You may wish to update your system:

leap154:~ # zypper -n update
Loading repository data...
Reading installed packages...

The following 2 package updates will NOT be installed:
  glib2-tools libgio-2_0-0
Nothing to do.
leap154:~ #

BTW: You said above your time is limited.On the other hand you are posting lots of detail which don’t help much in troubleshooting. You may reconsider your strategy.

12

Thanks for your reply. It is greatly appreciated.

With respect to doing the zypper -n update - will that work without a working name server?

I have no time today to do this (and I certainly understand that your help is offered as a courtesy and your time is also limited) I will, however, have time to run what you ask tomorrow.

Thanks again.

Happy Holidays!

13

How? If you mean running /usr/sbin/named.init - this file does not exist on Leap 15.4. Always show complete commands and their full output.

The named start scripts in Leap 15.4 do not produce the output you showed. Which implies you are still using some leftovers from the previous release. It is possible that script attempts to run named in chroot (which was previous way to sandbox it). chroot is not more used on Leap 15.4.

Show

cat /etc/sysconfig/named
systemctl cat named.service
1 Like
14

If “zypper -n update” fails you may replace the link /etc/resolve.conf by a file of the same path containing the following as a temporary workaround. Refer to the documentation of your router for its addresses.

nameserver 192.168.178.1 
nameserver fd00::xxxx:xxxx:xxxx:xxxx
15

Thanks for all the replies.

I had manually copied the named.init file from my old system to a separate drive, and then to /usr/sbin on the non-working 15.4 system and then ran it manually. Honestly, I was somewhat panicked and when I get that way, I try to find something that works. Since it did not work, I did not keep the file in /usr/sbin, and the 15.4 system, moving forward, is in exactly the same state as the system state immediately after I finished the 15.4 update. I’ll be patient for a reply, I know its a holiday weekend and I am back running the 15.3 working system. I won’t try anything like that again since it was not useful and could possibly have make things worse. My apologies for confusing the situation, and I will chalk it up to “lessons learned”.

Note: I am only working with the non-working 15.4 system now. It seems doing anything about the non-working, updated 15.3 system is moot since 15.3 is no longer supported.

It looks like you are correct about the chroot assumption - please see the requested output below, and please let me know, at your earliest convenience, what needs to be done from this point on.

Output of cat /etc/sysconfig/named

## Path: Network/DNS/Name Server
## Description: Names server settings
## Type: yesno
## Default: yes
## ServiceRestart: lwresd,named
#
# Shall the DNS server 'named' or the LightWeight RESolver Daemon, lwresd run
# in the chroot jail /var/lib/named/?
#
# Each time you start one of the daemons with the init script, /etc/named.conf,
# /etc/named.conf.include, /etc/rndc.key, and all files listed in
# NAMED_CONF_INCLUDE_FILES will be copied relative to /var/lib/named/.
#
# The pid file will be in /var/lib/named/var/run/named/ and named named.pid
# or lwresd.pid.
#
NAMED_RUN_CHROOTED="yes"

## Type: string
## Default: ""
## ServiceRestart: named
#
# Additional arguments when starting the name daemon with the init script
# /etc/init.d/named or rcnamed.
#
# For example "-n 2" to use two CPUs if named is unable to determine the
# number of available CPUs.
#
# See man 8 named for all available commandline options.
#
# "-t /var/lib/named/var" is added if NAMED_RUN_CHROOTED is set to yes.
#
# "-u named" is used in any case by the init script to run the named daemon as
# user 'named' after completing privileged operations.
#
NAMED_ARGS=""
## Type: string
## Default: ""
## ServiceReload: named
#
# All mentioned config files will be copied relativ to /var/lib/named/, when
# 'named' is started in the chroot jail.
#
# /etc/named.conf and /etc/rndc.key are always copied.  Also all files from
# include statements in named.conf.
#
# Filenames can be relative to /etc/named.d/.
#
# Please take care of the order if one file needs a setting of another.
#
# Example: "/etc/named-dhcpd.key ldap.dump rndc-access.conf"
#
NAMED_CONF_INCLUDE_FILES=""
## Type: string
## Default: ""
## ServiceReload: named
#
# Programms to be executed each time the DNS server 'named' is started or
# reloaded.
#
# Filenames can be relative to /usr/share/bind/.
#
NAMED_INITIALIZE_SCRIPTS="createNamedConfInclude"

## Type: numeric
## Default: 512
## ServiceReload: named
#
# Keysize of rndc.key
#
RNDC_KEYSIZE="512"

Output of systemctl cat named.service

# /usr/lib/systemd/system/named.service
[Unit]
Description=Berkeley Internet Name Domain (DNS)
After=network.target
After=time-set.target
Wants=nss-lookup.target
Wants=time-set.target

[Service]
Type=forking
KillMode=process
EnvironmentFile=/etc/sysconfig/named
ExecStartPre=+/usr/lib/bind/named.prep
ExecStart=/usr/sbin/named -u named $NAMED_ARGS
ExecReload=/usr/bin/kill -HUP $MAINPID
ProtectSystem=strict
ReadWritePaths=/var/lib/named /run/named /var/log
PrivateDevices=yes
PrivateTmp=yes
ProtectHome=yes
ProtectHostname=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
ProtectKernelLogs=yes
RestrictNamespaces=yes
RestrictRealtime=yes
RestrictSUIDSGID=yes

[Install]
WantedBy=multi-user.target

Output of rpm -V bind

S.5...GT.  c /etc/named.conf
.M....G..  g /run/named
.....UG..    /var/lib/named/master
.M.......  g /var/lib/named/named.conf.include

After taking your suggestion of replacing the symlink to the resolv.conf file with a resolv.conf file containing this

nameserver 9.9.9.9
nameserver 8.8.8.8

I ran zypper -n update, rebooted and bind still did not start. If the output of zypper -n update is needed, I’ll be happy to post it.

BTW - the openSuSE system is my router.

And again, I did not preserve the change to /etc/resolv.conf. Moving forward, I will be working from the image backup I made immediately following the upgrade to 15.4.

Thanks again.
Happy Holidays!

16

Hello,

I see that when installing samba the error occurs and that for the non working leap 15.3 system you have

AFAIK on my tumbleweed systems samba or samba-ad-dc install a file /usr/lib/system/system/named.service.d/26-samba-dlz.conf with this content on my samba server

rasp:/usr/lib/systemd/system/named.service.d # cat 26-samba-dlz.conf
[Service]
ReadWritePaths=/var/lib/named /run/named /var/log/named /var/lib/samba/bind-dns

But if samba-ad-dc is not provisionned the directory /var/lib/samba/bind-dns is not present and this cause a failure when starting named
On my main system where samba is not provisioned I have

hpprol2:/var/lib/samba # ls -l
total 24
drwxrwxr-x 9 root ntadmin 4096 déc.   3 11:15 drivers
drwxr-xr-x 3 root root    4096 déc.   3 11:15 lock
drwxr-xr-x 2 root root    4096 déc.   3 11:15 netlogon
drwxr-xr-x 3 root root    4096 déc.   3 11:15 private
drwxrwx--- 2 root users   4096 déc.   3 11:15 profiles
drwxr-x--- 2 root winbind 4096 déc.   3 11:15 winbindd_privileged
hpprol2:/var/lib/samba #

Can you check if the file /usr/lib/system/system/named.service.d/26-samba-dlz.conf is present on your non-working leap?

If yes as work around you can maybe create the directory /var/lib/samba/bind-dns

Regards
Philippe

1 Like
17

Running random program from different distribution is unlikely to help.

Run

named-checkconf
echo $?

and post full output.

1 Like
18

Thanks. I am filing that under “lessons learned”.

On the 15.4 system -
Output from named-checkconf

/etc/named.conf:10: option 'cleaning-interval' is obsolete and should be removed 
/etc/named.conf:40: open: /etc/named.conf.include: file not found

Output from echo $?

1

Thanks for your help. Please let me know what the next steps are at your earliest convenience. Note, I doubt that I will have time to do anything with it until Monday.

19

Thanks for your reply.

Yes, on the non-working 15.3 system, I do have that file, and the contents appear identical to the file that you have on your tumbleweed system

[Service]
ReadWritePaths=/var/lib/named /run/named /var/log/named /var/lib/samba/bind-dns

Since /var/lib/samba/bind-dns did not exist on my non-working 15.3 system, I created the directory and then rebooted, however, bind still did not start. As a side note, I’ve never had a need for active-directory and therefore, never bothered with it. I assume active-directory is what we are talking about.

Also, I did check my Leap 15.4 system for that file, and it does not exist on at least my Leap 15.4 system. Therefore, I think it is unlikely the reason that bind is failing to start on my 15.4 system is due to this.

Thanks again.

20

Spoon feeding?

Comment this out. And if named-checkconf still fails after that, fix any remaining problems it reports.

1 Like