Bug 84409

Summary: RFE: allow multiple dns servers via boot parameter (regression) [patches included]
Product: [Fedora] Fedora Reporter: Matthew Miller <mattdm>
Component: anacondaAssignee: Jeremy Katz <katzj>
Status: CLOSED ERRATA QA Contact: Mike McLean <mikem>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideKeywords: FutureFeature
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: FC4
Fixed In Version: RHBA-2005-220 Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-06-09 11:29:04 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
scan dns parameter for multiple servers
none
don't discard info for additional servers
none
fixes new problem where numDns gets zapped back to 1
none
fixes the _new_ thing where secondary and tertiary dns entries get capriciously discarded :) none

Description Matthew Miller 2003-02-16 02:56:47 UTC
Currently, it's possible to specify the primary dns server via the dns= boot
parameter. It'd be nice if this parameter would allow multiple servers. I will 
attach two small patches which enable this.

The first patch makes setupNetworkDeviceConfig in net.c search the dns parameter
for multiple comma-separated servers. This is completely backwards-compatible
with the current behavior, but if additional servers are specified, they're used
too.

The second patch makes this information not get discarded when the network
config newt gui is shown -- currently, only the primary server is displayed and
the others are ignored. This leaves the GUI alone -- only the first shows up
still -- but if additional servers were specified earlier, they're carried forwards.

Comment 1 Matthew Miller 2003-02-16 02:57:29 UTC
Created attachment 90111 [details]
scan dns parameter for multiple servers

Comment 2 Matthew Miller 2003-02-16 02:58:28 UTC
Created attachment 90112 [details]
don't discard info for additional servers

Comment 3 Matthew Miller 2003-02-16 03:01:07 UTC
(I had a for loop in the first patch, but decided it looks cleaner and is easier
to understand as a while loop. The code in the  second patch may not be at
precisely the best place to do what it does, but it seemed like the
least-intrusive.)

Comment 4 Jeremy Katz 2003-02-17 20:59:43 UTC
Committed with a few minor changes

Comment 5 Matthew Miller 2003-02-18 15:55:19 UTC
cool, thanks.

Comment 6 Matthew Miller 2004-04-29 14:51:54 UTC
Hmmm. Additional servers now seem to get dropped again in FC2t3. This
is definitely a regression, as it worked before. Should I open a new
bug or reopen this one?

Comment 7 Matthew Miller 2004-04-29 18:49:51 UTC
No comment, so I'll reopen. :)

Comment 8 Matthew Miller 2004-04-29 19:10:56 UTC
Created attachment 99800 [details]
fixes new problem where numDns gets zapped back to 1

Ahaha! This is what was doing it. An || here makes no sense -- it was
overwriting the command-line DNS entries whenever the IP address was static.

Comment 9 Jeremy Katz 2004-04-30 03:55:00 UTC
Committed

Comment 10 Matthew Miller 2004-04-30 04:08:01 UTC
thank you!

Comment 11 Matthew Miller 2004-12-28 21:46:23 UTC
Doh; we're back again. The block of code that does this got moved around
(presumably, based on a comment in the changelog, to fix bug #122554, but I
don't have permissions to see that) again, and again cfg->dev.numDns is getting
hard-set to 1 even if there's other entries.

(This is in both the nahant beta 10.1.1.3 version and in the FC devel tree.)

I'll attach a simple patch which I believe should fix this _and_ not break
whatever #122554 is.

Comment 12 Matthew Miller 2004-12-28 21:47:32 UTC
Created attachment 109157 [details]
fixes the _new_ thing where secondary and tertiary dns entries get capriciously discarded :)

Comment 13 Jeremy Katz 2005-01-04 16:17:15 UTC
bug 122554 is basically that if you type the wrong IP for the dns server when
doing a static IP and then go back it doesn't remember the change.  Can you
verify that that still works with your new patch?

Comment 14 Matthew Miller 2005-01-04 17:16:40 UTC
Yeah, still works. I tested it, and I also have logical reason to believe that
will still work... that's what I assumed bug 122554 was. The old (wrong) way did
the check and only then set cfg->dev.dnsServers[0] = addr. The new patch doesn't
do the check and just sets cfg->dev.dnsServers[0] = addr, but rather than
setting cfg->dev.numDns to a hard-coded 1, it only sets it to 1 if it was
previously less than 1. So it should be all good.

Comment 15 Jeremy Katz 2005-01-04 18:04:58 UTC
Yeah, the logic followed right, I just wanted a quick test to make sure I wasn't
going crazy since I'm sure I'll forget to do so by the time I get it built.

Committed to CVS, thanks.

Comment 16 Tim Powers 2005-06-09 11:29:04 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2005-220.html