Игорь Олемской — практические заметки по системному администрированию Linux CentOS

Pacemaker – набор утилит от ClusterLabs для управления распределением ресурсов вычислительного кластера.

Pacemaker позволяет гибко распределять ресурсы по узлам кластера, следить за их доступностью, поднимать в случае падения ресурса, отрабатывать failover целого узла.

Если говорить кратко, Pacemaker работает по принципу Heartbeat, только расширяет его функциональность до высоких высот. Во-первых, Pacemaker может управлять более чем двумя узлами кластера, во-вторых, мониторить состояние ресурсов, в-третьих, позволяет ресурсы клонировать. И еще много-много чего другого.

Pacemaker представляет из себя конгломерат из пакетов Pacemaker, Corosyc, OpenAIS, Heartbeat. Pacemaker использует транспорт сообщений Corosync/OpenAIS либо Heartbeat для взаимодействия между узлами кластера. При этом действующий транспорт в кластере может быть только одного типа: либо Corosync/OpenAIS, либо Heartbeat.

Не смотря на то, что предпочтительным транспортом является Corosync, пакет Heartbeat так же должен быть установлен, поскольку он включает в себя достаточно большое количество OCF скриптов для управления ресурсами кластера.

За работу Pacemaker в CentOS отвечают два LSB-скрипта:

/etc/init.d/corosync
/etc/init.d/openais

За конфигурацию Pacemaker на отдельной ноде отвечают файлы:

/etc/corosync/corosync.conf - конфигурация corosync
/etc/corosync/authkey - авторизационный ключ для работы в кластере
/etc/corosync/service.d/pcmk - файл для связки corosync и pacemaker

Конфигурация кластера представляет из себя единый внутренний файл, изменения в который можно вносить на любой ноде с помощью утилиты crm. Изменения распространяются по другим нодам в качестве diff’ов автоматически.
За конфигурацию кластера отвечает единая консольная утилита crm.
Мониторинг состояния кластера: crm status – мгновенный слепок состояния, crm_mon – реалтайм мониторинг из консоли.

Основные понятия

Узлы (ноды,nodes) кластера

Узел (нода,node) кластера представляет из себя машину с установленным Pacemaker и включенным в состав кластера.

Управление нодами кластера осуществляется через команду crm node:

crm node standby node1 - переключить node1 в режим простоя
crm node online node1 -  переключить node1 в рабочий режим
crm node fence node1 - убить (выключить) при помощи STONITH node1
crm node help - справка по операциям с узлами

Узлы, предназначенные для выполнения одинаковых ресурсов должны иметь одинаковую конфигурацию софта, который используется ресурсами. То есть, если ресурс res1 ocf:heartbeat:apache предполагается запускать на узлах node1,node2,node3 и он использует определенный нестандартный модуль mod_rpaf, то все три узла должны иметь установленный apache и mod_rpaf одинаковых версий. Это исключает ситуацию, когда ресурс при перемещении между узлами может запуститься на одном ушле и не может на другом.

Ресурсы

Что есть ресурс с точки зрения pacemaker? Все, что может быть заскриптовано. Обычно скрипты пишутся на bash, но ничто не мешает вам писать их на Perl, Python или даже на C. Все, что требуется от скрипта, это выполнять 3 действия: start, stop и monitor. В общем-то скрипты должны соответствовать LSB (Linux Standard Base) или OCF (Open Cluster Framework) — последнее несколько расширяет LSB, требуя также передачи параметров через переменные окружения с особым названием.

Ресурс может представлять из себя:

• IP адрес
• Демон с определенной конфигурацией
• Блочное устройство
• Файловую систему
• etc

Каждый ресурс представляет из себя LSB/OCF скрипт, который должен обрабатывать минимум три параметра: start,stop,monitor, выдавая корректные коды возврата.

Управление ресурсами осуществляется через команду crm resource:

crm resource stop resource1 - остановить ресурс resource1
crm resource start resource1 - запустить ресурс resource1
crm resource move resource1 node2 - принудительно переместить ресурс resource1 на node2
crm resource cleanup resource1 - удалить счетчики сбоев ресурса resource1 со всех узлов
crm resource cleanup resource1 node2 - удалить счетчики сбоев ресурса resource1 с узла node2
crm resource help - справка по доступным действиям

