When I need to verify an SSL certificate and the corresponding CA intermediate certs a good tool is openssl like this:

openssl verify -CAfile cabundle.crt www.domain.com.crt

Original post blogged on b2evolution.

Here's a single command to generate a new key and CSR:

openssl req -nodes -newkey rsa:2048 -keyout mydomain.key -out mydomain.csr

Original post blogged on b2evolution.

The goal of this series of articles has been to construct a high availability and load balanced MySQL cluster with CentOS on the RackSpace Cloud.

You should begin with this article to setup the HA Linux cluster:

HA Linux Cluster On RackSpace Cloud Servers

Then follow this article to add the multi-master MySQL replication:

MySQL Multi Master HA Cluster

The last part of the process is to add load balancing.

1. Start by installing HAProxy on both servers:

yum install haproxy

Unfortunately yum will provide an outdated version so we need to upgrade from source as follows:

cd /root/archive/ wget http://haproxy.1wt.eu/download/1.4/src/haproxy-1.4.14.tar.gz tar -xvzf haproxy-1.4.14.tar.gz cd haproxy-1.4.14 make TARGET=linux26 make install

Now edit /etc/init.d/haproxy and change this line:

exec="/usr/sbin/haproxy"

to:

exec="/usr/local/sbin/haproxy"

2. Now edit /etc/haproxy/haproxy.cfg

a. Remove all existing "listen", "frontend" and "backend" sections.

b. Find this line if it exists:

option httplog

and change it to:

option tcplog

c. Add this listen section:

listen mysql-cluster 0.0.0.0:3307 mode tcp balance roundrobin option mysql-check user root server db01 [HOST1_IP]:3306 check server db02 [HOST2_IP]:3306 check

The [PASSWORD] controls access to the HAProxy web interface. And [HOST1_IP] and [HOST2_IP] are the private addresses of the servers.

d. Repeat on the other server.

3. Set haproxy service to start on boot:

/sbin/chkconfig --level 345 haproxy on

4. Finally start the haproxy service.

/sbin/service haproxy restart

Original post blogged on b2evolution.

The goal of this article is to setup an HA Linux cluster on RackSpace Cloud Servers for MySQL with multi master replication and HAProxy for load balancing.

Begin by creating the HA Linux client as described here:

HA Linux Cluster On RackSpace Cloud Servers

Once this is complete then return to these instructions.

1. Begin by logging into each of the servers and creating a replication slave user with the following SQL commands:

GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%' IDENTIFIED BY '[PASSWORD]'; FLUSH PRIVILEGES;

Where [PASSWORD] is a strong random string. Use the same password on each of the servers.

2. Stop mysqld on both servers:

/sbin/service mysqld stop

3. On each server, edit the /etc/my.cnf file. Look through the my.cnf file for an existing section of replication options. If none is found then just add to the end of the file.

a. Find the "server-id" line and make sure that each server has a unique server-id. It does not matter what the id number is ... it just has to be different on each server.

server-id = 1

b. Set replicate-same-server-id to 0. This tells each server to ignore replication logs that refer to it's on id number.

replicate-same-server-id=0

c. Set auto-increment-increment to 2. If you have more then two servers in your cluster then set auto-increment-increment to the number of servers. If you think that you might increase the number of servers in the near future then set auto-increment-increment to the likely maximum number of servers. This parameter controls the span between auto-increment values. So for example a setting of 2 causes a sequence like 2,4,6,6, etc. A value of 5 would cause a sequence of 5,10,15,20, etc.

auto-increment-increment=2

d. Set auto-increment-offset to 1 on the first server and 2 on the second server. auto-increment-offset works in conjunction with auto-increment-increment to control the generation of auto-increment values. Each server needs a different auto-increment-offset to avoid conflicts. Assuming two servers, with auto-increment-increment set to 2 and auto-increment-offset set to 1 and 2 on the first and second server respectively will result in the following sequences:

Server 1: 1,3,5,7,9,11,... Server 2: 2,4,6,8,10,12,... auto-increment-offset=1

