I’ve been working on improved package scripts for debian/ubuntu and I’d like you feedback on it.
v2 had a few big issues when it came to the debian package.
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.
Incorrect ownership and permissions
Was handled in v3 alpha by giving the appropriate user (sonarr) ownership of the binaries.
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.
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.
Less package releases
Instead of publishing each release (eg 184.108.40.2060) 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.
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.serviceto 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.
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
/var/opt, but the debian guide indicates that only stuff without a package belongs there.
So I’ll be moving the binaries
/usr/lib/sonarr. And the config from
/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.
Don’t use home directory
I also highlighted it a bit above, v3 alpha was actually assigning
/var/opt/sonarras 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/sonarras appdata directory.
(Yes, this path can be changed via the debconf mentioned earlier)
The package will automatically migrate older v3 alpha installs.
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.
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.