You are currently viewing all posts in the general category.

An Ubuntu VPS on Slicehost: Web Server

As mentioned previously, I’ve recently moved this domain over to Slicehost. What follows is Part Two of a guide, compiled from my notes, to setting up an Ubuntu Hardy VPS. See also Part One, Part Three, Part Four.

Now we’ve got a properly configured, but idle, box. Let’s do something with it.

Nginx is a small, lightweight web server that’s all the rage on some small corners of the Net. Apache is extremely overkill for a small personal web server like this and, since we’re limited to 256MB of RAM on this VPS, it quickly becomes a resource hog. Lighttpd is another small, lightweight web server, but I’m a fan of Nginx. Try it out.

First, we need to install the web server. Nginx is now in Ubuntu’s repositories:

1
$ sudo aptitude install nginx

That’s all it takes in Hardy, but if you really want a guide for it, Slicehost has you covered.

Slicehost has a few more useful guides to Nginx, including introductions to the config layout and how to get started with vhosts:

Next up, we’ll need to install MySQL and PHP, and get them working with Nginx.

Slicehost has a guide for installing MySQL and Ruby on Rails, which also includes suggestions on optimizing MySQL. I follow the MySQL part of the guide, stopping at “Ruby on Rails install”.

Now MySQL is working, lets install PHP:

1
$ sudo aptitude install php5-common php5-cgi php5-mysql php5-cli

To get PHP as FastCGI working with Nginx, we first have to spawn the fcgi process. There are a few different ways to do that. Personally, I use the spawn-fcgi app from lighttpd. To use it, we’ll compile and make lighttpd, but not install it. We’re only after one binary.

Lighttpd has a few extra requirements, so let’s install those:

1
$ sudo aptitude install libpcre3-dev libbz2-dev

Now, download the source and compile lighttpd. Then copy the spawn-fcgi binary to /usr/bin/:

1
2
3
4
5
6
$ wget http://www.lighttpd.net/download/lighttpd-1.4.19.tar.gz
$ tar xvzf lighttpd-1.4.19.tar.gz
$ cd lighttpd-1.4.19
$ ./configure
$ make
$ sudo cp src/spawn-fcgi /usr/bin/spawn-fcgi

Then, create a script to launch spawn-fci (I call it /usr/bin/php5-fastcgi):

1
2
#!/bin/sh
/usr/bin/spawn-fcgi -a 127.0.0.1 -p 9000 -u www-data -C 2 -f /usr/bin/php5-cgi

The script tells spawn-fcgi to launch a fastcgi process, listening on 127.0.01:9000, owned by the web user, with only 2 child processes. You may want more child processes, but I’ve found 2 to be optimal.

Give the script permissions:

1
$ sudo chmod +x /usr/bin/php5-fastcgi

I then link the script filename to a version-neutral, err, version:

1
$ sudo ln -s /usr/bin/php5-fastcgi /usr/bin/php-fastcgi

Now we need an init script to start the process at boot. I use this one from HowToForge, named /etc/init.d/fastcgi:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
#!/bin/bash
PHP_SCRIPT=/usr/bin/php-fastcgi
RETVAL=0
case "$1" in
    start)
        echo "Starting fastcgi"
        $PHP_SCRIPT
        RETVAL=$?
    ;;
stop)
        echo "Stopping fastcgi"
        killall -9 php5-cgi
        RETVAL=$?
    ;;
restart)
        echo "Restarting fastcgi"
        killall -9 php5-cgi
        $PHP_SCRIPT
        RETVAL=$?
    ;;
    *)
        echo "Usage: php-fastcgi {start|stop|restart}"
        exit 1
    ;;
esac      
exit $RETVAL

Give it permissions:

1
$ sudo chmod 755 /etc/init.d/fastcgi

Start it:

1
$ sudo /etc/init.d/fastcgi start

Have it start at boot:

1
$ sudo update-rc.d fastcgi defaults

Alright, now that PHP is running how we want it to, let’s tell Nginx to talk to it. To do that, add the following to your vhost server block in /etc/nginx/sites-available/mydomain.com, making sure to change the SCRIPT_FILENAME variable to match your directory structure:

location ~ \.php$ {
    fastcgi_pass   127.0.0.1:9000;
    fastcgi_index  index.php;
    fastcgi_param  SCRIPT_FILENAME  /home/user/public_html/mydomain.com/public$fastcgi_script_name;
    include        /etc/nginx/fastcgi.conf;
}

