Tag Archives: Centos

The Perfect Home Assistant CentOS 8 Installation

Introduction

If you have a dedicated server that you want to set up Home Assistant on and would like to run it natively (not in a container), then this is the tutorial for you. This tutorial focuses on using CentOS 8 because I am personally familiar with RedHat based products. But those who chose to use Ubuntu, Debian, Alpine, Arch, etc should be able to benefit from a good chunk of the information explained here too.

Minimum Requirements

While Home Assistant works awesome on a Raspberry Pi for simple things, it can start to get sluggish and feel under-powered over time as you get addicted like the rest of us and continue to add automations to it. It specifically takes a hard it once you start adding automations that involve video and get fancy with others.

nuc6i5syh
Intel Nuc Kit nuc6i5syh
Thus, if you’re a hobbyist who plans on continuing to evolve your homes automation over time, a Raspberry Pi is not good enough. A small PC (and this tutorial of course πŸ˜‰ ) is the best way to go.

I am personally using a very old (outdated) model of an Intel Nuc that works great. But even if you just have an old PC lying around in the corner, that would be a fantastic choice too! Despite the official requirements identified here, for the most optimal experience (in my opinion), your Home Assistant PC should have:

Type My Suggested Minimum Requirement
RAM 8GB
CPU >= Intel i5
Network >=100Mbit/s
It’s strongly recommended that the server you choose to set up Home Assistant utilize a physical network cable and not WiFi.
Storage >=32GB
Storage is only really important if you plan on installing home surveillance (specifically video cameras). If you do, then target your storage to be at least 512GB or more instead. This will allow you to record with them and save the content locally (should you choose to do this).

Here is the breakdown of where the storage all goes (with respect to this tutorial):

Path Size Details
/etc/homeassistant/ 1GB Your configuration files are small (less then 256KB), however Home Assistant maintains what is called a Recorder which tracks itself in an SQLite database. This SQLite database tends to grow over time in size (which you can control). This is also the location of your homeassistant.log file which can also grow in size as well. By giving yourself (at least) 1GB here, you just provide enough room for future growth that will never interrupt your setup over time. More on the contents of this directory is discussed near the end of this blog.
/opt/homeassistant/ 2GB The entire installation of Home Assistant will sit here once you’ve completed this tutorial. The actual installation (with most bells and whistles) is just under 1GB. 2GB is just a suggested size because it will leave you with plenty of room for future growth.
/ 6GB Your root filesystem and all the core directories that go with it such as /boot, /tmp, /home, /usr, /var, … etc.
6GB is more than enough to host the Linux operating system and all of it’s needs while still leaving you ample space for growth.
/opt/homeassistant/video/ >128GB I’m just throwing this in here… Those who don’t have video recording cameras at their home (inside and out) can ignore this. But consider at LEAST 32GB per camera depending on how much you want to record. You may also want to plan for an expansion down the road too; I said >=512GB earlier and I meant it. Storage is cheap these days, so plan properly at the start.

Download the latest copy of CentOS 8 and stick it on a spare USB Drive you have and/or burn it to a DVD so that you can install it onto your PC.

The Base Home Assistant Setup

It is assumed at this point that you’ve set up your server or already had one running. Let’s set up a working environment that Home Assistant can work in. It’s important to have root or sudo privileges prior to running the commands below in each section.

General Server Preparation

The safest way to run Home Assistant is with it’s own dedicated user and permissions. The following will set up a working environment for us to build further onto:

# Again.. our basic layout will be:
# User: homeassistant
# HA Config: /etc/homeassistant
# HA Core: /opt/homeassistant

# Prepare our user:
sudo useradd -rm homeassistant \
   --home-dir /opt/homeassistant

# The dialout group allows us to access our external USB
# devices such as the Aeotec Z-Stick Series 5 (which is
# what I use). We want to add our user to this group:
sudo usermod -aG dialout homeassistant

