Tag Archives: Centos

Nagios Core 4.x Setup for CentOS 7.x

Introduction

A few years ago I blogged about setting up Nagios Core 4.x for CentOS 6.x. I later made a blog on setting up NSCA and NRPE too. But times have changed so I figured it was time to do an updated blog for CentOS 7.x and Nagios.

Some new great tools I’ve packaged to make a load and go setup for everyone is:

  • Nagios Core v4.x: updated RPM packaging which I continued to maintain and carry forward from my previous blogs.
  • Nagios Plugins v2.x: A ton of out of the box working plugins.

Best of all, with my RPMs, you can run SELinux in full Enforcing mode for that extra piece of mind from a security standpoint!

Nagios Core

Nagios (for those who don’t know) is an application that allows us to monitor other system/applications we manage. It’s primary function is to immediately bring to our attention any outage or anomaly is detected with our systems. This tool is completely free and should be an essential component of anyone’s business infrastructure.

The current version of Nagios (at the time of writing this blog) is v4.2.2. You can download the latest version from my repository (if you’re set up) as follows:

# Install Nagios Core using NuxRef repositories
# at: https://nuxref.com/repo
yum install -y nagios nagios-selinux

You can also download the packages manually if you wish using this table:

Package Download Description
nagios el7.rpm Nagios Core IV is the the actual monitoring server we can use to monitor our applications.
nagios-selinux el7.rpm An add-on package that allows you to run Nagios in Enforcing Mode.

Note: This RPM is not required by Nagios to run correctly.
nagios-contrib el7.rpm Extra tools that add to the great features Nagios already offers (such as distributed monitoring). These tools are not discussed in this blog entry; but maybe useful to you.
Note: This RPM is not required by Nagios to run correctly.
nagios-devel el7.rpm Header files for developers who want to build using the libnagios shared library.
Note: This RPM is not required by Nagios to run correctly.

Note: The source rpm can be obtained here which builds everything you see in the table above. It’s not required for the application to run, but might be useful for developers or those who want to inspect how I put the package together.

Configure Nagios Core

Once Nagios is installed it can be started like so:

# Start Nagios
systemctl start nagios.service

# If you want Nagios to start after the system is rebooted, you
# can type the following:
systemctl enable nagios.service

# Now we want to turn on Apache if it's not running, otherwise
# reload the configuration if it is:
systemctl status httpd.service && \
   systemctl start httpd.service ||\
   systemctl reload httpd.service

If you followed the instructions above you should be able to access the (Nagios) monitoring website right away by visiting http://localhost/nagios. If you’re installing this on another server you may need to open your web ports to access the Nagios Monitoring site:

# The following commands should be ran on your Nagios Server.
# It will enable our http (and secure https) port on our firewall so our
# monitoring website can be accessed remotely:
firewall-cmd --permanent --add-service=http
firewall-cmd --add-service=http
firewall-cmd --permanent --add-service=https
firewall-cmd --add-service=https
Nagios Credentials
Login nagiosadmin
Password nagiosadmin

You’ll be prompted for a user/pass combination; at this time the default values are defined in the table:

Once you’ve logged in, you can click on links like Services (under the Current Status heading) which will list to you all of the system services you’re currently monitoring and their status:

Nagios > Current Status > Services
Nagios > Current Status > Services

In the example, you can see Nagios has picked up on a high system load (denoted by the yellow warning entry).

Nagios at it’s most basic level is set up at this point and can be maintained by having a look at the following directories:

/etc/nagios/nagios.cfg:
The main configuration file that is read by Nagios when starting up. The only things you may want to change in here are:

Directive Description
date_format The default is us (MM-DD-YYYY HH:MM:SS), but personally I like iso8601 (YYYY-MM-DD HH:MM:SS).
# simple 1-liner to toggle date_format to iso8601:
sed -i -e 's/^\(date_format\)=.*$/\1=iso8601/g' \
   /etc/nagios/nagios.cfg
