Confused by 26.7 upgrade

[klinebau]

If you're not able to read and understand release notes before updating critical components, OPNsense may not be the correct solution for you. Consider switching to a consumer product.

Sounds kind of harsh.  I agree that this is not a typical consumer product and that it requires users to understand what is impacted before blindly pressing the upgrade button.  On the other hand, I think that the release notes might better identify breaking changes to flag users where more research is needed.

[bamf]

This is neither a consumer product nor a commercial solution. This is the community edition of an enterprise firewall. If you choose to use it, you need to educate yourself and read the release notes of every update before pressing the button. Community support relies on users doing their homework. Expecting enterprise-grade stability and active hand-holding without carefully reading the changelog misses the point of a community edition.

[franco]

Some people are not aware, but it bears repeating:

In the context of the BSD licenses, the "as is" provision means that the software is provided without warranties, and the authors generally disclaim liability for issues, failures, or damages resulting from its use, including operational errors.

We try our best to describe the changes. The code is open so it also documents the changes in a straightforward (but still very technical) way. If you want more you may want to consider participating in this process: the documentation is open and the changelogs are open too.


Cheers,
Franco

[nero355]

And what is 'config.xml'?

Ehh... seriously... ?!?!

It's the file that holds your complete OPNsense configuration and can be easily downloaded for backup purposes via the webGUI so you can restore it in the current or new installation of OPNsense ;)


You have just hit a bad spot in time during the history of OPNsense in my opinion where a lot of migrations need to be done to be compatible with future source code upgrades or whatever it's officially called :
- ISC DHCP got moved to a plug-in.
Luckily migrating to either KEA or DNSmasq is pretty easy thanks to .CSV file exports for your Static DHCP Mappings.

- Firewall Rules (Leagacy) got moved to a plug-in.
Firewall Rules [New] is now the only Firewall Rules section and needs to be migrated indeed.
The official plan was before upgrading from 26.1 to 26.7 but luckily it's not that strict and can be done afterwards too!

- Port Forward just got renamed to Destination NAT.
So that was pretty easy :)

- Outbound NAT is going to be the new Source NAT from now on.
So this also needs migrating now.
The offical plan is during 26.7 and before upgrading to 27.1 next year, but maybe you can get away with doing that later on too... Dunno...

And last but absolutely not least :
!!! Upgrade your Bootloader after upgrading to 26.7 !!!
However this is a FreeBSD thing and not OPNsense specific ;)

Once we get all this stuff behind us I am sure the updates/upgrades will be a lot less hassle than they seem to be now :)



Good luck! with all of the above...

[defaultuserfoo]

Some people are not aware, but it bears repeating:

In the context of the BSD licenses, the "as is" provision means that the software is provided without warranties, and the authors generally disclaim liability for issues, failures, or damages resulting from its use, including operational errors.

We try our best to describe the changes.

of course

And you're doing a fantastic job.  All the OPNsense installations I've to do with have been working 100% reliably without problems for years now, and that is quite an accomplishment.  Thank you.

The code is open so it also documents the changes in a straightforward (but still very technical) way. If you want more you may want to consider participating in this process: the documentation is open and the changelogs are open too.


Cheers,
Franco

Let me suggest this:

What if you were to point out the changes that may possibly break stuff for users or hide things more clearly, plus a link to the release notes, instead of presenting the relatively short note and the long list of detailed changes that is being shown when someone is about to update?

That might give room for the real important stuff, and when someone wants to know all the details they would still be easy to find.

The long list seems to me like it might be good information for developers and users who have been following the development rather closely --- and such users are probably interested only in a particular issue or change and not the whole list anyway.

I don't think you can expect from the 'normal user' to be familiar with all the details, and it doesn't --- and shouldn't --- matter what all the details are.  But, for example, it matters to the 'normal user' to know that it's a bad idea to use the firewall rule migration tool and/or that the 'normal user' needs to install a certain plug-in when he wants to en-/disable firewall rules after the update.  Why aren't we told such things?  Why are we being told things that don't mean anything to us instead?

Perhaps it might help to make updates less confusing :)

[defaultuserfoo]

This is neither a consumer product nor a commercial solution. This is the community edition of an enterprise firewall. If you choose to use it, you need to educate yourself and read the release notes of every update before pressing the button. Community support relies on users doing their homework. Expecting enterprise-grade stability and active hand-holding without carefully reading the changelog misses the point of a community edition.

