DHCP configuration bug
-
Fedora 21 Server minimal, fully updated, r6623
@Tom-Elliott @Sebastian-RothI helped update one of our sites that uses FOG for dhcp on Friday, and unknown to me, the DHCP configuration didn’t have a DNS or Router address written into it.
There was widespread panic on Monday morning when no computer in the building worked.
Here’s why.
There’s some new lines within
/lib/common/functions.sh
Line numbers 1846 and 1847:[[ $(validip $routeraddress) -eq 0 ]] && echo " option routers $routeraddress;" >> "$dhcptouse" [[ $(validip $dnsaddress) -eq 0 ]] && echo " option domain-name-servers $dnsaddress;" >> "$dhcptouse"
While I see how these checks would be beneficial, it results in chaos when
/opt/fog/.fogsettings
has these lines:routeraddress=" option routers 10.13.15.254;"; dnsaddress=" option domain-name-servers 10.51.1.7; ";
Clearly these variables aren’t “valid IPs” because they have the whitespace in them and text such as “option routers” and “option domain-name-servers” and semicolons and so forth, and would fail the
validip
function, therefore never getting echo’d to thedhcpd.conf
file.I’ve since fixed the
/opt/fog/.fogsettings
file so that it’s correct and will work, but that doesn’t mean other people’s are fixed. We need to correct for this. -
I’m going to create a feature request with the ISC-DHCP people.
there wasn’t an error, let alone even a message that there was no router address set in the DHCP config.
I feel very strongly that there should be a message for a DHCP option so critical!
ISC-DHCP gives messages about having other interfaces with other networks available that don’t have declarations. Why not a message for router addresses not being present?It’s a trivial thing but it would have immensely helped out. I would have at least caught the problem before I left on Friday, because I always check the status of DHCPD after FOG gets done setting it up - because it’s that important.
-
@Wayne-Workman Shall we have a false case for those statements like:
[[ $(validip $routeraddress) -eq 0 ]] && echo " option routers $routeraddress;" >> "$dhcptouse" || echo " option routers-seams-to-not-be-a-valid-ip $routeraddress;" >> "$dhcptouse" [[ $(validip $dnsaddress) -eq 0 ]] && echo " option domain-name-servers $dnsaddress;" >> "$dhcptouse" || echo " option domain-name-servers-seams-to-not-be-a-valid-ip $dnsaddress;" >> "$dhcptouse"
This would cause the DHCP server to fail on start I’d say!
Beside that I wonder why you had the full isc-dhcp config string in your .fogsettings file. Cannot find anything in the scripts that might cause this. Cannot reproduce either. Added by hand?
-
@Sebastian-Roth said:
Beside that I wonder why you had the full isc-dhcp config string in your .fogsettings file. Cannot find anything in the scripts that might cause this. Cannot reproduce either. Added by hand?
Did not edit by hand. This was installed back when FOG Trunk was still in the 2xxx SVN numbers. The installer used to put the string in the .fogsettings file like that, a long time ago.
We updated that site from SVN 2xxx to the latest on Friday.
-
@Sebastian-Roth said:
[[ $(validip $routeraddress) -eq 0 ]] && echo " option routers $routeraddress;" >> "$dhcptouse" || echo " option routers-seams-to-not-be-a-valid-ip $routeraddress;" >> "$dhcptouse" [[ $(validip $dnsaddress) -eq 0 ]] && echo " option domain-name-servers $dnsaddress;" >> "$dhcptouse" || echo " option domain-name-servers-seams-to-not-be-a-valid-ip $dnsaddress;" >> "$dhcptouse"
This would cause the DHCP server to fail on start I’d say!
I am in support of Sebastian’s idea, for the record.
-
@Sebastian-Roth https://github.com/FOGProject/fogproject/pull/91
Created a pull request for these changes.
-
I don’t know that either of those two items are “crucial”. What about the cases where people don’t want to specify a router’s option (e.g. proxyDHCP setup – I’m pretty sure ISC-DHCP is also capable in a proxy dhcp configuration mode) or a DNS address?
The way this was handled in the past, neither of those existed to begin with if the admin who’s doing the install didn’t want them. It changed the element from:
routeraddress=" option routers 10.13.15.254;"; dnsaddress=" option domain-name-servers 10.51.1.7; ";
To:
routeraddress=" #option routers x.x.x.x;"; dnsaddress=" #option domain-name-servers x.x.x.x; ";
So the lines where “there” but they were commented and unused.
I am fixing the updater portion to remove all of the match and replacing it with the valid IP in hopes to correct for the .fogsettings file. I’m also going to fix it in an attempt to read the IP out of the line to test it more appropriately.
-
Potential fix pushed.
-
Any word on this?
-
@Tom-Elliott The guy is in another country, he’s probably enjoying his Friday night right now. I’m sure we’ll hear from him on Monday.
-
@Wayne-Workman This was completely your thread lol.
-
@Tom-Elliott oh damn.