# Prepare our configuration directory
sudo mkdir /etc/homeassistant

# Adjust our permissions
sudo chown -R homeassistant:homeassistant \
   /opt/homeassistant /etc/homeassistant

# Some of the packages later installed with pip3
# require that they are compiled in your environment
# (or it will not work) so the following is also
# required:
sudo dnf install -y gcc make gcc-c++ systemd-devel \
    unzip tar

Python 3.8 Setup

We need to setup Python 3.8 into our CentOS environment because it is the minimum requirement for Home Assistant to work. So basically we have 2 options here: Take the most stable version of v3.8, or take the one manged by CentOS which is sometimes outdated. Either way, I’ve explained both below:

  1. Option 1: The CentOS Maintained Version:
    # Simply install the module
    sudo dnf module -y install python38 python38-devel
    
    # That's it... you're done :)
    
  2. Option 2: The Latest Stable Version:
    sudo dnf install -y bzip2-devel expat-devel gdbm-devel \
        libuuid-devel libffi-devel\
        ncurses-devel openssl-devel readline-devel \
        sqlite-devel tk-devel xz-devel zlib-devel wget \
        gcc make gcc-c++ tar
     
    # At the time this blog was written, the current
    # version was v3.8.5:
    VERSION=3.8.5
    
    #
    # Acquire
    #
    wget https://www.python.org/ftp/python/${VERSION}/Python-${VERSION}.tgz
    tar -xf Python-${VERSION}.tgz
     
    #
    # Configure
    #
    cd Python-${VERSION}
    ./configure --enable-optimizations
    
    #
    # Build
    #
    
    # This step can take a while - so be patient!
    make -j 4
    
    #
    # Install
    #
    
    # This is very safe and will not over-write
    # existing Python that ships with CentOS
    sudo make altinstall
    

Regardless of which route you chose to take, you can test the version out to see if you were successful:

# Test the version out:
python3.8 -V

Surveillance Video Camera Setup

Run the following commands if you have or plan on having surveillance cameras installed into your environment. Feel free to run this at a later time if you want. Basically you need a copy of ffmpeg available if you plan on accessing your camera stream in Home Assistant.

sudo dnf install -y epel-release dnf-utils
sudo yum-config-manager --set-enabled PowerTools
sudo yum-config-manager \
   --add-repo=https://negativo17.org/repos/epel-multimedia.repo
sudo dnf install -y ffmpeg

Home Assistant Installation

Assuming you’ve followed the sections Python 3.8 Setup and General Server Preparation above, we can now install Home Assistant:

# First we switch to our new homeassistant user we created:
sudo -u homeassistant -H -s
 
# Optional SSH Keygen Setup
[ ! -f ~/.ssh/id_rsa.pub ] && \
   ssh-keygen -f ~/.ssh/id_rsa -C "Home Assistant" -q -N ""

# Change to our home directory (if we're not there already)
cd /opt/homeassistant

# Prepare our virtual environment
python3.8 -m venv .

# It's always VERY important you activate your
# environment before you start running pip3
# commands
. ./bin/activate

# Perform our installation:
pip3 install homeassistant home-assistant-frontend \
     homeassistant-pyozw colorlog flask-sqlalchemy

# Return back to our root user
exit

Finally we must create an System D Startup file to make it easy to start/stop our instance of Home Assistant:

# the following will drop us in a startup script we can use with our environment
sudo bash <<EOF
cat << _EOF > /usr/lib/systemd/system/home-assistant.service
[Unit]
Description=Home Assistant
After=network-online.target
 
[Service]
Type=simple
User=homeassistant
ExecStart=/opt/homeassistant/bin/hass -c "/etc/homeassistant"
WorkingDirectory=/opt/homeassistant
PrivateTmp=true
Restart=on-failure
 
[Install]
WantedBy=multi-user.target
_EOF
EOF

# Pick up our new configuration
sudo systemctl daemon-reload