That the idea of 'community' --- whatever that idea might be --- is attributed to something doesn't mean that everyone who comes in contact with that something has to be educated to such an extend as, for example, to be able to read the very source code of all the components of a product like OPNsense.  Communities running (school) busses to transport residents (kids) usually do not require such residents (kids) to able to rebuild the engines of the very busses in order to use them, and they don't require the users of the busses to follow all the maintenance logs in detail in case a bus might have a flat tire or needs an engine rebuilt.  They don't even expect something like that from the bus drivers.

'Community' is a horribly overinflated word since a long time now such that it has become virtually meaningless.

There is only so much anyone can do.  Don't expect the bus drivers to rebuild the engines.  Don't expect the manufacturers of the busses to produce perfect busses the engines of which never fail.  And when someone suggests how the bus could be easier to use, don't just ignore his suggestion, and don't blame the user as uneducated and not sufficiently competent to use the bus.

Make it so that the bus driver can easily change a flat tire.  Make it so that everyone can understand the timetable.

Fortunately I don't need to use busses.  Last time I tried there wasn't even a timetable.  If there had been one, I probably wouldn't have been able to understand it.  These timetables are not for 'normal users'.  Busses suck.

[defaultuserfoo]

And what is 'config.xml'?

Ehh... seriously... ?!?!

It's the file that holds your complete OPNsense configuration and can be easily downloaded for backup purposes via the webGUI so you can restore it in the current or new installation of OPNsense ;)

Yeah I download the configuration every now and then, but the file has a pretty long name I don't pay a lot of attention to other than always saving it in the directory designated for it.  Besides, 'config.xml' is a very generic name.  What do you think how many files with that name do you have?

And what are these items


o firewall: move config.xml default LAN allow rules to new rules GUI
o firewall: legacy rules pages move to plugin


in the change log supposed to tell me?  I'm not familiar with the format and the contents of a file with the generic name 'config.xml'.  I don't know where and how firewall rules are stored.  What's with 'default LAN'?  That entry doesn't tell me anything because it's incomprehensible and meaningless to me.

What are the 'legacy rules pages'?  I happen to have an idea because I migrated my rules.  After migrating, there were still the automatic rules left and I didn't dare to delete those.  Now I can't see them anymore, if they are still there.  Will they stay forever now?  If I hadn't migrated, that entry would also be completely meaningless to me.

Where do the release notes tell me that I can't en-/disable firewall rules without installing a plug-in?  That would have been a relevant information.

You have just hit a bad spot in time during the history of OPNsense in my opinion where a lot of migrations need to be done to be compatible with future source code upgrades or whatever it's officially called :
- ISC DHCP got moved to a plug-in.
Luckily migrating to either KEA or DNSmasq is pretty easy thanks to .CSV file exports for your Static DHCP Mappings.

Dunno, ISC DHCP is still there.  I was wondering if there is a way to migrate and hoping for one.  It would be very tedious and error prone to do it all manually.

Where in the release notes were we told that there is some kind of DHCP migration tool and how to use it?

- Firewall Rules (Leagacy) got moved to a plug-in.
Firewall Rules [New] is now the only Firewall Rules section and needs to be migrated indeed.
The official plan was before upgrading from 26.1 to 26.7 but luckily it's not that strict and can be done afterwards too!

A couple weeks ago I was told it'll be years before a migration is required.  I do hope it's still many years because if I'd have to migrate, I'd have to completely redo those installations because the migration tool doesn't work.  That would take a week or so.

- Port Forward just got renamed to Destination NAT.
So that was pretty easy :)

- Outbound NAT is going to be the new Source NAT from now on.
So this also needs migrating now.
The offical plan is during 26.7 and before upgrading to 27.1 next year, but maybe you can get away with doing that later on too... Dunno...

Yeah I noticed.  From my perspective, fortunately it was merely a change in naming.  I didn't do anything with source NAT.

And last but absolutely not least :
!!! Upgrade your Bootloader after upgrading to 26.7 !!!
However this is a FreeBSD thing and not OPNsense specific ;)

Upgrade the bootloader?  Was that mentioned anywhere?  Doesn't that work automatically?  How would I upgrade it?

Once we get all this stuff behind us I am sure the updates/upgrades will be a lot less hassle than they seem to be now :)