check_for_updates The default is 1 (which is to check for updates). Personally, I don’t want my web page pinging Nagios every time i access the website for updates. Here is how you can do the same:
# disable update check:
sed -i -e 's/^\(check_for_updates\)=.*$/\1=0/g' \
   /etc/nagios/nagios.cfg

/etc/nagios/objects/contacts.cfg:
This is where a default contact has been created. Feel free to open this up and add your name and (especially the) email address.
/etc/nagios/objects/commands.cfg:
All of the possible checks Nagios can perform on it’s own (without any plugins or extensions) are identified here. It’s as easy as defining a command_name (give it some name) and then tell it what you want to execute with the command_line directive.

A Nagios command is really simple to write; you can write one in any language you want. Here is one written in bash shell:

#!/bin/bash
# Path: /usr/lib64/nagios/plugins/check_temp_file_count
# Please keep in mind this script is pretty useless but
# it's goal is to show you how easy it is to write a
# script for Nagios.
#
# The rules are simple:
# Whatever we echo to the screen get's displayed to Nagios
# and our return value from our script/program will
# determine the color code (and whether or not we alarm)

# A return code of zero (0) tells Nagios everything is okay
RET_OKAY=0

# A return code of one (1) tells Nagios we're reporting a warning
# about whatever it is we're monitoring
RET_WARN=1

# A return code of two (2) tells Nagios we're reporting a critical
# error
RET_CRIT=2

# I define 3 here, but quite honestly, anything you return that
# does not fit in the 0, 1 or 2 response type (as identified
# above) is considered an unknown state.  Try to avoid this
# type if you can.
RET_UNKN=3

# As a test script we'll count all of the files and directories
# in the /tmp folder
COUNT=$(find /tmp 2>/dev/null | wc -l)

# If we have less then 10 files we'll tell Nagios everything
# is okay:
if [ $COUNT -lt 10 ]; then
   echo "$COUNT files; everything is good!"
   exit $RET_OKAY
fi

# If we have less then 30 files we'll tell Nagios that
# it should report a warning
if [ $COUNT -lt 30 ]; then
   echo "$COUNT files; caution!"
   exit $RET_WARN
fi

# Anything more we should report a critical alarm
echo "$COUNT files; Critical!!"
exit $RET_CRIT

If you’re familiar with Perl, the Nagios team has made a framework with it which you use to make your packages too! I’ve already gone ahead and packaged the perl-Nagios-Monitoring-Plugin rpm for you if you want it.

Nagios will associate /usr/lib64/nagios/plugins/ as it’s plugin directory; so you should save any plugins you create there (to keep them all in a common location). Plus if you intend to use SELinux, this is the directory that Nagios is allowed to execute from.

Our entry in the commands.cfg for this new script might look like this:

; 'check_temp_file_count' command definition
; $USER1$ gets translated automatically to our Nagios Plugin directory
; so in our case: /usr/lib64/nagios/plugins/
; Ideally you should call the command the same name as the checking
; tool you wrote.
define command{
	command_name	check_temp_file_count
	command_line	$USER1$/check_temp_file_count
	}

/etc/nagios/objects/localhost.cfg:
This is just a general configuration file for the very machine Nagios is running on. If you open it up, you’ll see that it defines a lot of entries that reference commands (defined already in the commands.cfg file).

A new entry in the commands.cfg for this new script might look like this:

