[GTALUG] sysadmining is full of stupid details

[David Collier-Brown]

Many, /many/ enthusiastic people, some with very poor judgment. All you 
need is one per product, and you get an incredible mess.

In the military, you're
- OK with an officer who smart and enthusiastic
- better with one who smart and lazy
- sort of OK again with someone who is dumb and lazy, but
- if you have some who's dumb and enthusiastic, /they'll get you killed/.

--dave



On 03/11/16 05:28 PM, D. Hugh Redelmeier via talk wrote:
> 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).
> ---
> Talk Mailing List
> talk at gtalug.org
> https://gtalug.org/mailman/listinfo/talk


-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb at spamcop.net           |                      -- Mark Twain

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gtalug.org/pipermail/talk/attachments/20161103/8ed14586/attachment.html>