What is release 2.3_1?
-
This seems to be a very specific update and you are only able to identify if it's applied going to System > Update.
If you aplied it you will see here the 2.3_1, on main page you will only see 2.3-RELEASE.
–
Are you sure you want to update pfSense system?
Current Base System 2.3_1
Latest Base System 2.3_1
System is up to dateAnd I also would like to know what this "update" fixed/changed.
-
A system mail would be nice if a system or package update is available.
-
@x-ecuter ntpd got an update
-
More info here:
https://blog.pfsense.org/?p=2045
https://doc.pfsense.org/index.php/2.3_New_Features_and_Changes#Update_Patches
-
Flawless update. Slick stuff :)
-
Slick update, I agree.
Updating via System / Update / System Update included an update of an out-of-date package (pfBlockerNG), without asking or alerting, just doing it as part of the system update. Is this as expected, or a bug?
-
Updating via System / Update / System Update included an update of an out-of-date package (pfBlockerNG), without asking or alerting, just doing it as part of the system update. Is this as expected, or a bug?
That's expected, though should probably be made more clear. It's the same in that regard as it's always been, every base system update also updates all your packages. And significantly better than it used to be, since it'll only upgrade packages that are outdated (where 2.2.x and earlier would uninstall and reinstall all packages even if they were already up to date).
-
>>> Updating repositories metadata... Updating pfSense-core repository catalogue... pfSense-core repository is up-to-date. Updating pfSense repository catalogue... pfSense repository is up-to-date. All repositories are up-to-date. >>> Unlocking package pfSense-kernel-pfSense... done. >>> Downloading upgrade packages... Updating pfSense-core repository catalogue... pfSense-core repository is up-to-date. Updating pfSense repository catalogue... pfSense repository is up-to-date. All repositories are up-to-date. Checking for upgrades (5 candidates): ..... done Processing candidates (5 candidates): ... done The following 2 package(s) will be affected (of 0 checked): Installed packages to be UPGRADED: pfSense: 2.3 -> 2.3_1 [pfSense] ntp: 4.2.8p6 -> 4.2.8p7 [pfSense] The process will require 2 KiB more space. 493 KiB to be downloaded. Fetching pfSense-2.3_1.txz: . done Fetching ntp-4.2.8p7.txz: .......... done Checking integrity... done (0 conflicting) >>> Upgrading necessary packages... Updating pfSense-core repository catalogue... pfSense-core repository is up-to-date. Updating pfSense repository catalogue... pfSense repository is up-to-date. All repositories are up-to-date. Checking for upgrades (5 candidates): ..... done Processing candidates (5 candidates): ... done Checking integrity... done (0 conflicting) The following 2 package(s) will be affected (of 0 checked): Installed packages to be UPGRADED: pfSense: 2.3 -> 2.3_1 [pfSense] ntp: 4.2.8p6 -> 4.2.8p7 [pfSense] The process will require 2 KiB more space. [1/2] Upgrading ntp from 4.2.8p6 to 4.2.8p7... [1/2] Extracting ntp-4.2.8p7: .......... done [2/2] Upgrading pfSense from 2.3 to 2.3_1... [2/2] Extracting pfSense-2.3_1: ... done >>> Removing unnecessary packages... done. >>> Cleanup pkg cache... done. >>> Locking package pfSense-kernel-pfSense... done. SuccessImpressed ….. !
-
So 2.3_1 is not 2.3.1 and you can upgrade from 2.3_1 to 2.3.1?
And, after updating to 2.3_1 it does not actually address the problem until a manual process is performed outside of the update?
This is really confusing. No?
-
the update should be referred to it's full name, 2.3.0_1, to minimize confusion. And yes you will be able to update to 2.3.1.
-
it's full name, 2.3.0_1, to minimize confusion.
Are you sure you minimize confusion with this 'unexpected' naming scheme?
A lot of different options come to mind that may have been easier to understand. But maybe not to implement into your system? -
pfSense team, please change the naming scheme. And, please restart all the necessary services after a patch is applied to minimize misconfigured/unpatched production systems.
-
Nice new update system. Works pretty well. Happy to see no reboot required for this one. Yes would like to see release notes in the updater to give us an idea what to expect and anything we need to do.
No, I wouldn't want automatic restart of services long as the updater tells me which ones I need to restart since in production it may disrupt anybody using it.
-
…would like to see some frequent updates for openSSL in the future ;-)
https://www.openssl.org/news/secadv/20160503.txt
-
pfSense team, please change the naming scheme. And, please restart all the necessary services after a patch is applied to minimize misconfigured/unpatched production systems.
+1 for this
-
…would like to see some frequent updates for openSSL in the future ;-)
https://www.openssl.org/news/secadv/20160503.txt
Now that little updates of individual components can happen fairly easily, in some ways security updates for stuff like this could be done routinely, even if the particular security holes that are patched do not directly apply to pfSense use cases. Then people (or dumb security checking scripts) that check the version of these things will find it is up-to-date and be happy.
Of course there are the overheads in doing this of:
a) pfSense core people have to do a reasonable range of testing to avoid regressions.
b) Firewall admins may not appreciate having a (even small) update every couple of weeks, when it is strictly not essential. -
We can put out an update with much less of a test routine as in the past since testing can be limited to things that changed. But yeah one like openssl requires a lot more care than ntpd, since it touches a lot of things. The openssl fix is in 2.3.1 already. We're possibly releasing 2.3.1 soon enough that it'll be the first including it. If that's going to take a bit longer, we'll do a 2.3.0_2.
-
And when it gets to 2.4, to save confusion over the _1 _2 patches naming convention, it would be good to call it 2.4.0 - then every release has 3 numbers in it up front, and the patches add to the end - 2.4.0_1 …
Thus version 3 (one day/year!) would be 3.0.0 -
And when it gets to 2.4, to save confusion over the _1 _2 patches naming convention, it would be good to call it 2.4.0
Definitely, it ends up being too confusing without the implied zero there.
-
2.3a, 2.3b would have been way easier to understand than 2.3_1 while working on 2.3.1
But it's better than releasing an updated 2.x version without suffix which we already had as well…
