I’ve been noticing some wonkiness with the admin area of our WordPress blog at CheatCodes.com EXTRA!. Through some experimentation, I noticed that all of the issues went away if I put CloudFlare into Development Mode. This, however, isn’t a long-term fix, so I decided to create a CloudFlare Page Rule for the /wp-admin/ directory. To do this, just login to CloudFlare and create a Page Rule that covers:

http://example.com/wp-admin/*

Then turn off EVERYTHING: apps, cache, security, always on, etc.

This fixed most of my problem, but I noticed that I still had issues when logging in or out of the WordPress admin area, and I couldn’t figure out why.

Then it hit me – the login page for the WordPress admin area isn’t in the WordPress admin area, and therefore wasn’t covered by my CloudFlare Page Rule! Instead, the WordPress login page is here:

http://example.com/wp-login.php

So I added a second page rule that covered:

http://example.com/wp-login.php*

The asterisk is necessary to cover URLs such as:

http://example.com/wp-login.php?loggedout=true

Now the login/logout hangs and other strange behavior are gone, my WordPress admin area works great for all our authors, and I’m still benefitting from CloudFlare protection and optimization across the rest of the blog.

So if you’re noticing strangeness between WordPress and CloudFlare, create a Page Rule!

Related posts:

1. Fixing Postfix “certificate verification failed for gmail untrusted issuer” Error Message
2. Installing my 2nd ecobee and Using Group Admin Features
3. How to Install APC (Alternative PHP Cache) on CentOS 5.6

Here are the steps I take to adjust the clock on my Panasonic Hybrid phone system:

1. Move the Memory button on the back of the phone from SET to PROGRAM. PITS-PGM NO? -> will appear on the LCD screen.
2. Type *# followed by my 4-digit password to enter programming mode. SYS-PGM NO? -> will appear on the LCD screen.
3. Type 000. Day/Time Set will appear on the LCD screen.
4. Hit SP-PHONE key. The screen displays the current date.
5. Hit the FORWARD button to move forward through the date and to the time.
6. When the hour is flashing, enter the correct hour. Hit FORWARD to move to the next item and adjust minutes, if necessary.
7. To save the adjusted time, hit the AUTO DIAL / STORE button. You’ll hear a long beep to confirm.
8. Move the Memory button on the back of the phone from PROGRAM to SET.

Your Panasonic Hybrid phone system now has the correct time!

Related posts:

1. How to Disable Phone Options on a DSC Alarm Panel when Converting to Envisalink Internet Alarm Monitoring
2. Things I Do First on a Vanilla Linux System
3. ecobee Mothership Won’t Let My Thermostat Phone Home

Envisalink, the developers of the 2DS, now offer EnvisAlarm: an alarm monitoring service that integrates wonderfully with their free ESP service, which allows users to log in from anywhere to view and control their alarm system details.

However, since my DSC panels were still set up to transmit alarm information via the telephone, I had to disable a few options on my DSC panels that were no longer needed now that I’m monitoring over the Internet with my 2DS. If you’re a new Envisalink monitoring customer who previously used telephone monitoring, you’ll want to following these same steps that I took to disable the phone-related options.

These instructions assume you’re using the factory-default Installer Code of 5555 (which you probably shouldn’t). Insert your own installer code in place of the 5555.

• To disable the phone line: *8 5555 015 7 ##
• To turn off test transmissions (which are no longer needed since Envisalink monitors network connection from them to your 2DS continuously): *8 5555 371 9999 ##
• To turn off the phone dialer: *8 5555 380 1 ##

I relied on the following online docs to help me remember the correct menu options in the DSC panel:

http://www.myalarm.com/manuals_prog/832p.pdf

http://www.mainelectronics.com/pdf/HowToProgramDSCsystem.pdf

So far, I’ve been very happy with the price and service of Envisalink’s monitoring.

Related posts:

1. A Tale of Two Alarm Monitoring Cancellation Requests: Fire Protection Inc (Seattle) and Mountain West Security (Provo)
2. ecobee Mothership Won’t Let My Thermostat Phone Home
3. Set up VNC from Windows to Fedora 12 Over the Internet

http://www.linuxjournal.com/content/rebooting-magic-way

Was able to reboot a CentOS box with what appears to be a failing (failed?) file system. We had backups, but we’re evacuating the server now.

Related posts:

