One of our customers runs a system that has a shopping cart system and they like it when a customer upgrades their site to include full store functionality. This of course means an SSL certificate. And traditionally, this would mean an additional IP address that would need to added to the server to support the new certificate.

Entering wider spread usage is what is becoming known as the UCC (Unified Communications Certificate), which is just a fancy name for a regular X509 v3 certificate that utilizes the Subject Alternate Name extension. This extension allows the certificate creator to embed multiple alternate names that are cryptographically tied to the primary key that defines the certificate.

What this means in practical terms is that you could purchase a certificate whose primary name is www.mydomain.com and with the same certificate and IP address, support multiple variations of that domain name, such as secure.mydomain.com or www.mydomain.net, www.mydomain.org, etc… This is different than a wildcard certificate that is tied to a specific domain name and can be used on any third level host name as desired: *.mydomain.com.

Since many entities that have a web presence tend to pick up the .net/.biz/.org variations on their .com domain name, this type of certificate means that those additional names can be secured with the same certificate/IP address. This means simpler configuration and not having to burn an IP address for every single name variation.

I’ve tested GoDaddy’s version of this certificate that gives you a 5 name cert for $60/year on plain jane Apache under 10.4 client and it works without issue. I have two different vhosts with different ServerName directives and the SSL config under both simply use the same SSL

Example. Assume I have a cert that I have based on mydomain.com as the primary name and has the following names embedded in as Subject Alternate Name extensions:

1. www.mydomain.com
2. store.mydomain.com
3. www.mydomain.net
4. mydomain.net
5. admin.mydomain.net

Also assume that I have two different facets of my web application. The public facing side that is served by the .com and the admin/extranet that is served under the .net variation. My Apache config would look like so:


Listen 443
NameVirtualHost *:443

<VirtualHost *:443>
ServerName www.mydomain.com
ServerAdmin support@mydomain.com
DocumentRoot “/www/mydomain-com/”
<IfModule mod_ssl.c>
SSLEngine On
SSLCertificateFile “/etc/httpd/ssl/mydomain-com.crt”
SSLCertificateKeyFile “/etc/httpd/ssl/mydomain-com.key”
SSLCertificateChainFile “/etc/httpd/ssl/gd_intermediate_bundle.crt”
</IfModule>
ServerAlias mydomain.com store.mydomain.com
</VirtualHost>

<VirtualHost *:443>
ServerName www.mydomain.net
ServerAdmin support@mydomain.net
DocumentRoot “/www/mydomain-net/”
<IfModule mod_ssl.c>
SSLEngine On
SSLCertificateFile “/etc/httpd/ssl/mydomain-com.crt”
SSLCertificateKeyFile “/etc/httpd/ssl/mydomain-com.key”
SSLCertificateChainFile “/etc/httpd/ssl/gd_intermediate_bundle.crt”
</IfModule>
ServerAlias mydomain.net admin.mydomain.net
</VirtualHost>
notice the certificate files are the same for both vhosts and there is no distinguishing between IP addresses on the VirtualHost directive. Nice, clean, simple and it Just Works.

I’ve tested the certificate in the following browsers and none of them complain at all:

IE 6, FF2, Camino 1.5, Safari 2/3, Opera 8.5

X.509 v3 has been around at least since 2002 so it should be well supported.

Now, OS X Server should work exactly the same way as the underlying Apache system pieces are the same. The only issue comes into play with the way that ServerMgr handles storing certificates, their keys and passphrases and how Apache integrates all of these items.

Using the Server Admin app, you will not be able to use one of these certificates to secure two different Hosts that you enter as the host name in Apache is used by the “getsslpassphrase” binary to locate the certificate, private key, and password for the host in question to start SSL.

Since the primary name of the certificate is NOT the name of this secondary vhost, the loading process will fail. Any usage of this type of certificate will require you to manually create whatever non-primary VirtualHosts that would be setup to take advantage of these additional names secure by the “UCC” cert.

In order to get these certificates to load you will need to remove the passphrase from the key file so that Apache doesn’t call the getpassphrase and then fail.

the basic command for doing this is:
openssl rsa -in mydomain.key -out mydomain.key.open

For those who are use to working with OS X Server and doing something a bit out of the ordinary, this should not be surprising.

More SSL Certificate vendors are starting to offer this type of certificate, but I like the extra feature that the folks at DigiCert include with ALL their certificates: unlimited usage on any number of servers.

The DigiCert products are more expensive than the ones at GoDaddy, but theirs are single root certificates and they also go through additional layers of validation more than the simple “can you get an email at the domain” verification that GoDaddy utilizes.

Posted by Brian Blood as OS X Server, Servers, Web App Development at 5:56 PM CST

No Comments »

If you are unfamiliar with the basics of how email messages are sent and what happens with bounces, please read the previous article.

This article explains ONE way of dealing with bounces. It has its pros and its cons and does not account for ALL instances of bounces, but it does deal with the basics of implementing bounce handling and can be used as the foundation of a more sophisticated system.

The primary logic in this system is the ability to control the SMTP Envelope FROM address. We want to construct this so that when a message is returned, it will have encoded in it information that will tell us exactly who the message was originally sent to. The drawback to this method is that if we had originally a single message that was being blasted to 1000 recipients, we now have to create 1000 messages each with it’s own customized/encoded FROM address. (there can be only one FROM)

Once we can control the Envelope FROM, we need a domain for the bounces to be returned to. Whereas the messages may have been originally FROM list@mycompany.com, we want bounces to be returned to a special host name. This way we can segregate bounce handling to a different system (if so desired.) With that in mind the FROM address will be constructed like so: encodedrecipaddr@bounces.mycompany.com. Don’t forget to setup an MX record for this host name (which must point to an A record, CNAMEs or bare IPs are not allowed as MX data)

So, how do we encode the local part of the FROM address? It’s really up to you, but pick one way and stick with it. Our solution uses the following:

sentto-brian=networkjack.info@bounces.mycompany.com

You could get fancy like so:

sentto-2e64665495eab1fa4c276f73a610e054@bounces.mycompany.com

where 2e64665495eab1fa4c276f73a610e054 is an MD5 hash of the original email address.

Whatever method chosen, it’s necessary to track that particular encoding somehow as we will see it as the recipient on any possible bounces.
Here is the SQL table we used:

CREATE TABLE EmailAddressTracker (
EmailAddress varchar(255) NOT NULL,
EncodedFROM varchar(255) NOT NULL,
IgnoreBounces tinyint(1) unsigned NOT NULL default '0',
MsgCount int(10) unsigned NOT NULL default '0',
FirstEmail datetime NOT NULL,
LastEmail datetime NOT NULL,
FirstBounce datetime NOT NULL,
LastBounce datetime NOT NULL,
LastBounce2 datetime NOT NULL,
LastBounce3 datetime NOT NULL,
BounceCount smallint(5) unsigned NOT NULL default '0',
PRIMARY KEY (EmailAddress),
UNIQUE KEY EncodedFROM (EncodedFROM)
)

EncodedFROM holds the ENTIRE local part.

In the function that is ultimately responsible for sending the email out, we lookup/maintain entries in this table. This would be the place to apply policy and either let the message actually be sent or disable the email address somehow or ignore any policy if the IgnoreBounces flag were enabled for this particular email address.

---

If a message ultimately is rejected, we have to have some way of accessing this table. This is where Postfix and PHP come into play.We could simply have all messages for that domain fall into a mailbox which is accessed and read and parse the payload for undeliverable recipients, but we want direct access to the Envelope information. We could create a two tiered system that does do parsing as a fallback, but for now let’s keep it simple.

We are using Postfix on the server that is responsible for handling bounces. Two main additions to the postfix configuration are necessary.

1. add a transport to the master.cf file:
   mybh unix - n n - 10 pipe
   user=mailadmin argv=/usr/local/bouncehandler/mybh.php $sender $recipient
   This defines for postfix a transport that is of the pipe variety. Postfix will pipe any bounces we tell it to, to the executable script in question with the given parameters.
2. add a domain entry to the transport map so that messages that come in for our bounces.mycompany.com domain are sent to the newly defined transport:
   bounces.mycompany.com mybh:
   this can be a file called transport.map in /etc/postfix.
   don’t forget to the call postmap on the file so that it becomes a map hash file for fast access by postfix.

Once postfix is ready, the script defined can then do pretty much anything we want it to do.

Here is the relevant section of the PHP shell script that does the decoding and updating of the table.


#! /usr/bin/php -q
$sender = trim($argv[1]); // should be EMPTY
$recipient = trim($argv[2]);

$bounceProcd = FALSE;

$conn = ConnectToDB();
if (FALSE !== $conn)
{
list($encodedFrom, $bhDomain) = explode(’@', $recipient, 2);
//sentto-brian=networkjack.info@bounces.mycompany.com
$encodedFromSQL = mysql_real_escape_string($encodedFrom, $conn);
$query = “UPDATE EmailAddressTracker “.
“SET FirstBounce = IF(FirstBounce=0, NOW(), FirstBounce), BounceCount=BounceCount+1, “.
“LastBounce3=LastBounce2, LastBounce2=LastBounce, LastBounce=NOW() “.
“WHERE EncodedFROM = ‘$encodedFromSQL’”;
// We keep track of the datetime of the last three bounces to allow time based policy
// to be applied

$qResult = mysql_query($query, $conn);
$bounceProcd = mysql_affected_rows($conn) > 0;

// We have to read the data that postfix is sending to us in stdin
// we don’t have to necessarily do anything with the data, but we could store it into a table for later
// processing if we couldn’t determine the original recipient or wanted to double check our results

$dataLen = IgnoreMessageData();
}

// if we couldn’t connect to the db or there was not a record in the table that matched
// our clause for the specific encoded FROM, then exit back to postfix with a
// Temporary Failure. This will cause postfix to queue up the bounce
// message for later processing
$exitStatus = (TRUE == $bounceProcd) ? 0 : 75;
// 75 = EX_TEMPFAIL per sysexits

exit($exitStatus+0);

function IgnoreMessageData()
{
$msgLen = 0;
$fd = fopen(’php://stdin’, ‘r’);
while (FALSE === feof($fd))
{
$dunsel = fread($fd, 1024);
$msgLen += strlen($dunsel);
}
fclose($fd);
return $msgLen;
}
return;
?>

Notice that this script does NOT apply policy. It merely is there for statistical tracking and that is all it should do.

Policy of whether to allow any future messages to be sent to the user are applied in the Sending function, since that is closer to where the emails are actually generated. The bounce handling system has it’s one job and can do it well without complications.

So there it is. A simple and effective way of catching bounces for your web application.
My favorite part of this solution is the extremely minimal configuration required inside postfix.

Happy bounce tracking.

Posted by Brian Blood as Mail Server, Servers, Web App Development at 9:07 PM CST

No Comments »

Email.

As much as we depend on it, it was never designed to be a 100% reliable communications medium. And with the rise of spam over the past 10 years, it has become a blessing and a curse to System Admins the world over. We continually are balancing on that line of “How come I never got that email?” vs “Why do I get so much spam?”

So, when your client asks you to build and manage a mailing list system, you cringe as you KNOW that sometime, somewhere down the line that these thousands of messages being sent out WILL cause you a headache.

Companies and service providers tend to use a mix of internal and external rules, blacklists, whitelists and other automated policy to achieve a reduction in hearing either of those two questions above. (We love you users, but not hearing from you is the best praise)

These systems tend to clash with each other when thrown into the real world. We don’t want YOUR spam, but you had better accept messages from MY customers mailing list.

In terms of infrastructure, the best way to stay off the radar of other systems as a possible source of spam is to make sure you have good reverse DNS, proper and resolvable HELO responses and that you adhere to RFCs in the way your MTA behaves.

In terms of the actual email you send and the entire life-cycle of those messages, the best way to build and maintain a good reputation is not to send email to recipients that don’t exist. Yahoo is one of those providers that will ding you hard and shut down incoming mail from you if you send too many messages to unknown or disabled recipients. Two of our clients learned the hard way when their older systems for sending email did not include a method for handling bounces.

What they did have in their favor was a bottleneck function for sending email. Any email sent by the system was sent by this function and not directly using the built-in PHP mail() function. This gave us a place in the code to alter how the email is delivered. We could then make sure that bounces would come back to us in a way that we could easily detect the original recipient. Mailing list software that does automated bounce handling (like mailman) does this kind of thing all the time.

Quick overview of how email is sent.
You have what is known (in SMTP parlance) as the envelope and the payload. This is very analogous to sending a letter through the postal mail. You have a letter (the payload) which could be your letterhead, it may have a date and a To: and From: and Regarding:, etc… You pop that into an envelope (the envelope) and address it with who the letter is to be delivered to and what the return address is for if the letter cannot be delivered. Your message could be delivered to someone who is not actually the person listen in the headers of your actual letter and the return address could also be different from the From: portion of your letter as well. You could send a Blind Carbon Copy of the letter to a third party who is unnamed in the letter by sending another copy with their delivery address on the envelope.

So, we’ve established that the information on the outside of the envelope doesn’t necessarily have to have any relation to those named on the letter inside the envelope. Since it is your email program that reads the information in the payload and never sees the information on the “envelope”, this gives us tremendous flexibility in how we send email messages with customized envelopes that aid in our bounce detection.

What happens when an email bounces? A new message is created with special parameters.
Who gets the bounce message? The envelope recipient of a bounce is exactly what was defined as the envelope sender of the original message.
What gets bounced? That depends. There are no strictly adhered to standards as to what a bounce message looks like. What is in the payload could take a hundred different forms as mail server software vary as to what they place into the bounce message payload. Usually a Subject header with “Undeliverable” something or other.
What is the sender of a bounce message: BLANK. This prevents bounces from eternally being rebounced as there is no one to return it to (this is known as a double bounce)

Efficient delivery of email can send a message that was originally addressed to multiple people by only delivering a single digital copy of the message to a server (assuming the recipients are all hosted on the same end server.) However, with bounce messages, the address(es) the message did NOT make it to are NOT part of the only strictly adhered to portion of the Delivery cycle, the SMTP envelope. Parsing of the bounce payload is required with standard SMTP envelope usage. This is not exact and can fail as a bounce detection method.

What we need is to have some way of detecting the EXACT recipient that bounced. See the next article for one method of solving this problem.

Posted by Brian Blood as Mail Server, Servers, Web App Development at 9:06 PM CST

No Comments »

We are trying very hard to move all our systems to PHP 5. This means going through lots of old code and correcting some bad habits.

The biggest offender is the not quoting of references to keys in an associative array like so:

$Data[FirstName]

which should be:

$Data['FirstName']

so, I pulled out my favorite text munger, BBEdit and it’s excellent grep functionality and the ability to do searching over a directory. I ended up using this pattern:

\[([a-zA-Z]+[_a-zA-Z0-9]+)\]([^"'}])

This is looking for a left bracket, then any string that must start with an alpha character, then a right bracket. It’s also making sure there is NOT a quote or tick or right brace after that. The replacement pattern of:

['\1']\2

Now, this search picks up more than one would want, so it does take some effort to manually go through the results and do the replacement one by one. But I was able to take a medium to large code base and clean it up in about an hour.

Posted by Brian Blood as Text Munging, Web App Development at 5:12 PM CDT

No Comments »

A really good client of ours has been colocating with us since late 2003. They’ve grown their web application from running on a Xserve 1.0Ghz DP G4 to an Xserve 2.0Ghz DP G5, then moving their database off to a separate big hardware RAIDed Dell server.

They came to us about a year ago (May 2006) and said they were getting a big new client who wanted to run their entire site on their system and they were going to need a load balanced system with plenty of power and scalability. Earlier in the year (Feb 2006), Apple had introduced their second generation MacMini that now sported the new Intel Core Duo chips along with Gigabit Ethernet. At that time, we were also concerned about increased power usage in our cage, so we picked up an Intel Mac Mini 1.66Ghz Core Duo, had it upgraded to 2GB of RAM (the G4’s could only handle 1GB) and started to really put it through it’s paces.

It turned out to be a real winner.

• In terms of power consumption, no matter how hard I tried I could not make that Mini use more than 0.37A of power. I blasted that thing with multiple concurrent CPU and disk bound processes, getting really heavy loads and disk read/writes.
• In terms of CPU, when we ran a battery of tests to really try and emulate this customers environment which is a very complex PHP web application. It really shone and had tremendous performance, even under load.

The final configuration we ended up with was:

MacMini Intel 1.66Ghz Core Duo, 2GB RAM and we replaced the stock Seagate 80GB 5400rpm SATA 2.5″ notebook drives with the Hitachi E7K100 60GB 7200rpm SATA drive. These are the drives that IBM puts on it’s blade servers as they are rated for 24/7 usage.

Total Cost: ~$1,000 each. (we bought the Apple ram)

We worked with the client to help factor their web application so that it could be properly load balanced. Changes were necessary in the following areas:

• session storage
• code updates (simultaneous CVS updates)
• media upload handling (you can no longer assume you have the resources you did when you only had a single server)
• host name abstraction to keep the Apache conf files nice and clean.
• centralized logging of web hits/visits.

After all the hardware and software was ready, we setup the content rules for the load balancer and turned it on. It was very gratifying to see the Minis perform very well even under adverse load conditions. (The big client sends out large email newsletter runs that bring flash crowds to the site.)

One of the more interesting experiences we’ve had with this system was when we migrated their Xserve G5 in as web server #4 in the load balanced group. Mind you this is not a puny box. We even upgraded the drive system in it to a hardware RAID 5 based set. Since that time we have had to periodically adjust the weighting rules on the load balancer to give more and more priority to sending hits to the Intel Minis instead of the Xserve G5. We are now at a 3:3:3:1 ratio and the Xserve is finally at a lower overall load average than the minis.

Yes, you read that right: the Intel MacMini is somewhere between 2 and 3 times faster than a Xserve G5 in raw cpu performance.

And it uses one fifth the power. With a nice sliding rack tray, you can easily get 6 of them into a 2U space. (excuse the cabling mess)

---

We’ve also considered a different configuration whereby we set the Minis on their side and “stack” them horizontally. The Mini is right at 2 inches tall and a 6.5 inch square, so accounting for some space for air flow and cabling you could get 7, maybe 8 of them in a row, resulting in a 4U tall set. With the right mounting, you could get easily 2, maybe 3 of these rows on a sliding tray. You do have to account for the external power supply, but that separation actually works out as a major benefit as the cables could be run so that you have a single U of dedicated space for the power supplies and put some directional cooling air flow over them.

Result: With only 2 rows of Minis, you get:

• roughly the same CPU power as 28 Xserve G5s
• about the same power consumption as 5 Xserve G5s (8.4A vs 9A)
• 6-7 times less space (4-5U of Minis vs 28U)
• easily less than half the per unit cost ($1,000 vs ~$2-$3K)

---

The Intel Dual Xeon Xserve looks promising as well in terms of raw cpu performance, but I’ve seen reports that it suffers from the same high power consumption as any other Dual Xeon system does: ~ 3A. However, this is TEN TIMES the power consumption of a MacMini, so for a high density web farm, this is not a better solution. Better to utilize that Intel Xserve as a database server to take advantage of it’s greater RAM capacity (32GB), increased threading (dual dual-core) and 64-bit capability.

Related CPU performance anecdote: We have another client with a Compressor video encoding grid made up of Intel MacMinis and he found out (Apple also confirmed it) that he needed to remove the PowerMac G5 DP from that grid as it was the weakest link!

In summary, a MacMini based farm is a powerful solution for almost any web application. You get low cost, low power, the ease of use and security of a OS X based system. A very compelling formula. Our client is very happy and is looking to add 2 more MacMinis in the near future. We’ve built this type of system for another client and they are extremely happy with the performance of their web application, too. If your organization is interested in a MacMini web farm, please contact us for a quote.

Some additional links regarding MacMinis

• Installing Debian GNU/Linux on the Mac Mini go
• 123Macmini.com - A Mac Mini User Community go
• Mac Mini hacks Forum for the Apple Mac Mini go
• Squeezing 2 MacMinis into a 1U custom case go

I’ve posted a followup to this article.

Posted by Brian Blood as Content Networking, Servers, Web App Development at 9:54 AM CDT

14 Comments »

We support the Hypersites development team in handling all their colocation and load balancing systems and occasionally doing web application consulting for them to help make their site better, faster, stronger and more agile. The Hypersites Application Builder is truly a marvelous piece of software. You should give it a spin for your next web project.

One of the underlying parts of their architecture that we advised them on long ago was to utilize the compression based encoding that most browsers support to reduce the actual amount of traffic sent over the internet to deliver a page. Another item was to build out versions of the pages that their system created and store those in a caching system of some sort. We had considered using memcache, which is a great way of storing that transient data that most web apps end up creating/using, but they decided on a much simpler (KISS) database table.

In that table are stored 3 versions of a page’s html: plain html, gzip and compress

The team recently made a change in their code so that instead of grabbing all three columns of data from the cache table, then choosing which version of the data to use, they chose which column to select before making the query.

The result: In about 70% of the calls to the cache table, the query result dropped to 10% of it’s original size.

By making a simple change to the logic in their code, they accelerated their software (at least that portion of the code) by TEN FOLD, something which no amount of reasonably-priced hardware upgrades would have accomplished.
Very cool and a good lesson.

Posted by Brian Blood as Database, Web App Development at 11:55 AM CST

No Comments »