[SOLVED] Future automatic major upgrades?

[denn;s]

Hey!

My company is considering moving from pfsense to opnsense and performing major upgrades automatically would make the decision easier. 
The feature of automatic updates was discussed here: Feature: Automatic updates #814
Actually, it does not install major upgrades or pass any parameters to the auto-update function.

This could be realized with e.g.:
- Auto-update parameters (maybe something similar to apt-get upgrade and apt-get dist-upgrade)
- Major upgrade cron job in the webgui
- Possibility to create custom cron job in the webgui and using opensense-update

I understand why it is not possible by default but in some usecases it would make sense.
So are you guys planning to add something like this in future releases?

regards
Dennis

[franco]

Hi Dennis,

Yes, eh, what can I say: maybe?

Major updates were always working prior to 17.1, because we'd never switch the FreeBSD major versions so the whole thing was mostly ABI-stable. It only took the next cron job to realise the critical section was reached (like 16.1.x upgrading to 16.1.20 before 16.7.x was unlocked).

The switch to FreeBSD 11.0 was too critical and some packages were always having ABI issues even on the same minor FreeBSD before so we really only added the major upgrades during the 16.7 series which made all of this possible. We surely did not want to automate this at all. There's not even a GUI button for that reason.

Now that we've made it through, I guess we can safely assume that this is the major upgrade cycle we will be going through twice a year.

I've added a ticket: https://github.com/opnsense/core/issues/1376

It will likely be the same cron job with the addition of a single parameter such as "PERFORM_RISKY_MAJOR_UPGRADE_IF_AVAILABLE". We should simply make clear this is a dangerous operation.

What do you think?


Cheers,
Franco

[denn;s]

Hi Franco,

thank you for the quick reply!

I've added a ticket: https://github.com/opnsense/core/issues/1376

It will likely be the same cron job with the addition of a single parameter such as "PERFORM_RISKY_MAJOR_UPGRADE_IF_AVAILABLE". We should simply make clear this is a dangerous operation.

That is exactly what we are looking for 
And we are totally aware of the risks in performing automatic major upgrades.
So we ensure doing tests, before updates/upgrades will go "productive"!
(e.g. own mirror)
And if you need someone to test it
<- ! 

best regards
Dennis

[franco]

Hi Dennis,

Thanks for the feedback. I'll do this in the next week and report back.


Cheers,
Franco

[denn;s]

Great !

best regards
Dennis

[franco]

Hi Dennis,

This was added just now, the cron parameter for auto-update being ALLOW_RISKY_MAJOR_UPGRADE

Support will be added to 17.1.10 and runs fine for 17.7 pre-releases from what I could see. On 17.1.9 and lower adding the parameter stops the auto-update from working currently. The price of progress..

See https://github.com/opnsense/core/commit/93072dd80


Cheers,
Franco

[Woi]

@denn;s is this working for you?

@franco yesterday I set ALLOW_RISKY_MAJOR_UPGRADE as only parameter for the "Automatic firmware update" cron job. OPNsense is 17.1.11_1-amd64 and I was expecting an upgrade to 17.7.1 this night. But I'm still on 17.1.11_1. Did I missed something or did I found a bug? If so, do you like me to fill a prober bug report on github?

Additional info:

Code: [Select]

root@gw:~ # sudo --user=nobody  /usr/local/sbin/configctl firmware auto-update
OK


Code: [Select]

Sep 1 05:40:03 lighttpd[37099]: (log.c.217) server started
Sep 1 05:40:02 configd.py: generate template container OPNsense/WebGui
Sep 1 05:40:01 configd.py: [f15ebc76-1a80-4261-8cf8-dd59866b1adc] generate template OPNsense/WebGui
Sep 1 05:40:01 lighttpd[98929]: (server.c.1828) server stopped by UID = 0 PID = 36244
Sep 1 05:40:00 configd.py: [dbd634a1-c328-40c3-9ad0-e1b64b00eb3b] attempting automatic firmware update


[franco]

Did you apply the cron changes? Saving is not enough. The parameter must show up in /var/cron/tabs/nobody


Cheers,
Franco

[Woi]

Oh my god. That was too obvious. Thanks for the quick reply.

But there is another thing in my mind: How do users, that do not follow the changelogs, get to know about this parameter?
Or more general: You're doing a great job and quick process with OPNsense, but I have the feeling documentation and help system are lagging behind.

[franco]

To be honest, we do not wish to document this particular feature because it is a support nightmare.

Reading the code or searching the forum is ok to get the proper context here.

Code that does exist but is not documented could also be subject to change so documenting it "permanently" will let users thing we broke something if we want to change it / replace it.

We're working on another feature soon for "scheduled" updates which will be self-explanatory in the firmware settings section:

https://github.com/opnsense/core/issues/1798

That being said, documentation grows, we're likely going to release the sources for 18.1 if all goes well as well. Hopefully receive a bit of help from the community, too.


Cheers,
Franco

[Woi]

To be honest, we do not wish to document this particular feature because it is a support nightmare.

Reading the code or searching the forum is ok to get the proper context here.

Code that does exist but is not documented could also be subject to change so documenting it "permanently" will let users thing we broke something if we want to change it / replace it.

We're working on another feature soon for "scheduled" updates which will be self-explanatory in the firmware settings section:

https://github.com/opnsense/core/issues/1798

Ok, that makes a lot of sense, at least for this particular feature.

That being said, documentation grows, we're likely going to release the sources for 18.1 if all goes well as well. Hopefully receive a bit of help from the community, too.

It would be great to allow for pull request for the documentation.  Indeed, that was something I planed  to create a feature request for