; the 'use' directive identifies a template of information to save
; us from typing it all out here.  For now; just leave this as
; local-service.
;
; The 'hostname' defines our server (defined at the very top of this same
; file. Since the host at the to was defined as 'localhost', we need
; to use this same name here too
;
; The next field is just a description field; it will be how this service
; is presented on Nagios through the website
;
; The check_command is the name we gave it in the commands.cfg
; file.
define service{
        use                             local-service
        host_name                       localhost
        service_description             Count our Temporary Files
        check_command                   check_temp_file_count
}

Check to see if Nagios has any errors with any new configuration you provided:

# This command just tells Nagios to read in it's configuration
# and check if it appears valid:
nagios -v /etc/nagios/nagios.cfg

If everything checks out okay, go ahead and reload Nagios with our
new configuration:

# Reload Nagios
systemctl reload nagios.service

Nagios Plugins

If you’ve installed Nagios, there isn’t really any good reason why you shouldn’t just install the Nagios Plugins too. This is just more tools and checking scripts to make Nagios all that more powerful. The best part is, these tools have been tested over the years, so they’re already proven to be reliable and will allow you to accomplish most monitoring without much effort.

Nagios Plugins
Nagios Plugins

It’s important to note that the Nagios Plugin RPMs are NOT required by Nagios to run correctly. They merely just improve it’s existing functionality. You may however want to install the plugins you’re interested in that monitor systems you’re using.

The current version of the Nagios Plugins (at the time of writing this blog) is v2.1.3. You can download the latest version from my repository (if you’re set up) as follows:

# Install Nagios Core using NuxRef repositories
# See: https://nuxref.com/repo for more information
yum install -y nagios-plugins nagios-plugins-selinux

You can also download the packages manually if you wish using this table:

Package Download Description
nagios-plugins el7.rpm 50+ plugins that are fully adaptable to Nagios in every way. If you’re planning on installing Nagios, don’t forget about adding this package for it’s convenience!
nagios-plugins-selinux el7.rpm An optional add-on package that allows you to use the Nagios Plugins in Enforcing Mode.
nagios-plugins-ldap el7.rpm A Nagios plugin that can be used to check integrity and data entries within an LDAP database.
nagios-plugins-mysql el7.rpm A Nagios plugin that can be used to check integrity and data entries within an MySQL (or Maria) database.
nagios-plugins-ntp el7.rpm A Nagios plugin that can be used to check the NTP status of the machine it’s called on.
nagios-plugins-pgsql el7.rpm A Nagios plugin that can be used to check integrity and data entries within an PostgreSQL database.
nagios-plugins-samba el7.rpm A Nagios plugin that can be used to check status of your Samba mounts and their availability.
nagios-plugins-snmp el7.rpm A Nagios plugin that can query SNMP enabled appliances (routers, firewalls, switches, servers) and convert their output back to something Nagios can monitor or report.

Note: The source rpm can be obtained here which builds everything you see in the table above. It’s not required for the application to run, but might be useful for developers or those who want to inspect how I put the package together.

The main thing to know about this package after it is installed is the slew of new plugins available to you in /usr/lib64/nagios/plugins/ and a config file to get you started which references most of them in /etc/nagios/conf.d/nagios-plugin-commands.cfg.

Extra Plugins

There are a lot of great plugins on Nagios Exchange! I packaged just a few of them because they required patches and tweaks to work out of the box. All of these are available on my repository, but feel free to haul them down directly here:

Package Download Description
nagios-plugins-lvm el7.rpm / src.rpm / NE Source This plugin finds all LVM logical volumes, checks their used space, and compares against the supplied thresholds.
nagios-plugins-crm el7.rpm / src.rpm / NE Source A plugin for monitoring a Pacemaker/Corosync cluster.
Note: that this plugin requires perl-Nagios-Monitoring-Plugin to work.
nagios-plugins-drbd84 el7.rpm / src.rpm / NE Source A plugin for monitoring a DRBD v8.4 setup.

Credit

This blog took me a very (,very) long time to put together and test! The repository hosting alone accommodates all my blog entries up to this date. All of the custom packaging in this blog was done by me personally. 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

The remaining portions of this series can be found here:

  • Part 2 – NRDP for Nagios Core on CentOS 7.x: This blog explains how awesome NRDP really is and why it might become a vital asset to your own environment. It’s also provides the first set of working RPMs (with SELinux support of course) of it’s kind.
  • Part 3 – NRPE for Nagios Core on CentOS 7.x: This blog explains how to set up NRPE (v3.x) for your Nagios environment. At the time this blog was written, there was no packaging of it’s kind for this version. So allow me be the first to share it with you!

Host Your Own WordPress Site

Introduction

A while back I decided to host my blog on my own servers and cut the cord with WordPress.com. There were no hard feelings really; I just didn’t like the limited options for plugin choices I had. I didn’t like all the extra features they forced me to use that made my blog (response time) slower.

The standalone version of WordPress is much more scaled down and fits my requirements better. The standalone version also allows me to pick and choose from a sea of amazing plugins at my disposal.

Prerequisite

You’ll need to have full (Linux) shell access to the server you’re intending to host this from. I set up my hosting using a CentOS 6.x machine; therefore the instructions I identify here are for that. That said, the instructions won’t stray too far off (requiring a tweak here an there) from those people who choose to use other Linux distributions.

You’ll want to first install a few packages:

# You'll basically need PHP, MySQL 
# As root (or a user with sudoer's permission) type the following:
sudo yum -y install php-fpm php-mbstring php-mcrypt \
             php-mysql nginx mysql mysql-server gawk \
             openssl

Optional FTP Support

FTP support is really nice to have with a WordPress setup! You can use it to automate the installation of plugins through the admin page. This is great for situations where you’re setting up a WordPress account for someone who isn’t too teksavvy. It also allows grants your users enough access to install plugins through WordPress’s administration interface.

I strongly suggest you read my blog entry on Configuring and Installing VSFTPD on CentOS 6 if you’re interested in going this route.

It’s important to note that WordPress functions just fine without an FTP(S) server too!

Step 1 of 8: Prepare our Environment.

To make life really easy (so you can cut and paste this right to your command line without any effort at all), lets create some environment variables.

Please note that this step MUST be ran before any of the other steps are. If you’re returning to this blog entry to resume from a step you left off at, be sure to apply these environment variables again!

Please note that you must be root or have sudoer’s permission to be able to perform any of these tasks successfully on your server.

# Our WordPress user
WPUSER=nuxref

# The FQD you will be serving your data from.  If you
# don't have your own domain, then set this to an
# underscore '_' (without the quotes '')
WPURL=nuxref.com

# Some Database Information
# - what are we going to call our database name?
DBNAME="wordpress_$WPUSER"
# - it's easier to just use the WordPress user account here
#   but if you want to change it to something else; here is
#   where you can do it:
DBUSER=$WPUSER
# - we will want to create a confusing password that others
#   can't guess. I don't recommend you use what i've identified
#   here because anyone else who knows you read my blog will
#   guess this first.  But here is where you should set your
#   database password you intend to use.
DBPASS="v3ryC0nFU51Ng-Pw%"

# If you plan on creating an FTP Account; you'll want to
# populate these variables too. This account does not have
# to be the same as the $WPUSER account. In fact making it
# different (even just slightly) would be a good idea!
# Below i just add '-ftp' to the end of the already
# determined user above.  Feel free to change this.
WPFTPUSER="$WPUSER-ftp"
# Set an FTP password; It would be a good idea to not use
# the one identified below as it's merely display only.
# some special character don't work with VSFTPD (like '!')
# if you plan on using it .
WPFTPPASS="4nt3rP455%rd"

# The following is only used for our SSL Key Generation
COUNTRY_CODE="7K"
PROV_STATE="Westerlands"
CITY="Lannisport"
SITE_NAME="Life as a Lannister"

Step 2 of 8: Create our User Account

You’ll want to create an isolated environment for our client (or you) to work within. By securing an environment; in the event anything is ever compromised, destruction will be limited to what we allow our client access to.

# First create a system directory to host our project.
sudo mkdir -p /opt/$WPUSER/html/static

# Create a dummy, favicon.ico file for now. If you feel
# ambitious, Google this if you're not sure what it's for
# so you can place your own custom one here
touch /opt/$WPUSER/html/static/favicon.ico

# Create System User
sudo useradd nuxref -M --system \
   --comment "$WPUSER WordPress Account" \
   --home /opt/$WPUSER \
   --shell /sbin/nologin

# Secure our new directory we created
chmod 711 /opt/$WPUSER
chown -R $WPUSER.$WPUSER /opt/$WPUSER

If you’ve followed my blog on Securing and Protecting Your CentOS 6 System then you might have wisely chosen to set up disk quotas. If not; then you can skip over to the next step.

# Detect the device using our home directory
DEV=$(df -l -P /opt/$WPUSER | awk 'END{print $1}')
# Restrict Users Disk Quota to 600MB
sudo setquota -u $WPUSER 180000 600000 0 0 $DEV

Step 3 of 8: Generate SSL Keys

We need to generate some Secure Socket Layer (SSL) keys so that we can provide a secure connection for logins. Otherwise our passwords we choose to work with the site could be exposed.

To make things simple, you can use my genssl tool first discussed in an earlier blog I wrote here. available for download from my github page and then just do the following:

# Generate a self signed key:
genssl -s $WPURL
# Install it:
sudo install -m 0400 $WPURL.key /etc/pki/tls/private/$WPUSER.key
sudo install -m 0444 $WPURL.crt /etc/pki/tls/certs/$WPUSER.crt

Or you can simply do the following:

# The following will generate SSL Keys (if you don't have any already)
sudo openssl req -nodes -new -x509 -days 730 -sha256 -newkey rsa:2048 
   -keyout /etc/pki/tls/private/$WPUSER.key 
   -out /etc/pki/tls/certs/$WPUSER.crt 
   -subj "/C=$COUNTRY_CODE/ST=$PROV_STATE/L=$CITY/O=$SITE_NAME/OU=IT/CN=$WPURL"
 
# Permissions; protect our Private Key
chmod 400 /etc/pki/tls/private/$WPUSER.key
 
# Permissions; protect our Public Key
chmod 444 /etc/pki/tls/certs/$WPUSER.crt

Step 4 of 8: Install our WordPress Bundle

Now we need to Download and install WordPress into our environment.

# WordPress Configuration
# Acquire latest version from here https://wordpress.org/download/
# (At the time it was 4.4.2)
wget --no-check-certificate https://wordpress.org/latest.tar.gz -O wordpress.$(date +'%Y.%m.%d').tgz

# Extract our downloaded copy
sudo tar xvfz wordpress.$(date +'%Y.%m.%d').tgz \
    -C /opt/$WPUSER/html --strip 1

# Apply some more permissions
sudo find /opt/$WPUSER/html -type d -exec chmod 755 {} \;
sudo find /opt/$WPUSER/html -type f -exec chmod 664 {} \;
sudo find /opt/$WPUSER/html -exec chown $WPUSER.apache {} \;

# Grant write permissions to a few tools our plugin installers
# will need access to later on:
find /opt/$WPUSER/html/wp-content/ -type d -exec chmod 775 {} \;
sudo chmod 660 /opt/$WPUSER/html/wp-config.php

Step 5 of 8: Configure and Prepare our Database

Now we need to configure our MySQL (or MariaDB) database. First make sure it is running:

# The below command will start the database if it isn't
# already running:
sudo service mysqld status &>/dev/null || \
   sudo service mysqld start

# Next make sure you're system is configured to start
# the database each and every time your server turns on
sudo chkconfig --level 345 mysqld on

Now we need to prepare our database that WordPress can use.

# SQL Initialization
( cat << _EOF
CREATE DATABASE $DBNAME;
GRANT ALL PRIVILEGES ON $DBNAME.* TO "$DBUSER"@"localhost" IDENTIFIED BY " $DBPASS";
FLUSH PRIVILEGES;
_EOF
) | sudo mysql

Step 6 of 8: Configure our Web Hosting Service

Okay now we need to host our website. Effectively linking the database we just prepared with the WordPress software we just installed. We do this as follows using NginX:

# By default (assuming a CentOS installation), we can
# plug into our configuration by writing our data in
# /etc/nginx/conf.d/
# So lets do just that:
cat << _EOF > /etc/nginx/conf.d/wordpress_$WPUSER.conf
#
# $WPUSER WordPress Web Hosting
#
server {
    # Support Web Traffic at port 80
    listen       80;
    server_name  $WPURL;
    root   /opt/$WPUSER/html;

    # Our log files
    access_log  /var/log/$WPUSER/$WPUSER.access.log  main;
    error_log  /var/log/$WPUSER/$WPUSER.error.log;

    # Our main handler
    location / {
        root   /opt/$WPUSER/html;
        index  index.html index.htm index.php;
        # Support Permalink changes
        try_files \$uri \$uri/ /index.php?q=\$request_uri;
    }

    # Anyone logging into our site should do it securely
    location /wp-admin/ {
       # Always redirect to secure site
       rewrite ^/(.*) https://$host/\$1 permanent;
    }
    location /wp-login/ {
       # Always redirect to secure site
       rewrite ^/(.*) https://\$host/\$1 permanent;
    }

    error_page  404              /404.html;
    location = /404.html {
        root   /usr/share/nginx/html;
    }

    # redirect server error pages to the static page /50x.html
    #
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }

    # Support the favicon (for those wanting to use it)
    location = /favicon.ico {
        root   /opt/$WPUSER/html/static;
    }

    # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
    #
    location ~ \.php\$ {
        fastcgi_pass   127.0.0.1:9000;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  \$document_root\$fastcgi_script_name;
        include        fastcgi_params;
    }

    # Deny access to the wp-config file
    location ~ /wp-config\.php {
        deny  all;
    }
}