# Make it so Home Assistant starts even after a
# server reboot
sudo systemctl enable home-assistant

# Let's start it up now
sudo systemctl start home-assistant

The final piece of the puzzle is to expose port 8123 to our network so that we can access our instance of Home Assistant:

sudo bash <<EOF
cat << _EOF > /usr/lib/firewalld/services/home-assistant.xml
<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>Home Assistant</short>
  <description>Home Assistant Web Portal</description>
  <port protocol="tcp" port="8123"/>
</service>
_EOF
EOF

# Reload our firewall so it can find our recently
# created configuration file (defined above)
sudo firewall-cmd --reload
 
# Now we'll add our new firewall service
sudo firewall-cmd --zone=public \
   --add-service=home-assistant --permanent

# once again reload our firewall to open our newly
# declared port:
sudo firewall-cmd --reload

Finalizing Your Installation

Home Assistant Initial Login PageYou can now visit your new Home Assistant server at http://ip.to.your.server:8123 and start setting up your account for the first time.

When you first access the page you will be able to create the first system user (also the administrator account) that you can build automations with.

Home Assistant Upgrades

You’ll find that Home Assistant is rapidly expanding and always fixing issues and adding more cool features you can play with. Upgrading Home Assistant is as easy as this:

# Switch to our home assistant user:
sudo -u homeassistant -H -s

# Change to our home directory (if we're not there already)
cd /opt/homeassistant

# It's always VERY important you activate your
# environment before you start running pip3
# commands
. ./bin/activate
 
# Switch to our homeassistant user
pip3 install --upgrade homeassistant

# Return to our user with sudoer's permission
exit

# Restart Home Assistant
sudo systemctl restart home-assistant

A Quick Overview

At this point you should be all set up with a running copy of Home Assistant to play with. Here are some general files and directories that will begin appearing in your server’s filesystem in the /etc/homeassistant/ directory that you may want to know about:

homeassistant.log

All of the logs associated with Home Assistant will show up here. This is a fantastic location to begin your troubleshooting should you run into problems.

configuration.yaml

This is the core configuration that will drive your entire Home Assistant application from this point forward. Any changes to this file will require you to restart Home Assistant for the changes to take effect.

home-assistant_v2.db

This is the Home Assistant Recorder. From within your Home Assistant Dashboard, you can click on History button off of the dashboard to see the contents.

/etc/homeassistant/home-assistant_v2.db example

secrets.yaml

This is a simple file that allows you to map key/value pairs. The idea is to keep all of your passwords and/or tokens that you otherwise want to keep from prying eyes. This file should be given very strict permissions:

# protect this file if you intend to use it
chmod 600 /etc/homeassistant/secrets.yaml

For example, you might use Apprise to send you an email notification. In order to send an email Apprise needs your personal email information. As an example, in your configuration.yaml file you might do this:

# /etc/homeassistant/configuration.yaml
# ...
notify:
  name: apprise
  platform: apprise
  url: !secret apprise_url

Then in your secrets.yaml file you now need an entry for a new keyword you created called apprise_url. Your entry in the secrets.yaml file might look like this:

# /etc/homeassistant/secrets.yaml
# Define your Apprise details in a secure location:
apprise_url: mailto://myuser:mypassword@gmail.com

More details on how secrets work can be found here in the Home Assistant documentation. Also, check out the Apprise wiki to see all of the different services you can notify with it.

automations.yaml

This is where you can begin constructing your own Home Assistant automations once you’ve added a few integrations into Home Assistant.

An example of an automation you might have set up could send us an email using Apprise at sunset:

# /etc/homeassistant/automations.yaml
#
# Utilize Apprise to send a notification
#
alias: "[Interactive] - Sunset Apprise Notice"
trigger:
  platform: sun
  event: sunset

action:
  service: notify.apprise
  data:
    title: "Good evening"
    message: "This sun is setting."

Configuration Backup

