Debian/Ubuntu user feedback requested

v3 Testing
#1

I’ve been working on improved package scripts for debian/ubuntu and I’d like you feedback on it.

Introduction

v2 had a few big issues when it came to the debian package.

  1. The lack of built-in startup scripts
    Was already handled in the v3 alpha, but required further refinement to deal with username and group settings.

  2. Incorrect ownership and permissions
    Was handled in v3 alpha by giving the appropriate user (sonarr) ownership of the binaries.

  3. apt updates conflicting with the built-in updater
    This issue mostly persists, the permission issue is resolved, but if apt installs ‘master’ and built-in ‘develop’, people would end up with downgrades. Either way users would end up installing the same version twice, once in-app and once via apt.

Planned changes

  1. Migration support for NzbDrone package
    I wanted to mention it last, but let’s start on a high tone.
    The sonarr package will automatically detect running instances of nzbdrone, and automatically bail if it’s still running. UNLESS there is an systemd unit associated with that instance. In that case sonarr will stop nzbdrone, mask (disable) the unit… pickup the existing nzbdrone database and import it.
    We will not automatically migrate installs that use classic init.d scripts, we had to draw the line somewhere.
    It will however not reuse any of the user/group names, but more about that later.

  2. Less package releases
    Instead of publishing each release (eg 3.0.0.310) to apt, we plan to publish 3.0.1. That takes care of all the startup-scripts, users, groups and permissions. But the built-in updater takes care of further releases.
    If something changes in the startup-scripts or OS dependencies, then we’d publish 3.0.2, but is expected to be a rare occurrence.
    For the diehards and debian-puritans, we’ll also publish each release in a separate repository, but in that version the built-in updater will be entirely disabled and branch-locked. (With the hope that very few would use it)
    This mostly deals with issue 3, because both the package and built-in updater will be somewhat aware of eachother and avoid conflicts.

  3. Use debconf for user/group
    In my personal setup I have a ‘sonarr’ user and a ‘mediahost’ group. The group contains other members such as ‘sabnzbd’ and ‘plex’, this ensures that the related apps have the required permissions to access my media files.
    I found it rather annoying that I had to use systemctl edit sonarr.service to edit the startup group.
    So, in the new package, debconf has been configured with 3 questions of which only one is asked by default: the group name. While defaulting to ‘sonarr’, it’s likely that this group should be different and it’s better to ask the user.
    The other questions are of ‘low’ priority and only asked if apt is given the appropriate cmdline argument. ‘user’ defaults to ‘sonarr’ and ‘config dir’ defaults ‘/var/lib/sonarr’, which are sensible defaults imo.
    The specified user and group is used to assign ownership to the binaries and app data folders, as well as initializing sonarr.service with the same values.

  4. Move out of /opt
    There has been some confusion on my part about what debian really advices. In a way sonarr is an add-on software and would belong in /opt and /var/opt, but the debian guide indicates that only stuff without a package belongs there.
    So I’ll be moving the binaries /opt/sonarr to /usr/lib/sonarr. And the config from /var/opt/sonarr/.config/Sonarr to /var/lib/sonarr. Both moves are dealt with automatically.
    This is more in line with what we see with other apps such as ‘plex’, and i figured we had only one chance to do it right this time.

  5. Don’t use home directory
    I also highlighted it a bit above, v3 alpha was actually assigning /var/opt/sonarr as home dir for the ‘sonarr’ user, and dumping the actual database files in /var/opt/sonarr/.config/Sonarr. This felt wrong. So when creating the user we don’t assign the home dir anymore (actually we assign /nonexistent per some guide), but existing users aren’t modified. And in sonarr.service we added -data=/var/lib/sonarr as appdata directory.
    (Yes, this path can be changed via the debconf mentioned earlier)
    The package will automatically migrate older v3 alpha installs.

  6. Updated sonarr.service umask
    I also added Umask=002 to ensure that any files written by sonarr automatically give rw permission to the group as well.

Feedback

So, what do you think about these changes. Do they fit better for your particular setup? Do you have an edge-case that would interfere with these changes?

We also need to translate this to other platforms, such as docker, synology, qnap and others. But we’re not actually responsible for those ports. So I expect some head-butting with package maintainers.

#2

While I agree most of this makes sense, the only item that I dont like is not prompting by default for the user and assuming sonarr. If we are prompting for the group, why not the user? I get that a lot of applications run under different users, for permission controls, however in my case I run all my media applications, except for plex, under the “VPN” user. This user has dedicated routing in my IP tables to ensure all traffic for applications run by this user go over my VPN tunnel.

#3

That’s an interesting usecase for the username.

I kinda had to make trade-off. I preferred asking no questions as all but the default for group simply didn’t make sense from a permission standpoint.
This is going to be the first ‘experience’ people have when installing sonarr and I prefer to keep it as simple as possible.

It’s still possible to pick the user, either via dpkg-reconfigure or DEBIAN_PRIORITY=low/medium apt install sonarr, but that latter one is certainly less convenient and something powerusers must know before hand to be effective.
I’d be willing to consider setting user to high prio as well, but first let’s see how others respond.

An alternative might be to ask for the group first, and if the user changes the group, ask for the user as well.

#4

An alternative might be to ask for the group first, and if the user changes the group, ask for the user as well.

I like this approach, and think it would be a good alternative.

#5

I updated the config script locally to see how it goes, but it feels odd. We basically have a few scenarios.

debconf priority is high by default, at least it was on my install. Users can configure debconf to have another priority such as normal. normal is supposed to have decent defaults, why high does not.

Previously the user could run:

  • run apt install sonarr and get asked only for the ‘Sonarr Group’.
  • or; run DEBCONF_PRIORITY=medium apt install sonarr and get asked for the ‘Sonarr User’ and then the ‘Sonarr Group’.

The new scenario goes like this:

  1. user runs sudo apt install sonarr
  2. debconf asks for the ‘Sonarr Group:’ with a default of ‘sonarr’:
    Description: Specify the group that Sonarr must run as. The group will be created if it does not already exist. If the user doesn't already exist then this group will be specified as the user's primary group. Any media files created by Sonarr will be writeable by this group. It's advisable to keep the group the same between download client, Sonarr and media centers.
    2a) If the user doesn’t change the default then that’s all the user is asked.
    2b) If the user does change the default then debconf will ask for the ‘Sonarr User:’ (default ‘sonarr’)
    Description: Specify the user that Sonarr must run as. The user will be created if it does not already exist.

My problem with that is that the description of the ‘Sonarr Group’ mentioned a username that it hasn’t asked for yet. That feels confusing.

Finally, I made group a high priority because I want ppl to enter a more sensible group name. If people follow that advice, then we force the question about user to appear. Thus most ppl will be asked both questions regardless and the whole trick becomes meaningless.

I see two reasonable options:

  1. Always ask for user and group.
  2. Only ask for group. And instead add a hint to the install documentation so powerusers are made aware of
    DEBCONF_PRIORITY=medium/low and dpkg-reconfigure.
#6

Haven’t used 3.0 yet but from the current setup I’d say better to ask for both. As you say, it’s more logical and it’s also somewhat expected since you’ll run into similar configuration situations on other applications as well.

#7

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.