The firewall rules were a nightmare, and that was handled badly by not telling us that we don't need to migrate and that the migration will break all the rules.  Instead it was made to appear as a harmless migration, using that tool, taking a look at the export to see if it looks messed up or not, and importing it.  It looked fine and all the rules were broken after the import.

A big fat warning is required, but there was none, and there still doesn't seem to be one.

Good luck! with all of the above...

Thanks, to you too.

[Plethodon]

Some people are not aware, but it bears repeating:

In the context of the BSD licenses, the "as is" provision means that the software is provided without warranties, and the authors generally disclaim liability for issues, failures, or damages resulting from its use, including operational errors.

We try our best to describe the changes. The code is open so it also documents the changes in a straightforward (but still very technical) way. If you want more you may want to consider participating in this process: the documentation is open and the changelogs are open too.


Cheers,
Franco

Seems I unintentionally stirred up a lot of feelings about the upgrade.

First, it's safe to say that I failed to read the upgrade notes prior to upgrading. That's on me. And, in an odd way, it's a testament to the previous upgrades, which were so smooth that I never felt compelled to read the notes. That was my mistake.

Second, I can't speak to whether the release notes would have adequately prepared me for the big change, since I didn't read them. It sounds like some people were fine with the communication and some were not. In the future, I'll examine the release notes closely.

Thanks to the devs for all their work.

[Patrick M. Hausen]

@Plethodon a very supportive conclusion. Thanks.

[notspam]

If you take a step back and look at the issue constructively and compare it with how well-known firewall manufacturers handle things there is certainly room for genuine improvement.
Without background knowledge, the release notes are indeed very sparse.

So, here is a suggestion:

Either expand the release notes with more text and explicitly highlight where the admin needs to take action...

...or, alternatively, provide both release notes (the current brief version) and separate "upgrade notes." The upgrade notes would contain the specific details regarding what needs to be considered during the upgrade process.

That would genuinely improve quality for everyone and reduce mishaps.
And yes, simply clicking without reading isn't good practice, but this approach would make the process far more transparent.
It would also save both the user and the manufacturer a lot of support-related effort.

[franco]

As an additional data point: business edition uses are less likely to make a case for unclear release notes/documentation.

> Either expand the release notes with more text and explicitly highlight where the admin needs to take action...

It's an option, but it will also considerably slow down development progress while it would ignore the simple fact that not everyone will always understand everything.  Sometimes it's wording.  Sometimes it's a language barrier.  Sometimes it's a skill issue.  I think the forum or even Reddit is a much better platform for personal attention than "getting it right the first time" and questions still popping up regardless.

One example is:

https://github.com/opnsense/changelog/blob/master/community/26.7/26.7#L98

I don't see how that is unclear.  But there have been at least a dozen questions.


Cheers,
Franco

[notspam]

I've been working in this field for over 30 years.
And yes You certainly don't have to include everyone, definitely not.

But upgrade notes are truly industry standards in computer science. Having to gather information individually from Reddit, forums, and the internet is not standard practice. This has nothing to do with open source per se.

A clear document, which can happily incorporate the known issues to be addressed, and cross-links to the forum issues, would be ideal. I greatly appreciate opnsense and everyone's work.

But this is a real blind spot. And again, it's not about robbing agility. But more structure and transparency are also important in computer science.

Otherwise, there would be stable releases with full documentation and testing. But nobody wants that except shortly before major releases.

I would like to support this with the extended release/upgrade notes feature.
Perhaps a form of swarm intelligence is possible for that.

[Labber53]

The community has spoken. My contribution is that I am not recommending 26.7 for my clients. I'm running 26.1 in home lab.
My net promoter score dropped from a 8 to a 6. That said, I'm willing to help with crowdsourcing getting things testing and documented.

[defaultuserfoo]

https://github.com/opnsense/changelog/blob/master/community/26.7/26.7#L98

I don't see how that is unclear.  But there have been at least a dozen questions.


Cheers,
Franco

"All rules will continue to work regardless of the plugin being installed or not and are easily migrated using the given assistant."

Apparently the rules didn't continue to work.  That they are 'easily migrated' is definitely wrong.

"If you want to be on the safe side during the upgrade itself please remove the plugin before proceeding."

Which plugin is that?

Other than that, I'm finding the section with the 'Migration notes, known issues and limitations' the most important and relevant part of these release notes.

[defaultuserfoo]

The community has spoken. My contribution is that I am not recommending 26.7 for my clients. I'm running 26.1 in home lab.

What do you recommend instead?