Plan: explain why "Restore" is missing (headless Linux restore)

Development
1

Follow-up to Improve the Linux Restore workflow for headless servers by @Chad_Neeper. I’d like to implement the first part of that request and want to check the design first.

Current behaviour: the Restore button only appears if ServerStatus::canRestore() is true, meaning the client is online, its RESTORE mode isn’t disabled, and (with file access tokens) allow_file_restore is on. If any of those fail, the button simply isn’t there. Linux clients ship with RESTORE=disabled in /etc/default/urbackupclient, so on a headless box the first experience is a missing button and no hint why.

Proposal (no change to the security model):

  1. Have the server tell the web UI why restore is unavailable. It already knows, because the client reports its mode during capability exchange. So return a reason alongside can_restore: client offline / restores disabled on the client / file restore disabled in server settings.
  2. The UI then shows a disabled Restore button with a short explanation, e.g. “Restores are disabled on this client. Set RESTORE=server-confirms in /etc/default/urbackupclient (Linux) to allow restores started from the server.”
  3. Optionally, a separate and smaller follow-up: have the Linux installer ask whether to enable server-confirms, defaulting to the current disabled.

The server still can’t change the client’s restore mode, so it stays the client’s decision, as Chad asked.

@uroni: is that acceptable, and do you prefer the wording or the installer prompt handled differently? I’d start with 1 and 2.

Improve the Linux Restore workflow for headless servers
4

Perhaps displaying the command to use to start the restore on the client would be useful? E.g. something like

urbackupclientctl restore-start --backupid 34 --path foo/bar

and then only as non-recommended option saying that the button can be enabled via setting server-confirms.

Don’t like asking in the installer (too many questions might be problematic) – maybe it can be a command line option or something to configure on the server for downloaded clients.

5

That’s a better idea, thanks. Plan then:

  1. When a client is online but restores aren’t enabled, instead of just hiding the Restore button, the file browser shows the command for the backup and folder you’re looking at, e.g. urbackupclientctl restore-start -b 34 -d "foo/bar", with -v <name> added for virtual clients, and a note that it removes files not in the backup unless -n is added (same as the web restore).
  2. Below that, as the non-recommended alternative: the Restore button can be enabled by setting RESTORE=server-confirms on the client.

For the installer, agreed, no extra question. I’d look at a server setting for the Linux client installers downloaded from the web interface, so they come preconfigured with server-confirms. Unless you’d prefer a command-line option to the install script instead?

I’ll start with 1 and 2 against 2.5.x.