Backing Up DevonTHINK Databases without Time Machine

The Mac Power Users podcast has a way of costing me money. The most recent example of this is my purchase of DevonTHINK in January. In the months since my usage of DevonTHINK has grown exponentially and, as I’ve put more and more data into it, backing up my DevonTHINK databases has become a major concern for me. I was surprised to discover DevonTHINK doesn’t really have a built-in mechanism for creating full backups and recommends using Time Machine for creating full backups. I’m not opposed to Time Machine and my wife and I use it to backup our MacBook Pros to a Synology NAS, but I wanted additional copies of my DevonTHNIK databases to exist outside of Time Machine so I could do slightly more interesting things with them. For instance, I can back up the secondary copies t two off-site backup providers for maximum redundancy in the event of a nuclear apocalypse, zombie invasion or other equally terrifying disaster. Wait. I’d probably be dead if either of those things happened so having access to my DevonTHINK databases probably wouldn’t matter…I digress.
Continue reading “Backing Up DevonTHINK Databases without Time Machine”

Quick Tip: Flush the System Security Services (SSS) Cache on Red Hat Enterprise Linux

After deleting a large number of service accounts from our FreeIPA infrastructure, I found they were still, supposedly anyway, resolvable by various hosts in our environment and that was preventing me from adding them locally. I suspected the issue was related to cacheing and referenced the SSS man page to figure out how to purge the its cache.

To flush a specific user entry from the SSS cache run the following command:

If that doesn’t do the trick run the following command to purge everything from the SSS cache:

Verify the desired user entry has been removed from the SSSD cache and is no longer present on the system with the following command:


Deploy a LAMP Stack with Salt, Salt-Cloud, and the AWS CLI: Part 1 – Introduction and Architecture


Over the next few weeks we’ll be learning how to use Salt, Salt-Cloud, and the AWS CLI to provision and configure a complete LAMP (Linux, Apache, MySQL, PHP) stack on top of Amazon AWS resources. The infrastructure will be comprised of the following Amazon AWS components:

  • Three (3) t2.small Amazon EC2 instances
  • One (1) Auto-Scaling group with associated launch configuration for additional instances created in response to infrastructure events (high CPU load, high RAM utilization, a sudden spike in requests, etc)
  • One (1) Elastic Load Balancer (ELB) instance
  • One (1) Amazon Simple Storage Service (S3) bucket for storage of static site assets
  • One (1) Amazon Virtual Private Cloud (VPC)
  • One (1) hosted zone in Amazon’s Route 53 DNS service
  • One (1) Elastic File System (EFS) volume with mount targets in two Availability Zones
  • One (1) Amazon Relational Database Service (RDS) instance configured for Multi-AZ replication

Continue reading “Deploy a LAMP Stack with Salt, Salt-Cloud, and the AWS CLI: Part 1 – Introduction and Architecture”

Quick Tip: Poll the Postfix mail queue and send a Slack notification if it starts to fill up

A few weeks ago I wrote a short post explaining how to flush the Postfix mail queue if it started filling up, but I didn’t mention how to determine if it’s filling up. The following script polls the Postfix mail queue and, if the status is anything other than “Mail queue is empty”, the script sleeps for two minutes to allow the queue to finish processing and polls it again. If the queue still doesn’t show as empty a notification is sent to a specific Slack channel. This script has already proven quite useful for us a couple of times when our upstream mail relay has experienced issues. Please note that for this script to provide maximum value you should probably run it on a schedule using a job scheduler like Cron or Rundeck so you and/or your team will be automatically notified if your mail queue starts filling up unexpectedly

Force a VMware VM to remove a stuck SCSI disk without a reboot

I was adding additional storage to a virtual file server a couple of weeks ago and I accidentally added a new disk using the wrong interface type. Upon realizing my mistake, I removed the disk in VMware vDirector, but, for whatever reason, the virtual machine, the OS or some combination of the two simply wouldn’t realize the disk had been removed and was no longer available on the SCSI bus. The block device ID consistently showed up in fdisk output even though it no longer existed and the SCSI bus had been scanned multiple times in vain. This could’ve probably been resolved with a simple reboot, but this VM was providing shares for production systems and couldn’t go down during the business day. A little poking around in the /sys/class/block directory pointed me in the right direction and I finally figured out I could trigger a rescan for only the offending drive with the following command:

After rescanning for only the stuck drive, it finally disappeared from the output of fdisk and I was able to add the drive again using the correct interface type. I realize there are much cleaner ways to do this, but most, if not all of them, require a reboot and I had to keep the system online while dealing with this issue. If anyone knows of another way to force a stuck block device to be dropped without a reboot please feel free to comment below.


How-to: Harden SSH Authentication with Google Authenticator

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!

Continue reading “How-to: Harden SSH Authentication with Google Authenticator”

Quick Tip: Locate the Temporary Password in a MySQL Community Server Installation

I was working on a project at work last week which required me to use the MySQL Community Server distribution of MySQL. This was my first time ever using this variant of MySQL Server, but I didn’t see any fundamental differences between it and more mainstream versions like MariaDB, etc. Unfortunately, I would soon be proven wrong. As I was going through my usual database server deployment checklist, I started the mysql_secure_installation script and was unable to use it to set the password for the root user. This seemed strange to me since, to my knowledge anyway, MySQL shipped with no root password set and relied on the user to set one. Apparently, that’s not the case with MySQL Community Server. Instead, MySQL Community Server generates a temporary password for the root user and applies it during initial start-up. After a bit of Googling I found that the generated password is logged to /var/log/mysqld.log so we can use grep to quickly figure out what it is. To determine the default root password generated by MySQL Community Server during initial start-up run the following command:

Then run mysql_secure_installation and follow the prompts as you normally would.