SOLVED 1.3.0 installer does not handle class B IP's correctly with DHCP
-
Server
- FOG Version: 1.3.0 RC23
- OS: Ubuntu 16.04 x64 server
Client
- Service Version: N/A
- OS: N/A
Description
When installing FOG and setting the IP for example to be 172.16.200.251, then it sets the wrong subnet.
Class B subnet should be 255.255.0.0, but it’s set to 255.255.255.0 in the “.fogsettings” file.
If the “.fogsettings” file is corrected, then the installer writes wrong values to “dhcpd.conf”.In my example, the DHCP range was set to 172.16.38.10 - 172.16.38.254.
In “dhcpd.conf” the “subnet” section was set to:subnet 172.16.0.10 netmask 255.255.0.0{This causes the DHCP server fail a syntax check on the config file. The correct line should read:
subnet 172.16.0.0 netmask 255.255.0.0{ -
Just in case you wanted to check it out yourself. The link to the functions the installer uses to get the subnet mask of the system. We typically start with the IP address of the Nic that DHCP is being applied to so as to prevent a possible reassignment of that IP (as essentially your FOG Server has become the network). The first link is where it’s building the dhcp config file. The second is where it’s gathering the subnet mask information. The third is where it’s converting the data for use as the subnet mask.
https://github.com/FOGProject/fogproject/blob/dev-branch/lib/common/functions.sh#L1950
https://github.com/FOGProject/fogproject/blob/dev-branch/lib/common/functions.sh#L91
https://github.com/FOGProject/fogproject/blob/dev-branch/lib/common/functions.sh#L163
-
I agree.
-
I don’t think this is something we need to be concerned about. If you’re hitting issues, update your /opt/fog/.fogsettings file to use what you need and expect.
-
@Wayne-Workman Right. The idea is your setup is already good to go the first time you’ve run it, so what you set shouldn’t need to be set EVERY cycle. What about those with specialty requirements (such as those on isolated networks) that want the stuff configured for their main network without having to reconfigure themselves.
-
Only if it’s not already set:
https://github.com/FOGProject/fogproject/blob/dev-branch/lib/common/functions.sh#L1950 -
@Wayne-Workman To my knowledge, the value IS updated. configureDHCP happens every time you run the installer, which is where the network is being set.
-
@Tom-Elliott Ah - and the re-install re-used the value in the .fogsettings file. Ok.
I suppose we should update the subnet mask in .fogsettings, or just not store it there. Isn’t the value only used for the DHCP configuration anyways?
-
@Wayne-Workman Correct, the bottom line as to the originating issue is when the first installation occurred, the interface was setup in 255.255.255.0 mask rather than the expected 255.255.0.0 mask.
-
@Tom-Elliott Right but the way it’s coded in the installer - the installer literally does not care about what class the IP is - the class makes zero difference. Literally, the correct subnet mask is pulled from the desired interface, and the start and end range and the network address are all mathematically calculated. Nothing is guessed, classes are not considered whatsoever.
Bottom line is - if the interface you want to use is correctly configured, the FOG installer upon it’s first run will not make a mistake with the DHCP configuration.
-
@Wayne-Workman That’s why I brought in all the links. I know nothing changed. But as was stated, the address was within a Class C range, until it wasn’t (if that makes any sense).
-
I don’t even see what the issue is with the start range really. We wrote it so it starts 10 addresses ahead of the network address:
https://github.com/FOGProject/fogproject/blob/dev-branch/lib/common/functions.sh#L1952And it looks to me that the network definition is written exactly as it should be. I was under the impression that something changed in code, but that doesn’t appear to be the case. It appears that the installer and DHCP were configured and then the server’s IP was changed later. Of course this would break things.
-
@Tom-Elliott I helped write it. And if it’s that big of a concern, we can add to it to just reserve the server’s IP address in the dhcpd.conf file.
-
-
And if you look, it’s using the network address to supply the subnet anyway.
-
Okay. You wrote it.
-
@Tom-Elliott said in 1.3.0 installer does not handle class B IP's correctly with DHCP:
We typically start with the IP address of the Nic that DHCP is being applied to so as to prevent a possible reassignment of that IP (as essentially your FOG Server has become the network).
ISC-DHCP will not lease it’s own IP address, and there’s no reason to not start the range at the network address.
-
@Tom-Elliott said in 1.3.0 installer does not handle class B IP's correctly with DHCP:
@EspenU right but the ip and subnet are determined by what’s defined on the nic when you run the installer. While you can change these things I think your seeing class c subnet is because that’s what the nic was set for.
Dammit you right. The first installation was probably run before a static IP was set on the server. That explains a lot.
Thanks for your help. Sorry to have bugged you with such a silly mistake. -
Just in case you wanted to check it out yourself. The link to the functions the installer uses to get the subnet mask of the system. We typically start with the IP address of the Nic that DHCP is being applied to so as to prevent a possible reassignment of that IP (as essentially your FOG Server has become the network). The first link is where it’s building the dhcp config file. The second is where it’s gathering the subnet mask information. The third is where it’s converting the data for use as the subnet mask.
https://github.com/FOGProject/fogproject/blob/dev-branch/lib/common/functions.sh#L1950
https://github.com/FOGProject/fogproject/blob/dev-branch/lib/common/functions.sh#L91
https://github.com/FOGProject/fogproject/blob/dev-branch/lib/common/functions.sh#L163
-
@EspenU right but the ip and subnet are determined by what’s defined on the nic when you run the installer. While you can change these things I think your seeing class c subnet is because that’s what the nic was set for.
-
@Tom-Elliott The server IP is 172.16.200.251. The DHCP subnet section does not directly set the range, it only says in which subnet the range is located. At least that’s how I understand the config file, I’m no expert.
The range is specified further down in the same subnet section, so that’s where you would have to make sure that there is no conflict with the server IP.