1. Fixing Postfix “certificate verification failed for gmail untrusted issuer” Error Message
2. How to set up two NICs on different subnets with static routes and separate default gateways that remain after a reboot
3. How to Back Up a Linux Server to Amazon S3 with Duplicity and AutoMySQLBackup

Even if you’re the most contentious hax0r who always backs up your data, if your backups are stored in the same physical location as the source data, then your data is still ”waiting to be lost” in the event of a fire, flood, theft, or other disaster. By combining Amazon’s low-priced S3 (Simple Storage Solution) Cloud-based storage solution with some excellent some open source backup tools, you can now be more prepared than ever without spending a fortune.

This how-to demonstrates how I combined the following tools to automate my off-site backups:

• Amazon S3: cheap, secure, redundant, off-site storage service
• AutoMySQLBackup: free software to create backups of MySQL databases
• Duplicity: free software that does smart backups to remote locations
• GPG: allows encryption and signing of data for privacy
• dt-s3-backup.sh: a slick shell script that ties all these tools together

Step 1: Set up your Amazon S3 Storage Bucket

I won’t walk through all the steps to do this, as Amazon makes it easy. Just sign up for their S3 service (you only pay for what you use), sign in, find the Security Credentials page and take note of your Access Key ID and your Secret Access Key. You’ll need them later. You should also set up an S3 Bucket to store your backups. Write down the name of your bucket for use in a later step.

Step 2: Download AutoMySQLBackup (optional)

If you don’t have any MySQL databases to back up, or you have your own preferred method of backup in your databases, you can skip this step. AutoMySQLBackup is a free utility that quickly and easily create dumps of your MySQL data – which we’ll back up to Amazon S3 in a later step.

Download AutoMySQLBackup from SourceForge and run the simple install.sh script to set it up. I followed this excellent blog post to help me get AutoMySQLBackup configured and working. I had to make a few minor changes because I’m using a more current version of AutoMySQLBackup and some of the variable names in the config file were different, but it’s pretty straightforward. Once you’ve got it backing up your databases, you’re ready to move on.

Step 3: Download and Install Duplicity

Duplicity is the program that does most of the heavy lifting in this situation. It manages the actual file backup (full or incremental), compression, encryption, and the file transfer to any number of off-site storage locations. Lots of documentation is available online, in case your needs differ from the ones explained here. As always, Google is your friend.

To install Duplicity if you’re running Fedora, RHEL, or CentOS, it’s as simple as doing:

yum install duplicity

For Ubuntu or Debian users, do:

apt-get duplicity

If you’re running some other flavor of Linux, refer to the Duplicity website for help installing.

Step 4: Create a GPG Key for Backups

Because you’re going to be transferring your precious data over the Internet, and storing it in an off-site location that shouldn’t be, but still technically could be, accessed by snooping Amazon employees or hackers, it’s best to encrypt your data before sending it… “to the CLOUD!” Seriously, those commercials are so annoying.

Even if you already have a GPG key, I recommend creating a separate one just for backups (which we’ll also store in a secure location later so you’re never stuck without the ability to decrypt your data later). Do:

gpg --gen-key

You can accept all the defaults, but make sure you use a passphrase when creating this key, since Duplicity will require it. After you’ve answered all the questions, the output should look something like this:

We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
.++++++++++++++++++++..+++++++++++++++++++++++++++++++++++++++++++++++++++++++.+++++
.+++++..+++++.+++++++++++++++++++++++++++++++++++++++++++++.....>.++++++++++................................+++++
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
+++++.++++++++++..++++++++++...++++++++++...+++++.+++++..+++++.+++++..+++++++++++++++.+++
++++++++++++..+++++++++++++++..++++++++++..+++++++++++++++++++++++++...+++++..+++++>+++
+++++++>.+++++>+++++......................+++++^^^
gpg: key 1F6C9247 marked as ultimately trusted
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   2  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 2u
pub   2048R/1F6C9247 2011-11-05
      Key fingerprint = FC81 D8E3 8090 EEE3 1D98  E000 045C D80E 1F6C 9247
uid                  Backup Key <backup@example.com>
sub   2048R/12D6A5B0 2011-11-05

Take note of your key’s public GPG Key ID, which is listed on the line where it says “key xxxxxxxx marked as ultimately trusted” (in this example, it’s 1F6C9247). You can also find your GPG key’s public ID with:

gpg --list-keys

which will spit out something like:

pub   2048R/1F6C9247 2011-11-05
uid                  Backup Key <backup@example.com>
sub   2048R/12D6A5B0 2011-11-05