Создание ресурсов осуществляется через crm configure primitive … .

Создание ресурса веб сервера apache из скрипта OCF apache осуществляется командой:

crm configure primitive sites-httpd ocf:heartbeat:apache params \
configfile="/cluster/conf/httpd-sites/conf/httpd.conf" httpd="/usr/sbin/httpd" port="85" \
statusurl="http://127.0.0.1:85/server-status" testregex="Apache" op monitor interval="30s"

Где

• sites-httpd – имя ресурса
• ocf:heartbeat:apache – расположение скрипта ресурса. ocf – тип скрипта (ocf или lsb), heartbeat – набор скриптов heartbeat, apache – имя скрипта. OCF скрипты располагаются в /usr/lib/ocf.
• configfile, httpd, port, statusurl, testregex – набор параметров OCF скрипта. Их имена, семантика и использование индивидуальны для каждого скрипта.
• op monitor interval=»30s» – применять к скрипту операцию monitor каждые 30 секунд. В случае если скрипт ocf::apache monitor вернул статус отличный от нуля, осуществляется попытка потушить ресурс и поднять его снова. При определенном количестве сбоев осуществляется решение о перемещении ресурса на другой узел.

Апач очевидно необходимо повесить на определенный IP адрес. По этому необходимо создать ресурс IP адреса:

crm configure primitive sites-ip-ext ocf:heartbeat:IPaddr2 \
        params ip="192.168.0.31" cidr_netmask="32" \
        op monitor interval="30s"

Однако очевидно что IP адрес и апач должны стартовать последовательно и на одном узле. Для определения таких связей используются Группы ресурсов

Группы ресурсов

Это последовательный список ресурсов, которые должны запускаться в определенном порядке, останавливаться в обратном порядке и исполняться на одном узле.

Например, ресурсы веб-сервера Apache (sites-httpd) и IP адрес для него (sites-ip-ext). Это два ресурса. Очевидно, что Apache не поднимется, если в системе нет определенного для него IP адреса. По этому мы создаем группу sites:

crm configure group sites sites-ip-ext sites-httpd

Теперь в кластере имеется группа под названием sites, включающая в себя два ресурса. К группе можно обращаться как к отдельному ресурсу: перемещать, устанавливать связи и свойства.

Вес связи

Для установки предпочтений связей используется вес связей от -INFINITY до +INFINITY. Установка с весом -INFINITY или +INFINITY является жесткой. Вес +/- INFINITY не может оспариваться другими условиями. Вес в целочисленном представлении может.

location

Директивой location можно определить предпочтительный запуск определенного ресурса/группы на определенном узле.

Установка предпочтения запуска ресурса httpd с весом 50 на node1 и весом 100 на node2:

crm configure location httpd-prefer-node1 httpd rule 50: node1
crm configure location httpd-prefer-node2 httpd rule 100: node2

Установка жесткого запуска ресурса httpd сугубо на node1 (ахтунг! при сбое ресурса его миграция на другие ноды будет весьма затруднена!):

crm configure location httpd-prefer-node1 httpd rule INFINITY: node1

Ресурс httpd не должен вообще никогда запускаться на node2:

crm configure location httpd-prefer-node1 httpd rule -INFINITY: node2

colocation

Директивой colocation можно определить предпочтительный запуск определенных ресурсов/групп вместе на одном узле.

Запускать ресурсы WebSite ClusterIP только на одном узле

crm configure colocation website-with-ip INFINITY: WebSite ClusterIP

Никогда не запускать ресурсы nginx и apache на одном узле

crm configure colocation nginx-not-apache -INFINITY: nginx apache

Установка

Нужно убедиться что:

• IP и hostname ноды взаимно отвечают друг другу в DNS на A и PTR запросы.
• Настроена ssh авторизация по публичному ключу текущей ноды со всеми остальными, всех остальных с текущей и текущей с текущей
• SELinux выключен
• Временная зона на всех нодах одинакова и время синхронизировано

Подключаем репозиторий ClusterLabs и устанавливаем софт:

cd /etc/yum.repos.d
wget http://www.clusterlabs.org/rpm/epel-5/clusterlabs.repo
yum install pacemaker corosync openais

Содержимое файла /etc/corosync/corosync.conf:

