server

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!

To the uninitiated, Boost is a module for Drupal which has the potential to make your Drupal-based website run many times faster than it's currently running. Boost basically converts pages on a Drupal site into static html files, and allows your website to direct anonymous (non-logged-in) users to the cached html pages.

Doing so speeds your site up quite a bit, because instead of your web server having to run some PHP scripts and connect to your website's database, the server can simply send the complete html file, which requires no extra processor cycles or memory to compile. If your website has a lot of anonymous traffic, the potential speedup is very large. Instead of serving hundreds of users per minute, you could serve thousands.

Here's a quickie: A lot of Mac users are on Windows networks, and need to sometimes connect to a shared folder on their network to share/retrieve documents with other Windows users. The easiest way to do this is to type in the path to the shared folder in the "Connect to Server..." dialog box. To do this, just:

1. Switch to the Finder.
2. Choose the "Connect to Server..." menu option in the Go menu (or press Command-K).
3. Type in the path to your windows shared folder as follows:

smb://SERVER_NAME/share-name/folder-name

Hopefully, a dialog box will open up asking you to type in your username and password. If you need to find out the path of your windows shared folder, ask your network administrator. (note: private shared folders usually have a dollar sign after them—for example, smb://SERVER_NAME/share-name/folder-name$).