Currently we are not state-of-the-art, we can change settings and apply them.
But why do we force them to save?
i would prefer the normal CLI way, that every setting (not for CA, etc, but for Firewall/IFs/..), we should have no immediate save.
Instead after changing settings and/or pressing apply, all settings should be inside a running-config.
If and only if we do a logout with save confirmation or manually save action using write-memory from CLI (shell) or GUI, we wont persist on the current conf.
Another variant would be, to have some tagged configs, which work fine, so if we go to our OPNsense and know it was running fine, we make a tagged config.
This tagged config should be selectable, maybe we could have 20 or more of them with a description like an svn commit.
Anyway if we put the power plug, running-config needs to be dropped and we want to start with startup-config instead so we cant ever lockout ourself.
okay plugging out is ancient, but another way would be:
If OPNsense notices, that the Web or SSH connection which initiated the change is not communicating anymore, it should do a rollback to a well known state.
Also it needs to check a new handshake... and some more tests..
Maybe its ancient, but its well prooven. we could have a watchdog, which notices, that the admin is not connected anymore, and then it could rollback.
a bit offtopic but also same thing:
add dual firmware image / dual installation like android project treble with AB image.
if update fails, we need a super quick way to get back.
no time for playing BSD admin on shell or sth else.. nobody wants this...
we just want to go back to previous installation before update.
means just use double HDD space for installation.
Maybe you should take a look at snapshots (https://docs.opnsense.org/manual/snapshots.html), which would probably solve all of those problems - and they do not use double the HDD space...
Quote from: meyergru on March 16, 2025, 06:00:32 PMMaybe you should take a look at snapshots (https://docs.opnsense.org/manual/snapshots.html), which would probably solve all of those problems - and they do not use double the HDD space...
This seems to be a quite intelligent solution, so we can define a snapshot in a good well known state and set it to recover on next boot.
then play and fiddle with the config and lets see if we can do 1-2 days.
then make a new snapshot and set it as default.
seems to be a good solution, maybe we can automate this a bit?
There are basically two kinds of situations you probably want to address:
1. You have made a configuration or a bunch of them that you want to rollback because it did not fit your needs. Then you can use System: Configuration: History where you compare any of the last N saved configurations to each other and roll back to any one you like. This is possible from the console as well.
2. If you have locked out yourself of OpnSense by hosing up your configuration really badly, or if you plan to do a system upgrade where you are not sure that everything works afterwards, you can create a snapshot that is "known good", and it even includes the whole system installation, not only the configuration. I always create a snapshot before a system upgrade or when I know I am doing something that could be fatal.