Now let’s create that /etc/nginx/fastcgi.conf file that’s being included above. As per the Nginx wiki article, mine looks like this:

fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
fastcgi_param  SERVER_SOFTWARE    nginx;
fastcgi_param  QUERY_STRING       $query_string;
fastcgi_param  REQUEST_METHOD     $request_method;
fastcgi_param  CONTENT_TYPE       $content_type;
fastcgi_param  CONTENT_LENGTH     $content_length;
fastcgi_param  REQUEST_URI        $request_uri;
fastcgi_param  DOCUMENT_URI       $document_uri;
fastcgi_param  DOCUMENT_ROOT      $document_root;
fastcgi_param  SERVER_PROTOCOL    $server_protocol;
fastcgi_param  REMOTE_ADDR        $remote_addr;
fastcgi_param  REMOTE_PORT        $remote_port;
fastcgi_param  SERVER_ADDR        $server_addr;
fastcgi_param  SERVER_PORT        $server_port;
fastcgi_param  SERVER_NAME        $server_name;

Then restart Nginx:

1
$ sudo /etc/init.d/nginx restart

Let’s create a file named test.php in your domain’s public root to see if everything is working. Inside, do something like printing phpinfo.

Go to http://mydomain.com/test.php. See it? Good. If you get “no input file specified” or somesuch, you broke something.

If you create an index.php, and delete any index.html or index.htm you might have, you’ll notice Nginx throws a 403 Forbidden error. To fix that, find the line in your vhost config (/etc/nginx/sites-available/mydomain.com) under the location / block that reads index index.html; and change it to index index.php index.html;. Then restart Nginx.

If you want SSL with your Nginx, Slicehost has a guide for generating the certificate and another guide for installing it.

You’ll want to install OpenSSL first:

1
$ sudo aptitude install openssl

There is one bug in the second guide. In the first server module listening on port 443, which forwards www.domain1.com to domain1.com, the rewrite rule specifies the http protocol. So, in effect, what that rule does is forward you from a secure domain to unsecure: https://www.domain1.com to http://domain1.com. We want it to forward to a secure domain. Simply change the rewrite rule like thus:

rewrite ^/(.*) https://domain1.com permanent;

Next up: install a mail server. (Previously, we did a basic setup.)

An Ubuntu VPS on Slicehost: Wordpress

As mentioned previously, I’ve recently moved this domain over to Slicehost. What follows is Part Four of a guide, compiled from my notes, to setting up an Ubuntu Hardy VPS. See also Part One, Part Two, and Part Three.

I prefer to install Wordpress via Subversion, which makes updating easier. We’ll have to install Subversion on the server first:

1
$ sudo aptitude install subversion

After that, the Wordpress Codex has a guide to the rest of the install.

