peerdns=no, NetworkManager, doesn't work?

[Ron Yorston]

Tom Lane <tgl at redhat.com> wrote:
>Dan Williams <dcbw at redhat.com> writes:
>> This is _exactly_ the problem that other distros use resolvconf for;
>> stuff updates /etc/resolv.conf all the time,
>
>Uh, *what* stuff?  I have never had such a problem before in any Fedora
>version (or any other platform for that matter).

Absolutely.  Once I've configured a resolv.conf file on a machine that's
using a static IP address (and not NM) *nothing* should interfere with it.

>And before you dismiss the idea that NetworkManager is doing it, you
>need to explain away the line "# generated by NetworkManager, do not edit!"
>that's being inserted during the overwrite.

I had a similar situation.  When I installed F9 I decided to give NM another
chance.  It worked nicely on a wireless laptop but a machine with a static
IP address wasn't properly configured.  (There are some comments about this
on BZ 134886, but the problem might actually be with anaconda.)

Eventually I got fed up of having the machine with the static IP address
not appearing on the network until somebody logged in, so I turned off
NM and reverted to the network service.  This worked until the machine
was rebooted and my resolv.conf was overwritten by one with the "generated
by NetworkManager" comment.  My initial reaction was "blame NetworkManager",
but in fact it seems that there was a left over copy of the old resolv.conf
in /etc/sysconfig/networking/profiles/default.  Once I'd sorted that out
(and I'm not quite sure now what did it:  monkeying about with system-
config-network, perhaps) the problem went away.

So, despite appearances, it wasn't NetworkManager's fault.

There are still problems with NetworkManager, the network server and
system-config- network.  NM is getting better but it isn't suitable for
server-type machines.  Switching between NM and the network service is
definitely flaky, and the lack of documentation on NM is a big
hindrance to its adoption.

Ron