server {
    # We should listen on a secure URL too so that we can
    # hide our admin login credentials from prying eyes
    listen       443;
    server_name  $WPURL;
    root   /opt/$WPUSER/html;

   ssl on;
   ssl_certificate /etc/pki/tls/certs/$WPUSER.crt;
   ssl_certificate_key /etc/pki/tls/private/$WPUSER.key;
   ssl_session_timeout  5m;

   # Secure our site by only allowing the TLS protocol
   ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
   ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128:AES256:AES:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK';
   ssl_prefer_server_ciphers on;
   ssl_session_cache  builtin:1000  shared:SSL:10m;

   access_log  /var/log/nginx/$WPUSER.access.log  main;
   error_log  /var/log/nginx/$WPUSER.error.log;

   location / {
      root   /opt/$WPUSER/html;
      index  index.html index.htm index.php;
      # Support Permalink changes
      try_files \$uri \$uri/ /index.php?q=\$request_uri;
   }

   error_page  404              /404.html;
   location = /404.html {
      root   /usr/share/nginx/html;
   }

   # redirect server error pages to the static page /50x.html
   #
   error_page   500 502 503 504  /50x.html;
   location = /50x.html {
       root   /usr/share/nginx/html;
   }

   # Handle favicon
   location = /favicon.ico {
       root   /opt/$WPUSER/html/static;
   }

   # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
   #
   location ~ \.php\$ {
      fastcgi_pass   127.0.0.1:9000;
      fastcgi_index  index.php;
      fastcgi_param  SCRIPT_FILENAME  \$document_root\$fastcgi_script_name;
      include        fastcgi_params;
   }

   # Deny access to the wp-config file
   location ~ /wp-config\.php {
      deny  all;
   }
}
_EOF

