luci icon indicating copy to clipboard operation
luci copied to clipboard

luci-mod-system: flash: [RFE] improve GUI for config backup and restore

Open Lanchon opened this issue 1 year ago • 3 comments

AFAICT, luci generates config backups in these instances:

  1. System / Backup/Flash / Generate archive
  2. System / Backup/Flash / Flash image... / Upload / Keep settings...
  3. out of scope: System / Attended Sysupgrade / Search... / Request firmware image / Keep settings...

(2) has these options:

  • Skip from backup files that are equal to those in /rom
  • Include in backup a list of current installed packages at /etc/backup/installed_packages.txt

while (1) and (3) have no options. it would make sense, especially for (1), to have these options as well.

btw, wording of options in (2) is a bit weird, because it uses possibly incorrect grammar and refers to a "backup" that the user is not aware of and is a sysupgrade implementation detail.

"Skip from backup files that are equal to those in /rom" should better be:

  • Do not back up files that...
  • Skip backing up files that...
  • Skip backup of files that...

"Include in backup a list of current installed packages at /etc/backup/installed_packages.txt" should better be:

  • Include in backup a list of currently installed packages at /etc/backup/installed_packages.txt
  • Include in backup a list of currently installed packages (/etc/backup/installed_packages.txt)
  • Save a list of currently installed packages to /etc/backup/installed_packages.txt

for utility and consistency, the "Generate archive" button in (1) should pop up a window asking for backup options, the same as those in (2). (and maybe consider adding more sysupgrade options if relevant.) i especially think that "Save a list of currently installed packages..." should definitely be available in (1), and maybe even enabled by default. (after this change is done, these options could be added to (3) as well.)

it would be best if the same exact wording was used in all instances of the GUI. this creates a problem: "Flash image..." offers a "Keep settings and retain the current configuration" checkbox, hiding the fact that it is not really keeping anything, but is instead creating a backup and then restoring it after the upgrade. with this fact hidden, wording that refers to a "backup" becomes unclear.

(side note: i think it is important that every user knows how the sysupgrade process works. many, many openwrt users ignore that everything is wiped and some things are restored during sysupgrade, and they expect the more common behavior of distros: that their files won't be deleted during an upgrade. IMHO, the current wording that hides that backup and restore steps are about to be made is harmful.)

Also, in (2) there is the "Keep..." checkbox and 2 other checkboxes that lose meaning if keep is not set, but this is not very apparent in the UI except that they get greyed out if you uncheck keep (but they keep their state anyway).

for all this, i propose that the "Keep settings and retain the current configuration" checkbox would be better changed for radio buttons with nested checkboxes that more explicitly describe what is about to happen:

  • Back up current configuration and restore it after the upgrade
    • Save a list of currently installed packages to /etc/backup/installed_packages.txt
    • Do not back up files that are equal to those in /rom
  • Reset configuration to defaults

having visibility of the backup/restore steps during sysupgrade improves a couple things:

  • allows the same wording for the same options in (1) and (2) (and eventually (3)).
  • educates users on the workings of the sysupgrade mechanism
  • and avoids the dead checkboxes

allow config restore during flashing

There is no reason why flashing an image should not allow a simultaneous restore of configuration, as this seems supported in the command line. If you want to restore the working state of a device to an instance in the past, you currently first need to flash an image, then reboot, then restore settings, then reboot.

This is more than a nuisance: the router may not be able to operate at all in its environment without basic configuration such as IPs, wifis, etc. and if the router is being accessed remotely, say via a VPN, the exercise becomes impossible.

with this in mind and extending the previous section, the ideal UI would again be radio buttons with nested checkboxes:

  • Back up current configuration and restore it after the upgrade
    • Save a list of currently installed packages to /etc/backup/installed_packages.txt
    • Do not back up files that are equal to those in /rom
  • Restore a previously generated configuration backup
    • Backup archive: backup-XXXX-2024-04-15.tar.gz
  • Reset configuration to defaults

where the file chooser should pop up as soon as you click the "Restore a previously generated..." radio and roll back if a valid file is not chosen.

thanks!

Lanchon avatar Apr 15 '24 10:04 Lanchon

Hello @Lanchon - thanks for the analysis. There are some useful ideas here.

Please examine the difference between backup (noun) and back up (phrasal verb) which you conflated in your text, as a matter of clarity. Also loose vs lose (yeah, there are native speakers who hate that idiosyncratic difference).

it would be best if the same exact wording was used in all instances of the GUI. this creates a problem: "Flash image..." offers a "Keep settings and retain the current configuration" checkbox, hiding the fact that it is not really keeping anything, but is instead creating a backup and then restoring it after the upgrade. with this fact hidden, wording that refers to a "backup" becomes unclear.

So if the net result is that the settings are identical, and configuration is retained, I think the setting has earned a good title.

(side note: i think it is important that every user knows how the sysupgrade process works. many, many openwrt users ignore that everything is wiped and some things are restored during sysupgrade, and they expect the more common behavior of distros: that their files won't be deleted during an upgrade. IMHO, the current wording that hides that backup and restore steps are about to be made is harmful.)

The source is open and everyone is free to inspect it if any wording is ambiguous, until we get a better wording.

should pop up a window

In a GUI context, never pop shit up when starting a process. Ideally, never pop shit up. This reeks of bad design; of failure to obtain a choice or information that you can do already now. Then when you (for real this time) start the process, it actually starts. No mickey-mouse shit "are you really sure?"

This is not an attack on the improvement idea - just... never do popups in a GUI.

i especially think that "Save a list of currently installed packages..." should definitely be available in (1),

You especially? ;) Who else did you ask? :) Yeah, I think that's a low-cost addition to a backup. Whose intention means that restoring a backup can get a system back to how it was before.

