This rtrim of ".0" is stripping any "0" from the end of the passed-in
version strings. That makes "2.3.10" become "2.3.1" which then removes
any chance of the following nice comparison logic working.
Just removing the "0" seems fine. It keeps the supplied version data
untouched, just getting rid of any trailing dots.
Apart from fixing the bug here, this change has the side-effect that a
version change from "2.3" to "2.3.0" will now be seen as an upgrade.
What is the requirement for that?
Do you want to have extra logic that checks for "bare" zeroes on the end
and make "2.3", "2.3.0", "2.3.0.0"... all be considered the same
version?
This is a resubmit of PR #1810 after integrating with the current
master.
For people that are running a development or RC version that is later
than the official release, this will display that on the dashboard
version check.
This is a resubmit of PR #1785 after integrating with the current
master.
If the user changes the subnet of an interface then applies without
adjusting the DHCP pool range/s to be in the new subnet, then an invalid
dhcpd.conf is generated. The DHCP server complains about it and exits.
If you have only 1 LAN with DHCP then it does not make a difference -
you are not going to get DHCP whatever happens because there is no valid
pool data. But if there are multiple LAN-style interfaces with DHCP then
you can cause no DHCP-service on LAN when you are messing with settings
on OPT1/OPT2...
I did this to myself last night, and even after rebooting got no DHCP
for either my LAN or OPT1, just because the OPT1 pool settings were bad.
This change checks that the pool ranges are in the interface subnet. If
they are not, then they are excluded from dhcpd.conf and a notice os
filed. The user gets the flashing notice stuff on the webGUI to tell
them what is wrong. And any other good DHCP interfaces+pools continue to
work.
This is a resubmit of PR #1783 after integrating to the current master.
Forum: https://forum.pfsense.org/index.php?topic=96827.0
Sometimes there can be unexpected stuff in a config. To avoid errors
like "PHP Fatal error: Cannot unset string offsets in
/etc/inc/upgrade_config.inc on line 291" it seems good to use
belts-and-braces checks with any unset() of associative array elements,
just in case the thing above is an empty string (instead of an array or
non-existent thing). An unnecessary error in processing the upgrade code
can mean missing other important upgrade stuff.
These are the places I could see in upgrade_config.inc where unset() is
not already protected by isset(). A lot of them are "that could not ever
go wrong", but IMHO it is worth protecting them all just to be sure.
This is a resubmit of PR #1773 after integrating with current master.