Nothing further is needed, unless you want fancy rewrites. In that case, we’ll have to make a change to your Nginx vhost config at /etc/nginx/sites-available/mydomain.com. Add the following to your server block under location / {:

# wordpress fancy rewrites
if (-f $request_filename) {
    break;
 }
 if (-d $request_filename) {
     break;
  }
  rewrite ^(.+)$ /index.php?q=$1 last;

While we’re here, I usually tell Nginx to cache static files by adding the following right above thelocation / { block:

# serve static files directly
location ~* ^.+\.(jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|css)$ {
    root  /home/user/public_html/mydomain.com/public;
    expires 7d;
    break;
}

That’ll go in the https server section, too. Now, enable rewrites in your Wordpress config. I use the following “custom” structure:

/%year%/%monthnum%/%day%/%postname%/

Then, restart Nginx:

1
$ sudo /etc/init.d/nginx restart

And there you have it! You know have a working, new web server and mail server.

(Previously, we did a basic setup, installed a web server, and installed a mail server.)

Beautifying

Another redesign! This one only 6 months from the last. How remarkable is that?

The base template and heavy CSS of the last design made this change relatively simple. This time around, I’m using YUI Reset and YUI Fonts. I started using both of them a month or two ago on a couple other sites. It’s hard to imagine building a site without them now. They take a lot of headaches out of CSS.

This design is not using YUI Grids. I have used it before, but I don’t think it offers any benefit with this kind of design. It’s more suited toward a content intensive site with many nested divisions. Something like Yahoo’s front page.

You’ll also notice a Twitter feed on the top of the index page. I’ve been trying to figure out what the appeal of Twitter is, but so far, it’s escaped me. I figured embedding tweets on the site would provide extra encouragement for me to try it out. I think Twitter may lend itself to my summer on the road, too. So, we’ll see how long that lasts. It seems to be noticeably slow, so I might have to find another way to pull the data.

Another new feature is tags. I started tagging posts a while ago, but haven’t displayed them till now. The majority of posts are not tagged. Maybe someday I’ll go back and tag the 1,300 old posts – but I doubt it.

Some kinks of the design are still being worked out, but if you notice anything strange – whether it be from the redesign, server move, or mail move – let me know.

A Move to Slicehost

Yesterday I moved this domain over to Slicehost.

Ian first told me about Slicehost when we were both looking to move away from Dreamhost last November. Initially, we both intended to find another shared host, but that proved far too difficult – it seems most hosting companies have something against shared hosting with decent limits and ssh access (that last part is the kicker).

I signed up with Slicehost at the end of last year and tinkered around with it for a month or so, experimenting with setting up the server in different ways. Eventually, I found an Ubuntu-Nginx-PHP-MySQL-Postfix-Dovecot setup that I enjoyed, and one which I was comfortable administering. In the beginning of the year, I moved a couple of my domains over to the Slice. It’s been a great experience. I’m not sure why it took me 6 months to finally move this domain – my primary one – over. Running a VPS is deceivingly simple* and well worth the effort. If you’re currently running on a shared host and have some basic competency in a UNIX environment, I’d recommend giving it a shot.

In a bit I’ll post a series of guides, compiled from my notes, on how I setup the server.

  • It’s deceivingly simple if you’re not running a full mail server with virtual users running around everywhere. That part was a pain. Hence, the move to Google.

Google Apps

Last week I outsourced my email to Google Apps.

For years, my paranoia has prevented me from moving my mail. I never liked the idea of Google parsing through each message for keywords to generate ads. In fact, I usually don’t even allow Google to cookie me. But now most of my regular email contacts have started using GPG. Enough of my mail is now encrypted that I’m comfortable with Google.

I haven’t decided yet if I prefer the Gmail interface or Thunderbird. In the web interface, I use FireGPG for signing and d/encrypting, which of courses places signatures inline. Since I’m jumping back and forth between that and Thunderbird/Enigmail, in order to maintain some measure of consistency, I’ve told Enigmail to sign inline instead of using PGP/Mime. It is a bit annoying, and will probably frighten the sheeple, but that’s the way it is for now.

So, please encrypt all email. And if you don’t, be aware that Google is reading it.

Walking

Walking

Walking itself is the intentional act closest to the unwilled rhythms of the body, to breathing and the beating of the heart. It strikes a delicate balance between working and idling, being and doing. It is a bodily labor that produces nothing but thoughts, experiences, arrivals. ... [T]he mind, the body, and the world are aligned, as though they were three characters finally in conversation together, three notes suddenly making a chord. Walking allows us to be in our bodies and in the world without being made busy by them. It leaves us free to think without being wholly lost on our thoughts. - Rebecca Solnit, Wanderlust

Photo Booth Is Much More Entertaining Than Work

Photo Booth

Sole and Superfeet

Last March, I used part of my REI dividend on a pair of Sole Ed Viesturs Ultra Cushion footbeds. Prior to this, I’d been using Green Superfeet in my Lowa Renegade boots.

When I pulled the Green Superfeet out of my boots and attempted to install the new Sole footbeds to insure I had a proper fit, they were quite hard to insert – much harder than the Superfeet. I took them out and compared them with the Superfeet to see if they wanted trimming, but they appeared only a millimeter or so longer. They were, though, much thicker than the Superfeet – particular in the arch area – which was what, I deduced, made the fit a bit more tight.

So, I tried inserting them again, this time shoving them almost all the way in, then put in my feet to force the footbeds into place. I felt around a good deal to assure myself that there was no bunching at the toe, then took them out again and popped them in the oven.

Sole includes a sticker on the bottom of one of the pair that turns from silver to black when properly heated. They claim that 2 minutes in a 200F oven should do it, but that, if not, give ‘em 5 minutes, then assume the sticker is defective and stick the footbeds into your boots anyway. Well, it actually took 6 minutes in my oven at 200F. After the sticker had turned black, I stuck the footbeds into my boots, laced them up, and stood up straight, feet shoulder-width apart, toes pointed forward, for two minutes. The warmth was actually quite pleasant, particularly on a cold, wet day.

An aside on Superfeet:

I purchased my first pair of Green Superfeet last summer while working for the National Park Service. My footwear at the time was a pair of Merrell Sawtooth boots – easily the stiffest, most uncomfortable boot I’ve ever worn. Any more than 6-7 miles in those and my feet would start to develop an ache. And going over ridges: that was absolutely no fun. The boots were completely lacking in support during downhill endeavors – which, to be fair, was not entirely the boots’ fault. My arches aren’t completely collapsed, but I do have flat feet, which, as you may know, equals zero shock absorption. So when I traversed my way down a rocky slope in the Sawtooths, I felt it. Shortly after purchasing the boots, but long enough after that I felt I had broken them in as much as I could, I went out and bought the Green Superfeet. The difference was stark. Really quite amazing. They were hard and awkward for about the first week, but after that break-in period, the Superfeet turned the Merrell Sawtooths into completely acceptable boots. I could log far more miles, over any terrain, with any slope, all without ache. They were great. When I left the park, I bought a second pair of Superfeet, this time for my 5.11 HRT boots, in the hopes that I could breathe a little more life into them. Alas, it was for naught. Even with the Superfeet, I had to admit to myself that the 5.11s were at the end of their life.

While I would certainly call the Superfeet supportive, I’m not sure I’d term them comfortable. And in fact, Superfeet claims that the insoles should not be comfortable. If it felt like one was walking on a soft mattress, the insoles wouldn’t be giving the feet any support. I don’t know much about feet, but the argument makes sense to me. Personally, while moving with the Superfeet, I had no complaints, but standing still for more than a few minutes, they would start to become noticable uncomfortable. Not painful, but uncomfortable. The discomfort originated in the arch area of the footbed, which I felt was too high for me. A bit like if I had a small ping pong ball or somesuch under my arch. Again, I don’t know much about feet, but this made complete sense to me. My feet are flat, thus I have very little shock absorption. The Superfeet provide shock absorption, thus they must be pushing up my arch. So I couldn’t, and still can’t, complain.

While I’m here, I’d like to make a comment on Superfeet sizing. My boot size is a US 9.5. Superfeet classifies their insoles by letters. Their size E equates to shoe sizes US 9.5-11. I’ve used size E Superfeet in three different pairs of boots (all size 9.5), and it’s always been a perfect fit. No trimming necessary. Great for me, but if you happen to be size US 11, I’d be a little weary. Definitely buy them from a store with a decent return policy, as you may find yourself wanting to upgrade to size F.

But when I heard about Sole, who made footbeds that actually molded themselves to the wearers feet, and that wearers often termed them as not only supportive, but comfortable, I was intrigued. I thought perhaps they could reach a pleasant medium between pressing up the arch for support, but not pressing it up too much.

Back to Sole:

After the initial 2 minute molding process, I walked around them a short while. An immediate, very stark difference from the Superfeet was evident. The Soles were, in fact, comfortable. The level of comfort worried me, actually. I feared they wouldn’t give me any support what-so-ever.

I have by now logged enough mileage, over enough terrain, under enough of a load to over a verdict: thumbs up. The comfort, compared to the Superfeet, allows me to to travel slightly greater mileages in the same boots than before.

I still keep the Green Superfeet in my running shoes, but I, personally, find the Sole footbeds superior. I would caution that feet are extremely variable, and the merits of both Superfeet and Sole are strong, but, it would seem, complimentary to different foot types. Experiment!

There is absolutely no reason not to purchase a pair of non-standard insoles for your footwear – even with good boots. The thin, non-supportive, flimsy things that manufacturers include standard cannot match a custom pair. I expect the majority of those reading this site probably recognize their feet as extremely valuable assets, and are not unaccustomed to spending uncommonly large sums of money on a good pair of boots and socks. So do yourself a favor, take the next step, and buy decent insoles. There is little less valuable in this world than mobility, and, whatever brand they may be, custom insoles will allow you to go harder, better, faster, longer.