Add Boot Environment [Snapshots] Integration - #7749
Conversation
This pull request introduces a new feature to the OPNsense web interface, allowing users to manage FreeBSD boot environments directly within OPNsense. This integration provides an intuitive and seamless way for users to create, manage, and switch between boot environments, enhancing system management and recovery options.
…his into core at some point. * remove model as it wasn't actually used * simplified api actions and left some comments for work still in need to be done * removed some unused code in the volt template ref: #7650
* move "not supported" to endpoint so we can use it in the same template * add some php doc to the endpoints * basic validations for name validity and duplication * cleanup the volt template to its bare minimum, which is more inline with how other components work at the moment ref: #7650
* cleanup python scripts, use one simple wrapper around bectl while keeping output roughly the same (errors could be simplified, but may be a next step) * make some columns sortable in the grid, including created time ref: #7650
* further simplify python script ref: #7650
Final bits and pieces to bring bectl into OPNsense. * Move BootEnvironments into Core package as this is likely a more logical place (and api endpoints look nicer, /api/core/boot_environment/) * Rename the menu item to Snapshots, when possible we prefer single clause names and snapshots might need less explanation for non-fbsd users (eventually, we are creating snapshots here) * Change zfs check message to a "alert alert-warning" dialog and change the text a bit * Remove used includes [use] in php files * Merge Menu and ACL with Core model, same as firmware ref #7650
|
@sheridans if you have time to test and review, that would be highly appreciated |
|
@AdSchellevis thank you for the time and effort you put into this, in such a short time frame, I'll run some tests. Excited to see this introduced. Thank you for helping getting this over the line! |
| private function find($fieldname, $value) | ||
| { | ||
| if (empty($this->environments)) { | ||
| $this->environments = json_decode(trim((new Backend())->configdRun('bootenvironment list')), true) ?? []; |
There was a problem hiding this comment.
we do have a "zfs" file for this, rather not clutter?
|
|
||
| $msg = null; | ||
| if ($this->findByName($name)) { | ||
| $msg = gettext('A boot environment already exists by this name'); |
There was a problem hiding this comment.
we may want to consider to rename all the "boot environment" strings to "snapshot" too. Similar to "BE" which is highly ambiguous in our scope.
| <name>System: Boot Environments</name> | ||
| <patterns> | ||
| <pattern>ui/bootenvironments/*</pattern> | ||
| <pattern>api/bootenvironments/*</pattern> |
| @@ -0,0 +1,41 @@ | |||
| [list] | |||
| command:/usr/local/opnsense/scripts/bootenvironments/bectl.py | |||
There was a problem hiding this comment.
I would also prefer this in system directory.
fichtner
left a comment
fichtner
left a comment
There was a problem hiding this comment.
Do we want to fix these things post merge? Up front would be cleaner I guess.
|
@fichtner yes, it looks like I missed a spot there indeed. |
* rename all "boot environments" to "snapshots" for consistency * merge zfs configd command with zfs template
This pull request introduces a new feature to the OPNsense web interface, allowing users to manage FreeBSD boot environments directly within OPNsense. This integration provides an intuitive and seamless way for users to create, manage, and switch between boot environments, enhancing system management and recovery options. Renamed the menu item to "Snapshots" in an attempt to explain the feature to non-FreeBSD users.
|
@sheridans @AdSchellevis thank you both 🎉 |
|
An option to automatically create a new snapshot before OPNsense performs an update would be perfect. This way you could skip the manual creation of a snapshot before you update. Is this included (yet)? |
|
Due to the fact that this quickly and sometimes inexplicably fills the disk it is not included at the moment. |
Could be solved with an additional option like "keep the latest X snapshots". |
|
No, it could not. A ZFS snapshot grows bigger with any subsequent change, such as logging. Thus, limiting the number of snapshots is essentially useless to limit the space being used. Even more, since the snapshots are built on top of each other, having many of them does not increase the space used all that much. The only viable option I can see is a checkbox for the user to decide if he wishes a snapshot before the upgrade. |
|
One option I was toying with is to take a snapshot mark it as previous, mark current as current (zfs properties) perform upgrade. On successful boot, remove the one marked as previous. Purely for use in an auto recovery s scenario, should something go pear-shaped during the upgrade On failure, current as failed, reboot into previous. |
|
There apparently appears to be some severe misunderstanding of how this thing works.... The below is an example from XigmaNAS: |
|
I missing something? The only snapshots I proposed removed, are the last succesful, iff successful. Llatest would be marked bad if failed, allowing user to investigate or delete and retry. Specifically I was thinking create snapshot, mount it, perform upgrade on mounted, activate reboot, if successful remove previous, if failed mark bad, reboot into previous allowing user to debug or delete and retry. |
This pull request introduces a new feature to the OPNsense web interface, allowing users to manage FreeBSD boot environments directly within OPNsense. This integration provides an intuitive and seamless way for users to create, manage, and switch between boot environments, enhancing system management and recovery options. Renamed the menu item to "Snapshots" in an attempt to explain the feature to non-FreeBSD users. (cherry picked from commit 7118a82) (cherry picked from commit c3af228)
6 participants
This PR supersedes #7650 and implements the new Snapshot feature.
As @sheridans nicely noted in the original PR:
Notable changes on top of the initial PR:
TODO:
[ ] Documentation