deployment¶

host@home: Setting Up Your Network

[2013-12-19 I'm not currently hosting @ home but Snowden leaks have made me rethink]

My Billion 7300 modem/router does a simple task well

My first step on the path to hosting @ home was to get a good Net connection. I selected a Naked ADSL plan from Australian provider Internode. Australians pay crazy high prices for Internet but $60 a month for 150GB (combined download/upload) doesn't seem too steep. In order to host @ home I needed to disable the Internode network firewall to enable incoming traffic.

Internode gives me a dynamic IP (which I actually prefer). Most DSL routers come with support for dynamic DNS built in and mine does a great job of updating my DNS entry within seconds of my IP changing. All other domains hosted here will have CNAMEs pointing this host only a single hostname needs to be updated when my IP changes.

When my modem light glowed steady on Friday I knew I could get started configuring the router. I'm fond of Billion modem/routers which sell for around $60.

Configuring the router

ADSL Routers tend to be pretty easy to configure via their web interface providing you remember the admin password or have something to poke in the hole to reset it to factory defaults. The other thing you have to work out is the IP address the modem is  running on. For some reason 192.168.0.1 is not the universal standard - my modem was on 192.168.1.254.  Go figure. Here's what I do when setting up a new host@home network.

• Change root password from the factory default
• Configure DHCP to handout my ISP's nameservers and my own domain
• Configure DHCP to IPs from 100 - 200 (I reserve others for manual addressing)
• Forward incoming connections to a gateway IP (which forwards traffic using HAProxy)
• Configure dynamic dns

ADSL router updates dynamic dns entry when IP changes

I installed apache2 on my gateway host to test external access. You should be able to access it here: home.failmode.com

In the next installment...

The next post will cover setting up HAProxy on the gateway host to so that incoming requests can be routed to the correct internal servers.

Fixing Chef’s “Attribute hotspot is not defined” error

I was trying to install Opscode's Chef using the "Bootstrap Chef Rubygems Installation" method. It was failing hard with something about a 'hotspot'.

[mbailey@island chef]$ sudo chef-solo -c /etc/chef/solo.rb -j ~/chef.json -r http://s3.amazonaws.com/chef-solo/bootstrap-latest.tar.gz
[sudo] password for mbailey:
[Mon, 14 Feb 2011 15:20:34 +1100] INFO: Setting the run_list to ["recipe[chef::bootstrap_server]"] from JSON
[Mon, 14 Feb 2011 15:20:34 +1100] INFO: Starting Chef Run (Version 0.9.12.1)
[Mon, 14 Feb 2011 15:20:34 +1100] ERROR: Running exception handlers
[Mon, 14 Feb 2011 15:20:34 +1100] ERROR: Exception handlers complete
/usr/local/lib/ruby/gems/1.9.1/gems/mbailey-chef-0.9.12.1/lib/chef/node/attribute.rb:428:in `method_missing': Attribute hotspot is not defined! (ArgumentError)

There's a bug in ohai-0.5.8 (19 Oct 2010) that is fixed in HEAD. The simple steps fixed my problem and allowed me to install Chef.

$ git clone git://github.com/opscode/ohai.git
$ cd ohai
$ sudo rake install
gem install pkg/ohai-0.5.8 # but I wanted sudo gem install
Successfully installed ohai-0.5.8
1 gem installed
$ sudo gem install pkg/ohai-0.5.8.gem
Successfully installed ohai-0.5.8
1 gem installed

I hope this saves you some time and frustration.

Getting monit to restart mongrel after a crash

An annoying aspect of the Mongrel webserver is that it refuses to start if it detects a stale pidfile. This causes real problems when you're trying to use something like Monit to automatically restart mongrel after a crash.

Most daemons check whether the process_id in the pidfile is running. Ezra has indicated that a future release of mongrel will do this but in the meantime, we can use mongrel_cluster with the --clean option to remove stale pidfiles before starting mongrel.

Update /etc/init.d/mongrel_cluster to include the --clean option in the start and restart commands.

  start)
    # Create pid directory
    mkdir -p $PID_DIR
    # chown $USER:$USER $PID_DIR

    mongrel_cluster_ctl start --clean -c $CONF_DIR
    RETVAL=$?
;;
  stop)
    mongrel_cluster_ctl stop -c $CONF_DIR
    RETVAL=$?
;;
  restart)
    mongrel_cluster_ctl restart --clean -c $CONF_DIR
    RETVAL=$?

Update your monit config to use mongrel_cluster. Note that monit sets a restricted path (PATH=/bin:/usr/bin:/sbin:/usr/sbin) and the internals of the mongrel_cluster gem call mongrel_rails without specifying the path. mongrel maintainers [http://mongrel.rubyforge.org/ticket/31#comment:1 suggest] using env in the monit command and said this is already fixed in a svn. I've found creating a symlink from /usr/local/bin/mongrel_rails to /usr/bin/mongrel_rails does the trick. Then update your monit config to look something like this:

check process mongrel-8010 with pidfile /var/www/apps/tubemarks/shared/pids/mongrel.8010.pid
group mongrel
start program = "/usr/local/bin/ruby /usr/local/bin/mongrel_rails cluster::start --only 8010 -C /etc/mongrel_cluster/tubemarks.yml"
start program = "/usr/local/bin/ruby /usr/local/bin/mongrel_rails cluster::stop --only 8010 -C /etc/mongrel_cluster/tubemarks.yml"

The nice part here is the --only option which allows you to restrict the command to a single mongrel process (as defined in the config file).

I've deprec-1.99.16 has been updated to use mongrel_cluster as described above to clean up stale pidfiles before starting mongrel. As a side note, I was glad to see mongrel has a new website and is being fed and cared for by it's new owners.