Introduction
Recently NZBGet v17 was released which involved a massive re-factoring and over-haul of most of it’s back-end. Here is a quote taken from the ticket (#88) that makes up the bulk of this release:
Due to a wide variety of platforms we could not control which version of compiler is used. To make it compatible even with old compilers NZBGet was targeting old C++ versions.
In last years C++ has been evolved dramatically. New versions were standardized by ISO as C++11 and lately C++14. These new standards bring many interesting features to the language making it much more pleasure to work with.
The new (C++) standards are amazing, there is no doubt about that. But the problem is that not all (Stable) Linux distributions support these new standards. To put it in perspective, here is a chart of some Linux Distributions and the GCC standards they support (without any extra hacking/effort):
| Compatibility | C++98 | C++03 | C++11 | C++14 | C++17 |
|---|---|---|---|---|---|
| Red Hat 5 / CentOS 5 | Yes | Yes | No | No | No |
| Red Hat 6 / CentOS 6 | Yes | Yes | No | No | No |
| Red Hat 7 / CentOS 7 | Yes | Yes | Yes | No | No |
| Ubuntu 12.x | Yes | Yes | No | No | No |
| Ubuntu 14.x | Yes | Yes | Yes | No | No |
| Ubuntu 16.x | Yes | Yes | Yes | Yes | No |
| Fedora 22 | Yes | Yes | Yes | Yes | no |
| Fedora 23 | Yes | Yes | Yes | Yes | Yes | Fedora 24 | Yes | Yes | Yes | Yes | Yes |
The point is: By making NZBGet require the C++14 standard, the list of supported (Linux) distributions drops significantly.
Just use the NZBGet Binaries Already Provided
Yes, NZBGet allows you to install an already pre-compiled version of it, and if this satisfies your needs, then I’m not here to tell you to change.
In my personal opinion, there are several problems with going with this approach:
- Your program is statically linked to everything it uses. What does this mean? It means that any vulnerabilities discovered and patched on your system (via distributed system updates) will NOT patch NZBGet. These patches that are released don’t just resolve vulnerabilities, but they also add stability too.
This isn’t to say NZBGet isn’t stable, it’s to point out that it can’t reap benefits of added stability when it becomes available. - There is no package management using the binary provided on NZBGet’s website and therefore no version control (unless you’re using Microsoft). Thus, you can’t automate it’s deployment through tools like yum, dnf or apt-get (depending on your distribution).
Just to give you an idea of how many libraries NZBGet (v17) links to; here they are. I also identify the likelihood of a patch to be released between now and the next 3 months (purely speculation based on recent releases):
| Package | Risk | Description |
|---|---|---|
| glibc, libgcc & libstdc++ | MED | The systems standard libraries (what this whole blog is about really). Ideally you don’t want to use programs that aren’t linked to a different system core then the one your system depends on. This core is managed by your distribution and is key to it’s stability. It only makes sense to use it for everything else too! |
| gmp | LOW | Just a really powerful library for doing mathematical calculations. There are rarely exploits found here; but it’s worth noting that this is a dependency of NZBGet. |
| keyutils-libs | MED | A wrapper library for the key management facility system calls |
| krb5-libs | MED | A network authentication system. |
| libselinux | LOW | An API for SELinux applications to get and set process and file security contexts and to obtain security policy decisions. This is very customized for each distribution. Ideally you’ll always want to link to you’re managed library. |
| libxml2 | LOW | XML Parser which is used for reading through your NZB Files and RSS feeds. |
| nettle, trousers & openssl-libs | HIGH | The encryption between you an your Usenet provider is here. This is also the encryption between you and your indexer. There are constant exploits an vulnerabilities detected in these encryption libraries. These libraries alone are the main reason you should not use the NZBGet binaries and link to the ones you can keep current instead. |
| xz-libs, & zlib | LOW | Compression libraries for handling zip files (like those zipped NZB files for example when bundled). |
| p11-kit, pcre, ncurses-libs, libtasn1, libffi, & libcom_err | LOW | Some important libraries, but nothing with a high risk level associated with them. They’re still worth noting as they’re part of its requirements. |
The point is that there are a lot of moving parts that make up NZBGet and you should make sure that it links to shared actively maintained libraries that you have control over.
You Talk To Much, Just Hand Over Whatever It Is You’re Selling!
Sure, here they are:
- CentOS 7: rpm / src
Note: This is the true bread and butter of this blog because this rpm contains the NZBGet v17 installable package completely modified to work with the C++11 standard. Thus you can take advantage of this beautiful piece of software while still using your shared libraries. - Fedora 22: rpm / src
- Fedora 23: rpm / src
- Fedora 24: rpm / src
The Fedora packages were all compiled using C++14 standard; there was no patch required for them.
You can also feel free to connect to my repository by following the information provided here and then download them using yum or dnf.
A worthy note about these packages:
- It’ll automatically create a nzbget user (an group) for you so that you can control access to your downloads better.
Adding users to it’s access is as simple as just adding them to the nzbget group:# Add a user to the nzbget group usermod -a -G nzbget myuser
- Provides a SystemD service ready to go for those who want to tie it to their systems startup and shutdown.
# Add NZBGet to the startup of your system systemctl enable nzbget.service # Start it up now if you like too! systemctl start nzbget.service # Now you can go ahead and access http://localhost:6789 with your browser # The default login/password is nzbget/tegbzn6789
- A small separate patch in these RPMs change:
- All of the ~/downloads references to ~/Downloads.
- All references to /usr/local/bin to /usr/bin.
- Added ~/.config/nzbget/ to the default paths list (for those who just want to run nzbget -d as they’re user). I personally prefer to tuck all my configuration files in .config/ instead of the root folder of my home directory (which still works too if you want).
- A default configuration (/etc/nzbget.conf) is pre-prepared for you which
- configures most of the basic settings out of the box such as unrar and 7za paths.
- sets up the logging directory to be /var/log/nzbget/nzbget.log (with log rotation on).
- sets up the $MainDir directory to /var/lib/nzbget which is pre-created already for you and protected by the nzbget user and group.
What About Everybody Else?
For those using other Linux Distributions like Ubuntu, you can download my patch file which back-ports all of the C++14 code to C++11 here.
Alternatively, you can follow these instructions which should get it working for you (using share libraries instead):
# Note: The below is only applicable to v17.0. # Download the NZBGet v17 Source wget https://github.com/nzbget/nzbget/releases/download/v17.0/nzbget-17.0-src.tar.gz # Download the patch: wget https://repo.nuxref.com/pub/patches/nzbget/nzbget-use.c++11.patch # Extract the tarball tar xfz nzbget-17.0-src.tar.gz # Change into the directory it extracts to pushd nzbget-17.0 # Apply the patch patch -p1 < ../nzbget-use.c++11.patch
You’ll see output like this:
patching file config.h.in patching file configure.ac patching file daemon/connect/Connection.cpp patching file daemon/connect/TlsSocket.cpp patching file daemon/main/Scheduler.cpp patching file daemon/queue/QueueEditor.cpp patching file daemon/util/Observer.h patching file daemon/util/Thread.cpp patching file daemon/util/Thread.h patching file daemon/util/Util.h patching file linux/build-nzbget patching file Makefile.in
You can now build NZBGet (assuming you have all the right libraries):
# first rebuild the configure script (part of what the patch prepares) autoreconf -i automake # You may need to install the following packages # Red Hat / CentOS 7: # sudo yum install libxml2-devel libpar2-devel \ # ncurses-devel dos2unix \ # openssl-devel autoconf, libtool, automake # # Ubuntu: # sudo apt-get install libxml2-dev libpar2-dev \ # ncurses-dev dos2unix \ # libssl-dev autoconf, libtool, automake # Now you can run the rest of the setup: ./configure # correct any problems you have here. The configure # script will look after telling you if you're missing # any libraries or not. If there are no problems then # go ahead and type: make # Now you can install it into your system make install
Now the last commands don’t provide you any kind of package management like RPMs or DEB packages do. But there is enough information in this blog create your own installable package here if you wanted. The main thing you accomplish is that you link a working copy of NZBGet to your stable (upgradable) system libraries.
Credit
Please note that this information took me several days to put together and test thoroughly. The C++11 patch alone took me several hours to test an create. I may not blog often; but I want to re-assure the stability and testing I put into everything I intend share.
If you like what you see and wish to copy and paste this HOWTO, please reference back to this blog post at the very least. It’s really all I ask.
Aug 5th, 2016 – Update
Since writing this blog, the amazing developer (hugbug) of NZBGet reached out to me to incorporate my patch (a much simplified version of it) into the next release of NZBGet (v17.1)! Here is a link to the pull request. So this pretty much renders this blog entry useless but accomplishing (at the end) none the less! 🙂 I still intend to package NZBGet (and all of it’s future releases) on my repository for those still interested.
Sept 10th, 2016 – Update
NZBGet v17.1 came out and the packages in this blog and the repository have been updated to reflect this. Those that still wish to build it manually can do so as follows:
# Download the latest version of NZBGet wget https://github.com/nzbget/nzbget/releases/download/v17.1/nzbget-17.1-src.tar.gz # You may need to install the following packages # Red Hat / CentOS 7: # sudo yum install libxml2-devel libpar2-devel \ # ncurses-devel dos2unix \ # openssl-devel autoconf, libtool, automake # # Ubuntu: # sudo apt-get install libxml2-dev libpar2-dev \ # ncurses-dev dos2unix \ # libssl-dev autoconf, libtool, automake # Now you can run the rest of the setup: CXXFLAGS="-std=c++11 -O2 -s" ./configure --disable-cpp-check # correct any problems you have here. The configure # script will look after telling you if you're missing # any libraries or not. If there are no problems then # go ahead and type: make # Now you can install it into your system make install
Sources
- An updated blog on setting up NZBGet and/or SABnzbd
- NZBGet Ticket #88: This is the ticket that made it so NZBGet became incompatible with so many systems.
- Just another blog on a good Usenet solution. It touches more on CentOS 6, but there are still other packages within it that are useful an compatible with the packages shared in this blog post.
- A great post that was invaluable in creating the C++11 patch on Stack Overflow.