pfSense+ 22.05/Wireguard dependency not documented

[gabacho4]

@bigtfromaz because if you weren’t going to update your pfsense version, or there wasn’t a new version, you could update your packages and be on your way. But if you’re going to update version, don’t touch the packages. It’s really not complicated and it’s literally documented in its own text box titled Warning.

[KOM]

@gabacho4 It's a completely absurd way of doing things. This has been a problem for several years now already. It's ridiculous to offer packages to an unsupported platform and then expect the users to know not to update. I'm glad it's finally being fixed.

[bigtfromaz]

@jimp 2 years old and it doesn't seem that difficult, but I get it. There may be a number of UI issues, and policy decisions involved in this one.

An intermediate step might be in order. A message could be displayed, triggered when a package is selected for update and a system update is available. You could then display something like "Warning! A system update is available. System updates should always be applied before package updates." Then allow the user to proceed at their own peril. I suspect this step could be implemented with a small, localized pull request.

Which brings me to the title of my post. "dependency not documented"

Long term, merely hiding all new packages is incomplete. Adding system dependencies to package metadata would allow you to display only packages tagged to run on the current system level as well as record inter-package dependencies. This capability is found in many package managers, e.g., NuGet, Maven, Docker, Linux... You can chase dependencies up and down the hierarchy during package upgrades. As long as the metadata is accurate, users won't be able to break things as easily as they do now.

[bigtfromaz]

@gabacho4 said in pfSense+ 22.05/Wireguard dependency not documented:

It’s really not complicated and it’s literally documented in its own text box titled Warning.

I don't appreciate your condescending tone.

Where is that text box? We still have a number of other routers still running 22.01 and they are all showing package upgrades available in the Package Manager including the WireGuard with the undocumented dependency, AND NO WARNING.

Are you saying that users are supposed to memorize the documentation? If so, then, well...I'm stumped.

[bmeeks]

@gabacho4 said in pfSense+ 22.05/Wireguard dependency not documented:

@bigtfromaz because if you weren’t going to update your pfsense version, or there wasn’t a new version, you could update your packages and be on your way.

Unfortunately this statement is incorrect in the context of a pfSense update being available! If you update the packages with a new pfSense upgrade showing as available (and you neglect to reset the package repo pointer on the SYSTEM > UPDATE menu), then you will very likely corrupt the system in one or both of these two ways.

The first way is the package update might drag in a new version of some critical shared system library and that new library may break the existing OS install. The current package repo is always recompiled against the new kernel when a pfSense update is posted.

The second way- which is less "fatal" than the first- is the package update brings in some updated support libraries for that package, and those new libraries are compiled under a new FreeBSD version (the new version in the offered pfSense upgrade, for example) and thus will not run on the existing pfSense kernel. So your updated package is now broken and will not run on the current pfSense version.

Bottom line is NEVER update packages when a new pfSense version is also being offered as an upgrade UNLESS you go to the SYSTEM > UPGRADE page and change the Branch drop-down appropriately (to "Previous stable version xxx").

As @jimp mentioned in his post, there is a feature request to hide package updates when a pfSense version update is also available. Hiding the package update will help users to not shoot themselves in the foot.

I agree with others here that seeing an offered package update on the system itself, without an associated warning being displayed on the system itself, is setting folks up for failure. Sure, anyone can go read the docs, but not everyone memorizes each sentence and paragraph. Even with that said, good software should be as helpful as possible to keep the user from doing something detrimental to system health using controls and methods presented in the software itself. Ergo, pfSense proudly displaying an update is available for your favorite package but failing to tell you on the same screen that updating is not recommended at this time because it may brick your firewall ... .

[bigtfromaz]

@bmeeks Your "bottom line" was clear two cycles ago. I have to apologize for the confusion. My comment that you quoted was directed to @jimp at Netgate with thoughts about the evolution of the opensource product. It wasn't meant to consumed in the current tense.

With that said, I do apologize conflating two concepts in my note to @jimp. Let me state these more clearly now. They are in fact suggestions for improvement targeted for Netgate.

1: Today, the moment you make a new pfSense release available, package authors can no longer release critical fixes for currently deployed packages. Your package manager lacks the ability to identify which packages work on which release. I know this because I see two packages available on our other three pfSense+ routers. WireGuard, which we determined cannot run on the current release by virtue of a production outage; and another which we can no longer assume is safe to install. Yet there they are.

