>Quoting Steve Litt (sl...@troubleshooters.com): > >> 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 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng