OPNsense Forum
English Forums => General Discussion => Topic started by: floydian on December 05, 2018, 03:46:33 pm
-
I'm on my little phone display and I made a mistake in the NAT rules and now there is an option to apply changes. I don't see any option to cancel or revert back.
-
what works for me is to just go back a page or back to the dashboard or another location and back to the page settings i messed up.
Worst case go to System Configuration and History and roll back the changes.
-
Yep, System: Configuration: History can do a rollback.
Cheers,
Franco
-
Maybe a "Cisco-like" approach would be something worth considering?
I mean, having 2 separate configs:
1. A running config, effective immediately at "Save"
2. A start-up config, effective at OS load. Would require an extra "Save to start-up config" step to be modified.
This way, if a mistake is made, and you get locked-out or something, a restart would be also a roll-back, since no "Save" has been made to the start-up config yet.
Thank you!
If yes (more votes), I could write that request on github, but what do you people say?
-
considering I don't have to work very hard to screw things up I vote yes Please :)
-
The only thing needed is to simply cancel the changes. They're not applied, how come there's no way to just go back without reboot nonsense. I am making a mistake of EDITING instead of CLONING nonstop, thanks to the tiny buttons:/
-
I don't think having live changing and separate saved changes like network switches is a good idea. That already causes problems with experienced network admins.
Navigating away from the page is the easiest way to avoid saving changes but it might be worthwhile to add a cancal button to each page that just sends you back to the lobby.
One thing to note when using history to revert changes. None of the services are restarted during this. It only changes the config. So after you revert to an earlier version you'll want to reboot OPNSense.
-
Oh I would love a Cancel feature before an Apply too.
That would be handy indeed for mistakes, or when somebody else on the team left something in the middle of being configured...
I sometimes sweat bullets when pressing that Apply (Nuke) button being blind :).
Seeing what the apply is going to do is also something that would be useful.
(seeing the diff before it's applied for instance).
Same concept as the git stage/commit basically:
- see the diff
- can rollback the commit before the push
-
The thing is that all the apply buttons you see, aren't doing a universal apply of all the modules/components/plugins. The apply buttons make a call to the API of the module (namespace and model) they're embedded in. For example, if it's DHCP, the apply button is making a REST API call to the Service Controller of DHCP, and then it triggers a "ReconfigureAct" of only DHCP.
That means, each apply button is it's own entity with its own unique id.
And there can't be a cancel button next to the apply button most of the time, because changes in Bootgrids (The tables you input data in and press save), save the data directly to the /conf/config.xml via a REST API call. So, the data is already saved in the system, the apply only restarts or reloads the service with the new data.
Though for the config.xml there is already a diff feature here:
/ui/core/backup/history/this
When you do regular backups (best do them automated to nextcloud or something), it always shows the difference between the last backup.
-
thanks for the implementation details!
Makes total sense that each module handles how it is reconfigured.
Maybe having a "To be applied" summary on a dedicated screen or the dashboard could be an option?
It would list which modules/namespaces have pending applies and if possible also the actual changes.
Regarding the config.xml file, can't there be a concept of a temporary config.xml.new?
It makes me think of how proxmox deals with pending network interfaces configuration with a .new file that is used to generate the diff in the UI, and then gets swapped on Apply and ifreload is called accordingly.