CentOS 7 – An Enterprise Ready Problemless OS

Introduction

It must be about 8 years now since we choose CentOS as our default operating system for Linux servers. A lot has changed since then and it has always been on my to do to write a blog post about it. Karanbir Singh announced the release of CentOS 7.4.1708 on 13/09/17. As with all CentOS 7 components, this release was built from sources hosted at git.centos.org. It also supersedes all previously released content for CentOS Linux 7, and users are highly encouraged to upgrade all systems running CentOS 7. Make sure to read the release notes before upgrading.

One month later, we were able to patch all our CentOS 7 systems and did not run into a single upgrade problem. I would say that merits a big congratulations to the whole CentOS team, and of course also all Red Hat engineers for producing a problemless and stable distribution.

In this post I’ll try to give a general overview of what CentOS is about and why you should choose for this partcular operating system.

centos 7

CentOS Lifecycle

It’s very important to keep an eye on the lifecycles of the operating systems you are managing. Good planning ensures you have enough time to migrate your applications in time before your operating systems are no longer supported. 

CentOS VersionRelease DateFull UpdatesMaintenance Updates
319 March 200420 July 200631 October 2010
49 March 200531 March 200929 February 2012
512 April 200731 January 201431 March 2017
610 July 201110 May 201730 November 2020
77 July 2014Q4 202030 June 2024

Source: https://en.wikipedia.org/wiki/CentOS 

CentOS 7 Repositories

There are three primary CentOS repositories (also known as channels), containing software packages that make up the main CentOS distribution. 

  • base – Contains packages that form CentOS point releases, and gets updated when the actual point release is formally made available in form of ISO images.
  • updates – Contains packages that serve as security, bugfix or enhancement updates, issued between the regular update sets for point releases. 

  • extras – Provides additional packages that may be useful.

  • centosplus – Provides additional packages that extend functionality of existing packages. Please note that this repository is disabled by default. Using this repository is more dangerous than using other CentOS repositories, as it is designed to have several updated packages and it is not really designed to be completely enabled. You should only pick the packages you are looking for and use exclude= and includepkgs= (or exclude= and yum-plugin-priorities) to load only those packages from the centosplus repository. (also check the official centosplus documentation)

CentOS vs Red Hat Enterprise Linux

While CentOS is derived from the Red Hat Enterprise Linux codebase, CentOS and Red Hat Enterprise Linux are distinguished by divergent build environments, QA processes, and, in some editions, different kernels and other open source components. For this reason, the CentOS binaries are not the same as the Red Hat Enterprise Linux binaries. Red Hat Enterprise Linux (RHEL) is actually also open source. But although the code is available for Red Hat users, it is not free to use. Red Hat and the CentOS project announced 7 January 2014 they were actually joining forces.

 CentOSRHEL
License FOSS – GPL and othersCommercial – RedHat EULA
SecuritySELinux, NSS, Linux PAM, firewalld SELinux, NSS, Linux PAM, firewalld
Patches/fixesAs promptly as possible given available project resources.SLA through Red Hat
SupportSelf-support24x7 support through Red Hat
Package managementYumYum
Enterprise package managementSpacewalk / KatelloRed Hat Satellite
ClusteringLinux-HARed Hat Cluster Suite (RHCS)
BootloaderGRUB 2GRUB 2
Graphical user interface (GUI)GNOME 3 / KDE SC 4.10GNOME 3 / KDE SC 4.10
Service managementsystemdsystemd
Storage managementLVM / SSM LVM / SSM
Default file systemXFSXFS
ContainerizationDocker, KubernetesRed Hat OpenShift
Virtual device interface (VDI)SPICESPICE

red hat

There are a lot of advantages in choosing Red Hat 7 over CentOS 7. 

  • Enterprise-level support
  • Access to engineering resources
  • Red Hat’s Customer Portal
  • Certifications
  • Latest features

But choosing Red hat also has some considerable disadvantages:

  • Not free
  • Administration overhead for license management

