Since Qwest does not support the SpeedStream 5260, I turned to the Internet to see if anyone else had done anything like this before. What I discovered is that every DSL provider seems to use its own specific VPI/VCI settings, and “ISP approved” modems are usually just pre-configured with the correct settings. For example, the correct VPI/VCI values for AT&T DSL are 0/35, while Qwest uses 0/32. So it seems that all you need to do is find out the correct VPI/VCI values for your ISP and reconfigure your modem to match.

But how do you manage a SpeedStream 5260 when it’s just acting as a bridge? As it turns out, you can always access it via telnet at its default IP address (10.0.0.1). Just give your PC a static IP address (e.g. 10.0.0.2/255.0.0.0) and plug it directly into the modem with a regular straight-through cable. Once at the command prompt, type the following command:

show vc

This will list the current VCI/VPI settings on the modem. To change them for Qwest DSL, set the VPI to 0 and the VCI to 32:

set vc 0 32 llc max

These commands appear to take effect immediately (i.e. there doesn’t seem to be a command to save the config).

xe pif-scan host-uuid=<UUID of XenServer host>

If this command results in interfaces with funny names, such as NIC__tmp1234567890, there’s a way to fix that too. First get the UUID of the interface in question:

xe pif-list device=__tmp<numbers>

Get the host UUID of the interface:

xe pif-param-get param-name=host-uuid uuid=<UUID of interface>

Get the MAC address of the interface:

xe pif-param-get param-name=MAC uuid=<UUID of interface>

Remove the interface:

xe pif-forget uuid=<UUID of interface>

Reintroduce the interface with a more appropriate name:

xe pif-introduce device=eth<n> host-uuid=<UUID of XenServer host>  mac=<MAC address of interface>

And that’s it! Note that this process may cause the vendor name, device name, and PCI Bus Path to disappear in the host’s NICs tab in XenCenter. I’m not sure why this happens, but it seems to fix itself eventually. Also note that this process will leave behind “orphan” networks with names like “Pool-wide network associated with __tmp1234567890.” These networks can be safely and easily deleted via XenCenter.

It’s been a few years since I’ve developed software full-time, but since I still encounter articles about how great ORM is, I figured that either the situation has improved since then, or maybe I was just too stupid to harness the power of ORM. But then I found someone who has come to the same conclusions I did way back in 2006, and has written about them a lot more eloquently than I did in my original rant. At least I’m not alone anymore!

A typical PC mess. I couldn't live like this any longer!

The first thing I needed was a new desk, and since I live right down the road from an Ikea outlet, I started my search there. Now I should mention that I’m normally really skeptical about Ikea furniture because of their apparent love of particle board, but I was pretty impressed by their Galant Series of desks. The tabletop is particle board (of course), but I don’t care, since all the important structural components are made of aluminum. I settled on a 63″ wide Galant desk with the optional filing cabinet.

I also wanted a new chair, but that wasn’t actually part of the original plan for this project. I had pretty much been set on getting a Herman Miller Aeron Chair from the first time I ever sat in one, but since there was nothing wrong with my current chair, I couldn’t justify spending money on a new one. But then in a stoke of sheer luck, I happened across a used one in my local craigslist for $300. Obviously, I couldn’t pass up that deal.

Now that the boring furniture was out of the way, I needed to find a well-built server rack that would actually look good in my living room. As you can imagine, this was not an easy search, but I eventually settled on the Kendall Howard 12U Compact Series SOHO Server Rack. This is a really high-quality rack, and the price reflects that, but with a little patience, I was eventually able to find one on eBay for $300 (with front and rear mesh doors included).

Nice rack!

Next came the need for a couple of well-built rackmount cases that looked good and wouldn’t be as loud as an air conditioner. I considered Antec’s Take 4 Series and iStarUSA’s Silent Rackmount Chassis, but I decided they were both way too expensive for what they were. I settled on a couple of iStarUSA D-400s for about $150 each and iStarUSA 24″ TC-Rails for about $25 each. But I have to say that I was really disappointed with the rails, because they really short you on screws. If you just stick with what they give you, I can almost guarantee that your server will fall out of the rack, and I say this because it happened to me twice while I was racking the empty cases. I ended up just buying more screws at a local hardware store.

