Sometimes one takes a challenge with Linux. During my stay in Norway I wanted to find out whether one could bring a really old server system (regarding HW) to the latest Leap version of Opensuse. Such an old system can still serve valuable purposes – as testing complex configurations of server components, using it as an extended IDS/Firewall-system, etc. In my case I was fortunate as the real problem occurred with SW and not HW.
Regarding HW my concerns related to an old Nvidia GT 710. The advantage of this card was/is that it is passively cooled and provides enough power for using both a present KDE or Gnome desktop – if necessary or useful. I was lucky to find that the present G05 Nvidia drivers support this card.
Somewhat unexpectedly, real problems occurred with an installed named-service at the upgrade from 15.3 to Leap 15.4 – and again when upgrading from 15.5 to 15.6. While you can find many complaints on the Internet, I did not find a solution that covered all my problem. Therefore, I want to give Linux users or administrators who experience similar problems some hints.
Upgrade procedure
I followed a standard scheme. Note: For zypper realted steps below, I only give examples for the transition from Leap 15.5 to Leap 15.6. Other upgrade transitions were done analogously:
- Within the present Leap version refresh all repositories.
- Update all installed RPMs to the latest version
- Test that your Nvidia card is running with the drivers from SuSE’s Nvidia repository.
- Use the releasever-mechanism within the addresses in the repositories. I.e., replace the version number in the URLs by ${relasever}.
- Reduce the active repositories to a minimum (Update, OSS, Non-OSS, sle, backports).
- In a root terminal window execute the command
zypper –releasever=15.5 refresh - In a root terminal window execute the command
zypper –releasever=15.6 dup –download-only –allow-vendor-change - Leave your graphical desktop. Go to a TTY-Terminal (e.g. Ctrl-Alt-F1). Login as root. Execute “init 3”.
- In your TTY execute the command|br>: zypper –no-refresh –releasever=15.6 dup –allow-vendor-change
Potential named problem on Leap 15.3
Depending on your update status of Leap 15.3, there may already occur problems with RPM “bind” and the named-service during updates. They have their origin in certain versions of samba, which may break bind. Here are two links which may help you to solve these problems:
- https://www.opensuse-forum.de/thread/66234-leap-15-3-named-start-probleme-named-service-failed-to-set-up-mount-namespacing/
- https://bugzilla.suse.com/show_bug.cgi?id=1205946
If you should still have some package “samba-ad-dc” installed on your system, but no intentions to manage MS Active Directory environments, you may be willing to remove this package. In Leap 15.5 and 15.6 the samba-ad-dc RPMs have been removed, anyway. However, if you absolutely need samba-ad-dc, there are versions available in community repositories and for Tumbleweed.
Named problem after upgrade to Leap 15.4
I ran across a problem described at the following link:
https://forums.opensuse.org/t/named-stopped-working/152225/6
The problem is a missing script for generating an empty file, namely “/etc/named.conf.include”. This file was/is intended for adding some configuration options. You may follow the hints of user “quippy” in the last comment on the problem. The interesting thing with this obstacleis that the generator script
/usr/share/bind/createNamedConfInclude
appears again in Leap 15.6 with Leap 15.6 🙂 .
Named problems after upgrade from Leap 15.5 to Leap 15.6
I experienced multiple combined problems. The following steps may provide solutions.
Step 1: The option “additional-from-cache no;” in /etc/named.conf is no longer supported. So, I had to comment a respective line out in /etc/named.conf.
Step 2: As the generator for the empty file “/etc/named.conf.include” was provided again, I could reactivate a respective option in “/etc/sysconfig/named”.
Step 3: The working directory in “/etc/named.conf” had to be set as follows:
directory “/var/lib/named”;
Step 4: To avoid some problems with Google’s name service at 8.8.8.8, I added the following option to “/etc/named.conf”:
dnssec-validation auto;
Step 5: To become compatible with a fresh installation, I added the following option to “/etc/named.conf”
managed-keys-directory “/var/lib/named/dyn/”;
Step 6: Access rights problems and no longer a chroot environment.
My named services was previously started chrooted. The respective option in “/etc/sysconfig/named” is
NAMED_RUN_CHROOTED=”yes”
However, this option has not much of an effect these days. The chroot-environment under “/var/lib/named” is practically no longer existent. Actually it seems that Opensuse does not run “named” in a chroot environment any longer since Leap 15.4.
After some hours of working I found that at least on my system the access rights of some folders and files were not correct. Eventually, I installed a fresh bind RPM and named service on a Leap 15.6 laptop to get the necessary hints. Below, I give you my present knowledge status of the correct access rights:
Dir /etc
.... .... 4 -rw-r----- 1 root named 1210 Jun 30 16:43 named.conf .... 0 lrwxrwxrwx 1 root root 33 Jun 14 13:48 named.conf.include -> /var/lib/named/named.conf.include .... 4 drwxr-xr-x 2 root root 4096 Jun 15 12:25 named.d .... 4 drwxr-xr-x 2 root root 4096 Jun 11 17:55 namedb .... 0 lrwxrwxrwx 1 root root 23 Jun 11 14:26 rndc.key -> /var/lib/named/rndc.key
The directory “namedb” is empty in my case and not needed on Leap systems. It stems from old experiments. I removed it.
Note: This my be different on other Linux distributions. There the directory /etc/namedb may be required for a proper bind-installation.
Dir /run
.... 0 drwxrwxr-t 2 root named 80 Jun 30 14:31 named
Dir /run/named (will be filled automatically)
.... 0 drwxrwxr-t 2 root named 80 Jun 30 14:31 . .... 0 drwxr-xr-x 62 root root 1700 Jun 30 15:18 .. .... 4 -rw-r--r-- 1 named named 6 Jun 30 14:31 named.pid .... 4 -rw------- 1 named named 102 Jun 30 14:31 session.key
Dir /var/lib
.... 4 drwxrwxr-t 12 root named 4096 Jun 30 14:32 named
Dir /var/lib/named
.... 4 drwxrwxr-t 12 root named 4096 Jun 30 14:32 . .... 4 drwxr-xr-x 104 root root 4096 Jun 12 12:14 .. .... 4 -rw-r--r-- 1 root root 192 Nov 19 2009 127.0.0.zone .... 4 drwxr-xr-x 2 named named 4096 Jan 30 17:56 dyn .... 4 -rw-r--r-- 1 root root 182 Nov 19 2009 localhost.zone .... 4 -rw-r--r-- 1 named named 1421 Jun 30 14:32 managed-keys.bind .... 4 -rw-r--r-- 1 named named 3020 Jun 30 14:31 managed-keys.bind.jnl .... 4 drwxr-xr-x 2 named named 4096 Jan 30 17:56 master .... 4 -rw-r--r-- 1 root root 355 Jun 30 14:31 named.conf.include .... 4 -rw-r--r-- 1 root root 2928 Jan 30 17:56 named.root.key .... 4 -rw-r----- 1 root named 141 Jan 30 2012 rndc.key .... 4 -rw-r--r-- 1 root root 3313 Jan 30 17:56 root.hint .... 4 drwxr-xr-x 2 named named 4096 Jan 30 17:56 slave
Files in the folders dyn, master, slave should have owner.group “named.named” and 644 rights: “-rw-r–r–“.
You should compare the access rights in your installations with the above settings.
Note: Typical chroot-dirs like etc, lib, lib64, proc, run, usr, var, which may exist from older installations, are no longer needed. I have deleted them on my system.
With these settings, partially taken from a fresh installation on a Leap 15.6 system, the named-service was running correctly on my upgraded sever.
Conclusion
Over time the configuration of bind and the named service has changed. Therefore, upgrading rather old Leap systems may require some manual changes to the named configuration to make it compatible with present standards. In this post I have described some steps which may help readers to master a transition of the named service from a Leap 15.3 system to an up-to-date Leap 15.6 system.