Now restart our web services

# Ensure our web browser and php handler will start
# even if our server is restarted
chkconfig --levels 345 php-fpm on
chkconfig --levels 345 nginx on

# The following just makes sure we reload and take
# on our new configuration.  If we're not running
# then we start the services up
service php-fpm status &>/dev/null && \
   service php-fpm restart || \
   service php-fpm start

service nginx status &>/dev/null && \
   service nginx restart || \
   service nginx start

Step 7 of 8: Optionally Setup an FTP Account

Most people can skip this step; it again presumes you’ve followed my other blog on Configuring and Installing VSFTPD on CentOS 6. If you have not gone here or have set up FTP your own way, you can also skip this step and move on with Configuring WordPress.

# Create a WordPress Plugins FTP Account
echo $WPFTPUSER >> /etc/vsftpd/users.passwd
echo $WPFTPPASS >> /etc/vsftpd/users.passwd
 
# Protect Password
chmod 600 /etc/vsftpd/users.passwd
chown root.root /etc/vsftpd/users.passwd
 
# Now convert content into a db structure
db_load -T -t hash -f /etc/vsftpd/users.passwd /etc/vsftpd/virtual.users.db
chmod 600 /etc/vsftpd/virtual.users.db
chown root.root /etc/vsftpd/virtual.users.db
 
