Written based on duplicati_2.0.2.1-1_all.deb. This is only concerning running duplicati in headless server mode.
If you install the afore mentioned deb file, the application configuration and data (indexes) are being stored in the /usr/lib/duplicati directory. This flies in the face of standard *nix app data / config / binary filesystem isolation.
Personally, I not worried about the app data (var) /configuration (etc) isolation. I’m more worried the fact that the data is in /usr/lib/duplicati. I know I have sqllite DB over 2GB in size. I got bitten by this filling up my / partition multiple times. I didn’t expect app data to be in /usr (which inherits from / ). Most admins also wouldn’t expect app data to be in /usr anywayw so it could be missed in backup schemes and have unexpected performance issues (Disk I/O).
I’m working on a git push for enhancing this but it would also break the current deb installed because all the configuration would be moved to /var/lib/duplicati instead of /usr/lib/duplicati.
Assuming /var/ is the “right” place to store the config (I certainly wouldn’t know), could /usr/ be checked during install and used of content already exists (call it legacy storage mode) else use /var/?
IIRC, we are not particularly strong with deb experience, so you might have just volunteered as the local expert.
Normally, Duplicati will choose to use the “current user”. By “headless” I think you also assume it is running as root?
I guess this is because you run as root, which has permissions to write this folder. But I agree that Duplicati should not write into that folder.
We have had a similar issue before on Windows where data is moved from %APPDATA% to %LOCALAPPDATA%. My choice then was to keep everything “as-is” but use the new location for new installations. Existing users can move their data if they want.
The line for this is here:
I think you can get what you want if you change the localappdata variable to point to /var on Linux (or something like that):
Not sure what the cross-distro way is to get the /var path.
I’ve already moved it successfully with stock Duplicati-server.exe configuration options. The issues is the defaults of the executable and the script wrappers around it. Windows has a different style of data storage than *nixes and Duplicati’s defaults represent that. That’s fine.
The issue is that the script wrappers as they are blocking you from setting some of the required changes to comply with *nix standard without changing the raw script itself. /usr should almost never contain anything that needs to edited by a user/ admin other than for fixing a bug.
I’ve been thinking about how setup the /etc/default/duplicati file to work well with both the systemd service.unit and the older init.d script. I think I’be thought of a good way to handle both but I haven’t had a time to test it yet.
Honestly, I’ve avoided having to deal with creating DEBs. There’s a lot of power to them and thus a lot of complexity too.
This is coming from a person who used to write ebuilds for gentoo and I still deal with creating RPMs for CentOS/RHEL for my job all the time. So DEB isn’t the nicest packaging software to deal with. But I’ll take a look at it.
Now that I’m looking at the RPM/DEB package. I’m going to start with RPM since I know that packaging system better, I think we also need to look into splitting the some of the utilities into sub-packages. I plan on doing this to remove the GUI/X requirements from the duplicati packages for headless *NIX packages.
Plans:
duplicati(-common) : contains common libraries and CLI executables.
duplicati-server : contains services configuration and runs as appropriate user (root/admin/Backup User/ etc) and webserver configuration
duplicati-gui : contains all GUI dependencies and standard execuables.
