This PR changes to use relative database paths by default. The default mode is to store all databases in the same folder.
With this update, the paths stored in the server database can now be relative, in which case they are resolved relative to the datafolder.
This makes it simpler to move the data folder as the paths are not stored in full.
For new backups, relative paths are assigned.
For existing backups, the full paths are retained.
If the database path is updated manually, the path will be made relative, if it is relative to the datafolder; otherwise a full path is stored.
This fixes#6677
The SelfOnly mode was removed as was the "removeAdditionalSources" logic. Instead, the new SelfLimited mode always removes sensitive information, such that by default we do not store any sensitive information, not even with encryption enabled.
This is required to avoid accidentially leaking secrets found in remote sources, or the target url, in case the leak happens somewhere else than on the remote destination.
Additionally, this resolves an issue where remote source information could leak via the DisplayNames property.
To reduce logic bugs a separate ResolvedTaskConfigMode extracts the 3 different dimensions of the selection, and a test is added to ensure it behaves as expected.
When performing searches on some remote source, like MS365, the actual file paths are not meaningfull to the user. Instead, the UI will display metadata that makes it easier to navigate.
This PR updates the search feature to optionally look in metadata and find matches there as well, making it simpler to work with such data.
This PR revives the `store-task-config` option that was never shown in the user interface and extends the feature to allow more flexibility in exporting the configurations.
The `Auto` setting is now on by default. For encrypted backups, this will store the backup configuration of the current backup with the backup for easy restore of a configuration.
For unencrypted backups, nothing will be stored by default.
To manually pick the what backup configurations are stored, the following options are also available:
- None: no configuration is stored
- Self: The configuration of the current backup is stored
- All: The configurations of all backups are stored
If the backup is not encrypted, the data is stored without any secrets (encryption keys, passphrases, passwords, api-keys, etc).
To override this, the following two options are also present:
- SelfWithForcedSecrets
- AllWithForcedSecrets
Using one of these when encryption is enabled has no additional effects, but for unecrypted backups this will include all secrets in the backups in plain-text.
This fixes#6256
This fixes#3073
This PR fixes a bug that caused backup searching to be case-sensitive.
The PR also exposes the case sensitive-flag in the API endpoint so the UI can toggle case-sensitive searching.
This PR adds a new option `--disable-default-secret-provider` that will fully disable probing for the default secret provider.
This is to assist in cases where the secret provider is broken or shows unwanted popup dialogs.
This updates ngclient to 225, and also adds `--duplicati-webservice-suppress-welcome-page` to automatically disable the welcome page that is shown on new installs.
This modifies the `newbackup.json` embedded file that specifies how to configure a new backup to no longer set the compression module or the dblock-size.
These options have a default value already defined, so there is no need to store the settings in the database.
This PR adds experimental support for running the backup in an isolated process.
The motivation for this is to protect the server from a faulty process and later enable running server and processing with different security levels.
This needs to be toggled on, and then it will run the process isolated. When running as an isolated process, the "Abort" call will kill the process so it can no longer become "stuck".
This PR has a large blast radius because it takes the final step and bumps up the Controller to be fully async.
We have historically done a piece-by-piece update, so all operations were already async but the controller interface was kept synchronous.
With this update, the controller is now fully async and all tests are updated.
Most places where the new C# compiler warns about function names not ending in `Async` were also adressed, giving a massive refactor change.
Functionally, no changes are done.
This PR deprecates the `mssp` and `od4b` backends as they stopped working when the APIs were turned off.
The upgrade path is to use `sharepoint` instead (which used to be named "SharePoint v2").
This PR also adds a small amount of metadata to modules so they can be marked as "untested" or "deprecated", and the configuration for marking modules has been set up in `BackendModules.cs`.
The backends that we currently cannot test (usualy due to not having public signups) are now marked as untested.
This PR fixes an issue where the callback for updating the usage reporter was not correctly registered.
The effect of this was that settings changes should update the usagereporter (disabling or setting the level), but due to the missing callback settings were not applied until the server restarted.
With this fix, the settings are applied immediately.
This PR extends the search API to allow versions to be added so searching can be limited to specific versions.
Before this PR, only time was supported, but this is picking versions older than the timestamp as well.
In some cases the database update can fail, and this could leave the transaction open.
Eventually, it will be collected and the transaction disposed so it will be sorted, but in the meantime attempts to save settings will fail as SQLite does not support multiple active transactions.
This PR adds failure dispose of the transactions in a few places to ensure failures does not cascade outside the original failure.
The logic is now that the properties for each of the server settings are defined on the constant that triggers them, instead of splitting it across the API and internal database.
This makes it less error prone to introduce newsensitive server settings.
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 PR adds masking to remote sources so the passwords are not leaked to the browser. The logic works the same as for TargetURL, where the sensitive fields are replaced by a password placeholder before being transmitted via the endpoints.
When data returns, the masking is removed by looking at the original source and the unmasked value is then encrypted before being stored in the database.
Since the sources is an array and not just a single field, the logic here uses the mount point as a "key" for figuring out which new sources map to the original sources. This is robust in the face of re-ordering, deletions and additions.
If there is just a single remote source (assumed most common) this will match even if the prefix does not, making it possible to change the prefix in this case.
For multi-remote sources, it is not possible to change the prefix without also re-typing all masked properties.
If there is a need later, we could extend the matching to look for how many unique protocols are there, and maybe servers as well to try to match better when the prefixes have been renamed.
There is a guard right before saving a source that rejects it if the source contains the placeholder so we ensure that even faulty logic cannot persist an invalid connection string.
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.
When updating the server settings, the server would not emit the new settings on save, causing the UI to be inconsistent if websocket is active.
This happened primarily when saving advanced options.