No setup is complete without regular backups taking place. The following is just a basic configuration backup setup you can use to get you started:

# For Backups (run these commands as the homeassistant user):
sudo mkdir -p /opt/homeassistant/backups
sudo chown homeassistant.homeassistant /opt/homeassistant/backups

# This is a simple script to get you started:
sudo bash <<EOF
cat << _EOF > /opt/homeassistant/bin/backup.sh
#!/bin/sh
# Create a backup of Home Assistant
TARGET=/opt/homeassistant/backups
SOURCE=/etc/homeassistant
 
[ ! -d "\$TARGET" ] && /usr/bin/mkdir -p "\$TARGET"
[ ! -d "\$TARGET" ] && exit 1
 
tar cfz "\$TARGET/\$(date +'%Y.%m.%d')-config.tgz" -C \$SOURCE . 
RET=\$?
 
# Tidy; Keep X days worth
find -L \$TARGET/ -mindepth 1 -maxdepth 1 -name "*.config.tgz" -mtime +120 -delete
exit \$RET
_EOF
EOF

# Permissions to be executable
sudo chmod 775 /opt/homeassistant/bin/backup.sh

# Prepare ourselves a cron job that will run our backup every week
sudo bash <<EOF
cat << _EOF > /etc/cron.d/homeassistant_backup
0 0 * * 0 homeassistant /opt/homeassistant/bin/backup.sh &>/dev/null
_EOF
EOF

Credit

This blog took me a very (,very) long time to put together and test! 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. Alternatively, I certainly won’t turn down a coffee if you wish to buy me one! πŸ™‚

Sources

A Free SSL Web Hosting Solution

Introduction

SSL Web Hosting has been made free by a number of providers such as Let’s Encrypt and ZeroSSL for years now. I wrote this blog because I truly believe web administrators and developers should leverage this if they aren’t already.

I’ve personally come across an amazing tool called Dehydrated which I used to leverage this. The best part about Dehydrated is that it even operates using the MIT license, meaning it’s also completely free to use!

Dehydrated Setup

An ideal SSL Web Hosting solution comes with the perfect tool to do all of the work for you…

Installation

#
# Make sure curl is installed:
#
# RedHat/CentOS v5,6, and 7 Users
sudo yum install -y curl

# RedHat/CentOS v8+ and Fedora Systems:
sudo dnf install -y curl

# Debian/Ubuntu Systems
sudo apt update && sudo apt get curl

# Download Dehydrated (as root)
curl https://raw.githubusercontent.com/dehydrated-io/dehydrated/master/dehydrated \
   --output /usr/bin/dehydrated

# Set proper permissions
chmod 755 /usr/bin/dehydrated

# Make a wellknown directory for the acme-challenge strings
mkdir -p /var/www/dehydrated

# SELinux Proof it (for those that use it - and you should!)
semanage fcontext -a -t httpd_sys_content_t \
          '/var/www/dehydrated/(/.*)?'

Initial Preparation

Next we need to just prepare some basic configuration needed by Dehydrated:

mkdir -p /etc/pki/dehydrated
pushd /etc/pki/dehydrated

# SSL Hosting Configuration; Identify your hosts
#
# Below shows how I set up nuxref.com; you will want to
# identify ALL of the SSL hostnames you plan on supporting
# here:
cat << _EOF > domains.txt
# nuxref Hosts; swap these with your own:
# syntax:
#   domain sub1.domain sub2.domain subx.domain > output_file
nuxref.com www.nuxref.com repo.nuxref.com > nuxref_com
_EOF

# Create ourselves a config file:
cat << _EOF > config
# our wellknown directory
WELLKNOWN=/var/www/dehydrated
_EOF

# First time use only
/usr/bin/dehydrated --register --accept-terms

Nginx Configuration

You’ll want to create the the following parameter file that you can source in all of your domain configuration files:

cat << _EOF > /etc/nginx/dehydrated_params
location ^~ /.well-known/acme-challenge {
   alias /var/www/dehydrated;
}
_EOF