Frankly, this is a giant blotch on the superior painting that is pfSense. The availability of a new pfSense release should not matter when maintaining and deploying packages built and tested for the current release. The only thing that should matter is knowing which packages have been tested and released for the currently running version of pfSense. Here's a rhetorical question, "What do we customers do if a currently running package develops a critical issue that requires a package update?" Right now, the answer is you might have to upgrade pfSense first. I can tell after a full career dealing with mission critical systems, this is not what enterprise organizations want to hear. What they want to hear is “We developed a patch and it’s available in the package manager, now.”

The solution is simple. Add a property to your package metadata, listing the pfSense releases on which each package/release is approved to run. Then, alter the pfSense package manager to show only package versions that have been tested for the current running release. Currently, our other three Netgate appliances might well show no available packages. But if you encounter a critical package issue in the future, you'll have an enterprise-grade way to manage the issue.

Deployments of new pfSense releases will remain robust and offer package authors more flexibility going forward. When you issue a new release, you simply add the necessary metadata to every package/version that's been tested. The package author must build, test, and certify each release they want made available on the new pfSense release. Or perhaps merely testing and certifying their current build is enough. In either case, their package metadata must be tagged for the new pfSense release. If the required testing is not completed for the new release, the package will not be available in the new pfSense release.

2: Packages-to-package dependencies are half implemented. When reading package descriptions, I see comments like this:

"FRR routing daemon for BGP, OSPF, and OSPF6 Conflicts with Quagga OSPF and OpenBGPD. These packages cannot be installed at the same time."

The statement is in text and provides critical information that belongs in your package metadata.

The solution may be to add an "incompatible package" list to your package metadata. This is a little more difficult because your package manager must now traverse a many-to-many relationship between the packages to determine acceptable coexistence. This will require a bit of logic to audit and detect circular dependencies. But any good software engineer should handle that without a lot of trouble. The bigger challenge will be resisting the urge to take a shortcut.

My bottom line, these are my thoughts for what they are worth. Take it as constructive criticism from a person who wants Netgate to thrive. These comments are focused on useability and are not meant to be a specification. Please don't critique them as anything more than that.

And...no response is required.

[bmeeks]

@bigtfromaz, I think you mistook what I meant. I actually agree with you pretty much 100%.

My "reply quote" was actually meant for @gabacho4's post, but he had referenced your name in his reply I was quoting, thus your name got pulled into my reply. I was correcting his particular statement about updating packages when a new pfSense version was available. I should have removed your name tag in the quoted reply, but I just plain didn't realize how it might come across.

[jimp]

You still have a fundamental misunderstanding.

Packages know which version they work with -- each release is on a separate branch and set of directories in the repository. The problem is that your firewall is looking at the new repository where the upgraded packages are because it wants to upgrade.

You can go and manually set the update branch to the legacy branch/previous release and then re-check for packages and it's fine.

We can, and have, published updates for packages on past releases when needed.

As for conflicts, The FreeBSD pkg system manages things like dependency checks/conflicts on some levels but the text in the GUI lets the user know in more explicit terms what does/doesn't work together.

[dotdash]

@jimp
I understand, but the current situation invites foot shooting and I hope the fix makes it off the todo list soon. A simple warning when you went to the package manager to either upgrade or change the the branch would suffice. That would help prevent users updating/re-installing packages from bricking the system.

[bigtfromaz]

@jimp Oh! I don't think we've ever bothered with those settings.

Why not merely set the default branch to the version that's currently running and hide the ability to select a newer release until is installed? You can move it forward for them during the base system upgrade, which is offered to them on the landing page.

That would hide the packages from the user until after the base system upgrade.

So now I'm back to my original reaction...two years?

[bigtfromaz]

@jimp Ok. So I took a few minutes and there's somthing I'm not getting.

When the Update setting is set to 22.05 the Package Manager shows two updatable packages, WireGuard 0.1.6_1 and ipsec-profile-wizard 1.0_4.

And much to my surprise, when the Update setting is set to 22.01, I see one updatable package WireGuard 0.1.6_1 !:

Is this correct? Is WireGuard 0.1.6_1 supposed to work on 22.01, or not? Upgrading WireGuard to 0.1.6_1 is the action that took down WireGuard in our NH router.

Here are the messages from the NH log that appear to describe the problem:

Jun 27 21:12:15 kernel linker_load_file: /boot/modules/if_wg.ko - unsupported file type
Jun 27 21:12:15 kernel KLD if_wg.ko: depends on kernel - not available or version mismatch

What's wrong?