1.3.0 installer does not handle class B IP's correctly with DHCP

[EspenU]

@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.

[Wayne Workman]

@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]

Okay. You wrote it.

[Tom Elliott]

And if you look, it’s using the network address to supply the subnet anyway.

[Tom Elliott]

https://github.com/FOGProject/fogproject/blob/dev-branch/lib/common/functions.sh#L1985

[Wayne Workman]

@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.

[Wayne Workman]

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#L1952

And 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]

@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).

[Wayne Workman]

@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.

[Tom Elliott]

@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.

[Wayne Workman]

@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?

[Tom Elliott]

@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.

[Wayne Workman]

Only if it’s not already set:
https://github.com/FOGProject/fogproject/blob/dev-branch/lib/common/functions.sh#L1950

[Tom Elliott]

@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.

[Tom Elliott]

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]

I agree.