You’ll see your key’s ID on the top row after the slash. Write it down (don’t worry, it’s not a security risk like a password) to refer to in the next step.

Step 5: Download and Configure dt-s3-backup Script

While trying to make all the aforementioned tools work together, a stumped across a very cool script that already did it for me. This blog post explains the script, and the script itself is hosted on GitHub.

Download the script to your server (I put mine in /usr/local/bin) and then open it up in an editor. You’ll need to put the following in the appropriate locations inside the script:

• AWS_ACCESS_KEY_ID: Your Amazon Access Key (duh!)
• AWS_SECRET_ACCESS_KEY: Your Amazon Secret Access Key (double duh!)
• GPG_KEY: Your GPG Key ID of the key you created in the previous step
• ROOT: I changed this to just “/” so that I could back up anything on the system. You’ll pick the exact directories you want in a bit.
• DEST: Since we’re backing up to Amazon S3, comment out the “file:” line, uncomment the “s3+http:” line, and put the name of the Amazon S3 bucket you created for backups in the first step. If your bucket name were “my.awesome.backups” then this line would be DEST=”s3+http://my.awesome.backups/”

Skip the INCLIST and EXCLIST options for now, and tinker with the STATIC_OPTIONS to your liking. These will simply be passed to Duplicity, so you can check the Duplicity docs for all the possilibities. I have mine set to STATIC_OPTIONS=”–full-if-older-than 4W” which means my backup (which I run daily) will do incremental backups unless it’s been 4 weeks, in which case it will do a full backup. I also kept the default CLEAN_UP_TYPE and CLEAN_UP_VARIABLE settings. Again, refer to the Duplicity docs for other options.

Finally, I also tinkered with the Logfile settings and Email Alert settings.

Step 6: Choose which directories to include and exclude

Use the INCLIST and EXCLIST sections of the dt-s3-backup.sh script to list which directories you want to include and exclude while doing your backups. Examples are shown in the script. Make sure that whatever directory you used to store your database backups with AutoMySQLBackup is included. If you want hidden directories excluded, be sure to include them. The following are my lists:

INCLIST=(  "/www/" \
           "/etc/" \
           "/home/" \
           "/root/" \
           "/usr/local/bin/" \
           "/usr/local/backups/db/" \
        )

 EXCLIST=(   "/www/logs" \
            "/etc/selinux" \
            "/home/*/Download/" \
            "/root/*/Download/" \
            "/home/*/.*/" \
            "/root/.*/" \
            "/home/*/logs" \
            "/home/*/Maildir" "/home/*/mail" "/root/Maildir" "/root/mail" \
        )

These settings work for me, but there’s no guarantee they will work for you. It’s your data, so you should completely understand what is and isn’t going to be backed up.

Step 7: Do a Test Run

