The RouterStation Pro comes preloaded with a relatively old installation of OpenWRT Kamikaze.  Being a sucker for bleeding-edge software, I definitely wanted to check out code from the main Subversion repository to get it up-to-date as far as development goes.  Here’s how I did it.

bkero@ponderosa ~ $ svn co svn://svn.openwrt.org/openwrt/branches/backfire
bkero@ponderosa ~ $ cd backfire
bkero@ponderosa ~/backfire $ make menuconfig

Now you select some options to specify that we are building an OpenWRT image for a RouterStation Pro:

Looks like I’ll be going back to my real incognito mode of simply using another firefox profile and deleting it afterwards.

One solution I tried was to turn up the time between tests from 5 minutes to 10 minutes. This still had generated problems, as munin-cron runs still weren’t done after 10 minutes, and any greater time between polls meant subpar graph granularity.

My final solution was to modify munin’s cron entry to the following:

*/7 * * * *     munin test ( ! "$(pidof /usr/bin/munin-cron)" ) && test -x /usr/bin/munin-cron && nice -19 /usr/bin/munin-cron

I ran a test to see if there’s still a PID active from munin-cron, and if not check to see if the munin-cron executable exists. If it does exist, run a munin-cron job with the nicest setting possible.

I’ve recently come back from the Apache Retreat 2010. Here are some pictures that I took!

A tarball of all relevant files can be found here.

All files are hereby released under the GNU Public License version 2, and are apparently copyrighted by Oregon State University.

There are 2 major parts to this system. The first is the cf.classes file, which simply describes which hosts belong in each class. The relevant classes are as follows:

service_munin_host  = ( larch )
service_munin_node  = ( binhost columbia coos fir fraxinus g1 g2 g3 g4 )
package_munin_node  = ( service_munin_node www_phpbb_com )

The second part is the cf.munin file, which holds all the rules that each host should follow. Included are several support files that do such things as generate the munin.conf file, since that is difficult to do by hand.

First off, you’re going to have to install the munin package. You’ll also need to have a web server installed, I prefer apache:

# For Gentoo,
emerge munin apache
# For CentOS/Fedora
yum install munin apache
# For Debian
aptitude install munin apache

Gentoo and CentOS both install the HTTP root in /var/www/localhost/htdocs/munin. After setup, the graphs will be available at http://localhost/munin

Debian requires a bit more attention. Debian munin installs the HTTP root in /var/www/munin. so after the setup, a vhost will have to be created to access it. To do this(on Gentoo) I created an apache vhost file, /etc/apache2/vhosts.d/08_munin.conf. On Debian, the file is the same but the path is different, /etc/apache2/sites-available/08munin

Munin showed the most promise and compatibility with many of the services we run at the OSL, such as memcached and varnish. I liked how the plugin system is set up independently on each host, and that each plugin can be managed, configured, and consolidated through symlinks.

For the benefit of the uninitiated the setup on each node goes something like this:

#For gentoo
emerge munin
#For Fedora/CentOS
yum install munin-node
#For Debian/Ubuntu
apt-get install munin-node

Each client is a “node”, and runs the daemon ‘munin-node’. It’s configuration file exists at /etc/munin/munin-node.conf. This file merely tells the daemon which user to run as, which interface/port to listen to, where to log, and which munin masters are allowed to poll statistics.

I’ve been to several LAN parties recently, and have been getting a very accurate understanding of how much a pain it is to lug around a 30lb case, 30 inch monitor, and all the accessories.  I’ve looked at gaming laptops;  they all seem too expensive, too expensive, and too slow compared to something I could build myself, for cheap.

The total cost for the project needed to be under $80.  I already have a good gaming rig, and the convenience of such a thing is only good if the cost is low.

In an effort to modernise my gaming rig, I purchased a second nVidia 8800GT to compliment my first.  Benchmarks and reviews indicate that this setup yields comparable performance to many of today’s more expensive offerings.  This is a log of the installation and testing of the cards.

The Accelero S2 is an aftermarket heatsink used to provide additional cooling to video cards.  Although it was originally intended for lower-end cards, the greater surface area is able to cool an nVidia 8800GT adequately.  It has 2 heat pipes routed through the base of the sink and bend into a U-shape, protruding through a massive array of fins.  The kit also includes 8 RAM sinks.  This is enough for the RAM modules, although you’re on your own for cooling the voltage regulation sections of the card.  The Accelero S1 heatsink is physically larger than the S2, and includes additional heatsinks for cooling the FETs.  Luckily, I had spare Swiftech MCP15 heat sinks available from a previous project.  3 additional sinks per card were needed.

Kernel

Support is in the mainline kernel except for:

• Fingerprint reader
• Touchscreen
• Panel buttons

Wireless

It’s an Atheros 5008 card, supported fully by the ath5k driver.  Early driver versions in old kernels such as 2.6.30 have very shaky hardware support, therefore unless you’re running the latest available code, I would recommend swapping it out.  I’ve removed the integrated wireless card in favour of an Intel 5350AGN, which has been working well in the laptop. It draws a bit more power, but gives me WiMax support(another big kernel/userland headache), and dual band 802.11n.