# Please read the corosync.conf.5 manual page
compatibility: whitetank
 
totem {
        version: 2
        secauth: off
        threads: 0
        interface {
                ringnumber: 0
                bindnetaddr: 192.168.0.0
                mcastaddr: 239.192.1.1
                mcastport: 4000
#               broadcast yes
        }
}
 
logging {
        fileline: off
        to_stderr: no
        to_logfile: yes
        to_syslog: yes
        syslog_facility: local2
        logfile: /var/log/corosync.log
        debug: off
        timestamp: on
        logger_subsys {
                subsys: AMF
                debug: off
        }
}
 
amf {
        mode: disabled
}

Где:

• bindnetaddr – Сеть класса С для внутренних коммуникаций, это не IP адрес ноды, это сеть /24, в котором он находится
• mcastaddr, mcastport – адрес и порт для мультикастовых сообщений

Файл /etc/corosync/authkey суть случайная последовательность байт длинной около 128 байт, должен быть одинаковый для всех нод кластера. Следовательно, для первой ноды кластера мы его создаем

dd if=/dev/urandom of=/etc/corosync/authkey bs=1 count=128
chmod 600 /etc/corosync/authkey

А для остальных нод кластера мы его просто копируем.

Файл для связки corosync & pacemaker /etc/corosync/service.d/pcmk:

service {
        # Load the Pacemaker Cluster Resource Manager
        name: pacemaker
        ver:  0
}
END

Стартуем:

/etc/init.d/openais start
/etc/init.d/corosync start
chkconfig opeais on
chkconfig corosync on

Убедиться что кластер стартовал можно командой crm status.

Написано по мотивам Linux HA на основе Pacemaker (значительно дополнил статью).

As promised in one of my previous posts about dual-primary DRBD and OCFS2, I've compiled a step-by-step guide for Fedora. These instructions should be somewhat close to what you would use on CentOS or Red Hat Enterprise Linux. However, CentOS and Red Hat don't provide some of the packages needed, so you will need to use other software repositories like RPMFusion or EPEL.

In this guide, I'll be using two Fedora 14 instances in the Rackspace Cloud with separate public and private networks. The instances are called server1 and server2 to make things easier to follow.

NOTE: All of the instructions below should be done on both servers unless otherwise specified.

First, we need to set up DRBD with two primary nodes. I'll be using loop files for this setup since I don't have access to raw partitions.

yum -y install drbd-utils
dd if=/dev/zero of=/drbd-loop.img bs=1M count=1000

Put this loop file initialization init script in /etc/init.d/loop-for-drbd and finish setting it up:

chmod a+x /etc/init.d/loop-for-drbd
chkconfig loop-for-drbd on
/etc/init.d/loop-for-drbd start

Place this DRBD resource file in /etc/drbd.d/r0.res. Be sure to adjust the server names and IP addresses for your servers.

resource r0 {
	meta-disk internal;
	device /dev/drbd0;
	disk /dev/loop7;
 
	syncer { rate 1000M; }
        net {
                allow-two-primaries;
                after-sb-0pri discard-zero-changes;
                after-sb-1pri discard-secondary;
                after-sb-2pri disconnect;
        }
	startup { become-primary-on both; }
 
	on server1 { address 10.181.76.0:7789; }
	on server2 { address 10.181.76.1:7789; }
}

The net section is telling DRBD to do the following:

• allow-two-primaries — Generally, DRBD has a primary and a secondary node. In this case, we will allow both nodes to have the filesystem mounted at the same time. Do this only with a clustered filesystem. If you do this with a non-clustered filesystem like ext2/ext3/ext4 or reiserfs, you will have data corruption. Seriously!
• after-sb-0pri discard-zero-changes — DRBD detected a split-brain scenario, but none of the nodes think they're a primary. DRBD will take the newest modifications and apply them to the node that didn't have any changes.
• after-sb-1pri discard-secondary — DRBD detected a split-brain scenario, but one node is the primary and the other is the secondary. In this case, DRBD will decide that the secondary node is the victim and it will sync data from the primary to the secondary automatically.
• after-sb-2pri disconnect — DRBD detected a split-brain scenario, but it can't figure out which node has the right data. It tries to protect the consistency of both nodes by disconnecting the DRBD volume entirely. You'll have to tell DRBD which node has the valid data in order to reconnect the volume. Use extreme caution if you find yourself in this scenario.