The sourcing part is really easy now. You must add this entry in all of your configuration files that you’ve defined in your /etc/pki/dehydrated/domains.txt file (above).

# Place this in all of your NginX files in the server{} block(s):
include        dehydrated_params;

You’ll want to make sure once you got all of the include statements in place, and that you reload NginX so that it can take on your new configuration:

sudo systemctl reload nginx

Generating our SSL Keys

We’re now at the part of the blog where we test to see if all of our setup (defined above) was correctly put into place.

# We must always run Dehydrated from within this directory
pushd /etc/pki/dehydrated

# Force an initial update
dehydrated -c

The above command will run against all of the domains you defined in /etc/pki/dehydrated/domains.txt and attempt to verify them (in order to generate an SSL key for you). If it fails, it’s most likely because of the following:

  1. You’re not correctly hosting that domain on port 80 on this server we just set up together.
  2. You have an error in your NginX configuration and/or you forgot to add an include dehydrated_params; within one of your domain configuration(s).

If everything went smoothly, you’ll now have new SSL keys you can add to your NginX configuration. This allows you to host your website secured now using your own set of registered SSL keys. You’re almost home free now! You need to dive back into NginX and prepare yourself a new server block of code that listens on port 443 with SSL turned on.

server {
  # SSL
  listen 443;
  ssl on;

  #
  # your security setup and location entries here
  # See https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html
  # for some ideas

  # Don't forget to point to your newly generated SSL Keys:
  # swap nuxref_com
  ssl_certificate /etc/pki/dehydrated/certs/nuxref_com/cert.pem;
  ssl_certificate_key /etc/pki/dehydrated/certs/nuxref_com/privkey.pem;
}

Set It and Forget It

Free SSL Web Hosting keys being free do however come with a catch: they don’t last long. They don’t expire in 2-3 years like a normal paid key would – these ones expire in 30 days in some cases. So it’s up to you to either remember to run dehydrated -c often, OR just automated it like so:

# next add a cronjob so it updates automatically
cat << _EOF > /etc/cron.d/dehydrated
# at 14:20 every day update SSL certificates
20 14 * * * cd /etc/pki/dehydrated/ && dehydrated -c &>/dev/null && systemctl reload nginx &>/dev/null
_EOF

Sources

A Redhat Usenet Solution

Introduction

The two top programs in the Usenet world are NZBGet and SABnzbd. Both of these tools have their strengths and weaknesses. Both of them also have a strong community that chooses one over the other and have their own preferences why they did. But at the end of the day, both of them are amazing and well maintained by their developers and the community that follows them.

I’ve recently begun packaging these tools in addition to some of the plugins that go with them. My goal was to just bring awareness to those who use the CentOS/Fedora/RedHat world that their lives just got easier! At the time this blog was written CentOS 8, Fedora 31, Fedora 32, and Fedora 33 were the current distributions.

The Setup and Target Audience

This blog was centered around the Nuxref repositories I maintain. Thus, this is the cleanest CentOS/RedHat RPM based installation with very little effort required. Simply:

  1. Connect to my repository.
  2. Install your desired packages (explained below):
  3. Enjoy!

The Nuxref Repositories

Before you proceed with the rest of this blog; you’ll first want to get yourself set up with the Nuxref repositories. This is where all of the packages are that will allow you to proceed with one (or both) of the solutions below.

The easiest way to do this is to visit the repository website and follow the instructions to get connected.

CentOS 8 users will want to connect to EPEL if they haven’t already done so:

# Connect to EPEL:
sudo dnf install -y epel-release

NZBGet Usenet Solution


The NZBGet solution comes with the following:

Provides a SystemD service ready to go for those who want to tie it to their systems startup and shutdown.

# Install NZBGet from the Nuxref repository
sudo dnf install -y nzbget

# Add NZBGet to the startup of your system
sudo systemctl enable nzbget.service