e. Now on each server, add master-host, master-user, master-password, and master-connect-retry settings. Remember that the master-host should be set to the other server. I like to use hostnames as long as they've been defined in /etc/hosts so that there is no dependency on external name-resolution.

Here's the first server:

master-host = db2 master-user = repl master-password = [PASSWORD] master-connect-retry = 60

And here's the second server:

master-host = db1 master-user = repl master-password = [PASSWORD] master-connect-retry = 60

f. Uncomment or add a log-bin line:

log-bin=/var/lib/mysqllogs/bin-log

g. Setup expire_logs_days and max_binlog_size so that the binary logs don't grow in an uncontrolled fashion.

expire_logs_days = 10 max_binlog_size = 100M

h. Uncomment or add relay-log and relay-log-index lines:

relay-log=/var/lib/mysqllogs/relay-log relay-log-index=/var/lib/mysqllogs/relay-log.index

4. Next start the mysqld service on both servers:

/sbin/service mysqld start

5. Now login to the mysql command line on each server and run "SHOW SLAVE STATUS". Examine the output and verify that "Slave_IO_Running" and "Slave_SQL_Running" are both "YES".

Congratulations, you now have a high-availability MySQL cluster!

Special thanks to Richard Benson at Dixcart whose similar articles for Debian inspired this effort.

Original post blogged on b2evolution.

Our goal is to setup a pair of RackSpace Cloud Servers in a redundant cluster using a shared IP address. We'll use the "heartbeat" package from Linux-HA (http://www.linux-ha.org) for the cluster messaging layer and "pacemaker" package from ClusterLabs (http://clusterlabs.org) for the cluster resource manager.

Before starting this procedure you'll need to:

a. Create the two cloud servers. These instructions are specific to CentOS for the operating system.

b. Open a ticket with RackSpace Cloud support and request a public IP address to be shared between the servers.

You can use the instructions for other situations but you'll need to make the appropriate adjustments.

1. Setup hosts file entries. On each server, edit /etc/hosts and add entries for each servers public and private interfaces. You'll also find it convenient to setup ssh keys between the servers for easy access.

2. Now use yum to install some prerequisite packages:

yum install net-snmp perl-libwww-perl libesmtp perl-Net-SSLeay perl-MailTools ipvsadm OpenIPMI libibverbs librdmacm openhpi PyXML

Repeat this step on the second server.

Note: Several of these packages are not available on the standard RHEL yum channels. If you're working on something other then a RackSpace Cloud server then you might need to install the EPEL channel. Just go to:

http://fedoraproject.org/wiki/EPEL

Then download and install the appropriate package to add EPEL.

3. The version of heartbeat available in the standard yum repositories is outdated. So we'll install a more recent version of heartbeat, pacemaker and supporting components from:

http://www.clusterlabs.org/rpm

Start by creating a working folder:

mkdir /root/archive cd /root/archive

Then use wget to download the latest version of each of the following package:

cluster-glue-1.0.6-1.6.el5.x86_64.rpm cluster-glue-libs-1.0.6-1.6.el5.x86_64.rpm corosync-1.2.7-1.1.el5.x86_64.rpm corosynclib-1.2.7-1.1.el5.x86_64.rpm heartbeat-3.0.3-2.el5.x86_64.rpm heartbeat-libs-3.0.3-2.el5.x86_64.rpm openais-1.1.3-1.6.el5.x86_64.rpm openaislib-1.1.3-1.6.el5.x86_64.rpm pacemaker-1.0.10-1.4.el5.x86_64.rpm pacemaker-libs-1.0.10-1.4.el5.x86_64.rpm resource-agents-1.0.3-2.el5.x86_64.rpm

Finally install the packages:

rpm -i *.rpm

Repeat this step on the second server.

5. Next step is to configure heartbeat.

a. Setup keys for authentication between the instances.

Edit /etc/ha.d/authkeys and add:

auth 1 1 sha1 [PASSWORD]

