Knaddison.com

We recently were reviewing proposals from two vendors. One vendor claimed 100% uptime. Another vendor claimed 99.95% uptime. Our SLA to customers is below both of those numbers, but 100% feels better than 99.95% right? So we should go with 100% right?

My experience is that the uptime number in an SLA is purely for marketing purposes. Pure. Marketing. Purposes. If you read 100% and think the service will be online for 100% of the time? Shame on you.

The really important thing is the detail behind the SLA. Here are a few tricks I've seen that make a 99.999% SLA roughly worth nothing.

• What are the exclusions? Most service providers are hosted somewhere (Amazon? Physical space?) that has it's own uptime guarantee. If that provider goes down is your SLA still in effect? Many SLAs exclude acts of nature like a hurricane that can take down a single provider.
• What do you get when the number is broken? Some contracts give you a credit. Some give you cash. Some give you a credit that is worth your monthly cost multiplied by the percent of time they were offline. Is that worth much to you?
• Do you get more if the outage is persistent? If a service dies for an hour that's a problem. If it dies for a day that is horrible. I want to be compensated more if the outage is prolonged.
• Whose monitoring counts? What kind of monitoring? I've had times where my monitoring (Pingdom) showed a site was offline for hours, but internal monitoring showed it was fine. I got no credits.
• What counts as "down" - if the service is online but taking 10 times longer than normal to process requests, is that OK? What if the service is online but network connectivity is degraded?
• How are periods of downtime calculated? An SLA I read only counted a full hour of continuous downtime as real downtime. Many outages are 10 minutes here, 20 minutes there. I want to be compensated for those as well.

Below is a ladder of feedback, ranked by usefulness in ascending order:

Levels of useful feedback:

1. Silence (i.e. not giving feedback)
2. X is bad.
3. X is bad because Y
4. ...instead I suggest Z
5. ...instead I suggest Z because Q
6. ...instead I suggest Z because Q. I'm happy to help with that.
7. ...instead I suggest Z because Q. I've already done some (or all) of the work.

Earning bonus points

Regardless of which level you're on, you can get bonus points by following some simple tips:

OK, so it's not really "new." It's a little over a year old, but the Drupal community on Gittip just recently got over 150 people which is the threshold where Gittip starts displaying members of the community.

So, congratulations to the Drupal Community! (and to Gittip).

Why is Gittip a useful tool for the Drupal community?

I think a lot of people want to give a little support (via money) to the people who work on Drupal but there is a lot of friction in the way of giving money. Does the person use Paypal? What is their PayPal email? What if you only want to give someone $10? The friction of that whole transaction far outweighs the $10 gift.

There's also a mismatch in the action: most payment systems like a check or PayPal are used one-time (again, because of the friction) but the benefit from a contribution and the desire to pay back that benefit live on for as long as you have a Drupal site. A lot of these topics are discussed in an old Lullabot Podcast where they point out that if every active user of Views gave Earl a few dollars for their use of he'd have a bit over $2 million.

My perspective is that it hasn't been easy enough for people to give that money and the friction is holding them back. Gittip solves a lot of these friction problems and the timing problem by making it easy to do small recurring payments to anyone on github or twitter.

One example that Dries requested: let's help AlexPott extend his "unemployment" and let him focus his genius on Drupal 8 core development!

What does the evolution of our use of Gittip look like?

Among the people who have joined the Drupal community on Gittip:

I recently had to setup OpenSWAN on Ubuntu to be part of a site-to-site VPN with a Cisco ASA 5520. There are a few resources I used to get me there. It was hard to find these resources so I'm keeping track of them for myself and in the hopes it helps someone else.

• this amazing page, about the same thing on ec2 vpc
• man ipsec
• configuring openswan ipsec server - great advice including some "gotchas" and troubleshooting ideas
• linuxjournal backgrounder on ipsec and vpns
• openswan installation and configuration tutorial
• A nice chart about cidr notation in ip addresses
• A gist about setting up openswan site-to-site on ec2
• A serverfault article about two people doing this behind some routers

My requirements were:

• local ike peer IP address: 89.76.54.321
• remote ike peer IP address: 123.45.67.89

• remote: also want all addresses in 123.45.0/24 to be addressable

• Authentication: pre shared key

• Encryption Scheme IKE
• Diffie Hellman Group: Group 2
• Encryption Algorithm: AES-256
• Hashing Algorithm: SHA1
• IKE Negotiation Mode: Main mode

• Lifetime (for renegotation): 480 minutes

• Phase 2 Encapsulation: ESP

• Phase 2 Encryption Algirithm: AES-256
• Phase 2 Hashing Algorithm: SHA1
• Perfect Forward Secrecy: No PFS
• Lifetime (for renegotiation): 480m

And here is roughly what my /etc/ipsec.d/connection.conf looks like:


conn i2c

The Discover It card launched late in 2012 (I wrote about it earlier).

When it first came out there was a heavy promotion of the card via multiple channels. They had tv videos and articles were written about it

• DailyFinance.com - Discover launches "game changing" it card
• NerdWallet - Discover It Card Key to Cashback Glory - compares it to US Bank's Cash+ card and the Chase Freedom card and feels that it's competitive with both of those cards...except that Discover's network isn't nearly as broad as the Mastercard/Visa network.

One of the most interesting things to me about the card is the design on the front of the card:

It's so basic and they moved the numbers/expiration etc. to the back of the card. Here's a video showing an unboxing of the Discover it card:

You can see at 4 minutes into the video as he shows the card the front is just plain and simple. A very clean design!

Here were the items he described during unboxing the card:

• No annual fee
• No late fee (only affects credit cards)
• No foreign transaction fee
• Paying late won't increase APR
• 1% cashback on most purchases, 5% rewards program for certain purchases
• Talked to a real person within 3 minutes of calling the company

Today I needed to embed (iframe) a web page into facebook. Pretty simple idea, really - doing so should help improve conversion rates for visitors who are landing from Facebook. And, of course I want to do it as simply as possible so we can test the idea before investing more time into fancier features this might have (a facebook-like theme, facebookconnect to pre-fill user data, etc.)

So...I did a ton of searches for how to create embed a page in a very simple way. I don't want to use an SDK. I don't want to have any OAUTH or interactions. Just show my page inside the facebook header and sidebar! But...how to do it.

Facebook Static HTML Iframe App

Well, several tutorials and videos recommended using a third party app that would insert my iframe inside of the Facebook page.

This is indeed a very popular path to take. There are dozens of apps in use by tens of millions of people each month. WAT?

Of course, Facebook Canvas apps are just iframes...so...why do I need an APP to iframe my iframe? And how safe is your data when a 3rd party iframe is around your site? No, this solution simply will not do.

Make your own super simple Facebook App

Here's what you want to do.

1. Go to Facebook Apps site. You might need to agree to some terms of service or something.
2. Click "Create New App"
3. Fill in the basic info - skip hosting.
4. Fill in the "Basic Info" section. If you are unsure, leave it blank or read the help blurb. All you really need is a Display Name and Contact Email.
5. Check the green box for "App on Facebook"
6. Input your site URL for the Canvas URL and Secure Canvas URL. On October 1, 2013 all apps will be required to have https.

I recently wrote about setting up Jenkins. My next step was making it do something useful to help our team become more efficient. In most any team it's likely that you'll get some folks for whom "just use drush sql-sync" is not a reasonble solution.

My goal: get a database backup into dropbox on a regular basis and make sure no sensitive customer data is in that backup.

Make a Database backup of the live site

We're running jenkins on a non-production server (for a variety of reasons). So, we get a backup of the live database into a temporary scratch database using the drush aliases feature. That process sanitizes it a bit using the sql-sanitize feature of drush. Then we dump out that database.

1. Start with an up to date checkout of your live site's Drupal code
2. Use the multisite feature and create a sites/example.prod/settings.php where the $databases array has a set of read-only credentials to the production database
3. A second "site" at sites/example.scratch/settings.php
4. Setup a Drush alias that points to those two sites inside the Drupal - be sure to use the 'uri' element so that drush knows which set of credentials to use inside the sites/ folder:
   
$aliases['example.prod'] = array(
'root' => '/var/lib/jenkins/example_scripts/example_com_checkout_for_drush/',
'uri' => 'example.backup',
);
$aliases['example.scratch'] = array(
'root' => '/var/lib/jenkins/example_scripts/example_com_checkout_for_drush/',
'uri' => 'example.scratch',
);

5. The example.scratch credentials should point to a "scratch" database that is used just for these purposes.
6. Finally a line in the Jenkins job to copy the database from the live site to the backup.
   drush sql-sync @sitename.prod @sitename.backup