I have been on canary channel, initially via installation of duplicati_2.0.3.2-1_all.deb. Today I tried updating to 2.0.3.6_canary_2018-04-23 via the web page, and surprisingly to me, it worked. However, it apparently did not install a new deb package. The dpkg package manager still shows the old version.
I’m concerned about where the new install files are now. I’m not sure where they are installed or how they are being picked up by systemd. I fear they would not be properly uninstalled if I remove the duplicati package, because the package manager does not know about them.
The update manager is designed such that it can install updates without needing administrative/root privileges (which dpkg requires).
Duplicati’s “install” is just an unpacking of the archive (zip in most cases). The deb file is installed in /lib IIRC, and you can uninstall that via the package manager. The updates are stored in ~/.config/duplicati/Updates (you can get the exact info by running mono Duplicati.Library.AutoUpdater.exe info).
The package manager does not know anything about the updates you have installed, so it will leave them behind if you uninstall. But you can simply remove the folder and the update will be uninstalled.
I have installed Duplicati deb-package 2.0.2.1-1 and updated using the web interface several times. Currently, the web interface says I am running 2.0.3.9_canary_2018-06-30.
Now I wanted to use the command line tool and used duplicati-cli help and noticed it prints 2.0.2.1_beta_2017-08-01 as version. This is /usr/bin/duplicati-cli and last changed 2017-08-01. So I ran mono Duplicati.CommandLine.exe help in /usr/lib/duplicati and again got the old version. I checked systemctl status duplicati, which says it runs /usr/lib/duplicati/Duplicati.Server.exe. This file is also last changed 2017-08-01.
When I found this thread, I searched for ~/.config/duplicati/Updates, but it is not there. ~/.config/Duplicati (capital D) is there, but no Updates folder, only the sqlite files, backups thereof and control_dir_v2.
So now I am really confused. Where is the current Duplicati canary actually coming from? I have the feeling that this is a mess and maybe a deb-repository may be a better option?
In case Duplicati has some security issue, you could never remove the vulnerable file through updates done by the web interface? It normally would not be run. But I almost used an old commandline-tool that normally should not be run.
Edit: Ok, running mono Duplicati.Library.AutoUpdater.exe help in /usr/lib/duplicati shows this:
Updates are downloaded from: https://updates.duplicati.com/beta/latest.manifest;https://alt.updates.duplicati.com/beta/latest.manifest
Updates are installed in: /usr/share/Duplicati/updates
The base version is "2.0.2.1_beta_2017-08-01" (2.0.2.1) and is installed in: /usr/lib/duplicati
This version is "2.0.2.1_beta_2017-08-01" (2.0.2.1) and is installed in: /usr/lib/duplicati
So in /usr/share/Duplicati/updates I found all the updates. When I run mono Duplicati.CommandLine.exe help in /usr/share/Duplicati/updates/2.0.3.9, it prints the current version.
Still I am unsure how my systemd job runs the current version. Actually, it seems to run the old version that then runs the new version!?
The security-considerations and this-looks-like-a-mess arguments remain
Yep, that’s what happens. The base version is (2.0.2.1 in your case) is what was manually installed and when run will look in the updates folder to see if a newer version has been installed via the GUI update process.
If newer versions are found, the most recent one will then be executed as a child process resulting in both apps running (though the base version just passed things off to the new version and isn’t actually doing anything else).
Okay, thanks for this insight. But I guess more people may run the base version of the command line tool accidentally, as this does not seem to automatically run the current version.
Also this shows a disadvantage with this approach. Even if you fix this now, i.e. you change the command line tool so it runs the current version if possible, you cannot roll out this change to me through the GUI update process.
Edit: Is there a cleanup for old updates? I currently have 4 versions there (base + 3 updates), each ~ 41MiB. Some people may have 20 such versions there? This seems like a waste of space.
The idea is that the only thing the old version does, is to launch the new version.
This limits any security impact to the launcher code, which is basically “set env-var; execute new binay”.
The idea is that both versions look for the same folder, so they should run the same version.
I think the problem is that the systemctl version is running with elevated privileges and finds /usr/share/ to be write-able, and then stores the updates there. When you run the cli, it has less privileges and then finds ~/.config to be writeable.
The other solution would be to require elevated privileges, and then replace the current installation. Would you prefer this, or do you have a better solution?
Yes, there is a limit of 4 old versions, they should be removed automatically.
Although it’s a Windows thing, I think the env var is what I tried removing from WindowsService’s Server start. This then let me have my web UI Activate button actually “activate” the new version without restarting service. Problem was that the forwarding through the parent to the child didn’t work, so Service couldn’t do shutdown. Linux users probably don’t see this, and I’m still wondering why more Windows users aren’t asking about this.
Depending on how the 4 old versions get verified, I get nervous about Duplicati service stops running issues.
There’s also a possible issue with at least the Synology start/stop/status script (and maybe other Linux), and Windows command line Control-C. I’m not ready to advocate for big change yet. Maybe just need more fixes.
Just throwing my own thoughts into this, not speaking for the original poster or anybody else about this issue.
The idea is that both versions look for the same folder, so they should run the same version.
I think the problem is that the systemctl version is running with elevated privileges and finds /usr/share/ to be write-able, and then stores the updates there. When you run the cli, it has less privileges and then finds ~/.config to be writeable.
I tried running /usr/lib/duplicati # mono Duplicati.CommandLine.exe help as root and it shows the base version. Also I confirmed that root can write in /usr/share/ by trying touch /usr/share/Duplicati/test and touch /usr/share/Duplicati/updates/test and both work.
The other solution would be to require elevated privileges, and then replace the current installation. Would you prefer this, or do you have a better solution?
I would prefer if Duplicati would be updated by apt from a repository. This has many advantages:
It verifies updates (Duplicati may do so as well, but - don’t get me wrong here - I trust more into apt that this is bug free than any software that ships its own update mechanism)
It can notify me when updates are there (can even be easily integrated into monitoring systems like Icinga)
