ZenLinux Blog

While I happen to own a colocated server and do all of my own system administration, many Ruby on Rails developers would prefer to use an outsourced hosting solution, even if only to get started with. Geoffrey Grosenbach just posted a very handy review of a few companies that do Rails hosting and his experience with them. The reviews are particularly useful because Geoff knows what he’s doing, and any problems he encountered were not likely due to ignorance on his part.

Last night’s NHRuby.org meeting went very well, despite sub-optimal brightness from my LCD projector. You can view a meeting summary on our wiki.

When I first watched the PeepCode RJS screencast, I noticed that TextMate (an OS X programmer’s editor) has a really nifty file open dialog. It opens a pop-up window where you can simply start typing the name of a file in your project and you will be presented with a drop-down list of files that match. As you type more, the list narrows down, or you can select one of the filenames to open with your arrow keys.

I immediately started drooling over this and figured there had to be a way to do this in jedit, my preferred editor. The OpenIt plugin is the one you want to enable for this. As with everything in jedit, you can configure this plugin to your heart’s content, telling it to compile its list of available filenames from the current Project, or every file under a certain directory tree. You can also tell it to ignore certain filename patterns when it generates the list. I have OpenIt bound to the Ctrl-Alt-o keyboard shortcut.

Oh, and if you’re not using jedit with Java 1.6, I’d strongly recommend trying it out. There is a significant performance boost, and the font antialiasing is improved. There are a few guides and debian packages floating around for Java 1.6 that you can find for Ubuntu on the Ubuntu Forums.

I’ve been doing lots of fun stuff that I’ve wanted to blog about, including setting up a decent Rails deployment environment on CentOS. But I’ve been insanely busy lately, so it’s going to have to wait a bit longer.

Tomorrow is the second meeting of the NH Ruby/Rails User Group, and the meeting topic will be the use of RJS Templates in Rails. It’s a very practical presentation if you want to integrate all sorts of AJAX-y goodness into your web applications. I hope to see you there. There will be free giveaways for everyone who attends.

Information about the meeting location and time can be found on the NHRuby.org wiki.

I discovered via the awesome blog of Amy Hoy that there is a conference being planned in NYC by the New York City Ruby Brigade. The Gotham Ruby Conference is scheduled for April 21, 2007. I’m a bit disappointed that I won’t be making it to RailsConf this year, so I’m very certain I can make this one instead to get my conference-fix.

I’m working with Debian Sarge (stable) on an embedded Linux device at work, and recently wasted a lot of time tracking down problems with DHCP. Specifically, the client was changing IP addresses intermittently during a DHCP lease renewal – not cool. So I put the device behind another Linux system running its own DHCP server, and found the following clue in the logs:


dhcpd: DHCPDISCOVER from 00:d0:c9:9e:ae:59 via eth1
dhcpd: ICMP Echo reply while lease 192.168.1.215 valid.
dhcpd: Abandoning IP address 192.168.1.215: pinged before offer
dhcpd: Wrote 0 deleted host decls to leases file.
dhcpd: Wrote 0 new dynamic host decls to leases file.
dhcpd: Wrote 9 leases to leases file.
dhcpd: DHCPDISCOVER from 00:d0:c9:9e:ae:59 via eth1
dhcpd: DHCPOFFER on 192.168.1.210 to 00:d0:c9:9e:ae:59 via eth1
dhcpd: DHCPREQUEST for 192.168.1.210 (192.168.1.1) from 00:d0:c9:9e:ae:59 via eth1
dhcpd: DHCPACK on 192.168.1.210 to 00:d0:c9:9e:ae:59 via eth1


Interesting… Some research (and help from the folks on the GNHLUG discussion list) uncovered that the client was sending a DHCPDISCOVER while still using the old address. When a DHCP lease is being renewed, the client is supposed to send a DHCPREQUEST, not DHCPDISCOVER.

So why on earth was it doing this in the first place? My only explanation is that the dhcp-client package that Debian Sarge comes with (v2) isn’t following the specification correctly. I have no idea how old that package is, but I do know that nearly all of the modern Linux distros I’ve used for years come with dhcp3-client. Fortunately, the Debian stable repositories include dhcp3-client – it’s just not the default client!

The lesson from all of this?: don’t assume that just because a package is in Debian’s default stable install you can take its correct operation for granted.