This PR adds support for generating a self-signed CA and then using that CA to generate TLS certificates.
A new tool `duplicati-configure` / `Duplicati.CommandLine.ConfigureTool.exe` is added to manage the certificates. The tool saves the configuration in the database and is meant to run with elevated privileges for the initial CA installation.
The option `--configure-https` can be added to server/trayicon, and if the process has permissions, this will automatically install the CA certificate.
If a CA is configured, the server will automatically issue, renew and use a TLS certificate.
With this setup, the TLS is opt-in, but once the flow is well tested, we can switch it to opt-out.
This adds a connection string repo, where connection strings can be stored.
The general idea is that it is possible to store connection strings, say an S3 connection, and then re-use the connection string for multiple backups, editing as needed.
The implementation supports listing connection strings, creating, updating, and deleting them.
The connection strings are masked so sensitive information is not available in the browser, and the logic patches connection strings internally to ensure markers are replaced with the correct values.
The connection string itself is stored in full, such that a Duplicati version roll-back will not make the connectionstring become invalid.
There is also an endpoint that allows updating existing backups using the connection string, so it is easy to rotate keys. The logic for this feature is that it retains: scheme, port, host, path, and any extra settings on the target url.
It does not remove settings from the target, but will overwrite or add settings from the connectionstring.
This PR adds support for locking files if the backend supports it.
To activate locking, set the option `--file-lock-duration=30D` and the backup will lock the files.
If the database is rebuilt with the intention of continuing the backups, use the option `--repair-refresh-lock-info` which will update lock information in the database after recreating the database.
The locking works by asking the backend to lock files after a backup has completed.
The implementation keeps track of which files are currently assigned a lock and prevents attempting to delete the files that are currently locked.
Note that the bucket should not have a default lock policy as Duplicati needs to finish the backup before the locking is applied.
In this initial version, Azure Blob Storage, B2, S3 and iDrive are supported with locking.
The CLI is updated to allow setting locks on a specific version. The backend tool is updated to allow setting locks on specific files.
This PR adds the option to provide additional settings when importing a backup.
The ServerUtil has been expanded to support passing in the target url and backup passphrase when importing a backup.
Also clarified wording around the import passphrase as there are (at least) two passphrases related to imports.
This fixes#6640
This PR adds a dynamic property so a backend can signal if it supports streaming, based on the settings.
This is currently used for the File backend, so that toggling `--use-move-for-put` will disable streaming on the backend instead of relying on the `--disable-streaming-transfers` flag.
This PR adds the option to limit the available modules to just the set of specified choices.
If no option is set, all modules are available (default).
If the option is set, only those in the list are available (whitelisting).
The options are:
- `--allowed-backend-modules`
- `--allowed-encryption-modules`
- `--allowed-compression-modules`
This PR adds the ability to manage backup configurations outside of the the client.
The implementation ensures that locally created configurations cannot be affected by the remotely managed backups.
If the instance is not connected to a remote console, this has no effect.
This PR updates the local database to add the column `ExternalID` that tracks backups that are managed remotely.
This PR adds support for retries in the backend tester.
The CI tests have been updated to retry operations 3 times, which will hopefully make the CI tests more stable.
This PR adds a `--detailed` flag to ServerUtil that reports additional data for each backup. The JSON output now also includes the schedule and any metadata.
This adds a nonce to the refresh token such that each request to obtain a refresh token must now also provide a matching nonce.
When using non-persisted logins, the request to the server is the same, but the "remember me" flag toggles a shorter duration for the refresh token.
The FE can then store the nonce in either local storage for persisted logins or in session storage for non-persisted logins.
The default is currently to always issue refresh tokens with a nonce, but this can be toggled with the JWT configuration.
The ngax client does not have the non-persisted login so it stores the nonce in local storage, using a name that is compatible with ngclient so the user can swap between them without needing to re-login.
The server util was updated to also store the nonce.
This fixes#6451
This PR updates the probing logic to not try the database if a password is supplied on the commandline.
It also fixes a crash that could happen at an unwanted place, if the user does not have write access to the supplied data folder. After this, the application will still crash due to not having a place to write information, but it does not crash in the preloader logic. This also prevents creating the folder while probing for the database.
This PR also fixes a case where the database could become encrypted, if the ServerUtil was providing an encryption key to an unencrypted database. Before this fix, the database would be encrypted with the key provided to ServerUtil, which would most likely cause the Server/TrayIcon to fail starting and perhaps crash.
This fixes#6377
Kenneth Skovhede