Closed ghost closed 3 years ago
MichaIng
commented
3 years ago Many thanks for your suggestion.
Jep this totally makes sense. The logic from Radarr can be ported, even the download URL scheme matches. Do you think its worth it to force a reinstall on next DietPi upgrade to migrate all ARMv7/8/x86_64 systems?
Note that this won't work on ARMv6, which does not support Mono.
ghost
commented
3 years ago ..Sonarr soon too..
The instructions on how to change from Mono to .Net version is here: https://wiki.servarr.com/lidarr/system#update-to-net-core-version. Mono versions of Lidarr will no longer be supported in future.
No need to force a conversion, only have new Lidarr (dotnet) version ready to install. Admins can then manage it themselves, specially for systems that do not support dotnet / mono, or only support one or the other. Otherwise, to force a conversion means backing up the existing data/configs first, uninstalling the mono version, re-installing the dotnet version, and then putting back the data/configs to keep the data/configs, etc... can get messy eps for old versions - admins can do it themselves?
ghost
commented
3 years ago Currently, dietpi-software Lidarr (mono) install defaults as /opt/Lidarr/ with user-group lidarr dietpi, data found under /mnt/dietpi_userdata/lidarr/ with user-group lidarr dietpi.
Uninstalling Lidarr (mono) to install Lidarr (dotnet) remvoes /opt/Lidarr/, wipes/resets the existing data/configs, etc. in /mnt/dietpi_userdata/lidarr/ and removes the log simlinks (/var/log/lidarr/ folder nuked), so backup is required before this is done.
To be consistent/mirror with Radarr, I'd suggest maybe as follows (although it can be installed any-which-way)
Radarr (mono) originally Installed as /opt/Radarr/
now Radarr (dotnet) via dietpi-software installs as /opt/radarr/ with /mnt/dietpi_userdata/radarr/ data with simlinked logs /var/log/radarr/...etc.
/opt/Lidarr with /mnt/dietpi_userdata/lidarr/ data with simlinked logs /var/log/lidarr/... .etc.
with new Lidarr (dotnet) via dietpi-software install as /opt/lidarr (lowercase) and rename any existing /mnt/dietpi_userdata/lidarr/ to /mnt/dietpi_userdata/Lidarr/ (backup data) and/or backup the old logs in /var/log/lidarr/ if required, and newly create /mnt/dietpi_userdata/lidarr/ with simlinked new logs /var/log/lidarr/.... etc.Lowercase installs should be default, since *nix file/folder case matters.
MichaIng
commented
3 years ago Yes, I'd switch to lower-case /opt/lidarr then as well. Migration via dietpi-update patches wouldn't be done via uninstall+install but via reinstall, to preserve all data and configs. When succeeded, the old /opt/Lidarr is removed, everything else would be migrated by the dietpi-software install/config steps.
ghost
commented
3 years ago Would it be prudent to standardize all dietpi-software that uses the /mnt/dietpi_data/folder, to store app data in /mnt/dietpi_data/.confg/ instead of just /mnt/dieti_data/ ?
I believe ~/.config/ is the usual place for app data/configurations eg /home/<user>/.confg/<appfolderdata> so to keep it consistent /mnt/dietpi_data/.config/would make more sense?
There are several dietpi-software installed packages that do not use .config folder...like the *arr's, etc. when the /dietpi_data/ is store location.
MichaIng
commented
3 years ago You mean you want to have them e.g. hidden in explorer, respectively the parent /mnt/dietpi_userdata list cleaner? /mnt/dietpi_userdata/lidarr is the home directory of the lidarr user, hence, depending on how the software distributes configs and data within, /mnt/dietpi_userdata/lidarr/.config/lidarr might exist (not in this case). The possibility of /mnt/dietpi_userdata/.config/lidarr/.config/lidarr is a little too nested, IMO.
As we speak of system services and not (login) user services, the usual way is to store configs in /etc/lidarr and data in /var/lib/lidarr, but many software titles do not conform to that concept at all. Merging it into /mnt/dietpi_userdata/lidarr was more a practical choice, as this directory can be moved easily to an external drive, to reduce system drive/SD card I/O, allow easier backups or migration to a new system etc, and some software titles simply take only a single directory as input.
Another practical issue is that some software titles always use their executables directory for configs and data. In such cases, usually /mnt/dietpi_userdata/<name> holds the whole installation, in a fashion it is otherwise often (FHS conform) used in /opt/<name>. Having a whole software installation provided within a .config subdirectory, is a bit strange. So as of different behaviour of different software, moving all /mnt/dietpi_userdata/<name> to /mnt/dietpi_userdata/.config/<name> is definitely not the right way, but I'm open to discuss a different approach, depending on the issue behind your suggestion.
ghost
commented
3 years ago Sort of yea. I was under the impression that it was the dietpi user only folder, since the name implies dietpi_userdata , not any other users' services/apps running,etc.. Also the sub-folders appear to be similar to /home/(user)/ structure (downloads, Music, Pictures, Videos eg users' own files & sub-folders).....
If its just for the user application/service data, then the dietpi_userdata label is a little misleading - perhaps something for future consideration to rename it as /mnt/dietpi_data/ ?
That way each user sub-folder can exist and settings stored as mentioned above. with its relevant permissions/ownership....ie:
/mnt/dietpi_data/dietpi/(all apps/service config/data stored here, for only the 'dietpi' user running apps)
/mnt/dietpi_data/lidarr/(all apps/service config/data stored here, for only the 'lidarr' user running apps)
/mnt/dietpi_data/radarr/(all apps/service config/data stored here, for only the 'radarr' user running apps)
/mnt/dietpi_data/(user)/(all apps/service config/data stored here, for only the '(user)' user running apps)
etc.. for each user....if you get my meaning. Then browsing the data folder its so much cleaner and easier to locate any app data, and can selectively backup what one wants at whatever intervals required, etc.
Otherwise if more than just app/service settings/config/data, then just use the /home/(user)/ structure on /mnt/home/ as normal for easy backups, portability, etc.
a little regression, albiet a little related.....anyhow food for thought.
MichaIng
commented
3 years ago etc.. for each user....if you get my meaning. Then browsing the data folder its so much cleaner and easier to locate any app data
That is how it is done now, aside of the "dietpi" user, which has its home in /home/dietpi (like any login user automatically), and will be removed in future versions (the last software titles running with it will get their own user, creating a custom login user will be offered instead on first boot). I agree that dietpi_userdata is probably a bit misleading. I think originally it was designed to be the userdata directory indeed and using it for app data and config joined for mentioned reasons. Also some logic is there to have dedicated download/media directories there, as many software titles (downloaders, file servers, media players and streaming servers) require non-exclusive access to music, videos, downloads, etc: downloader must be able to download to "downloads", Sonarr must be able to import from "downloads" to "videos", Samba must be able to R/W "videos" and Kodi at least requires read access, write access as well when metadata is to be changed.
It's basically two conflicting concepts of running software and storing variable data in general: running everything with the unprivileged login user, storing everything in its home directory, versus running every daemon/service as dedicated service user, storing everything in a system directory not associated to any specific login user, providing access via group memberships. Debian packages follow the second approach mostly, while many other software titles we install from (Git) sources directly are intended to be used with the first approach. Setting up both so that they work together the challenge.
ghost
commented
3 years ago Ok that mostly makes sense - the name does however give the wrong impression (it's not intuitive).
Also by default the dietpi (user) /home/dietpi/ folder is missing when SMB'd to the pi, instead it shows only the /mnt/dietpi_data/ folder content (with default permissions, r access to sub-folders, etc.). Also SSH'd with dietpi access to the other user folders (/mnt/dietpi_data/
MichaIng
commented
3 years ago the name does however give the wrong impression (it's not intuitive).
Agreed. It's however a little difficult to change such things just on a regular update, as this path is used in so many created service files, configs etc. I think a change can only be done when keeping the old patch valid via symlink, which causes even more confusion for existing systems.
That SMB and other cloud/network drive solutions use this path instead of the dietpi login user's home directory, is a security feature, not an issue: There may be private information, SSH keys and other crypto keys etc stored in users' home directories, which must never be part of a public network share or cloud share solution. The /mnt/dietpi_userdata directory is explicitly not a home directory of a login user, but a separate "global" media directory to be used by multiple services/system users.
Also SSH'd with dietpi access to the other user folders (/mnt/dietpi_data/, etc.)
It is key here that this directory is not any users directory, but a global system directory. The setup is meant to be used by a single real person, or multiple persons using/sharing the same software/services and media, like a family. I think that covers 99% of the cases, at least if an SBC is used. I never heard of an SBC that is used by multiple people with their own login user account, own software and such. If this is the case, then of course using /mnt/dietpi_userdata at all may be not applicable, aside of keeping it as server-software data store, for databases, or e.g. Nextcloud data and such, which are naturally accessible only to the service user, not any login user (aside of root, of course).
MichaIng
commented
3 years ago PR up: #4665
Creating a software request
Formal software information
Are there similar/alternative software titles available with DietPi-Software?
What makes your requested software better than the above solutions, if available?
How can DietPi make the installation easier or compatible, than following the install instructions or do APT installation, if available?
dietpi_userdataand storage space.Can you provide the installation steps that you would suggest DietPi-Software to do?
wget --content-disposition 'http://lidarr.servarr.com/v1/update/master/updatefile?os=linux&runtime=netcore&arch=arm64'which grabs (the latest?)https://github.com/lidarr/Lidarr/releases/download/v0.8.1.2135/Lidarr.master.0.8.1.2135.linux-core-arm64.tar.gzAre you willing to help maintaining the software installation, e.g. in case of needed setup changes due to updates etc.? This is not needed, but could speed up our decision to implement it, as man power is always a topic :wink:.
Vote for this software on FeatHub: https://feathub.com/MichaIng/DietPi/