If you'd like to read about DRBD split-brain behavior in more detail, review the documentation.

I generally turn off the usage reporting functionality in DRBD within /etc/drbd.d/global_common.conf:

global {
	usage-count no;
}

Now we can create the volume and start DRBD:

drbdadm create-md r0
/etc/init.d/drbd start && chkconfig drbd on

You may see some errors thrown about having two primaries but neither are up to date. That can be fixed by running the following command on the primary node only:

drbdsetup /dev/drbd0 primary -o

If you run cat /proc/drbd on the secondary node, you should see the DRBD sync running:

version: 8.3.8 (api:88/proto:86-94)
srcversion: 299AFE04D7AFD98B3CA0AF9
 0: cs:SyncTarget ro:Secondary/Primary ds:Inconsistent/UpToDate C r----
    ns:0 nr:210272 dw:210272 dr:0 al:0 bm:12 lo:1 pe:2682 ua:0 ap:0 ep:1 wo:b oos:813660
        [===>................] sync'ed: 20.8% (813660/1023932)K queue_delay: 0.0 ms
        finish: 0:01:30 speed: 8,976 (6,368) want: 1024,000 K/sec

Before you go any further, wait for the DRBD sync to fully finish. When it completes, it should look like this:

version: 8.3.8 (api:88/proto:86-94)
srcversion: 299AFE04D7AFD98B3CA0AF9
 0: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r----
    ns:0 nr:1023932 dw:1023932 dr:0 al:0 bm:63 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0

Now, on the secondary node only make it a primary node as well:

drbdadm primary r0

You should see this on the secondary node if you've done everything properly:

version: 8.3.8 (api:88/proto:86-94)
srcversion: 299AFE04D7AFD98B3CA0AF9
 0: cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate C r----
    ns:1122 nr:1119 dw:2241 dr:4550 al:2 bm:1 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0

We're now ready to move on to configuring OCFS2. Only one package is needed:

yum -y install ocfs2-tools

Ensure that you have your servers and their private IP addresses in /etc/hosts before proceeding. Create the /etc/ocfs2 directory and place the following configuration in /etc/ocfs2/cluster.conf (adjust the server names and IP addresses):

cluster:
	node_count = 2
	name = web
 
node:
	ip_port = 7777
	ip_address = 10.181.76.0
	number = 1
	name = server1
	cluster = web
 
node:
	ip_port = 7777
	ip_address = 10.181.76.1
	number = 2
	name = server2
	cluster = web

Now it's time to configure OCFS2. Run service ocfs2 configure and follow the prompts. Use the defaults for all of the responses except for two questions:

• Answer «y» to «Load O2CB driver on boot»
• Answer «web» to «Cluster to start on boot»

Start OCFS2 and enable it at boot up:

chkconfig o2cb on && chkconfig ocfs2 on
/etc/init.d/o2cb start && /etc/init.d/ocfs2 start

Create an OCFS2 partition on the primary node only:

mkfs.ocfs2 -L "web" /dev/drbd0

Mount the volumes and configure them to automatically mount at boot time. You might be wondering why I do the mounting within /etc/rc.local. I chose to go that route since mounting via fstab was often unreliable for me due to the incorrect ordering of events at boot time. Using rc.local allows the mounts to work properly upon every reboot.

mkdir /mnt/storage
echo "/dev/drbd0  /mnt/storage  ocfs2  noauto,noatime  0 0" >> /etc/fstab
mount /dev/drbd0
echo "mount /dev/drbd0" >> /etc/rc.local

At this point, you should be all done. If you want to test OCFS2, copy a file into your /mnt/storage mount on one node and check that it appears on the other node. If you remove it, it should be gone instantly on both nodes. This is a great opportunity to test reboots of both machines to ensure that everything comes up properly at boot time.

Dual-primary DRBD with OCFS2 is a post from: Major Hayden's Racker Hacker blog.

Thanks for following the blog via the RSS feed. Please don't copy my posts or quote portions of them without attribution.

Today, on my 28th birthday, I'm finally delivering on a promise to my readers which I made about two months ago. I've written a guide on how to host a web application redundantly in a cloud environment. While it's still a bit of a rough draft, it should be a good starting point for those who haven't worked in virtualized environments before. Also, it may show some of the more experienced systems administrators a new way to do things.

