>Quoting Steve Litt (slitt@???):
>
>> My philosophy: One big hammer prevents a 100 step packaging system
>> raindance.
>
>The Big Hammer always seems a great idea for a temporary solution.
>And I assume you know what the catch is with those.
>
>Every single time I've nailed down a sysadmin annoyance using the Big
>Hammer, it's come back to haunt me later -- and, moreover, it turned
>out that a further ten minutes of digging would have found a better
>solution that didn't cripple the system's administrative framework but
>would, instead, have worked with the framework.
>
>Setting /etc/resolv.conf immutable, the classic case that was the first
>I saw you fall in love with, is a case in point. There are multiple
>ways to ensure that a DHCP client respects and enforces your preference
>of recursive nameserver, averting the need for breaking system
>administration tools using the immutable bit.

Did everyone read what Rick said? He restated, for a specific
situation, the carved in granite troubleshooting rule that you
never coathanger the symptom, but instead fix the cause. I teach this
in every Troubleshooting course I teach. It's the stone truth.

Rick speaks of the immutability of /etc/resolv.conf breaking admin
tools. This is a specific instance of the more general principle that
when you coathanger a symptom instead of eliminating the root cause,
you create side-effects which are typically harmful. I've known audio
techs who *solved* the problem of intermittent blown fuses by wrapping
aluminum foil around the blown fuse and re-installing it. And of
course, the next time the customer's speaker wires shorted at high
volume, instead of blowing the fuse, all the output transistors and
drivers would short, possibly along with the transformer and bridge
rectifier (this was in the early 80's, remember), with the very real
possibility of your beloved amplifier bursting into flames (I've seen
this happen on another audio technician's service benche).

So why do I violate the principle of eliminating the root cause instead
of coathangering the symptom, in this particular case, when I tell my
students never to coathanger the symptom?

Troubleshooting, as defined on Troubleshooters.Com and my books and
courses, is defined as "restoring the system to its as-designed
behavior". When I chattr +i /etc/resolv.conf, I'm not troubleshooting,
I'm redesigning. I violently disagree with the design decision of
having the likes of wicd or NetworkManager modify my /etc/resolv.conf,
at least on a non-portable desktop. Even on a laptop, today you can DNS
from 8.8.8.8 and 8.8.4.4 anywhere you go, so there's no need to use the
local ISP's suggested DNS servers.

If I had demanded of myself to change the root cause instead of
coathangering the symptom, I'd have needed to go to the Void Linux
developers and ask them to find a way to accommodate DNS, in a
travelling situation, without changing /etc/resolv.conf. But of course
the software wasn't written by Void, it was written by people who have
drunk heavily of the FreeDesktop.org flavored drink. I'd have as much
success there as I'd have demanding Redhat drop systemd.

When I repaired consumer audio equipment for a living, we had Technical
Service Bulletins. Occasionally a bulletin would ask me to coathanger a
symptom, and I'd do so. Because the manufacturers and/or Pacific Stereo
had studied the situation and determined that the coathanger has
minimal side effects and that it's by far the cheapest solution.

Likewise, when I used Ubuntu, I wanted to get rid of Plymouth, which in
my opinion is eye-candy for Windows Weenies. I tried and failed with
package-manager-fu. I tried and failed with several other approaches.
Finally I just renamed the Plymouth executable, and BANG, things worked
like I wanted them to.

SteveT

Steve Litt
Spring 2021 featured book: Thriving in Tough Times
http://www.troubleshooters.com/thrive