We have been writing the SEARCH= line to ifcfg files in network.py
for a while, but it only contains the domain we extract from the
FQDN. For users wanting to use the network service over NM, this
presents a problem because the SEARCH line present in the ifcfg
file will always override the information from the DHCP server.
---
network.py | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/network.py b/network.py
index 7becba3..b5ecad4 100644
--- a/network.py
+++ b/network.py
@@ -582,10 +582,6 @@ class Network:
if dev.get('MTU') and dev.get('MTU') != 0:
f.write("MTU=%s
" % dev.get('MTU'))

- if self.domains != ['localdomain'] and self.domains:
- searchLine = string.joinfields(self.domains, ' ')
- f.write("SEARCH="%s"
" % (searchLine,))
-
# tell NetworkManager not to touch any interfaces used during
# installation when / is on a network device. Ideally we would only
# tell NM not to touch the interface(s) actually used for /, but we
--
1.6.0.3

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

On Dec 5, 2008, at 4:51 PM, David Cantrell wrote:

We have been writing the SEARCH= line to ifcfg files in network.py
for a while, but it only contains the domain we extract from the
FQDN. For users wanting to use the network service over NM, this
presents a problem because the SEARCH line present in the ifcfg
file will always override the information from the DHCP server.


If they're using NetworkManager, does it follow the logic to set up
the search domains by default? If so, seems fine


Jeremy

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Jeremy Katz wrote:
> On Dec 5, 2008, at 4:51 PM, David Cantrell wrote:
>> We have been writing the SEARCH= line to ifcfg files in network.py
>> for a while, but it only contains the domain we extract from the
>> FQDN. For users wanting to use the network service over NM, this
>> presents a problem because the SEARCH line present in the ifcfg
>> file will always override the information from the DHCP server.
>
> If they're using NetworkManager, does it follow the logic to set up the
> search domains by default? If so, seems fine

NetworkManager doesn't seem to care about the SEARCH line if the ifcfg
file. It sets up resolv.conf as you change networks and it has its own
handler for dhclient and it's own database of per-interface things such
as the search list.

In ifcfg-reader.c, NM currently pulls in the SEARCH value and will use
it to some degree, but based on the comment in the code, it doesn't look
like it will always do that. So I consider SEARCH to be ignored in the
long run by NM. Removing it from the ifcfg file and having NM enabled,
everything works fine. The only problems we are seeing right now are
the people that want to use the network service over NM and having the
SEARCH line in ifcfg overrides whatever dhclient gets back (which is how
dhclient-script has worked for a long time).

--
David Cantrell <dcantrell@redhat.com>
Red Hat / Honolulu, HI

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

On Dec 7, 2008, at 4:14 PM, David Cantrell wrote:

Jeremy Katz wrote:

On Dec 5, 2008, at 4:51 PM, David Cantrell wrote:

We have been writing the SEARCH= line to ifcfg files in network.py
for a while, but it only contains the domain we extract from the
FQDN. For users wanting to use the network service over NM, this
presents a problem because the SEARCH line present in the ifcfg
file will always override the information from the DHCP server.


If they're using NetworkManager, does it follow the logic to set up
the

search domains by default? If so, seems fine


NetworkManager doesn't seem to care about the SEARCH line if the ifcfg
file. It sets up resolv.conf as you change networks and it has its
own
handler for dhclient and it's own database of per-interface things
such

as the search list.

In ifcfg-reader.c, NM currently pulls in the SEARCH value and will use
it to some degree, but based on the comment in the code, it doesn't
look
like it will always do that. So I consider SEARCH to be ignored in
the
long run by NM. Removing it from the ifcfg file and having NM
enabled,

everything works fine. The only problems we are seeing right now are
the people that want to use the network service over NM and having the
SEARCH line in ifcfg overrides whatever dhclient gets back (which is
how

dhclient-script has worked for a long time).


Sounds sane

Jeremy

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list