Context: I had a working system that was stable for a decade (mail server, DNS, VPN, etc.). But that was insane. Regular updates are needed but old systems fall off the map. So rebasing is needed. And the longer you put it off, the worse it gets So I'm redoing everything, based on CentOS 7. What a sea of shallow lore is needed. By "shallow", I mean that each thing is easy. What makes the problem hard is that there is so much of this crud to get right. Today's example: spamassassin's log file shows a lot of messages to do with not being able to access the DNS server via 127.0.0.1. Eg: Nov 03 12:12:09 redeye spamd[1455]: dns: sendto() to [::1]:53 failed: Connection refused, failing over to [127.0.0.1]:53 Nov 03 12:12:09 redeye spamd[1455]: dns: sendto() to [127.0.0.1]:53 failed: Connection refused, failing over to [::1]:53 Nov 03 12:12:09 redeye spamd[1455]: dns: bad dns reply: Connection refused Why doesn't it use the server specified by /etc/resolv.conf? Apparently the spamassassin folk think that you'd be better off not sharing a DNS server since a lot of RBL servers limit the amount of traffic that a particular client DNS server is allowed to generate. So they force you to run a local DNS server on the same machine as spamassassin. This happens to be a lose for my system. My spamassassin host was using a DNS shared by my LAN. This was not shared with any other spamassassin, so I had no problem that that limitation solved. But it created a problem. And the diagnostic wasn't rubbed in my face, and the diagnostic does not point at the problem unless you know more than you should have to. I, of course, tried to find where this is explained and failed. I did see suggestions for running a local DNS server, but the reason did not apply. Simple fix: yum install unbound systemctl start unbound systemctl enable unbound I hope that the default settings are reasonable. What a waste of my time. Irony: once I fixed this, spamassassin spams syslog with a half dozen lines per mail message processed. And this is just one of a million trivial impediments. Notice that that systemd (and the previous init systems) needed separate commands for starting a service now (start) and starting one on boot (enable). Surely the most common case is to do both. Firewalld's GUI has this same problem. It is more confusing because you click away at tick boxes, the ones you have changed are not distinguished. You cannot see the "now" settings at the same time as the "on boot" settings. Looking at the log (to discover the original problem) is arcane in itself. The systemd command to look at logs is journalctl(1) (I'm surprised it is in section 1). The flag -b limits the output to things since the most recent boot. To look at a particular service, use _SYSTEMD_UNIT=spamassassin.service. How awful. It can be shortened to "-u spamassassin", but that's hardly mentioned in the enormous journalctl(1).