Beachy thoughts: Many ways to solve a problem

I’m always thinking about solving problems and the beach doesn’t change that. It’s kind of the way my mind works. It’s also the way life is.

There are many ways to solve problems ranging from complex to simple and I’ve encountered and used both in my time. The best solutions usually meet the following criteria.

• They solve the problem rather than circumventing it.
• They fit seamlessly in to the whole, whether hardware or software.
• They are simple.

Case 1

The great Both.org command line challenge was posed at the end of my article, The Linux Philosophy for SysAdmins, Tenet 02 — Transforming Data Streams. Unfortunately there were no takers, but I first issued that challenge at Opensource.com a few years ago. So I had a good response to that and the results were very interesting. Read those results to see the wide variety of solutions from Linux users around the world.

Those results ranged from very simple to very complex, all of which were within the rules set down in the challenge itself.

Case 2

Here at the beach I encountered an interesting problem, but one that’s been around since 2020 and the inclusion of systemd-resolved in Fedora 33. The basic statement of the problem is that systemd-resolved can fail to return DNS requests or cause significant delays. I experienced both symptoms in the hotel’s wireless system this week because they apparently use an internal name server on IP address 192.168.0.3. I intentionally left systemd-resolved running on my vgr3 laptop because it was supposed to work in exactly this environment and it does on my home network. But not here. The local DNS server — probably one supplied with the ISP’s router — doesn’t work well with systemd-resolvd. I created a new /run/NetworkManager/resolv.conf because NetworkManager will be configuring name services when the fix is completed. The revised resolv.conf looks like this.

You can see where I commented out the local name server. I added the Google Public DNS name servers.

# cat resolv.conf 
# Generated by NetworkManager
search both.org
# nameserver 192.168.0.3

# Google's public DNS servers
nameserver 8.8.8.8
nameserver 8.8.4.4

You can read the details of the problem and the solutions I used in my article, systemd — #12: Fixing systemd-resolved name service failures using Ansible. But I’ve copied the main part of the article here.

The new resolver allegedly has four operational modes, described in this Fedora Magazine article. None of the options seems to work correctly when the network has its own name server designed to perform lookups for internal and external hosts.

In theory, systemd-resolved is supposed to fix some corner issues around the NSS resolver failing to use the correct name server when a host is connected to a VPN, which has become a common problem with so many more people working from home.

The new resolver is supposed to use the fact that /etc/resolv.conf is now a symlink to determine how it is supposed to work based on which resolve file it is linked to. systemd-resolved’s man page includes details about this behavior. The man page says that setting /etc/resolv.conf as a symlink to /run/systemd/resolve/resolv.conf should cause the new resolver to work the same way the old one does, but that didn’t work for me.

My fix

I have seen many options on the internet for resolving this problem, but the only thing that works reliably for me is to stop and disable the new resolver. First, I deleted the existing link for resolv.conf, copied my preferred resolv.conf file to /run/NetworkManager/resolv.conf, and added a new link to that file in /etc:

# rm -f /etc/resolv.conf
# ln -s /run/NetworkManager/resolv.conf /etc/resolv.conf

This command stops and disables the systemd-resolved service:

# systemctl disable --now systemd-resolved.service
Removed /etc/systemd/system/multi-user.target.wants/systemd-resolved.service.
Removed /etc/systemd/system/dbus-org.freedesktop.resolve1.service.

I also changed /etc/nsswitch to remove the mdns entry.

# Generated by authselect
# Do not modify this file manually, use authselect instead. Any user changes will be overwritten.
# You can stop authselect from managing your configuration by calling 'authselect opt-out'.
# See authselect(8) for more details.

# In order of likelihood of use to accelerate lookup.
passwd:     files sss systemd
shadow:     files
group:      files [SUCCESS=merge] sss [SUCCESS=merge] systemd
#hosts:      files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] myhostname dns
hosts:      files resolve [!UNAVAIL=return] myhostname dns
services:   files sss
netgroup:   files sss
automount:  files sss

aliases:    files
ethers:     files
gshadow:    files
networks:   files dns
protocols:  files
publickey:  files
rpc:        files

I then ran the following command to keep authselect from overwriting my changes.

No reboot is required. The NSS resolver takes over, and name services work as expected.

I used the Ansible method when in my home lab network, but I’ve only got one system here, so I used the command line method and entered the commands myself instead of using Ansible. It worked perfectly and my name services problem is fixed.

Parting thoughts

In Case 1, we see a large number of people who solved a specified problem in different ways. Most were similar by the very nature of the problem, but no two were alike. Most were also quite simple. A few solutions were more complex, but those all did something different, such as including downloading the data as part of the program solution, or providing additional details beyond those requested in the challenge.

In Case 2, the commands required to implement the solution were simple and could be entered easily. However in a complex environment like a network with many hosts requiring the solution be applied, a more complex solution was required. I used Ansible which required creation of an Ansible playbook and testing with VMs.

In all instances of both cases — the solutions are elegant.