Replace [PASSWORD] with a long random string.

b. Set permissions on the authkeys file:

chmod 600 /etc/ha.d/authkeys

c. Next edit /etc/ha.d/ha.cf and add the following:

autojoin none keepalive 2 deadtime 15 warntime 5 initdead 120 ucast eth1 [INTERNAL IP OF HOST2] node [HOST1] node [HOST2] use_logd yes crm respawn

Set [HOST1] and [HOST2] to the hostnames of the servers.

Set [INTERNAL IP OF HOST2] to the private IP address of the second server.

Repeat these steps on the second server. When you create the ha.cf file for the second server, you'll use the internal IP of the first server in the ucast line.

d. Setup logd for automatic startup:

/sbin/chkconfig --level 345 logd on

Now repeat this procedure on the second server but make sure you set the internal IP of the first server in the ha.cf file.

6. Finally start the heartbeat and logd service on both servers:

/sbin/service logd start /sbin/service heartbeat start

7. The next step is to configure pacemaker.

Run the pacemaker configuration tool. It is called "crm". You'll use it to configure "resources" which in this case is a shared IP.

crm configure

If you get an error like "cibadmin not available, check your installation" when trying to run crm, then make sure that the "which" package is installed and that /usr/sbin is in your path.

Now enter the following into the pacemaker shell:

primitive shared_ip_one IPaddr params ip=[SHARED_IP] cidr_netmask="255.255.255.0" nic="eth0" property stonith-enabled="false" location share_ip_one_master shared_ip_one 100: [HOST1] monitor shared_ip_one 20s:10s commit exit

Where [SHARED_IP] is the IP address to be shared between the servers and [HOST1] is the hostname of the primary server.

Once this is done then you should be able to monitor the status of the cluster from either node using the crm_mon command. You'll get output like this:

============ Last updated: Sun Feb 6 14:00:42 2011 Stack: Heartbeat Current DC: node01 (cad6f81e-f772-4add-b5e2-c9a78b4ae430) - partition with quorum Version: 1.0.10-da7075976b5ff0bee71074385f8fd02f296ec8a3 2 Nodes configured, 2 expected votes 1 Resources configured. ============ Online: [ node02 node01 ] shared_ip_one (ocf::heartbeat:IPaddr): Started node01

8. Next step is to test failover on the servers.

a. Run crm_mon on the second server.

b. Reboot the first server:

/sbin/reboot

c. Monitor the second server and notice that when the first goes offline, the "shared_one_ip" is switched to the second server. After the first server finishes rebooting then you should see it come back online and "shared_one_ip" return to it's original location on the first server.

d. Repeat this test but reboot the second server and monitor the first.

And that completes the setup process. You now have an HA Linux cluster on the cloud!

Original post blogged on b2evolution.

Need to redirect from acme.com to www.acme.com with nginx? No problem ... just add a virtual host declaration for the non-www that redirects like this:

server {
listen 80;
server_name acme.com;
rewrite ^/(.*) http://www.acme.com/$1 permanent;
}

Original post blogged on b2evolution.

One of our clients is a school district that wanted to make content on http://www.khanacademy.org/ (KA) available to users without Youtube. The KA site uses a bit of javascript to test if the user's browser can get to youtube and if not it servers videos from an different source. Unfortunately this was not working for the client.

To solve the problem we setup mod_proxy as a reverse proxy. Then we used mod_headers, mod_filter and mod_substitute to rewrite the javascript going to client and force the use of the youtube alternative.

Here's the apache config that does the content rewrite. It's located in the reverse proxy virtual host:

# do not accept gzip - gzip bypasses filters RequestHeader unset Accept-Encoding # declare that content should be filtered through mod_substitute FilterDeclare NOTUBE FilterProvider NOTUBE SUBSTITUTE Content-Type $text/html FilterChain +NOTUBE # change the javacript test so that it always failes Substitute "s|youtube.com/favicon.ico|youtube.com/nfavicon.ico|in"

Original post blogged on b2evolution.