# Start it up now if you like too!
sudo systemctl start nzbget.service

You’ll now be able to access the web page through your browser accessing:
http://localhost:6789.
Note: The default login/password is nzbget/tegbzn6789 when prompted.

Here is a breakdown of how the custom NZBGet package works:

  • A default configuration (/etc/nzbget.conf) is pre-prepared for you which
  • sets up the logging directory to be /var/log/nzbget/nzbget.log (with log rotation on).
  • All of the variable data (file processing, etc) will be located in /var/lib/nzbget/*. In fact this is a very important directory because unless you configure things differently, all downloaded content will appear in /var/lib/nzbget/downloads.

To grant users on your system access to the data available through NZBGet, simply just add them to the nzbget group:

# swap the USER with your username you want to add to the
# nzbget group:
sudo usermod -aG nzbget USER

You can optionally choose to just run nzbget -d using your general account to launch a personal instance of NZBGet.

NZBGet Notifications

NZBGet can keep you posted on what it’s doing by sending you emails when a download completes (or fails). But it’s not just emails it can use as a medium; it can be Gotify, Twitter, Telegram, Amazon SNS, Slack, etc.

To leverage the notification features, you just need to install the NZB-Notify Plugin:

# Install the notification plugin from the Nuxref repository
sudo dnf install -y nzbget-script-notify

# Reload NZBGet so it takes on the new configuration
sudo systemctl restart nzbget

To enable it, you simply need to need to access the Notifications tab from within the NZBGet Settings section.

NZBGet Notification Setup
  1. Select the SETTINGS entry at the top right.
  2. Select the NOTIFY entry on the left hand side
  3. Notifications basically have to be defined as Apprise URLs; you can learn to construct the one for the services you wish to use here.

Finally it is a good idea to ensure the Notifications are triggered to run at the proper times:

NZBGet Settings – NZB-Notify Ordering
  1. Select the SETTINGS entry at the top right (if you’re not there already still from the previous steps).
  2. Select the EXTNSION SCRIPTS entry on the left hand side
  3. Make sure the Notify.py is listed in both the Extensions and ScriptOrder section.

NZBGet Video Sorting

Another great plugin for NZBGet is one that allows all content downloaded to be automatically sorted/renamed into a very conventional format. The amazing tool that does this is VideoSort. I’ve also gone ahead and packaged this so it would easy to use in a CentOS/Fedora enviroment like everything else:

# Install the videosort plugin from the Nuxref repository
sudo dnf install -y nzbget-script-videosort

# VideoSort can be a bit confusing to setup the first time; so the best way I can
# make this incredibly easy for you is to pre-load you with some good default
# configuration.  Here is how you can do it:

# First stop NZBGet:
sudo systemctl stop nzbget

# Backup the configuration file (so you can restore things they way they
# were if you don't like my approach):
sudo cp /etc/nzbget.conf /etc/nzbget.conf.backup

# Now thrown in our default configuration
# (just copy and paste the below):
NZBGETCFG=/etc/nzbget.conf

# First tidy up any conflicting entries (don't worry
# you backed this file up remember, we can roll back if you're
# not happy after:
sudo sed -i '/Videosort/d' $NZBGETCFG
sudo sed -i '/Category[0-9]\+/d' $NZBGETCFG

# Now copy in our new settings:
( cat &lt;&lt; _EOF
# Custom Categories
Category1.Name=movies
# (option &lt;DestDir&gt;) is used. In this case if the option &lt;AppendCategoryDir&gt;
Category1.DestDir=\${DestDir}/Movies
Category1.Unpack=yes
Category1.Extensions=VideoSort.py, Notify.py
Category1.Aliases=movies*
Category2.Name=tv
Category2.DestDir=\${DestDir}/TVShows
Category2.Unpack=yes
Category2.Extensions=VideoSort.py, Notify.py
Category2.Aliases=hdtv, tv*, s??e??

# VideoSort Script
VideoSort.py:MoviesDir=\${DestDir}/Movies
VideoSort.py:SeriesDir=\${DestDir}/TVShows
VideoSort.py:DatedDir=\${DestDir}/TVShows
VideoSort.py:OtherTvDir=\${DestDir}/TVShows
VideoSort.py:TvCategories=tv
VideoSort.py:VideoExtensions=.mkv,.avi,.divx,.xvid,.mov,.wmv,.mp4,.mpg,.mpeg,.vob,.iso
VideoSort.py:SatelliteExtensions=.srt,.sub,.idx,.subs.rar,.rar,.nfo,.jpg
VideoSort.py:MinSize=100
VideoSort.py:MoviesFormat=%.t.(%y)/%.t.%y.%qss.%qf.%qvc-%qrg
VideoSort.py:SeriesFormat=%s.n/S%0s/%s.n.S%0sE%0e.%e.n.%qss.%qf.%qvc-%qrg
VideoSort.py:EpisodeSeparator=E
VideoSort.py:SeriesYear=yes
VideoSort.py:DatedFormat=%s.n/%s.n-%e.n-%y-%0m-%0d
VideoSort.py:OtherTvFormat=%t
VideoSort.py:LowerWords=the,of,and,at,vs,a,an,but,nor,for,on,so,yet
VideoSort.py:UpperWords=III,II,IV
VideoSort.py:DNZBHeaders=yes
VideoSort.py:PreferNZBName=yes
VideoSort.py:Overwrite=no
VideoSort.py:Cleanup=yes
VideoSort.py:Preview=no
VideoSort.py:Verbose=no
_EOF
) | sudo tee -a $NZBGETCFG

# Restart our NZBGet instance so it takes on the new configuration
sudo systemctl start nzbget

Firewall Configuration

The package will provide you the files needed to set up the firewall and make NZBGet available to you from other stations by simply doing the following:

# Assuming your network is set up to the `home` zone, the following
# sets you up to expose TCP Port 6789 on your network
firewall-cmd --zone=home --add-service nzbget --permanent

# You can optionally expose your secure instance of NZBGet on TCP
# port 6791 as well if you want
firewall-cmd --zone=home --add-service nzbget-secure --permanent

# Now reload your firewall to take on the new change:
firewall-cmd --reload

SABnzbd Usenet Solution

You can start it up with the command:

# Install SABnzbd from the Nuxref repository
sudo dnf install -y sabnzbd

# Add SABnzbd to the startup of your system
sudo systemctl enable sabnzbd.service

# Start it up now if you like too!
sudo systemctl start sabnzbd.service

You’ll now be able to access the web page through your browser accessing:
http://localhost:9080.

Here is a breakdown of how the custom SABnzbd package works:

  • All of your log files will show up in /var/log/sabnzbd/sabnzbd.log
  • All of configuration will get written to /etc/sabnzbd/sabnzbd.conf
  • All of the variable data (file processing, etc) will be located in /var/lib/sabnzbd/*. In fact this is a very important directory because unless you configure things differently, all downloaded content will appear in /var/lib/sabnzbd/complete.

To grant users on your system access to the data available through SABnzbd, simply just add them to the sabnzbd group:

# swap the USER with your username you want to add to the
# sabnzbd group:
sudo usermod -aG sabnzbd USER

Firewall Configuration

The package will provide you the files needed to set up the firewall and make SABnzbd available to you from other stations by simply doing the following:

# Assuming your network is set up to the `home` zone, the following
# sets you up to expose TCP Port 9080 on your network
firewall-cmd --zone=home --add-service sabnzbd --permanent

# You can optionally expose your secure instance of SABnzbd on TCP
# port 9090 as well if you want
firewall-cmd --zone=home --add-service sabnzbd-secure --permanent

# Now reload your firewall to take on the new change:
firewall-cmd --reload

SABnzbd Notifications

SABnzbd can keep you posted on what it’s doing by sending you emails when a download completes (or fails). But it’s not just emails it can use as a medium; it can be Gotify, Twitter, Telegram, Amazon SNS, Slack, etc.

To leverage the notification features, you just need to install the NZB-Notify Plugin:

# Install the notification plugin from the Nuxref repository
sudo dnf install -y sabnzbd-script-notify

To enable it, you simply need to need to access the Notifications tab from within the SABnzbd Configuration section.

SABnzbd Notification Setup
SABnzbd Notification Setup
  1. Select the Enable notification script checkbox
  2. Select the Notify.py script from the dropdown list next to the Script category
  3. Next to the Parameter category, you must specify the URL(s) identifying which service(s) you want to notify.Depending on what you want plan on alerting, the URL(s) you specify in the Parameter field will vary. You can get a better understanding of the URL options supported here.

NGinX Frontend

Regardless of what downloader you chose to setup from the instructions above, you should NEVER directly expose SABnzbd or NZBGet to the internet… EVER! ALWAYS uses some sort of proxy to bridge the internet from systems you run on your local network. NGinX (pronounced Engine-X) can solve this very thing for you. NginX is much more actively maintained and focuses entirely protecting your servers while allowing them to safely host their backend HTTP(S) solutions.

# Install NGinX and httpd-tools (if they're not there already)
sudo dnf install nginx httpd-tools

# Add nginx to the startup of your system
sudo systemctl enable nginx.service

# Start it up now if you like too!
sudo systemctl start nginx.service

# Expose port 80 and port 443
sudo firewall-cmd --zone=home --add-service http --permanent
sudo firewall-cmd --zone=home --add-service https --permanent

# If you're installing NginX on the same server that you've installed
# SABnzbd or NGinX on, make sure you no longer expose the ports associated
# with them anymore:
sudo firewall-cmd --zone=home --remove-service nzbget --permanent
sudo firewall-cmd --zone=home --remove-service nzbget-secure --permanent
sudo firewall-cmd --zone=home --remove-service sabnzbd --permanent
sudo firewall-cmd --zone=home --remove-service sabnzbd-secure --permanent

# Now reload your firewall to take on the new change:
firewall-cmd --reload

Now add the following into your /etc/nginx/default.d/usenet.conf file:

   # NZBGet wrapper
   location /nzbget/ {
      proxy_pass   http://localhost:6789;
      proxy_cache  off;

      # Simple Security
      auth_basic            "Restricted Usenet Area";
      auth_basic_user_file  usenet.htpasswd;
   }

   # SABnzbd wrapper
   location /sabnzbd/ {
      proxy_pass   http://localhost:9080;
      proxy_cache  off;

      # Simple Security
      auth_basic            "Restricted Usenet Area";
      auth_basic_user_file  usenet.htpasswd;
   }

Now let’s set up a simple password file we can use to secure our content.

# Generate a password for the user 'usenet'.  You might want to
# switch this for your own name if you like:
sudo htpasswd -c /etc/nginx/usenet.htpasswd usenet

# you will be prompted to enter a password to associate with your
# new user.  Go ahead and provide one! :)

# You can generate more account if you want too; just remove the
# -c for future calls. e.g:
# sudo htpasswd  /etc/nginx/usenet.htpasswd user2

# It wouldn't hurt to just enhance the security associated with our
# new password file (for prying eyes):
chown root.nginx /etc/nginx/usenet.htpasswd
chmod 640 /etc/nginx/usenet.htpasswd

# You're almost done!
# Make sure your configuration won't break anything
nginx -t -c /etc/nginx/nginx.conf

# If the above passed okay, then it's safe to make your configuration
# live.
sudo systemctl reload nginx

Credit

Please note that this information took me several days to put together and test thoroughly. There was a tremendous effort put in place to make all versions of these programs compatible with all recent RPM based Linux distributions. 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.

Sources