Assembling the rack

When I started researching monitors, the big question was “Two or three,” but since I’m not a hardcore computer gamer, I decided pretty quickly that three monitors would just be overkill. I eventually settled on two LG L227WTGs for about $220 each. I’m still contemplating buying a dual monitor stand, but I’m not sure if I would gain anything other than a little bit better cable management.

The rest of what I bought for this project is fairly uninteresting, but I’ll list it here for completeness:

• Gigabyte GA-EP45-UD3P
• Intel Core 2 Duo E8400
• G.Skill 4GB DDR2-800 Kit
• EVGA GeForce GTS 250
• WD Caviar Black (1TB)
• Plextor PX-850SA Super Multi DVD±RW

Assembling my workstation and server

The other machine in my rack is a dedicated server that, among other things, hosts the website you’re looking at right now. The specs on this machine are fairly dated, as this is actually my old desktop from 2003, but I’ll list them as well for even more completeness:

• Asus A7N8X Deluxe (PCB 2.0)
• Corsair TWINX memory kit (512MB @ 333 Mhz FSB)
• Athlon XP 2500+
• WD Caviar Green (2×750GB in a RAID1 array)

The rack fully assembled

Other stuff in my environment (listed for ultimate completeness):

• Happy Hacking Keyboard Lite 2
• Logitech LX3 Optical Mouse
• Canon Pixma iP3000 Printer
• Grass Valley ADVC 110 Bidirectional Analog/Digital Video Converter
• Cambridge SoundWorks speakers from 1998
• APC Smart-UPS 1400
• Cisco PIX 501
• Linksys WAP54G

Since cabling was one of my major concerns, I really took my time and made sure all the visible cables were routed as neatly as possible, making liberal use of Velcro straps. And because everything is so tightly packed together inside the rack, I was able to further minimize the cable mess by replacing all the standard 6′ cables (power, network, USB, etc.) with 1′-3′ versions.

The results

As you can see, my new computing environment takes up about the same amount of space as the old one, but it looks way nicer and is much easier to work on (since everything is mounted on sliding rails that can be fully extended when necessary). It’s also semi-portable now, thanks to the casters on the rack itself.

exec { "install-foo":
    command => "curl -s -o /tmp/foo.run http://example.com/foo.run \
                && chmod o+x /tmp/foo.run \
                && /tmp/foo.run ",
    creates => "/usr/local/bin/foo",
}

This is pretty straightforward. The “command” parameter downloads and installs the package, while the “creates” parameter tells Puppet not to execute the command again as long as “/usr/local/bin/foo” exists. This keeps Puppet from unnecessarily downloading and reinstalling the program over and over again, but what happens when there’s a new version of foo.run? How does puppet know when it’s time to upgrade?

There may be better ways of doing this, but here’s a simple approach that has worked well for me:

$serial = "2009092501"
$serialfile = "/var/log/puppet/foo.serial"
exec { "install-foo":
    command => "curl -s -o /tmp/foo.run http://example.com/foo.run \
                && chmod o+x /tmp/foo.run \
                && /tmp/foo.run \
                && echo \"$serial\" > \"$serialfile\"",",
    unless  => "test \"`cat $serialfile 2>/dev/null`\" = \"$serial\"",
}

Notice that after running the command, I echo the value of $serial into the file at $serialfile. Then I use the “unless” parameter to check if the contents of $serialfile equals the value stored in $serial. If the values match, the command will not be executed. But now when I want to upgrade the foo package, all I need to do is update the value of $serial.

You have chosen not to trust “Go Daddy Secure Certificate Authority”, the issuer of the server’s security certificate (SSL error 61).

The solution is to download the appropriate root certificates (Godaddy’s are here) and save them to /usr/lib/ICAClient/keystore/cacerts.

wget -P /usr/lib/ICAClient/keystore/cacerts --no-check-certificate https://certs.godaddy.com/repository/gd-class2-root.crt https://certs.godaddy.com/repository/gd_intermediate.crt https://certs.godaddy.com/repository/gd_cross_intermediate.crt

Edit: One of my co-workers has a script that will do this for you.

rename "s/foo/bar/" *.baz

