Deb installs configuration and app data in non-standard location


#1

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.

What are people thoughts on this?


Backup job finished - or not?
#2

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. :wink:


#3

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.


#4

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.


#5

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.


#6

Looking at the packaging requirements, I think I’m going to wait for Server needs --parameters-file argument · Issue #2928 · duplicati/duplicati · GitHub to be implemented. That way I don’t have mess with mixing app configuration and distribution configuration. So if you want this faster, vote it up on the GitHub issue.


#7

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.