And yes, I do mention the administration overhead as a problem. This problem might not apply for everyone though. In my case though the process of ordering new Red Hat licenses or prolonging expiring licenses just takes a lot of (unnecessary) time. 

Final words

So I hope my blog post gave you some additional information to make a better informed decision which operating systems are best suited for your use case. If you need professional support, Red Hat is there for you, if you feel comfortable supporting your own Linux servers, follow the CentOS rabbit. 

Monitoring Microsoft Windows Updates

Introduction

Monitoring WSUS updates on Microsoft Windows Server is critical to ensure you get alerted when your systems need to be patched. The process to update Windows Updates on high priority servers implies proper planning to ensure no post-installation problems. If we could trust Microsoft patches for 100 %, installing WSUS updates on a system would be done the moment a maintenance schedule could be created for this system. Unfortunately in my personal experience, WSUS updates are more a cause of problems instead of a solution. That’s why we prefer to not install them too fast, as you might experience major issues with your production systems or with the software that is running on it. A recent example, a colleague accidentally patched some production SharePoint servers, which prohibited the creation of new sitecollections and caused issues with some icons. The only solution was to restore a backup…

Ideally the updates would first need to get tested on QA systems. If the QA servers are running for some times without issues, the production systems can get patched. The above is one of the reasons I spent some time combining the best features from the available Windows Update plugins on the Nagios Exchange.
Such as Christian Kaufmann’s idea to cache the list of Windows Updates into a file. This results in a much lower performance impact of the plugin on the servers you are monitoring. If you have any experience with WSUS updates, you will have noticed that the ‘TrustedInstaller.exe” process which is a MS Windows system process that takes care of querying the WSUS server and installing updates if requested. 

The plugin will count all available WSUS updates and output the count in every possible state. However it will only alert in case a set number of days have passed since the last successful update was installed. By using this method, you can then define a policy and agree to patch all systems which had no updates for a certain time. You could use different policies for QA and PR (production) systems to prevent problems. 

WSUS

 

Details

Some things you need to know about Windows Updates. Microsoft saves the date of the ‘last successful update’ in the registry. The location of the String Value is:

This date however is saved in the Greenwich Mean Time (GMT) or the Coordinated Universal Time (UTC) format. My plugin will try to translate this time to the local time format with the help of a function called Get-LocalTime. This function uses the [System.TimeZoneInfo] .NET class which is only usable if you have .NET 3.5 or higher. So keep in mind the ‘Last Successful Update’ date is in UTC format for servers where .NET 3.5 or higher is not installed.

The plugin will also check this registry key:

And give a warning if the system has a required reboot pending.

PSWindowsUpdate

Starting from Windows 10, Microsoft apparently decided to no longer make use of the above registry key. The only way I found to retrieve the last successful update date and time is with the help of the PSWindowsUpdate module. So I added another argument which allows you to select a different method named ‘PSWindowsUpdate’ to retrieve the necessary information. Please not that the default method is still the original method, I called ‘UpdateSearcher”

In order for this method to work, you will need to install the PSWindowsUpdate module in this location: C:\Windows\System32\WindowsPowerShell\v1.0\Modules. If you are using Powershell 5 you can just do:

I’ve included the 1.5.1.11 and 1.5.2 version of the module in the GitHub repository. Or you can download it on the Microsoft Script Center Repository.

How to monitor your WSUS updates?

  1. Please note that the default DaysBeforeWarning and DaysBeforeCritical parameters are set to 120 and 150. Feel free to adjust them as required or pass them as an argument.
  2. Put the script in the NSClient++ scripts folder, preferably in a subfolder Powershell.
  3. In the nsclient.ini configuration file, define the script like this:
  4. Make a command in Nagios like this:
  5. Configure your service in Nagios. Make use of the above created command. Configure something similar like this as $ARG1$:
    QA servers =>

    PR servers =>

  6. If you want to make use of the new ‘PSWindowsUpdate’ method you will need to have an argument like this:

(Almost) Final words

So why did I create another pluging to check WSUS updates? Because I’m using a system which completely automates Windows Update installation with the help of Nagios XI and Rundeck. The existing plugins did not meet my requirements.

Please note that there are several known issues with WSUS on some operating systems. It’s recommended to always update to the latest ‘Windows Update Client’. Please check Windows 8.1 and Windows Server 2012 R2 update history for more information. More specific, when using WIndows Server 2012 R2, you will really want the following KB’s:

  • KB3172614 => “July 2016 update rollup for Windows 8.1 and Windows Server 2012 R2”
  • KB3179574 => “August 2016 update rollup for Windows 8.1 and Windows Server 2012 R2”
  • KB3185279 => “September 2016 update rollup for Windows 8.1 and Windows Server 2012 R2”

When you don’t have these update rollup’s, checking  for updates and updating your Windows 2012 R2 systems could go very slow. In our case an update check could take up to 40 minutes instead of 10 seconds. 

Let me know on the Nagios Exchange what you think of my plugin by rating it or submitting a review. Please also consider starring the project on GitHub.

Monitoring WordPress Updates

Introduction

WordPress regularly releases updates with new features and bug fixes. It is advised to update asap, so monitoring your website for new WordPress updates is critical to ensure your website is fully patched against potential attacks. Automatic background updates were introduced in WordPress 3.7 in an effort to promote better security, and to streamline the update experience overall. By default, only minor releases – such as for maintenance and security purposes – and translation file updates are enabled on most sites. In special cases, plugins and themes may be updated.

In WordPress, there are four types of automatic background updates:

  1. Core updates
  2. Plugin updates
  3. Theme updates
  4. Translation file updates

Core Updates

Core updates are subdivided into three types:

  1. Core development updates, known as the “bleeding edge”
  2. Minor core updates, such as maintenance and security releases
  3. Major core release updates

By default, every site has automatic updates enabled for minor core releases and translation files. 

Update Configuration

Automatic updates can be configured using one of two methods: defining constants in wp-config.php, or adding filters using a Plugin.

Configuration via wp-config.php

Using wp-config.php, automatic updates can be disabled completely, and core updates can be disabled or configured based on update type.

Constant to Disable All WordPress Updates

The core developers made a conscious decision to enable automatic updates for minor releases and translation files out of the box. Going forward, this will be one of the best ways to guarantee your site stays up to date and secure and, as such, disabling these updates is strongly discouraged.

To completely disable all types of automatic updates, core or otherwise, add the following to your wp-config.php file:

Constant to Configure Core WordPress Updates

To enable automatic updates for major releases or development purposes, the place to start is with the WP_AUTO_UPDATE_CORE constant. Defining this constant one of three ways allows you to blanket-enable, or blanket-disable several types of core updates at once.

WP_AUTO_UPDATE_CORE can be defined with one of three values, each producing a different behavior:

  • Value of true – Development, minor, and major updates are all enabled
  • Value of false – Development, minor, and major updates are all disabled
  • Value of 'minor' – Minor updates are enabled, development, and major updates are disabled

Note that only sites already running a development version will receive development updates. For other sites, setting WP_AUTO_UPDATE_CORE to true will mean that it will only get minor and major updates.

For development sites, the default value of WP_AUTO_UPDATE_CORE is true. For other sites sites, the default value of WP_AUTO_UPDATE_CORE is minor.

How to check for WordPress Updates

  1.  Add the IP addresses of the Nagios servers that need access to the Allowed array in check_wordpress_updates.php”
  2. Put check_wordpress_updates.php in the root of you WordPress installation”
  3. Put check_wordpress_updates.sh in you Nagios plugin folder and call it from Nagios interface”

The result should look like this:

Wordpress updates plugin output

Thanks to Kong Jin Jie and hteske on whose scripts this is based.