The first parameter is a Perl expression. The second is a file glob. This command will replace the string foo with the string bar in all filenames ending in .baz.

The first thing you should know is that I had already been working professionally with Linux for ~10 years before I began studying for the exam. I doubt that so much experience is really necessary, but because the exam measures actual competency on live systems rather than your ability to memorize or “read between the lines,” I think it’s highly unlikely that someone with little or no working knowledge of Linux could successfully cram for this test. So I’d have to say that experience is an important prerequisite, but I’d also have to say that experience alone is almost certainly not enough. Considering the wide range of subject matter, it’s very likely that you’ll be tested on something you’ve never had to touch before.

In my opinion, the hardest thing about self-studying for the RHCE exam is knowing how much you need to know about each study point in the RHCE Prep Guide. In other words, when it says something like “you need to know basic configuration of x,” it’s hard to know exactly what “basic configuration” means. Although I’ve signed an NDA preventing me from revealing any details about the exam itself, I can tell you that nearly all of my study material came from two places:

1. RHCE Red Hat Certified Engineer Linux Study Guide by Michael Jang
2. Red Hat Deployment Guide

The rest of my study material came from search engines. I spent a lot of time comparing other people’s study notes to mine and reading anecdotes about the RHCE exam. While the result of this was usually a temporary blow to my confidence (there are a lot of horror stories out there!), I did find a few blogs and forum posts with some helpful information. Usually it was just an alternative way of doing something, but it was also nice to come across the occasional words of encouragement from a self-studied RHCE. Just knowing that other people had done it gave me a slight confidence boost (as I hope this post does for some of you).

The first thing I did was read Michael Jang’s book cover to cover, just trying to absorb what I considered to be the most important information from each chapter (i.e. concepts rather than commands). This took me a week or two. When I was done, I set up a test environment using VirtualBox. Then I decided it would help to have a condensed, single-page study guide to refer to, so I created a “wikified” version of the RHCE Prep Guide which I called my RHCE “cheat sheet”. For the next few weeks, I went through each study point on the “cheat sheet” and used my study material to test and document everything I thought I might need to know.

I found Michael Jang’s book to be a great study guide (the labs and example problems were a huge help), but I wasn’t completely happy with the amount of detail on some topics, as well as how it tends to follow the Red Hat course outlines rather than just sticking to the RHCE Prep Guide. I also found quite a few typos and just plain incorrect information, so that’s where the Red Hat Deployment Guide came in. While I was working on the RHCE “cheat sheet,” I would usually read the appropriate chapter(s) from Michael Jang’s book first, then I would supplement it with the appropriate chapter(s) from the Red Hat Deployment Guide. If I felt particularly weak in a certain area, I would also peruse the man pages and any HOWTOs I could find online. This was a long, arduous process, but it helped ensure that I wasn’t missing any important details.

For the last couple weeks, I tested myself by putting the “cheat sheet” away, doing a minimal install of CentOS in my test environment, and trying to configure everything I could without referring to any documentation whatsoever. Since the test takes place on a live system, I assumed from the beginning that the man pages would be available, but in order to save time, I wanted to make sure I could do everything off the top of my head. As a result, I ended up memorizing almost everything on the “cheat sheet,” which is probably why I was able to complete the exam so quickly.

Since I didn’t have a study partner, preparing for the troubleshooting section of the exam was a bit of a challenge. I did come across an interesting project called Trouble Maker which directly addresses this problem, but unfortunately, it has not been updated in several years and does not work on recent versions of CentOS. For a while, I actually considered writing my own trouble maker program, but I ultimately decided that this would be too much work. Luckily, I have a few friends who know enough about Linux to make a machine unbootable, so we made a game of it. I would give them my root password and challenge them to do something that would keep me from using my computer, then I would try to fix it as fast as I could.

When it was all said and done, I spent roughly six weeks (studying a few hours each day) to prepare for the RHCE. Considering how easy the exam was for me, I believe that I worked a lot harder than I needed to, but the results were clearly well worth the effort. The best advice I can give to prospective RHCEs is to take your time and practice until you can do everything in the RHCE Prep Guide off the top of your head. If you feel weak in anything, do yourself a favor and postpone the exam.