Last week, I was working on enabling SaltStack Beacons in our environment to notify my team if one or more of a number of important system configuration files is modified and part of the configuration process involves defining your chosen beacon(s) in the Minon’s configuration file. Manually defining becons on a single Minion is a pretty painless process, but manually defining the same beacons across our entire environment wasn’t something I wanted to do. Thankfully, we manage our Minion configruation file with Salt (yes, Salt can salt itself…with a few caveats) so I was able to define the Beacon configruation once and push it out to our entire environment. However, I didn’t want to execute the entire module the managed file is part of.
In a previous post I explained how to send a message to a specific Slack channel from a Salt state. Today, I want to tie that into another important concept of SaltStack: the Event Reactor (or Reactor for short). Reactor is a somewhat advanced featrue of Salt, but it opens up untold possibilities once you understand how it works. At a high level, Reactor responds, or reacts, to certain events received on the event bus. For example, let’s say you want to send a Slack message to a speciifc channel if a critical service fails to notify operations staff. That’s totally possible with Reactor. What if you want to send a Slack message then try to restart the failed service? Not a problem. In this post we’ll configure Reactor on the Salt master to listen for a specific event that indicates Apache (httpd) has failed then write a Reactor State to send a Slack message to our #alerts Slack channel and, finally, attempt to restart Apache.
Docker is an unbelievably popular technology right now. It’s extremely flexible and can be used at every stage of an application’s lifecycle. In fact, a Docker container and the application running inside it can move together through the application lifecycle all the way to production. In this post, we’re going to cover some of the core concepts of Docker by looking at how you can migrate an existing WordPress installation into Docker (or “Dockerize” it). For the purposes of this article, I’ll be creating Dockerized copy of this very blog. Before we get started, Let’s get started!
A long, long time ago (in this very galaxy) I wrote a post on how to Harden SSH on a Linux instance with Multi-Factor Authentication which focused on using a Yubikey to add an extra layer of security to the traditional SSH login process. Today though, I’d like to follow up on that post and examine the use of OTP (One-Time Password) tokens generated via an app to secure SSH login in much the same way as the Yubikey. The primary benefit to using a software-based token as opposed to the physical Yubikey token is that you don’t have to incur the expense of purchasing a Yubikey. We’ll be using Google Authenticator and CentOS, but the same principles apply to virtually all Linux distribution that use PAM-based authentication. It’s also important to note that other apps such as Authy and 1Password can be used to generate the OTP tokens. We’re using Google Authenticator due to it’s ease of use and ubiquity. Let’s get started!