The guide: Redundant Cloud Hosting Guide

As always, if you find anything in the guide that needs improvement, I'm all ears.

A simple guide to redundant cloud hosting is a post from: Major Hayden's Racker Hacker blog.

c0b6ad7e-f251-11df-b20b-4040336e00ef

Typical configuration for a
proxy-type load balancer

A typical load balancing configuration using hardware devices or software implementations will be organized such that they resemble the diagram at the right. I usually call this a proxy-type load balancing solution since the load balancer proxies your request to some other nodes. The standard order of operations looks like this:

• client makes a request
• load balancer receives the request
• load balancer sends request to a web node
• the web server sends content back to the load balancer
• the load balancer responds to the client

If you're not familiar with load balancing, here's an analogy. Consider a fast food restaurant. When you walk up to the counter and place an order, you're asking the person at the counter (the load balancer) for a hamburger. The person at the counter is going to submit your order, and then a group of people (web nodes) are going to work on it. Once your hamburger (web request) is ready, your order will be given to the person at the counter and then back to you.

This style of organization can become a problem as your web nodes begin to scale. It requires you to ensure that your load balancers can keep up with the requests and sustain higher transfer rates that come from having more web nodes serving a greater number of requests. Imagine the fast food restaurant where you have one person taking the orders but you have 30 people working on the food. The person at the counter may be able to take orders very quickly, but they may not be able to keep up with the orders coming out of the kitchen.

LVS allows for application servers
to respond to clients directly

This is where Linux Virtual Server (LVS) really shines. LVS operates a bit differently:

• client makes a request
• load balancer receives the request
• load balancer sends request to a web node
• the web server sends the response directly to the client

The key difference is that the load balancer sends the unaltered request to the web server and the web server responds directly to the client. Here's the fast food analogy again. If you ask the person at the counter (the load balancer) for a hamburger, that person is going to take your order and give it to the kitchen staff (the web nodes) to work on it. This time around, the person at the counter is going to advise the kitchen staff that the order needs to go directly to you once it's complete. When your hamburger is ready, a member of the kitchen staff will walk to the counter and give it directly to you.

In the fast food analogy, what are the benefits? As the number of orders and kitchen staff increases, the job of the person at the counter doesn't drastically increase in difficulty. While that person will have to handle more orders and keep tabs on which of the kitchen staff is working on the least amount of orders, they don't have to worry about returning food to customers. Also, the kitchen staff doesn't need to waste time handing orders to the person at the counter. Instead, they can pass these orders directly to the customer that ordered them.

In the world of servers, this is a large benefit. Since the web servers' responses no longer pass through the load balancer, they can spend more time on what they do best — balancing traffic. This allows for smaller, lower-powered load balancing servers from the beginning. It also allows for increases in web nodes without big changes for the load balancers.

There are three main implementations of LVS to consider:

LVS-DR: Direct Routing
The load balancer receives the request and sends the packet directly to a waiting real server to process. LVS-DR has the best performance, but all of your servers must be on the same network subnet and they have to be able to share the same router (with no other routing devices in between them).

LVS-TUN: Tunneling
This is very similar to the direct routing approach, but the packets are encapsulated and sent directly to the real servers once the load balancer receives them. This removes the restriction that all of the devices must be on the same network. Thanks to encapsulation, you can use this method to load balance between multiple datacenters.

LVS-NAT: Network Address Translation
Using NAT for LVS yields the least performance and scaling of all of the implementation options. In this configuration, the incoming requests are rewritten so that they will be transported correctly in a NAT environment. This puts a bigger burden on the load balancer as it must rewrite the requests quickly while still keeping up with how much work is being done by each web server.

Looking for a Linux Virtual Server HOWTO? Stay tuned. I'm preparing one for my next post.

A modern implementation and explanation of Linux Virtual Server (LVS) is a post from: Major Hayden's Racker Hacker blog.

c0b6ad7e-f251-11df-b20b-4040336e00ef

High availability is certainly not a new concept, but if there's one thing that frustrates me with high availability VM setups, it's storage. If you don't mind going active-passive, you can set up DRBD, toss your favorite filesystem on it, and you're all set.

