server

September 2018 Update: Ansible 2.7 (to be released around October 2018) will include a new reboot module, which makes reboots a heck of a lot simpler (whether managing Windows, Mac, or Linux!):

- name: Reboot the server and wait for it to come back up.
  reboot:

That's it! Much easier than the older technique I used in Ansible < 2.7!

One pattern I often need to implement in my Ansible playbooks is "configure-reboot-configure", where you change some setting that requires a reboot to take effect, and you have to wait for the reboot to take place before continuing on with the rest of the playbook run.

For example, on my Raspberry Pi Dramble project, before installing Docker and Kubernetes, I need to make sure the Raspberry Pi's /boot/cmdline.txt file contains a couple cgroup features so Kubernetes runs correctly. But after adding these options, I also have to reboot the Pi.

Pi Hole is a nifty open source project that allows you to offload the task of blocking advertisements and annoying (and often malicious) trackers to a Raspberry Pi. The installation is deceptively simple (a curl | bash affair), but I wanted to document how I set up mine headless (just plugging the Pi into power and the network).

Set up Raspbian Lite

I bought a Raspberry Pi model 2 B along with the official Raspberry Pi foundation Case. Then I bought a Samsung Evo+ 32GB microSD card (which comes with a full-size SD card adapter), and did the following steps on my MacBook Pro to set up the Pi's OS:

Through Facebook, I discovered this great video on one young man's experience as an altar server:

I definitely agree that the altar server can distract from the liturgy if he is not focused on his duty, and that priests should encourage the use of cassocks and surplices instead of albs. A large reason for my joining the Seminary was my experience as an altar server, assisting some very humble priests who were great representatives of the Church and very close to Jesus—and this was reinforced by how reverent and dedicated they were to the celebration of Holy Mass.

Server Check.in is a simple and inexpensive server and website uptime monitoring service I've recently launched.

If you have a website or online service you need to make sure is running, Server Check.in is a great way to get notified when there's a problem. Unlike most other monitoring solutions, Server Check.in offers free SMS (text) messages and email notifications, and it only costs $15/year (just $1.25/month!).

The Motivation

There are probably thousands of other uptime monitoring services on the web, and it's typically a good idea to use existing tools rather than build your own—if they're practical for your needs!

I had three main requirements for any service I wanted to use:

Midwestern Mac is proud to announce Server Check.in—a website and server monitoring service that is inexpensive and easy to use.

Server Check.in was built because, while there are some really powerful and flexible monitoring solutions out there, like Pingdom (we love Pingdom!), there aren't any really simple and inexpensive services that are better for individuals and small businesses who don't have a budget for more expensive and involved solutions, but still need to know when their servers or sites go down.

Server Check.in offers many features like free, unlimited SMS messages for outage notices, email notifications, and server latency monitoring. It will check on up to five servers or websites every fifteen minutes, and notify you when the servers and sites go down.

Sign up here for only $15/year—that's just $1.25 per month!

I have to set up a new LAMP server for different clients here and there, but not with enough frequency to warrant using a particular scripted solution or 'stack' from a particular hosting company. Plus, I like to have a portable solution that is flexible to the needs (and constraints) of a client's website.

Note on hosting providers: For hosting, I've used a very wide variety of hosts. I typically use and recommend Hot Drupal VPSes or Linode VPSes [affiliate link] running CentOS for a good LAMP server. Shared servers are only good for nonessential or low-traffic sites, but they are a bit cheaper and easier to use for simpler needs!

So, here's a typical step-by-step process for how I set up a CentOS 6 (similar process for CentOS 5) server for LAMP (Linux, Apache, MySQL, and PHP), often for low-to-moderate Drupal sites (one or many):

I've seen a ton of iptables configurations on the Internet, and none of them really got to the heart of what I need to do for the majority of my LAMP-based web servers (hosted on Linode, HostGator, Hot Drupal, and elsewhere). For these servers, I just need a really simple set of rules that restricts all incoming traffic except for web (port 80/443 for http/https traffic), ssh (usually port 22), smtp (port 25), and icmp ping requests.

The script below (save it as 'firewall.bash', chmod u+x it to make it executable, and run it with $ sudo /path/to/firewall.bash, then test your server (access websites, log on to it from another Terminal session, ping it, etc., and make sure that's all working)):

I use CentOS, but these guidelines should apply no matter what flavor of linux you use. We all know it's a good security practice to lock down your server and require SSH logins to use an RSA key/pair, rather than a password, right? Plus, it makes it easier for you to login to your server from your primary computers/devices...

I was setting up a new server recently, and spent probably half an hour figuring out why the standard way of creating a shared key, sending it to the server, putting it in /home/[username]/.ssh/authorized_keys, and trying to log in without a password wasn't working for me.

It turns out, there were permissions issues I hadn't thought of (I usually would create accounts through cPanel, since I only live in the Terminal out of necessity, from time to time). When you create the authorized_keys file, which contains public SSH keys for your computers, you need to make sure the permissions are set so that:

I just discovered (after asking about it in the #drupal IRC channel) the wonderful little program ab, included in an Apache installation. This little nugget does one thing, and does it well: It beats the heck out of your server, then tells you how your server did in terms of page serving. I tested a few different configurations on a dedicated, 4-core, 4 GB RAM server from SoftLayer, and used the following two commands:

1. Download the specified URL 1,000 times, with KeepAlive turned off (each request gets a new http connection):

ab -n 1000 -c 5 http://ip.address.of.site/path-to-page.php

2. Downlaod the specified URL 1,000 times, with KeepAlive turned on (thus allowing the connection to be maintained for as many http downloads as you have set in your httpd.conf file):

ab -n 1000 -kc 5 http://ip.address.of.site/path-to-page.php

I ran these tests a few different ways, and here are the results of the tests I ran with KeepAlive on, with the number of pages per second ab reported listed after the method:

• Drupal - normal page caching turned on, css/js aggregation, 55kb page – 12.5 pages/sec
• Joomla - no page caching (disabled due to buggy 1.x caching), 65kb page – 8.2 pages/sec
• Drupal - boost module enabled, serving up the boost-cached file – 3,250 pages/sec
• Joomla - custom page caching system enabled, serving static html file – 2,600 pages/sec

Speed boost due to caching: ~250x faster!