After Update 2.7.2 / 23.09.1

jrey

Interesting,

so for the first one I already post it above (but still is)
20231209-1757

for the pkg-static it is
2023-12-09T19:39:03+0000

and from the boot log it is
FreeBSD 14.0-CURRENT aarch64 1400094 #1 plus-RELENG_23_09_1-n256200-3de1e293f3a: Wed Dec 6 20:59:18 UTC 2023

The 9th being Sat, the official release before that and the install being Sunday the 10th.

the 2.7.2 test box as mentioned, the dates are more in line. It was installed Friday (8th) and all three dates there are on the 6th.

sounds like the repo perhaps got something different than what was first released sometime between Sat and Sun morning ?

the test box is a virtual, I wonder what would happen if I went back to the snapshot at 2.7.1 and applied the update again now. That might be a test later, if time permits. Other fish in the pond right now.
(Although I could, I am not going to do this on the production box, by going back to the ZFS snap. Seems working fine. Don't fix it.)

This certainly isn't a crisis by the way. Just seems odd.

stephenw10

Yup it's just confusing this close to a release. In fact I believe it's expected. Still digging though..

jrey

@stephenw10

Don't dig to hard...

is just odd that once a product is released the repo would end up with newer builds. A test repo sure, but production just seems like it should be frozen in time until a new release requires a new repo.

Maybe the "new" build was just to accommodate whatever took the repo's offline for most of yesterday. (although they went away shortly after I did the upgrade, and then remained unavailable for several hours)

jrey

@stephenw10

Don't want to keep hijacking the other thread or create a new one for this really. So this will be completely out of context on this thread and people can just scratch their head and ignore it

however over there you said:

Open a feature request for it if you want. However that is the expected behaviour it's not a bug.

Sorry, but anything that allows Joe User to shoot themselves in the foot (and this does) should not be "expected behaviour".

It is the current behaviour, true, i recognized that right away, but it should not be labeled as "expected" just because it is "current"

Your comment as a Netgate rep, makes me not sure I really care enough about it to create a change request either. It's not really a problem I have. I recognized what it was/is doing right away and know what it's doing. But Joe U might not, but the position it is "expected" is typical of so many companies. When they know full well it has the potential to break stuff for Joe U and elect to call it expected not a bug. Just baffles me.

-my 2 cents

I've removed my messages on the subject from the other thread.

stephenw10

If you add a feature request then other devs can make comments or suggestions on there.

My own opinion is that if you are able to add custom patches then we are limited in what we can or should do to prevent foot shooting. There's nothing to stop someone adding a custom patch that breaks everything whether that be applying or reverting. We could prevent adding custom patches that way at all but there are a lot of people using that. We could perhaps improve the warnings around using the package at all.

jrey

@stephenw10 said in After Update 2.7.2:

limited in what we can or should do

respectfully disagree. You can as I suggested:

display a warning on save (of new one that can't actually apply)
and
during / after an upgrade scan the patches and do the same determination, don't just automatically set the ones that are auto apply to apply if the changes already exist. flag them in the GUI as not required.

If I find some cycles, I'd actually consider "patching" this myself. That's how serious the problem could be for our friend Joe U.

There's nothing to stop someone adding a custom patch that breaks everything

That's true, you can't fix stu..pid. But that's not the case here - this is 100% a preventable situation on both counts, and the system should therefore protect itself and remain flexible as much as it can within the framework.

lot of people using that

Yup for sure. Me included. That's the main way I fix stuff that is "broken" that I know will never get fixed, but is required for operation in our environment -- I have a laundry list (actually a set of 8 patches at this time) that get reverted before every major update - re-evaluated with every new release and reapplied as required. ... I'm not open to discussion what those 8 items are in an open forum.

But if in some cases the redmine is closed as "not required" there is generally no point in continuing - just easier to fix it and move on.

Over and above those 8, there are redmine items (for example one we (you and I as I recall, but could be wrong on that) have discussed in the past (regarding the Traffic Graph Widget of all things)
That redmine is showing as affected version 23.05.1 Status New and 0% done, even though there is a patch on the ticket not a single comment since 10/28/2023 except one person who commented (a month ago) that "I can reproduce this in version 23.09"
I guess I could also just go on to redmine and comment saying "still in 23.09.1, but the patch still works." Seems futile since it hasn't even been looked at, in 2 months. Bigger fish and all.

Thanks for the banter,

EyeTap

What was seconds, is now in the minutes category.

I can confirm this observation - interestingly not right after the upgrade though but after 24 hrs after a final reboot.

Here fetching both the installed and available packages takes like 30 seconds.
The Update page takes about 30 seconds to open and further 30 seconds to check if the installation is up to date or not.
Opening the update settings page then also takes ~30 seconds to load...

I came from 2.7.1 where I couldn’t notice this behaviour - pfsense is running on a physical box, CPU usage is low and the bandwidth is fine, so I can’t see any bottleneck there…

More an annoyance than a true issue though….

jrey

@EyeTap

Here fetching both the installed and available packages takes like 30 seconds.

not here those pages are pretty quick maybe around 10-15 seconds to open and display the packages.

The Update page takes about 30 seconds to open

longer here, really haven't looked into it. this is where the delay is for me, just loading the page. and switching the tab is just as bad, that doesn't make sense.

further 30 seconds to check if the installation is up to date or not.

once it loads, another 10-20 seconds is typical for checking if there is something available. This would be while the cog is spinning (this seems pretty normal)

It's not really spending a lot of time going to the page. So almost never. There is enough noise when a new version is available, it becomes really obvious when it is time to check it.

That said, still the same observation today.
so for me this item is filed under category "of it is what it is"

stephenw10

@jrey said in After Update 2.7.2:

That's true, you can't fix stu..pid. But that's not the case here - this is 100% a preventable situation on both counts, and the system should therefore protect itself and remain flexible as much as it can within the framework.

As I say open a feature request for it. You may find other developers agree with you. I wouldn't be me coding that anyway.

jrey

@stephenw10 said in After Update 2.7.2:

Still digging though..

Add this to the low priority "dig" re packages (dig being the reference for unbound )

in the update ( 23.09.1)
the update log shows

unbound: 1.18.0 -> 1.18.0_1 [pfSense]

Number of packages to be upgraded: 9
[1/9] Upgrading unbound from 1.18.0 to 1.18.0_1...
===> Creating groups.
Using existing group 'unbound'.
===> Creating users
Using existing user 'unbound'.
[1/9] Extracting unbound-1.18.0_1: .......... done

unbound is working no issue, but it is logging itself as 1.18.0
and running the command

unbound -V

reports 1.18.0

where as in the 2.7.2 release there is no mention of unbound being upgraded to _1

unbound -V also reports 1.18.0 on that version
maybe that's the package the got slipped in ? or is expected

either way on 23.09.1 it is not reporting what is says was installed..

We can talk about the curl package too.. Upgraded on 23.09.1 now running 8.5.0 but 2.7.2 is still running 8.4.0 maybe that is also expected?

from 23.09.1 upgrade

Installed packages to be UPGRADED:
	curl: 8.4.0 -> 8.5.0 [pfSense]
	isc-dhcp44-relay: 4.4.3P1_3 -> 4.4.3P1_4 [pfSense]
	isc-dhcp44-server: 4.4.3P1_3 -> 4.4.3P1_4 [pfSense]
	openvpn: 2.6.5 -> 2.6.8_1 [pfSense]
	pfSense: 23.09 -> 23.09.1 [pfSense]
	pfSense-default-config-serial: 23.09 -> 23.09.1 [pfSense]
	pfSense-repo: 23.09 -> 23.09.1 [pfSense]
	strongswan: 5.9.11_1 -> 5.9.11_3 [pfSense]
	unbound: 1.18.0 -> 1.18.0_1 [pfSense]

from 2.7.2 upgrade

Installed packages to be UPGRADED:
	isc-dhcp44-relay: 4.4.3P1_3 -> 4.4.3P1_4 [pfSense]
	isc-dhcp44-server: 4.4.3P1_3 -> 4.4.3P1_4 [pfSense]
	openvpn: 2.6.7 -> 2.6.8_1 [pfSense]
	pfSense: 2.7.1 -> 2.7.2 [pfSense]
	pfSense-default-config: 2.7.1 -> 2.7.2 [pfSense]
	pfSense-repo: 2.7.1 -> 2.7.2 [pfSense]
	strongswan: 5.9.11_2 -> 5.9.11_3 [pfSense]

stephenw10

The curl pkg was updated in the repo. Upgrades after it was will have 8.5.0. Anything that was already upgraded can get it using pkg upgrade if needed.

The Unbound package had the port revision bumped to pull in a fix to a patch we carry:
https://github.com/pfsense/FreeBSD-ports/commit/4749e98e2dbffb8e725f68e5b437c5056c55a0bc

jrey

@stephenw10

Thanks

so the question about unbound wasn't so much about the difference between 2.x and 23.x but more about 23.x saying it is still reporting itself as 1.18.0 when it should be 1.18.0_1 ? is that the expectation?

unbound -V
reports 1.18.0

sounds like these are the parts that caused the Dec 9th date on the install completed on Sunday morning. Seems to answer that. Packages were added a couple of days after the release, and earlier installers will be "missing" or running older versions of those packages. I guess what they don't know won't hurt them.

Thanks for the clarity.

Patch

@jrey said in After Update 2.7.2 / 23.09.1:

So what I think you are saying that packages on a released build are changing in the background and after the release?
therefore those folks that updated earlier will have a different system than those who update later.. seems like the potential for a support nightmare.

@stephenw10 said in After Update 2.7.2 / 23.09.1:

We commonly upgrade packages for fixes between releases when required.

@stephenw10 said in After Update 2.7.2 / 23.09.1:

Anything that was already upgraded can get it using pkg upgrade if needed.

The Unbound package had the port revision bumped to pull in a fix to a patch we carry:
https://github.com/pfsense/FreeBSD-ports/commit/4749e98e2dbffb8e725f68e5b437c5056c55a0bc

Err
How is a user expected to know

a package such as unbound has been updated in the Netgate repro and
if they had delayed their update they would have got it but
on their install they have not as they updated early.

or does this mean users should intermittently run pkg upgrade just to in case as the "Upto to date" status may not be accurately reported in System -> Update -> System Update

jrey

@Patch

My Opinion... no you shouldn't have to --

when they "release" a system the repo for that Release version should be frozen at that version. You should never get a different bundle on Monday compared to what you got on Friday, or any other date span.

If they have to add something that was missed or late to the party. it should require a new repo.. ie 23.09.2 (or 23.09.1p1)

Slipstreaming packages into a released product is just bad practice for oh so many reasons.

if you look at my comments on this thread, even the announcement of the release wasn't "clean"

https://forum.netgate.com/topic/184642/netgate-releases-pfsense-plus-software-version-23-09-1-and-pfsense-ce-v2-7-2/7?_=1702381351314

Currently I'm trying to get through a security audit (these happen periodically in the real world) There has to be documentation on what changes are applied, when, by whom etc. Versions numbers typically have to match or auditors tends to get cranky. (so for example the unbound says 1.18.0_1 was installed but the package itself reports 1.18.0 this is NOT a pass, guaranteed. -
They are not running with the "big boys" in regards to releases and control.

I mean I get it, their lower end line of products are not intended for secure environments. But still basic adherence to release practices should not be that hard.

stephenw10

@jrey said in After Update 2.7.2 / 23.09.1:

more about 23.x saying it is still reporting itself as 1.18.0 when it should be 1.18.0_1 ? is that the expectation?

That is expected. Unbound itself, the compiled binary, is still 1.18.0 and so will report that when you call it. The port version was bumped to _1, you should see that from pkg info unbound

jrey

@stephenw10

yes I know, but that's not necessarily what the audit looks for.
They look for the what was installed see 1.18.0_1 and what is running "unbound -V" and logs both say 1.18.0

then it turns into a big long discussion about why, to mitigate the concern.

If the versioning just matched there would be no question. period.

johnpoz

@jrey said in After Update 2.7.2 / 23.09.1:

If the versioning just matched there would be no question. period.

I don't think that is going to happen with something like this - freebsd backported some stuff from 1.19 to the 1.18 release I believe.. There is not actual 1.18.0_1 from unbound (nlnetlabs).. see here

https://www.freshports.org/dns/unbound/?page=1#history

Or maybe the came up with their own fix and provided it in their package.

This is not uncommon in packages for linux and or bsd distros..

stephenw10

I understand. I'm not sure what we can do about it though. That's how the ports system has always worked AFAIK.

jrey

@stephenw10 said in After Update 2.7.2 / 23.09.1:

I'm not sure what we can do about it though

report with and display the version number from package it was installed with ? (yes I know that's a little more complicated feature, and likely wouldn't fly, but it would certainly simplify life) As it is, given the file date, build date, install log although not idea it is something that can be explained to mitigate the concern.

Not even going to bring @johnpoz 's response into the mix the last thing anyone needs to enter into the mix is that the back port came from yet a different version. I get it the _1 is a little of this a little of that. But the less of that, that requires explaining the easier it is to explain

Thanks guys,

johnpoz

@stephenw10 said in After Update 2.7.2 / 23.09.1:

That's how the ports system has always worked AFAIK.

As far back as I can remember on anything - that has always how ports have worked.. You can see a different version on the package then is actually what the application/binary version is.. This is not something for pfsense to tackle..

I feel for you if your auditors are idiots - most of them are, and many of them don't even understand what is going on other than some checkbox that matches up..

I could share many stories of dealing with their moronic take on things.. No I am not going to give you the user password hashes in the db so you can run a bruteforce on them.. If your saying its a concern - then you get the db from your box actually connected to the network as a normal user.. If the user circumvented the policy of using 3 out of the 4 with Pa55word! That is what the user did, the policy is met..

I have more of concern of giving you my user hash db - that you might leave on a usb stick in starbucks or something ;)

Why does the screensaver timeout have to be set to 2 minutes in the secured server room, that you need not only to auth to get into the building, but you also need to get through the security door into the server room with your code at the door. Twice there are 2 doors, one with your badge and 2nd with code.. And nobody is allowed in the server room other than IT admins without escort.. So why should the screen saver kick in and force me to reauth in 2 minutes.. Why can I not set it to 20 minutes..

Why do I need to change the emergency admin passwords, that are unique for every machine and locked in the safe in a sealed envelope every 90 days.. When the passwords have never been used? And nobody knows them to have possible leaked them.