update notifications - business edition

[osn1803]

Hello -

I have been using the business edition for about a year.

I have noted that minor version bumps happen automatically and smoothly via the cron job "Automatic firmware updates".

Major version updates aren't automatic, and I'm not clear on what is the correct way to engage with those to avoid being silently stranded in a dead-end branch and not getting updates.

I also have a cron job for "Firmware update check", but it doesn't notify me of its results. Because of this, it appears I missed the security updates for CVE-2026-44194 & 45158 due to being on 25.10.2, and the host was waiting for manual intervention to upgrade to 26.4.

I see a couple of things I could do:

• Since monit does email its output, I could create a custom monit task to run or wrap /usr/local/opnsense/scripts/firmware/check.sh.
• I can subscribe to notifications for https://github.com/opnsense/core/security/advisories, but that requires me to verify that each is addressed, whereas I'd like to simply know that it's automated.

Is there a better or more supported way to manage the transition to new major versions without surprises or gaps? (Even better, is an LTS version on the roadmap someday?)

Thank you, and apologies for my ignorance.

[Patrick M. Hausen]

Major releases for the business edition are published exactly every April and every October. Just check this space for announcements, then.

The moment a new major release is published all prior ones are EOL. There is only ever one supported release, community or business.

So I don't get what you mean by silently stranded. If you don't run 26.4 you run EOL software.

[Monviech (Cedrik)]

If you put this as cron job parameter it will also do major upgrades automatically:

https://github.com/opnsense/core/blob/eb2800a9bd76060fa17937840e3498c31e4081d2/src/etc/rc.firmware.subr#L34

ALLOW_RISKY_MAJOR_UPGRADE

[osn1803]

So I don't get what you mean by silently stranded.

Right, and by "silently" I mean it simply stopped getting updates. What I was asking is where I should have tuned in to be warned that the version I'm running was about to be EOL.

I wasn't aware that it's simply scheduled semiannually, so thank you.

I would really like to see an LTS release with some dwell time / overlap. Forcing commercial customers to upgrade twice a year at a specific time isn't great.

[osn1803]

If you put this as cron job parameter it will also do major upgrades automatically:

https://github.com/opnsense/core/blob/eb2800a9bd76060fa17937840e3498c31e4081d2/src/etc/rc.firmware.subr#L34

ALLOW_RISKY_MAJOR_UPGRADE

That's potentially useful, thank you.

[osn1803]

Since I use Zabbix in this environment, I crafted a trigger to watch for changes to /tmp/pkg_upgrade.json, which check.sh creates. (We'll see how fragile that turns out to be.)

This addresses the notification requirement, but the lifecycle management problem remains.

I'll leave this as a plea for Deciso: as your commercial support offering matures, please prioritize moving to a more typical release model which provides a short period of security updates for the previous release after a potentially breaking update drops. A minimum of 6 months is usually reasonable, to allow for scheduling and testing.

The current situation dilutes the stability value of the subscription model, as it creates a scramble and an unavoidable gap in compliance and exposure twice a year.

[Al Muckart]

This addresses the notification requirement, but the lifecycle management problem remains.

I'll leave this as a plea for Deciso: as your commercial support offering matures, please prioritize moving to a more typical release model which provides a short period of security updates for the previous release after a potentially breaking update drops. A minimum of 6 months is usually reasonable, to allow for scheduling and testing.

Business edition releases happen every 6 months so I'm not sure that timeframe is realistic.

The current situation dilutes the stability value of the subscription model, as it creates a scramble and an unavoidable gap in compliance and exposure twice a year.

What's the compliance gap for you?

For me, the thing I'd like to see is assurance that intermediate releases won't require a reboot and that being behind on a hotfix release won't prevent package operations in the GUI until the hotfix is installed.

Working through change control etc. and doing an upgrade is fine every six months, but having a hotfix or other release come out right afterwards and require another service-impacting upgrade is a gigantic PITA.

[franco]

Hmm, planning ahead for maintenance and update tasks twice a year is not a compliance burden -- it's a benefit.

In reality the business edition lags behind FreeBSD EoL by 3 months at least, some times worse. We patch it but it adds extra burden. The FreeBSD ports tree will quickly deteriorate when OS versions are abandoned by them. There is little we can do to prolong the life of past versions without creating work so that the model of 2 versions in support at each point in time is maintainable long term. We don't want to make this 4 versions as we have to divide (and effectively decrease) our efforts for each one.

This is also a broader ecosystem issue... it's not a singe software. It's a bunde of OS, hundreds of third party software programs that need compiling and on top GUI integration and QA and seamless updates. All parts are moving quickly these days why should we stay still now more than 10 years ago when we started this pace.


Cheers,
Franco