cat << _EOF > /etc/vsftpd/virtual.users/$WPFTPUSER
local_root=/opt/$WPUSER/html
# -------------------------------------------------------------------------
# User
# -------------------------------------------------------------------------
guest_enable=YES
guest_username=apache
local_root=/opt/$WPUSER/html
# -------------------------------------------------------------------------
# Permissions
# -------------------------------------------------------------------------
# write_enabled is required if the user is to make use of any of the
# anon_* commands below
write_enable=YES
# give the user the ability to make directories
anon_mkdir_write_enable=YES
# give the user the ability delete and overwrite files
anon_other_write_enable=YES
# give the user the ability upload new files
anon_upload_enable=YES
# Give the user permission to do a simple directory listings
dirlist_enable=YES
# Give the user permission to download files
download_enable=YES
# if the user has can upload or make new directories, then this will be
# the umask applied to them
anon_umask=0002
# delete failed uploads (speaks for itself)
delete_failed_uploads=NO
_EOF
 
sudo chmod 600 /etc/vsftpd/virtual.users/$WPFTPUSER
sudo chown root.root /etc/vsftpd/virtual.users/$WPFTPUSER

# Ensure our FTP Server will restart if our server
# is ever restarted:
sudo chkconfig --level 345 vsftpd on
# Update Service (to read in new configuration)
sudo service vsftpd status &>/dev/null && \
    service vsftpd restart || \
    service vsftpd start

