Say if you have Duplicati on a bunch of Windows and macOS machines and you want to keep them up to date by “deploying” updates. Is this possible? Obviously there’s silent install options, but when they are installed, the web interface still shows the old version. When does it update the database? Thanks.
Duplicati.Library.AutoUpdater.exe sounds like it does what you want, though I haven’t tested it for your use. The GUI autoupdater has a bug where a Windows service install needs a service restart. Other situations appear to be handled better by the GUI autoupdater, so perhaps the command line one will also work well.
If you prefer doing things remotely (just not using the web interface), there’s a third-party Duplicati client to access the internal web interface, while providing a command line interface for your scripting or whatever.
Thanks, but from what is in the documentation, that just sets a schedule for updates, doesn’t give any option to manually update with a specific version and installer through the command line. Also the documentation isn’t very clear: "Choose how to handle updates, valid settings: CheckBefore , CheckDuring , CheckAfter , InstallBefore , InstallDuring , InstallAfter , Never“”
What update? Before or after what? Why can’t a new installer by installed over top and then database updated when the service restarts like almost every other program?
I’m not seeing specific mention of “sets a schedule” on the Duplicati.Library.AutoUpdater page. I’m seeing “install updates” and “Install the latest update from the currently selected update channel” which stops the wish to install a specific version. That’s not what Duplicati considers an autoupdate. Duplicati is not yet as sophisticated as Windows in its update configurability (some would say Windows still has a way to go…), however it does allow different channels. The main ones in use are beta and a take-your-chances canary.
Another reason why upgrades tend to go up is because database formats go that way, and while “up” will always be planned for, “down” is not. Maybe what you really want is a do-it-yourself version of “up” though, and this can maybe be approximated by not running the autoupdater until you’re sure you want the update.
Sometimes admins prefer to have very specific control, so there may be a case for a feature to have that. Such a feature might tie in with some of the occasional discussion on automated large-scale deployment. Duplicati is not a large binary, so making the usual install work well in an automated rollout might save the added work (only so much work can be done…) of coming up with a good way to do updates-not-installs.
Also see comments elsewhere on channels, and upgrades versus downgrades. Beta versions appear to show up almost a year apart, so what sort of specific versions do you have in mind within the limitations?
Duplicati on Windows - two version numbers has much technical information on the update mechanism, including why Duplicati possibly chose to do what it thought was better than the typical upgrade-by-admin.
I’m kind of curious if the CLI updater knows how to restart the server (or Windows service), however CLI generally is quite independent, so you might need to use some OS mechanism to achieve such restarts, and restart should take care of the web interface showing the old (but still running) version before update.
I can’t provide a guaranteed good explanation of the documentation (maybe this is your “schedule” point?) however I think policy is most applicable to CLI use, and you have a choice of when you check for update, and when you download and install that update, all relative to the CLI command work that you are running. The code default appears to be CheckDuring, which sort of fits with the experience I’ve had, which is that check is automatic, and install is not. The ability to change update policy is presumably to give the choice.
You should be able to install over an existing install and the db will update expected. This will affect your Base Version.
Alternatively, you could push the updated version to each machine’s applicable updates folder. This would affect the “current version” and would not kick in until a Duplicati (or system) restart happened.
If planning to do downgrades, be sure to check for “version crossing” issues listed at the top of: