Needless to say Uptrack allows us to keep our kernels patched with the newest kernel patches to maintain a solid, stable and secure environment.

So how does it work? Well in laymans terms when new patches come out they automagically make it into a “rebootless update” and then apply it (according to them a large majority of the updates can be created without any programmer intervention). This allows you to apply updates on-the-fly without the need of rebooting. There is of course a more technical explanation, but I’ll stick with automagically for now.

One of the cooler features of Uptrack is it allows you to auto-update your kernels – this essentially leaves any need for human intervention. Now we’re not too keen on that since having our machines become self-aware is scary (arghh) so we opt for another cool feature. They offer a little web application that’s very simple yet effective. It simply lists all of the machines with Uptrack installed and their current kernel version. It let’s you know if any kernels our out of date or if any had issues installing. You can even view the update history of a machine to see which patch has been applied and what it fixed.

One of the things that we were concerned about was what if we ever decide to move away from using Uptrack? Does Uptrack gracefully “detach” from the machine with any issues? The answer is simple yes. When you remove Uptrack it reverts back to the original kernel when installed (yes, this means you would need to upgrade to a new kernel per usual). Cool beans.

We’ll post any updates regarding our experience with Uptrack here, though I doubt there will be many. We’re happy knowing there will be less maintenance windows needed and we can rest assured our kernels are up-to-date.

Cheers!

I have no doubt the affiliate system has a part to play in this with the Frog Host plans being higher and it’s commission percentage being higher it’s smarter to push it to make money.  Now wait a second Frog Host has higher numbers?  Well this is because offering 50% on a $80 plan is less of a hit than doing say 50% on a $40 plan.  We can afford to pay out more with Frog Host since the plans are much more expensive and with the power of unlimited a lot of users cost a heck of a lot less than $80/yr.

That’s about all I have to talk about I just thought it was interesting looking at some recent Hawk Host cancellations and seeing reasons pointing to Frog Host with various explanations given.  It just shows you the power of unlimited heck even if you own multiple unlimited brands I’ve heard of a lot of them losing a customer with one brand and gaining them back on another.  So they’re no further ahead and still using the same company in the end.

I currently have a sort wrist from all the programming and working mega hours I’ve been doing lately.  Sitting there programming and next thing I know I haven’t got up in 4+ hours. That’s recipe for a sort wrist or even a sore elbow or shoulder depending on the day.  I lead by example though and I cannot opt for time off or rest I’m the leader of the team.  I’m like Kobe I’m not opting for rest or surgery when I can continue to play through the pain.

Cody in an attempt to fix his posture opted for a new way of sitting but it has resulted in a sore back.  In the long term this change will help him but for the short term it has created a nagging injury.  Following my lead he is playing through the pain realizing the team needs him for our playoff push (Frog Host).  He continues to receive treatment in order to play through this and we command him on his dedication to the team.

Brian has the most serious injury right now on staff.  He opted to grow a beard to improve his game but it has come at a cost.  His beard is now becoming problematic with that extra facial hair.  He has developed a problem of food in the beard which if left untreated could develop into something that could affect him long term.  He’s not going to give up his beard without a fight though and has opted for the time consuming work of cleaning it every day.  He’s inspiring everyone else the most with his resilience to play through such an injury.  Next time you run into him on chat or in a support ticket make sure to tell him you’re supporting the team.

We realize we’re a playoff team and this regular hosting season is just a tuneup for the serious stuff.  You need to still play though which means while grueling and sometimes painful we’re there every day putting the work to make Hawk Host a success.

So if you have not realized yet just a joke post : -) My wrist is a little sore from aggravating an existing injury from playing sports by working to much lately.  Cody really does have a sore back because he wants to improve his posture. Brian does indeed have a beard and look like a caveman although he doesn’t have problems with getting food in it.  I just thought it be fun to post about something totally random and with no helpful information.  I hope you enjoyed reading it : -)

I always make sure to SSH into the machines a sort of habit of mine from back when we had a few.  Thankfully with SecureCRT it’s just select a few folders and I’m logged into all the machines.  After doing my usual checks of everything else I heard a beep come from SecureCRT and the first thing that came to mind is oh no something must have broke.  I start checking the servers and I get to Pluto the machine that has never had anything really happen to it.  It’s has hard drives fail and be replaced without any down time and it’s never had any issues with any of it’s hardware.  About the only issue it ever had was when a UPS blew in the server room it was in knocking it off line as well as some of our other machines.  The error was about the memory and it claimed to be a fatal error of some kind.  I did not like the sound of it yet the machine was still functioning as it should so that meant I needed to google and use my resources available to me.

The first thing I do is ask Cody what the heck does the message mean?  While I’m waiting for him to respond back I load up google and search and I find out that usually it suggests the memory is on it’s way out.  Cody finally messages me back with make a ticket with SoftLayer they’ll know what the heck that means.  Just as google suggested SoftLayer quickly determined this almost always means the memory on the machine needs replaced to avoid a major headache later on.  This meant a maintenance window needed to be scheduled for the server.  As I mentioned early I was in my half asleep state so I paste Cody our options and he says 1-4 is good we should do it then.  Being the half asleep person that I am I updated our ticket with that time.  In the past we’d do it ASAP or schedule something out of the suggested window times as they tend to be bad for us.  A few hours later after I had already posted notice on our forums I had an oh crap moment of did I just really schedule a window for 1:00AM CDT to 4:00AM CDT window?  At this point I was awake so that’s how I noticed and I realized that there was no way out of this we had informed everyone necessary already.  Since I was the fool to schedule it I’d be the sucker to have a Friday night / Saturday morning maintenance window to deal with since someone had to be there in case something bad happened.

My day went on as normal doing some work then calling it a day.  I had pizza for dinner and watched some family guy then two and half men so the usual suspects while I eat then decide what I’m going to do tonight.  I realized there wasn’t a whole lot I could do but the maintenance window was hours away so I decided to watch a movie to at least pass some time.  The movie finished and I realized I was still a long ways away from the maintenance window starting and I thought to myself what in the world am I going to do.  I went back to watching tv and ended up watching that’s 70s show and south park two shows I never really watch except they were the only decent shows on.  The window was still a ways away and I pulled out the xbox 360 and figured the window starts soon I better not play any game I won’t want to give up on in a bit so I can be on the computer.  I played a few games of Geometry wars to pass the time and finally it was 1:00 AM CDT which meant the window may start.

Unfortunately for me the window is 3 hours long so it ended up where it had not actually started yet as the machine was not off line.  Cody a few days earlier linked me to a the daily wtf post that he thought was funny.  I only really read posts on the site while I was working in an office and got bored from time to time.  I spent about an hour and a half reading all the posts on the site in the past three months as I got that bored.  I also made sure to post classics like The Source Control Shingle on our twitter while I was bored.  I also made sure to send Cody an email about how I hate maintenance windows especially ones this late and of course linked him to a post on the daily wtf he might like NPR Is Reading My Email, Just Fix It!, & More Support Stories mentioning the just fix it one that reminded me of some of the support tickets we get from time to time.  So after the hour and a half I got notice the Pluto server was finally going off line and I thought to myself finally!  I jumped on live chat because I was still bored and figured I’ll talk to some customers who come on complaining about the server being off line as everyone always does.  Usually when I try to man the live chat there is always someone who comes on who will sit there for several hours asking questions or frankly being an annoyance to me asking about if their web site looks like or what am I up to or something totally out of the scope of anything we do.  To my surprise this was not the case maybe it had something to do with the fact it was now 2:30 AM CDT and everyone was sleeping.  About the only customers we had who would be complaining or coming on would be from Asia.  Sure enough there were a few with their broken English and what not they asked what’s going on I linked them to the post and they posted some more rambled english about how Hawk Host rocks or at least I hope that’s what they meant.

As the window went on I resorted back to reading and doing basically nothing as I must have talked to anyone who cared about the server being down at 2:30AM CDT already.  I watched Jon Stewart Grills ‘Death Panel’ Originator (Canadian link) which provided me a few minutes of amusement.  The machine finally came back up a few tickets later and chats and everyone was happy the server was back online.  The best part there were no longer memory error messages being printed to console so it was a victory.  So in the end I waited around for nothing bad to happen but we always have someone to be there in case something bad does happen.

What I’ve learned about maintenance windows is don’t be a fool doing a late night one when you have nothing to do at such a late time.  If I was a midnight shift guy I might have found something to do but I was not.  So I basically had nothing planned to do and waited around then waited some more for the window to complete.  In the future I’ll make sure to have someone who actually is around during the late hours to be the guy who sits around waiting for nothing bad to happen.  Or at least schedule a more reasonable time that is late but not so late that it’s agony waiting for it to happen.  Also in the case of any window have something to do because we’re not the ones messing with the hardware so it becomes pretty boring pretty fast.

Well that’s the post I hope everyone enjoys the story and looking at it now I realized it seemed much better when I was half asleep thinking maybe it was a good idea to talk about my maintenance window adventure.  In hindsight though it’s not as exciting now that I’m awake and not going insane over sitting around waiting.

In this post I’ll be using two different VPS accounts as an example since we will need to spread the load across something. I’ll be referencing them as VPS1 and VPS2. In the examples they will be running Ubuntu, though most of the tutorial can be applied to any distribution. One thing to note is I’ll be using Aptitude for package management which is fairly specific to Debian based distributions. Usually Yum will be your alternative – and in the worse case scenario you will have to compile the packages manually.

What is Perlbal?

Perlbal is a single-threaded event-based server supporting HTTP load balancing, web serving, and a mix of the two.

Perlbal is a software load balancer created by Danga Interactive for the use on LiveJournal, Typepad, and other ventures. It’s a lightweight reverse proxy that has the ability to serve as a web server, though that is out of the scope of this post.

What is a “reverse proxy”?

According to Wikipedia a reverse proxy is:

A reverse proxy or surrogate is a proxy server that is installed in a server network. Typically, reverse proxies are used in front of Web servers. All connections coming from the Internet addressed to one of the Web servers are routed through the proxy server, which may either deal with the request itself or pass the request wholly or partially to the main web servers.

I believe this description is very fitting – it’s essentially a “middle man” for a request (in this case HTTP request) that decides where it should be routed to. This could mean simply deciding to put it on VPS1, or VPS2 – or it could mean if the HTTP request is for an image we’ll send it to Lighty, and if it’s a normal request to a PHP page we’ll send it to Apache. Think of it as a “router” in the literal sense.

Why is it useful?

I’ll give two simple scenario’s to try and explain the useflness of reverse proxies:

Scenario 1

You’re serving 100 requests/second and are running out of memory on your server – you notice that a good 80% of the requests are simply for static files, such as images and stylesheets – unfortunately Apache still takes a large amount of memory / CPU for these requests causing you to exhaust your resources. One way you could reduce the usage is simply setting up an alternative web server such as Lighty that has a lighter footprint to serve your static files, and keep Apache for the requests serving your application.

Scenario 2

We’ll also use the example of serving 100 requests/second – but let’s just say your server simply can’t handle the traffic. You could setup another server identical to your current one, and have the reverse proxy listen for incoming requests and it will direct the traffic to both servers seemlessly – allowing you to split the resources across the board and maintaining a fast / stable website.

These examples may have some flaws, though they’re simply here to illustrate common uses / the benefits of using a reverse proxy (or software load balancer).

First things first

First you need to find where your bottleneck is in your application. Is it the web server or is it the database server? Could it simply be slow SQL queries that could be fixed by adding a index? Ultimately you want to make sure that your application is optimized as much as possible – and make sure the bottleneck can’t simply be fixed by a few tweaks.

How do I setup the environment described in Scenario 1?

In this setup we’re going to use Apache to serve all HTTP requests relating to PHP – or your application, and use Lighty to serve static files such as images. The goal here is to use Lighty because of its low footprint to serve static files such as images and to lower the overall usage of your server.

1) Getting the packages

You will need the following packages:

• Apache  (setup for PHP)
• Lighttpd
• Perlbal

In Ubuntu each of these should be in the repositories, so you can install them with via Aptitude:

aptitude install apache2 lighttpd perlbal -y

I believe most package repositories have Apache and Lighttpd, though Perlbal could be a hit or miss. Luckily Perlbal is in CPAN so you can install it fairly easily:

perl -MCPAN -e ‘install perlbal’

2) Setting up Apache, Lighttpd

Once you’ve installed the packages you will need to configure both of the webservers to listen on a port other than port 80. The reason for this is Perlbal will  be listening on port 80 and deciding what to do with the requests. In this example I will have Apache listen on port 8080, and Lighty listening on port 8181:

Apache2 Configuration:

Listen 8080

It’s up to you to configure Apache completely, the point here is to simply have it listen on port 8080 instead of 80.

Lighttpd Configuration:

server.port = 8181

Once again it’s up to you to configure Lighty, we’re just having it listen on port 8181 instead of 80.

3) Setting up Perlbal

Now we have to setup Perlbal to handle the request. What we are going to do is have every request that is going to the subdomain “static.domain.com” be served via Lighttpd, and everything else via Apache. A quick note before we begin – Perlbal is capable of serving files, so Lighttpd is not required. I’m simply using it to illustrate how one would go about doing it.

Perlbal configuration:

load Vhosts

CREATE SERVICE select
SET listen = 127.0.0.1:80
SET roles = selector
SET plugins = vhosts

VHOST *.domain.com = apache_server
VHOST static.domain.com = lightttpd_server
ENABLE select

CREATE POOL apache_server
POOL apache_server ADD 127.0.0.1:8080
ENABLE apache_server

CREATE POOL lighttpd_server
POOL lighttpd_server ADD 127.0.0.1:8181
ENABLE lighttpd_server

In a nutshell this configuration does three important things – it tells Perlbal to listen on port 80 so it can accept the normal HTTP requests, it then says any request going to “*.domain.com” will be sent to our Apache instance, and anything going to “static.domain.com” go to our Lighty instance. For more information on Perlbals configuration please check out their documentation & mailing list.

4) Start everything up

Now we simply need to start up our web servers and Perlbal accordingly:

/etc/init.d/apache2 start
/etc/init.d/lighttpd start
/etc/init.d/perlbal start

5) See if it works

Last but not least we need to make sure everything works. Simply visit “domain.com” and make sure it loads accordingly, then visit “static.domain.com” and verify that loads. If both load fine it should be working – if you want to make sure you can take a peak in the logs to see incoming requests (/var/log/apache2/* , /var/log/lighttpd/*).

How do I setup the environment described in Scenario2?

In this setup we’re simply going to split the requests across two VPS servers. One of the VPS instances will house the Perlbal instance as well as the web server, and the other VPS will simpy house another web server.

1) Getting the packages

I’m going to assume you already have a web server of your choice setup on  both VPS1 and VPS2. All you will need to download is Perlbal:

On Ubuntu:

aptitude install perlbal -y

or installing Perlbal via CPAN:

perl -MCPAN -e ‘install perlbal’

2) Configuring the web server

The only configuration required on the web server is simply changing what port it is listening on. Keep in mind you only have to do this if Perlbal is sharing the same system as a web server – if you’ve decided to give Perlbal its own environment this is not necessary. In these examples I’ll assume you changed the web servers to listen on port 8080.

3) Configuring Perlbal

Now we have to setup Perlbal to listen on port 80 and direct the requests among VPS1 and VPS2

Perlbal Configuration:

CREATE POOL web_servers
POOL web_servers ADD 1.2.3.4:8080
POOL web_servers ADD 1.2.3.5:8080

CREATE SERVICE balancer
SET listen = 0.0.0.0:80
SET role = reverse_proxy
SET pool = web_servers
SET persist_client = on
SET persist_backend = on
SET verify_backend = on
SET balance_method = random
ENABLE balancer

Though the configuration is fairly self explanatory – we’re creating a “pool” and adding our web servers to it. We then create a “service” for Perlbal saying we want it to listen on port 80 and act as a reverse proxy. We also tell it to use the pool we just created. The other options you don’t need to worry about too much – though the “balance_method” option you have two choices: random and round-robin. The differences between them should be fairly obvious – random will choose a random server out of the pool while round-robin will go through each of the servers in the pool in a more orderly manner.

4) Start Perlbal

Now all you have to do is start perlbal:

/etc/init.d/perlbal start

5) See if it works

Simply visit your domain and see if the page loads – you can refresh a few times to make sure that it’s hitting both servers and both servers are responding accordingly. Once again you may want to check your web servers logs to verify it’s getting the requests.

This post is meant to be only a primer and not used in a production environment. I understand there are some principles I either skimmed over or completely omitted. This post was done solely off of memory and past experiences – so please be careful if you try to use a setup similar to the ones outlined in this post. If you come across any errors please let me know so I can fix them.

Some other similar topics I’ll try to cover in future posts:

• Setup software load balancing using HAProxy
• Setup software load balancing using NGINX
• Setup software load balancing using Pound

I’ve recently been fiddling around with multivariate testing on several websites I run (including Hawk Host) and I though it may prove to be a useful blog post for our customers. Here I’ll explain how to setup multi-variant testing using Google Site Optimizer and a simple web page (though you can apply it to any page / website).

Step One

After signing up for Google Site Optimizer sit down and decide on which portions of your website / webpage you want to subject to testing. Usually this is something like the a header, image, description or something along those lines. For example I’m currently utilizing it for Hawk Host on the tabbed content section.

Step Two

Once you’ve decided what you want to subject to testing on your website select “Create Experiment” on Google Site Optimizer. You will be prompted with two options: A/B Testing & Multivariate Testing. Select the latter. You will be prompted with a brief introduction to selecting which portions of your website you want to subject to testing (same as I said above) – scroll to the bottom of the page and select the check box and hit “Create”.

Step Three

You will now be asked to provide three URL’s:

1. Name Your Experiment
   This is an internal name for your experiment. Name it anything you like.
2. Identify Your Test Page
   This will be the URL to the page you’re testing. In Hawk Host’s case it’s the main page, or www.hawkhost.com
3. Identify Your Conversion Page
   This will help you identify which variants are converting – usually this will be your shopping cart success page or the page you want the visitor to end up on (a sales page, etc)

Once you’ve filled out the prospective fields hit “Continue”. You will be prompted with two radio buttons asking if your team will be installing the JavaScript code or if you will be. Depending on your situation select the appropriate option (usually the latter one).

Step Four

Here’s where we get nerdy. You will be presented with four sections of JavaScript to add to your webpage, each are very important so don’t skip any.

1. Control Script
   You will put this right after your beginning <head> tag. This just adds Googles JavaScript functions to help identify the sections you’re testing.
2. Tracking Script
   Paste this right before your closing body tag (</body>). This chunk of code adds Google’s tracking to your web page to provide detailed stats on which variants are being displayed, converted, etc.
3. Page Selections
   Use the example they provide for you and paste the code they provide right before the portion you want to be a variant. Here are some examples:

   
<script>utmx_section("heading")</script>
<h1>Test heading</h1>
</noscript>

   <script>utmx_section("content")</script>
<p>Test content</p>
</noscript>


   In these examples the portion directly following the utmx_section code is the default content. Usually this is what you currently have on your website. The variants are handled on Google’s end.

4. Conversion Script
   This portion of code will goes to the page where you want the visitor to end up. Usually this is a “Thank you” page after purchasing an item or something of that nature. Paste this on that page (ideally near the bottom).

Once you’ve done that select “Validate” – this will attempt to validate that the scripts are properly installed. Don’t be concerned if the conversion portion fails – depending on the software you’re utilizing for your website you may not be able to confirm the code directly (EX: success page after purchasing an item). Select “Continue” if everything passes the validation.

Step Five

You will now be prompted with an area to create your variants. You will notice all of the sections you created now show up on the left. Simply select “Add new variation” under the section you want to create a new variant. It will bring up a little text box with the default HTML code for your default value. From here modify it however you see fit – once you’re finished (make sure to preview it!) select “Save”. Go and do this for every section – but don’t add too many variations for each section. Unless you have a large amount of traffic you won’t get enough statistics on each permutation and will end up with worthless stats. Google recommends no more than 3 variations per section (we personally use 5~ per section on Hawk Host).

Once you’ve finished select “Continue”

Step Six

You will be brought to a page with a summary of your experiment. The most important thing on this page is deciding how much traffic you want to send to the experiment. If you select 100% that means everyone visiting your webpage will be subject to the variating content. If you select 50% only half of the visitors will be subject to the variating content, the other half will see the default content. We personally use 100% the majority of the time depending on how drastic the content change is. Use your discretion here.

Once you’ve finished with that select “Launch Now”

Step Seven

Wait! Wait several weeks to gather enough statistics – Google will provide you with in-depth stats on which combinations are being displayed, which are converting, and if possible it will tell you which seem to be converting on a regular basis. Using this information you should be able to find tune your website to convert as much as possible (based on design at least).

I hope this was useful to someone – I’ll try to clean this post up a bit over the next week or so, though feel free to ask any questions you may have in the comments. I’ll add image in the next couple of days to help clarify the steps mentioned.

Until next time,
Cody

If you were to ask a sales person for Verizon Wireless if they think you should switch to AT&T I would imagine theie response would be a “no” followed by some random sales propaganda. My point is this: if you’re concerned with something as important as a company going under, do your own  research and don’t ask a sales person!

What does this mean?

It simply means do your homework. Take a peak on Google, see when the domain was registered, see when the company was founded. Is it a registered business? Do they provide you with contact information (physical address, phone, etc)? All of these are questions you should be asking / looking for when searching for a host. After you’ve done all of that, look for third party reviews of the host. By that I mean by looking on forums such as WebHostingTalk, SitePoint, V7N, and such to see what your peers have to say about the host.

This is more sales propaganda!

Yes it is, though I think it applies to everyone. We here at Hawk Host take great pride in our transparency with our customers – we’re very verbose when it comes to anything that could affect services to providing our history. We believe communication and clean business practices are the best way to grow a company – and it’s yet to fail us. Though this may seem smug (albeit, it kind of is) – I personally believe companies should take a note of how we do things (not exclusively us, as plenty of companies do). Be honest, be blunt, don’t take shortcuts, treat your customers with respect, reap the benefits.

Are we going anywhere?

Simply put – no. We’re extremely stable, both fincancially and technically speaking. We have no debts, our company is privately held, and we’re a happy bunch.

Hopefully this didn’t go too far, but I thought it was important given the current situation amongst us (economy, etc). Hopefully our customers (and future customers) can rest assured Hawk Host is not going anywhere.

**NOTE** This is purely an opinion piece by me, and does not officially represent Hawk Host.

-Cody

So everyone is asking what is up with that foot?  I am even sort of wondering why is there a foot under the bed.  So can anyone explain this one to me?  This could also be an old picture and I’ve just found it now who knows.

Post your theories in the comments