Step 8 of 8: Configure WordPress

If you successfully pulled off all of the earlier steps, then you shouldn’t have any trouble from this point forward. The hard part is done with!

Wordpress Database SetupWordpress InstallationYou now need to open up your browser and access your new WordPress website to continue with the setup. Simply visit your website by browsing to http://your.wordpress.url/ (whatever you set this up as).

First you’ll be immediately presented with webpage that needs some information about the database we set up back in Step 5 (an environment variables defined in Step 1.

After you press the [Submit] button, you’ll then be asked to define some basic information about the blog you intend to set up. You can change all this later, so don’t worry. The important fields here are the administrator user and password you create.

You’re done now and ready to use WordPress

Great WordPress Plugins

The following plugins are worthy of a mention:

Credit

Please note that this information took me several days to put together and test thoroughly. 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.

SABnzbd Installation for CentOS 7.x

Introduction

SABnzbd is a versatile tool written in Python specifically designed to take an NZB-File as input and then retrieve all of the content defined inside of it for you automatically. Recently there have been new improvements with SABnzbd in the past few releases. So I thought I’d share a working out of the box solution using RPMs. In addition to this, I’ve packaged up my notification script I wrote which can further enhance this great product.

SABnzbd and Usenet

First off; lets summarize Usenet for those who don’t use it or aren’t already familiar with it. In the simplest terms: Usenet is a great big fucking mess; a total disaster. It’s basically a location where literally anyone with access to it can post/upload all they want at their free will anonymously. Don’t get me wrong; this is cool too because it’s basically one very large hard drive without anyone telling you what you can and can’t place onto it. Seriously though, just consider for a second what your computer would look like if you allowed absolutely anyone who has access to the internet to upload content freely and without rules to it. You’d probably run out of hard disk space quickly; and you’ll be left with a lot of content everywhere. Well; that’s exactly what Usenet is (greatly simplified); it’s one large centralized location filled with petabytes of data. The thing with Usenet though is… it isn’t, and won’t be running out of disk space anytime soon.

The good news is, (thankfully) people sift through the heaps of information constantly being posted (onto Usenet) using automated tools regularly. These tools that do the sifting are generally known as Indexers. I talk more about this in another blog I wrote here a while back. But basically whenever an Indexer finds some useful data, it records the location as to where it was found. Indexers record this information in a special file call an NZB-File. NZB-Files are effectively treasure maps containing the coordinates on Usenet to which a specific piece of data can be located at.

NZB-Files are like Treasure Maps
NZB-Files are like Treasure Maps

It should be known that if you’re planning on posting/uploading stuff to Usenet yourself (for backup purposes or what have you), most (good) software will generate you an NZB-File afterwards allowing you to retrieve your data back again later on.

Now lets throw SABnzbd into the picture because it specifically is designed to retrieve content based on an NZB-File it’s provided. The process looks a little like this:

SABnzbd Download Process
SABnzbd Download Process

  1. Acquire NZB-File: Presumably you already have it because you’re just trying to retrieve data you posted in the past. But alternatively, the NZB-File could have also been acquired from and Indexer too.
  2. Give SABnzbd Access to NZB-File: You simply hand off your treasure map to the application who’s actually going to go out there and get the content for you.

    This is truly the bread and butter of SABnzbd. The next set of steps identified below are all fully automated (and done behind the scenes) for you. They require nothing from you, but it’s worth explaining it for those who are interested.

  3. SABnzbd Establishes a Connection to Usenet: The catch with SABnzbd is it’s merely a vessel for fetching the data. You need to have provided it access to Usenet to which it will fetch this data from. Thus SABnzbd must (obviously) connect to a Usenet provider in order to retrieve data from Usenet itself. This step is put in place to make sure you’ve got yourself an account with a provider!
  4. SABnzbd Downloads Content: Segment by segment, each portion of your data is downloaded and re-assembled. There are lots of additional things that go on too such as making sure the data isn’t damaged and attempting to correct it (all automatic) if it is.
  5. SABnzbd Saves Data:If all goes well; and in most circumstances it will. You will have all of the content successfully retrieved at this point!

SABnzbd has tons of automation built into it; I’m really just focusing on the basics here to get you going.

I Want To Try It

Of course you do! So here’s the thing; if you’ve already connected to my repository here, you can get it by simply typing the following:

# Download and install SABnzbd plus the Notification Addon
# on CentOS 7.x using the nuxref repositories located
# here: https://nuxref.com/repo/
yum install -y --enablerepo=nuxref \
               --enablerepo=nuxref-shared \
               sabnzbd sabnzbd-script-notify

You can also just visit the location I host these packages directly (via my repository) here and download the RPMs for yourself:

Note: I provided the source rpms optionally; they are not required unless you want to build this for yourself from scratch.

SABnzbd Environment

It’s worth giving you a quick rundown of how the RPM installs itself upon your computer: First off, it creates a general user/group called sabnzbd. By default this is the user/group it will run as. To grant a user access to all of the content retrieved by SABnzbd, you can just add yourself to the sabnzbd group:

# as root; we can add ourselves to the sabnzbd group
usermod -a -G sabnzbd myuserid

# Note: if this user is logged in, they will have to log out and log
#       back in to have these new security credentials noticed. 

You can start it up with the command:

# as root; start up SABnzbd:
systemctl start sabnzbd.service

You’ll be able to access the web page through your browser by punching in https://localhost:9080.

You can set it up to survive reboots with the following command:

# as root; start up SABnzbd when the machine is first
# powered on:
systemctl enable sabnzbd.service
  • 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.

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:

# as root; start up SABnzbd when the machine is first
# powered on (assuming your network is set up to the `home` zone
firewall-cmd --zone=home --add-service sabnzbd --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). It can send you an notification on Pushbullet, and a few others too.

If you want to use the Notify script I wrote, you’re already almost set up and ready to go because it’s in the sabnzbd-script-notify rpm you already installed.

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.

Credit

This blog took me a very long time to put together and test! The repository hosting alone accommodates all my blog entries up to this date. 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.

Special thanks to Safihre for reaching out to me and allowing me to contribute to their product with the notification add-on.

Sources