But there's the rub: if the configuration+package state is responsible for how fucked the system was before the user had to resort to the restore, using this package state info needs to be configurable (to off), somehow. I'm sure decisions for those bits are in the lower-level system. Although with how things are today, it seems the safer of the two.

for all this, i propose that the "Keep settings and retain the current configuration" checkbox would be better changed for radio buttons with nested checkboxes that more explicitly describe what is about to happen:

* Back up current configuration and restore it after the upgrade
  
  * Save a list of currently installed packages to /etc/backup/installed_packages.txt
  * Do not back up files that are equal to those in /rom

* Reset configuration to defaults

Entirely possible - just that some of these GUI moments are manually built. Great if you've a PR to implement this.

This is more than a nuisance: the router may not be able to operate at all in its environment without basic configuration such as IPs, wifis, etc. and if the router is being accessed remotely, say via a VPN, the exercise becomes impossible.

This is a valid point. The underlying tools and bits are ready to be improved if you want to look into those bits.

I know @dannil sometimes has a go at tweaking GUI stuff too.

systemcrash avatar Apr 15 '24 21:04 systemcrash

Please examine the difference between backup (noun) and back up (phrasal verb) which you conflated in your text, as a matter of clarity. Also loose vs lose (yeah, there are native speakers who hate that idiosyncratic difference).

i'm not a native english speaker, so my wordings are just suggestions.

This is a valid point. The underlying tools and bits are ready to be improved if you want to look into those bits.

i only propose the flash+restore combo because i believe the sysupgrade command line already supports that, though i haven't double checked.

Great if you've a PR to implement this.

i don't like working on UIs, i prefer lower level development. my PRs to openwrt reflect that. for UI my contribution is limited to bringing ideas to the table; maybe someone likes them.

Lanchon avatar Apr 16 '24 00:04 Lanchon

with this in mind and extending the previous section, the ideal UI would again be radio buttons with nested checkboxes:

    Back up current configuration and restore it after the upgrade
        Save a list of currently installed packages to /etc/backup/installed_packages.txt
        Do not back up files that are equal to those in /rom
    Restore a previously generated configuration backup
        Backup archive: backup-XXXX-2024-04-15.tar.gz
    Reset configuration to defaults

A while ago I actually experimented with implementing this when first getting into developing LuCI since I found this was as an already open related issue at #5555 and I had thought of the same issue when doing sysupgrades when I just got started with OpenWrt, I didn't get very far though, basically just playing with the UI, no backend-integration code at all. I might give it a go again now when I know a little more now.

dannil avatar Apr 17 '24 17:04 dannil