I’m going to make an OBS package for Sonarr. At first I’ll just support OpenSUSE, but if people want to test packages, then it can build for Ubuntu, Debian, Fedora, CentOS, and Arch on i586, x86_64, some ARM platforms, and PPC. It can be synced up with Git to automatically build when a new tag is released.
I have some questions though:
Should I name the package and repo sonarr or nzbdrone? It’s a brand new package, so I don’t see why no call it sonarr, but nzbdrone is what’s used now.
I would be more than happy to move it to an official Sonarr OBS project after I get it stable and working in my home project. Would the official developers be interested in helping to maintain it?
What needs to be included as a dependency (not a build dependency)?
What are all of the default install locations that I need to know of (besides obvious things like the service configurations)?
sonarr, we’re phasing out nzbdrone as much as we can (until its completely moved over to sonarr)
Not really sure what that would entail, but we’re interested in figuring that out and having an official package.
mono 3.10+ (4.2.3 being the latest ATM), sqlite, media info (libmediainfo).
On Debian systems we use /opt/NzbDrone currently and the config is stored in ~/.config/NzbDrone, not sure if /opt/NzbDrone is the correct place (we’ve heard it isn’t), but we’re also considering something more user orientated so it has the permissions to update it, without setting the permissions after install.
Basically just pointing out breaking changes in the build process that come with new versions and ensuring that it doesn’t introduce new bugs/build failures. I have barely any knowledge of the actual code that Sonarr runs on, so I can only make it work so much.
It seems that /opt/sonarr would be the best place (according to this from the Linux Foundation. You should only use /usr/local/share (the only other possible place I think) for system-independent files (won’t work here because of compiled binaries for different architectures).
There are two methods to have the app function:
For a more traditional install, the config file would be in /etc/sonarr or /etc/opt/sonarr and the data/caches and other generated files would be in /var/opt/sonarr and/or /var/cache/sonarr. The config file could include only the more permanent things like the port to listen on or be omitted completely (this way things can be changed through the Web UI). A service would be added to the system (Systemd for OpenSUSE) that would run Sonarr as its own system user (this does mean that files created by Sonarr will need to have their permissions properly set to be read by whoever owns the parent folder).
With this method the package manager can properly update the app. In order to turn it on or off, a user must have administrator access to the system’s service manager.
For a more user-friendly install, a bash script would download the necessary files and bianries to ~/.sonarr of the current user’s home folder. The configuation and data could be stored in the same place or in ~/.config/sonarr. It would start with user login.
The caveat to this approach is that it would be a bad practice to have a system service reference a user’s home folder to start Sonarr on boot. However, the app would be able to update itself very easily. You wouldn’t need or use OBS or a real package for this approach, as you can just host the built packages somewhere and have Sonarr download and unpack them itself.
The last approach is the “best of both worlds” (but it has caveats too). Like option #2, a bash script will download Sonarr and Sonarr will update itself. However, it will extract to /home/sonarr or /opt/sonarr. The Sonarr user will own this folder.
This way a service can be created that doesn’t reference a non-system user or their home folder. However, the caveat is system security. The “proper” part of option #1 is really that everything is separated: only root can actually change the application files and configurations, and permanent configuration is held separately from the package files. This is very secure compared to the other solutions. Once again, you wouldn’t use a system package or OBS for this approach.
Wow. That’s a lot to consider. While all three options are easy for a simple user to deploy, I really side with option #1 with the system package because of the properness and fewest amount of failure points. You’ll have the least number of people cringe, and it’s two less things to worry about: dependencies and updating. You can’t really have a system package if you want automatic updates, but it’s way easier to deploy a architecture-specific binaries with system packages. With a package, the system will take care of the dependencies for you and require minimum versions of them with corresponding Sonarr versions. Basically, the package is a much more controlled environment. Users will be responsible for updating, but most distros with a major graphical environment enabled have an update utility that pops up at least weekly (most Ubuntu flavors, OpenSUSE, and even GNOME I think has it’s own thing). If a user is running without a graphical environment, then there’s a good chance that they know how to update the apps manual.
I would be happy to help develop whichever of these methods you prefer (it’s not my project, but I want to help).
We wanted to get rid of the permission issues related to the ubuntu package+built in updater, and that the apt-get would update to master, and built-in to develop if the user configured it differently.
To do that we wanted to create a ‘bootstrapper’ package, one that configures the upstart/systemd script, directories, permissions etc. But leave the updating to the built-in updater. The bootstrapper package wouldn’t get any updates.
Obviously there would be users that want to use the package manager exclusively for updating/security, so there would still be an full package available, but with the built-in updater not available. And only for the master branch.
Either way, the boostrap package would have to create a user, set permissions etc.
We want to supply systemd/upstart/init scripts from the get go, we don’t want ppl to write their own coz we can’t deal with the UI restart+shutdown logic.
We also need to start supplying packages for other distros, fedora, suse and some others have been on the list. But we won’t do that till we can create a VM for em to run the unit tests.
I also want to get rid of the default ~/.config/NzbDrone, instead using the /var/opt/Sonarr directory. Ppl would still be able to install Sonarr elsewhere, and configure it for a different data-dir. But stashing it in a home dir by default has been less than optimal.
Providing packages & startup scripts makes managing that easier. While still allowing ppl to tweak it.
Personally I’m not sure that OBS is useful in our case, considering we run thousands of unit tests for every release (on windows and ubuntu separately), we also have fairly close reigns on the build process via TeamCity.
Finally, we don’t build using tags. I put up the tags manually on the master branch so it’s easier to diff, but that’s it, just a convenience. develop auto-builds whenever a new commit is made, master is triggered manually.
It sounds like you want to go with the bash install script method. I don’t think that it’s worthwhile to have a package that simply doesn’t update and bootstraps the install. You would basically just be installing a script, which is an extra step when you can just run the script from curl. It’s just more to maintain. Plus, if your dependency requirements ever change, you will have to somehow sync the package updating with Sonarr’s version.
If you really want to ship RPM and DEB installers, OBS can save you a lot of hassle creating packages and repositories for Fedora, Ubuntu, OpenSUSE, and CentOS on all of the architectures. You wouldn’t run unit tests with OBS. You would still use TeamCity for that. Either your spec file works or it doesn’t. It’s just a script to configure what goes where and what dependencies are required. I’m not aware of any build service that will let you run tests on the packages.
It seems that you want bash script that will need to do the following:
Install easily with this type of command: curl -S https://download.sonarr.tv/v3/linux.sh | sudo bash
Detect the OS, ask to continue if it’s not supported
The script will create the user and group sonarr:sonarr
The script will create /opt/sonarr and /var/opt/sonarr and set sonarr:sonarr to own it with the right permissions.
Download and unpack Sonarr into /opt/sonarr.
If the dependencies aren’t already bundled or downloaded from a Sonarr official package (which would remove a lot of hassle here and make sure that everyone using Sonarr has the exact same configuration), it will detect the OS (and therefore the package manager) and install the dependencies.
Detect the OS’s service system and move and enable the proper file
Start Sonarr and prompt to go to a URL in your web browser
I would be happy to get started working on said script. Please let me know what you want for the following:
Whether or not to use a package or just a script
User/group name
Permissions and ownership of /opt/sonarr and /var/opt/sonarr
Would you be opposed to a --advanced flag that would prompt the user for directories, user/group name, force service type, etc.