If you want to go active-active, or if you want multiple nodes active at the same time, you need to use a clustered filesystem like GFS2, OCFS2 or Lustre. These are certainly good options to consider but they're not trivial to implement. They usually rely on additional systems and scripts to provide reliable fencing and STONITH capabilities.

What about the rest of us who want multiple active VM's with simple replicated storage that doesn't require any additional elaborate systems? This is where GlusterFS really shines. GlusterFS can ride on top of whichever filesystem you prefer, and that's a huge win for those who want a simple solution. However, that means that it has to use fuse, and that will limit your performance.

Let's get this thing started!

Consider a situation where you want to run a WordPress blog on two VM's with load balancers out front. You'll probably want to use GlusterFS's replicated volume mode (RAID 1-ish) so that the same files are on both nodes all of the time. To get started, build two small Slicehost slices or Rackspace Cloud Servers. I'll be using Fedora 13 in this example, but the instructions for other distributions should be very similar.

First things first — be sure to set a new root password and update all of the packages on the system. This should go without saying, but it's important to remember. We can clear out the default iptables ruleset since we will make a customized set later:

# iptables -F
# /etc/init.d/iptables save
iptables: Saving firewall rules to /etc/sysconfig/iptables:        [  OK  ]

GlusterFS communicates over the network, so we will want to ensure that traffic only moves over the private network between the instances. We will need to add the private IP's and a special hostname for each instance to /etc/hosts on both instances. I'll call mine gluster1 and gluster2:

10.xx.xx.xx gluster1
10.xx.xx.xx gluster2

You're now ready to install the required packages on both instances:

yum install glusterfs-client glusterfs-server glusterfs-common glusterfs-devel

Make the directories for the GlusterFS volumes on each instance:

mkdir -p /export/store1

We're ready to make the configuration files for our storage volumes. Since we want the same files on each instance, we will use the --raid 1 option. This only needs to be run on the first node:

# glusterfs-volgen --name store1 --raid 1 gluster1:/export/store1 gluster2:/export/store1
Generating server volfiles.. for server 'gluster2'
Generating server volfiles.. for server 'gluster1'
Generating client volfiles.. for transport 'tcp'

Once that's done, you'll have four new files:

• booster.fstab — you won't need this file
• gluster1-store1-export.vol — server-side configuration file for the first instance
• gluster2-store1-export.vol — server-side configuration file for the second instance
• store1-tcp.vol — client side configuration file for GlusterFS clients

Copy the gluster1-store1-export.vol file to /etc/glusterfs/glusterfsd.vol on your first instance. Then, copy gluster2-store1-export.vol to /etc/glusterfs/glusterfsd.vol on your second instance. The store1-tcp.vol should be copied to /etc/glusterfs/glusterfs.vol on both instances.

At this point, you're ready to start the GlusterFS servers on each instance:

/etc/init.d/glusterfsd start

You can now mount the GlusterFS volume on both instances:

mkdir -p /mnt/glusterfs
glusterfs /mnt/glusterfs/

You should now be able to see the new GlusterFS volume in both instances:

# df -h /mnt/glusterfs
Filesystem            Size  Used Avail Use% Mounted on
/etc/glusterfs/glusterfs.vol
                      9.4G  831M  8.1G  10% /mnt/glusterfs

As a test, you can create a file on your first instance and verify that your second instance can read the data:

[root@gluster1 ~]# echo "We're testing GlusterFS" > /mnt/glusterfs/test.txt
.....
[root@gluster2 ~]# cat /mnt/glusterfs/test.txt
We're testing GlusterFS

If you remove that file on your second instance, it should disappear from your first instance as well.

Obviously, this is a very simple and basic implementation of GlusterFS. You can increase performance by making dedicated VM's just for serving data and you can adjust the default performance options when you mount a GlusterFS volume. Limiting access to the GlusterFS servers is also a good idea.

If you want to read more, I'd recommend reading the GlusterFS Technical FAQ and the GlusterFS User Guide.

Thank you for your e-mails! I'll be expanding on this post later with some sample benchmarks and additional tips/tricks, so please stay tuned.

GlusterFS on the cheap with Rackspace's Cloud Servers or Slicehost is a post from: Major Hayden's Racker Hacker blog.

c0b6ad7e-f251-11df-b20b-4040336e00ef