On Fri, Oct 27, 2017 at 07:49:29AM -0400, Gene Heskett wrote:
On Friday 27 October 2017 03:46:27 Mart van de Wege wrote:Roberto C. Sánchez <roberto@debian.org> writes: > On Thu, Oct 26, 2017 at 12:24:32PM +0100, Darac Marjal wrote: >> Actually, there's no need to duplicate the effort. As I understand >> it, resolvconf is basically an optional helper program. Software >> that automatically modifies /etc/resolv.conf should first test for >> the presence of resolvconf (whether that be checking for the >> configuration directory of resolvconf or checking that resolvconf >> is running or... however resolvconf desires to be detected). If >> resolvconf is available, the changes are co-ordinated through >> resolvconf, otherwise, /etc/resolv.conf is modified directly. > > In my case resolvconf is not installed/available and I want > resolv.conf to be left alone. I want any other package that thinks > it needs to modify resolv.conf to leave it along. But there *is* a way to do that: install resolvconf. Granted, it might be nice if resolvconf had an easier way to configure a static setup, but as it is now packages that need to access resolv.conf should do this through resolvconf if it is available, so installing and configuring it *is* the right way to handle this. MartI must argue against it, until as you say, resolvconf is given a well documented way to be told to leave a "static" system alone. Until such time, I'll make /etc/resolv.conf a real file, and mark it and /etc/network/interfaces immutable. And frankly, I'm getting tired of the arguments saying it must beinstalled.
Who's saying it must be installed? Maybe I've missed something, but I think the consensus in this discussion was that if you want your resolv.conf to be unmanaged/static/administrator-controlled, then don't have resolvconf installed. If you have resolvconf installed, then what's the point of neutering it with a command?
(I realise that there are some packages that come with, say, ENABLED=no in /etc/default, but that's usually there because sensible defaults are difficult, and the package needs to be configured before use. Not so with resolvconf).
Not all machines are lappy's being toted to Micky D's for connectivity, where it /might/ make some modicum of sense IF it Just Worked. Here, it didn't just work on a jessie install, took me around an hour fighting with its local keyboard, to make networking work on the jessie install, and 15 minutes to make stretch work, but there I wasn't fighting with a kernel bug that kills keyboards and mice. So it didn't Just Work on a stretch install. So until such time as resolv.conf can look at /etc/network/interfaces, and finding the "static" keyword, leave that interface alone, it will be nuked on sight with a root rm... If by the debian 10 release, it must be installed, them MAKE IT WORK. My way, so far, does that. In my experience its a solution looking for a problem, and if it doesn't find one, it will make one. It's network-manager by a new name, and just as worthless. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene>
-- For more information, please reread.
Attachment:
signature.asc
Description: PGP signature