To test things out, find the following line in the dt-s3-backup.sh script and uncomment it (remove the #):

#ECHO=$(which echo)

As explained in the comments, this will run the script in test mode, which will spits out the full Duplicity command and send it to the email address you set up in the Email Alert settings.

Save your edited version of the script and run it with:

dt-s3-backup.sh --backup

Because it’s in test mode, it should think for a bit and then email you some output, which includes the full command that will be passed to Duplicity. If everything looks good, comment the #ECHO line out again, and go for it:

dt-s3-backup.sh --backup

Depending on many factors (the amount of data you’re backing up, the speed of your system, the speed of your connection to Amazon S3, the phase of the moon), you’ll have to wait for a bit. My system takes about 5 minutes to run a full backup.

If something goes wrong, check all your edits, and check the links to the other blog posts I’ve included. I won’t be any help answering support questions in this thread, because I’m not the author of any of these applications.

Step 8: Check Your Files

Assuming your backup worked, you can ask Duplicity to list all the files in your backup with:

dt-s3-backup.sh --list-current-files | more

Keep in mind that these will count as a requests against your Amazon S3 allowance. You get a bunch of free ones, but managing your Amazon bill is completely your responsibility.

Other options for dt-s3-backup.sh are available in its README file. I recommend experimenting with them until you’re familiar with the ones you’ll need.

Step 9: Automate

Once everything is working as you want it, don’t forget to create cron jobs for AutoMySQLBackup and dt-s3-backup.sh, I dump my databases nightly, and I do an incremental backup with dt-s3-backup weekly. Use whatever settings work best for you.

Step 10: Provide Feedback

I always welcome your feedback, especially if you have suggestions for making the process in this article easier to do or understand. If you have a different backup method that works for you, please feel free to share it. Because I’m not the author of any of these utilities, however, I can’t provide support in using them. Check the links I’ve provided for support, or contact the application authors directly if you’re having trouble.

Good luck moving your data from “waiting to be lost” to “backed up.” I know I sleep better knowing I’m better prepared to deal with disaster!

Related posts:

1. How to set up uShare media server on Fedora / CentOS to stream video and pictures to Xbox 360 or PS3
2. How to Reboot with a Bash Input/Output Error
3. Installing OpenDKIM RPM via Yum with Postfix or Sendmail (for RHEL / CentOS / Fedora)

Here’s my favorite YouTube video on how to field strip one:

No related posts.

You can – thanks to StartSSL - the self-proclaimed “Swiss Army Knife of Digital Certificates & PKI.”

While the interface may not be as slick as other SSL providers (like GoDaddy or Network Solutions), what StartSSL lacks in design they make up for in value. You can actually get a 128/256-bit Encrypted Class 1 SSL/TLS + S.MIME certificate for free. Seriously, no strings attached.

Step 1: Sign up and Get Verified

The first step is to sign up at StartSSL and verify your personal identity via email, and also verify that you have admin authority for the domain. I noticed that Chrome won’t work properly with their authentication procedure, so you’ll need to use IE, Firefox, or Safari. I won’t go through all the verification steps here. Just follow the instructions on their website to get verified, and get to the Control Panel. Or, try their Express Lane option to get verified and receive a certificate in one step.

IMPORTANT: Make sure you choose the proper domain and subdomain name for your certificate when you come to that point. You can change your mind later, but you’ll have to pay $25 to do so. Just be sure you understand everything before you start clicking buttons…

Eventually, you’ll reach the Certificates Wizard. Select a Web Server SSL/TLS Certificate. Then press the Skip>> button, because you’ll want to create your own private key and certificate request on your server.

Step 2: Create Your Key and CSR

The next screen is where you submit your certificate request (CSR). But first, you’ll need to build your private key and the CSR itself. Make a directory to store all your SSL files with

mkdir -p /etc/ssl
cd /etc/ssl

Of course, you can choose any directory to store your SSL stuff, and you may already even have one. Use whatever directory you like. I personally like /etc/ssl because it’s easy to remember.

Inside your /etc/ssl directory, do:

openssl req -new -newkey rsa:2048 -nodes -keyout hostname.domain.key -out hostname.domain.csr

You can use any filename you want for the key and csr, but I like to include the subdomain and hostname of the mail server in mine, such as mail.example.key and mail.example.csr.

This command build both your private key and the CSR. Answer the questions (you don’t have to answer the optional ones), and be sure that when it requests the Common Name, use hostname and domain name of your server as you’ll be entering it in your email client (such as mail.example.com). If you make a mistake anywhere along the way, you can CTRL+C out of it, or just re-run the command to write a new key and CSR over the existing ones.

Once the command is finished, do an ls to see the two files you just created.

Your private key must be kept, well, private. So get into the habit of setting proper permissions for private keys right after you make them.

chmod 0640 hostname.domain.key

Step 3: Give your CSR to StartSSL and receive your certificate

Spit out the contents of your CSR with:

cat hostname.domain.csr

Then copy the entire contents of the file (including the:

-----BEGIN CERTIFICATE REQUEST-----

and

-----END CERTIFICATE REQUEST-----

lines, then paste it into the text area of the StartSSL CSR request page.

Hit the Continue>> button, and then select the specific subomain and domain you’ll use (such as mail.example.com or www.example.com) to access your server. For the free Class 1 certificate, you can include the domain and only one subdomain. This means the certificate will work for example.com and www.example.com, or example.com and mail.example.com.

If you want your certificate to work for two or more subdomains in addition to the primary domain, you’ll need to pay $59.99 to become Class 2 verified. But the good news is that you can then generate unlimited Class 2 certificates, which allow multiple and/or wildcard subdomains on your certificates. This is actually what I did, and it’s still a bargain.

After your request is processed,  the certificate back from StartSSL, copy the contents and paste them into a file in your /etc/ssl directory called hostname.domain.crt (using your hostname and domain name, of course).

At this point, it’s a good idea to download all three files (key, csr, and crt) and store them somewhere safe. I have a secure USB key that I keep for such a purpose. Your .key file is irreplaceable at this point. If you lose it or accidentally delete it, you’ll have to revoke your certificate, which will cost you $25.

Step 4: Download the StartSSL Bundle

Certificates are about trust, and so you’ll need to inform your server that you trust StartSSL. List of certificate authorities that your server can trust are stored in Certificate Bundles. Download StartSSL’s bundle with:

wget --no-check-certificate https://www.startssl.com/certs/ca-bundle.pem -O startssl-ca-bundle.pem

If you have a pre-existing certificate bundle file somewhere on your server (such as ca-bundle.crt or cacert.pem), you may want to copy it into your /etc/ssl directory:

cp /etc/pki/tls/certs/ca-bundle.crt /etc/ssl

Then you’ll need to combine the StartSSL ca-bundle with your existing bundle (this step just copies the StartSSL bundle to the new filename if you didn’t have an existing bundle):

cat startssl-ca-bundle.pem >> ca-bundle.crt

Now edit your Postfix main.cf file and put in the updated locations of your private key, certificate, and bundle:

smtpd_tls_key_file = /etc/ssl/mail.scuderia.key
smtpd_tls_cert_file = /etc/ssl/mail.scuderia.crt
smtpd_tls_CAfile = /etc/ssl/ca-bundle.crt
smtp_tls_CAfile = $smtpd_tls_CAfile

This article assumes that you’ve probably already got Postfix set up for SSL/TLS with a self-signed certificate, so all the main.cf settings in addition to the ones I’ve mentioned above for TLS should already be in place. This article won’t explain how to do that (but there are plenty of great articles out there to get that working). I will, however, show you what the SMTP TLS section of my main.cf file looks like, in case it’s any help:

# SMTP TLS
smtpd_tls_auth_only = no
smtp_use_tls = yes
smtpd_use_tls = yes
smtp_tls_note_starttls_offer = yes
smtpd_tls_key_file = /etc/ssl/mail.domain.key
smtpd_tls_cert_file = /etc/ssl/mail.domain.crt
smtpd_tls_CAfile = /etc/ssl/cacert.pem
smtp_tls_CAfile = $smtpd_tls_CAfile
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom

Once you’ve got your settings right, restart Postfix with:

service postfix restart

Now you’re connecting to your outgoing mail server with a third-party signed certificate!

Related posts:

1. Fixing Postfix “certificate verification failed for gmail untrusted issuer” Error Message
2. Renewing a Self-Signed SSL Certificate on Fedora/CentOS
3. How to get DKIM and DomainKeys working with Postfix on RHEL 5 / CentOS 5 using OpenDKIM and dk-milter

(Big thanks to Murray K. and Todd L. for hand-holding me through this )

For my projects, I use a watered down version of the branching model presented in this article, so that I always have two branches:

• Master: which always represents a release version of a project
• Develop: which represents the progress I’m making toward the next release version

Therefore, for reasons that should be obvious, I always request that collaborators make pull requests only on the Develop branch.

Making changes to Develop

To check out my Develop branch, I do:

git checkout develop

I make whatever changes I want, and then make sure the files I want to include in commits are added with:

git add <filename>

(I only need to do this once per file.)

When I’m ready to commit at least one changed file, I do:

git commit -a

and then add notes about the changes I made.

Then I do:

git push

to push my local version of the Develop repo to GitHub.

Merging Develop into Master

Technically, with the branching model I’m using, I should never commit changes directly to Master. All updates should be put into Develop, and then once Develop represents a version that I think is ready to be released, and all the changes I want are committed to Develop and pushed, I merge Develop into Master with:

git checkout master
git merge develop
git push

Checkout Out Someone Else’s Repo and Submitting A Diff

When checking out someone else’s repo and submitting a diff to them, I do the following:

Do a git checkout of their develop branch with (usually):

git checkout develop
git pull

Then I create my own temporary branch from that with:

git checkout -b develop_branchname

Next, I edit or copy my changes into the branch and commit them with:

git commit -a

If I don’t have write/push access to the repo, I need to create a patch to send to the author with:

git format-patch develop..develop_branchname

After sending the diff, I can delete my temporary branch with:

git checkout develop
git branch -D develop_branchname

Further Reading

• GitHub Cheat Sheet

Related posts:

1. My Favorite ImageMagick Commands
2. “No controllers found” fix: set up Dell OMSA 6.3 32-bit on RHEL / CentOS 5.5 64-bit
3. “No controllers found” fix: set up Dell OMSA 6.4 32-bit on RHEL / CentOS 5.5 64-bit

Until now, when I wanted to manually invalidate a single file, I had to fire up CloudBerry S3 Explorer and scroll through thousands of files to get to the one I wanted to invalidate. For automated on-the-fly batch sync and CloudFront invalidation, I still rely on the excellent s3cmd command-line tool.

I’m not a developer, but I can lightly hack my way around PHP code – especially when it’s as clean as Clay’s.  I took his excellent script one small step farther to allow invalidating a single file via HTTP (using your browser) by including the to-be-invalidated filename in a URL, with the ability to optionally pass the CloudFront Distribution ID via a separate variable in the URL (handy for those of us managing multiple distributions). I highly recommend making sure you place this file in a password protected area of your website.

So here’s my modified version of Clay’s PHP script providing a simple way to invalidate a single file on CloudFront using your browser:

<?php
/**
 * Super-simple AWS CloudFront Invalidation Script
 * Modified by Steve Jenkins <steve stevejenkins com> to invalidate a single file via URL.
 * 
 * Steps:
 * 1. Set your AWS Access Key
 * 2. Set your AWS Secret Key
 * 3. Set your CloudFront Distribution ID (or pass one via the URL with &dist)
 * 4. Put cf-invalidate.php in a web accessible and password protected directory
 * 5. Run it via: http://example.com/protected_dir/cf-invalidate.php?filename=FILENAME
 *    or http://example.com/cf-invalidate.php?filename=FILENAME&dist=DISTRIBUTION_ID
 * 
 * The author disclaims copyright to this source code.
 *
 * Details on what's happening here are in the CloudFront docs:
 * http://docs.amazonwebservices.com/AmazonCloudFront/latest/DeveloperGuide/Invalidation.html
 * 
 */

$onefile = $_GET['filename']; // You must include ?filename=FILENAME in your URL or this won't work

if (!isset($_GET['dist'])) {
        $distribution = 'DISTRIBUTION_ID'; // Your CloudFront Distribution ID, or pass one via &dist=
} else {
        $distribution = $_GET['dist'];
}

$access_key = 'AWS_ACCESS_KEY'; // Your AWS Access Key goes here
$secret_key = 'AWS_SECRET_KEY'; // Your AWS Secret Key goes here
$epoch = date('U');

$xml = <<<EOD
<InvalidationBatch>
    <Path>{$onefile}</Path>
    <CallerReference>{$distribution}{$epoch}</CallerReference>
</InvalidationBatch>
EOD;


/**
 * You probably don't need to change anything below here.
 */
$len = strlen($xml);
$date = gmdate('D, d M Y G:i:s T');
$sig = base64_encode(
    hash_hmac('sha1', $date, $secret_key, true)
);

$msg = "POST /2010-11-01/distribution/{$distribution}/invalidation HTTP/1.0\r\n";
$msg .= "Host: cloudfront.amazonaws.com\r\n";
$msg .= "Date: {$date}\r\n";
$msg .= "Content-Type: text/xml; charset=UTF-8\r\n";
$msg .= "Authorization: AWS {$access_key}:{$sig}\r\n";
$msg .= "Content-Length: {$len}\r\n\r\n";
$msg .= $xml;

$fp = fsockopen('ssl://cloudfront.amazonaws.com', 443, 
    $errno, $errstr, 30
);
if (!$fp) {
    die("Connection failed: {$errno} {$errstr}\n");
}
fwrite($fp, $msg);
$resp = '';
while(! feof($fp)) {
    $resp .= fgets($fp, 1024);
}
fclose($fp);
print '<pre>'.$resp.'</pre>'; // Make the output more readable in your browser

Related posts:

1. How to Back Up a Linux Server to Amazon S3 with Duplicity and AutoMySQLBackup
2. Renewing a Self-Signed SSL Certificate on Fedora/CentOS
3. How to Install APC (Alternative PHP Cache) on CentOS 5.6

#UseDNS yes

and changing it to:

UseDNS no

I believe the delays were being caused by a combination of IPv6 and DNS, but regardless of the cause, that was the fix.

Related posts:

1. Set up VNC on RHEL 5.5 / CentOS 5.5
2. Installing OpenDKIM RPM via Yum with Postfix or Sendmail (for RHEL / CentOS / Fedora)
3. Building Postfix 2.8 on RHEL5 / CentOS 5 from Source