June 17, 2009
While we’re on an OpenWRT kick, let me mention that Amazon has the guaranteed flashable WRT-54GL for less than $50 again. I won’t even provide a non-referral link, so as not to raise eyebrows at wordpress.[non-]com[mercial]. I’m sure you could find it.
Possibly the best reason someone who’s not interested in getting to know their network or doing fun things with it is the possibility to use just one OpenWRT/DD-WRT/Tomato device (along with any standard wireless router) to extend internet connectivity to another part of the house without running wires or using shaky (and unencrypted) Power-Over-Ethernet.
On my list of future projects to waste my money on, though, is a set of cheap 802.11n devices, replacing the “G” bridges I’ve had for the last few years. Apparently, that day is near or already here. Of course “N” speeds only matter if you’re concerned with moving data between machines in the home. For a normal residence, any available residential networking technology is faster (in most cases orders of magnitude faster) than even the best of the universally crappy available residential internet connections, and so the bottleneck will always be at the WAN side (especially for upload.) Of course these days, most small businesses are actually paying more for even crappier Internet service. But I digress…
On a last OpenWRT note, if I had known about this contest in time, I definitely would have put together a team and devoted a few months. Maybe it really does pay to read Slashdot.
June 15, 2009
OpenWRT Kamikaze 8.09 processes /etc/config/dhcp and appends the settings specified there as command line options when running dnsmasq. To properly configure dnsmasq to point to your LTSP server you will both need to specify options in this file, and modify the dnsmasq init script for these new settings. (Note that you can also—right now—add an /etc/dnsmasq.conf with these options in standard syntax. But that’s not the way OpenWRT is heading, and there’s inconsistency across the various packages as to the use and naming of non-uci config files.)
The following worked for me with Debian Lenny running LTSP 5.1.10 installed fromt the repositories, other distros may require different paths:
In /etc/config/dhcp, add in the “config dnsmasq” section:
option dhcp_boot ltsp/i386/pxelinux.0,$LTSP_SERVER_HOSTNAME,$LTSP_SERVER_IP
option dhcp_option 17,'$LTSP_SERVER_IP:/opt/ltsp/i386/'
The first path is relative to /var/lib/tftpboot, the second is the ltsp chroot directory which should be in /etc/exports. The second option is equivalent to the root-path option offered by dhcpd (AFAIU) and solves the “need path” error. Apparently this is not necessary when the DHCP and LTSP servers are the same.
Etherboot clients may require different path information. And if you have a mixed set of clients, you can use the dhcp-vendorclass syntax demonstrated here (the paths in the dnsmasq section of this document are out of date, though they have been fixed in the rest of the page.)
In /etc/init.d/dnsmasq add in the “dnsmasq()” function:
append_parm "$cfg" "dhcp_boot" "--dhcp-boot"
append_parm "$cfg" "dhcp_option" "--dhcp-option"
# /etc/init.d/dnsmasq restart
Then boot one of your thin clients, hopefully to an LDM login screen.
(Credit where credit is due: This post on general PXE booting with Kamikaze got me halfway to getting this to work.)
June 15, 2009
OpenWRT is one of those great projects which suffers for lack of documentation. Even worse, there have been three generations of configuration methods, and the existing documentation and user-written howtos can often be vague about which version they refer to. Some commands are future compatible (meaning they will work on later versions of the firmware) and some are not. Some may work, but in less than optimal ways and leave you with a mess to maintain in the long run.
(A similar problem exists with Xorg where many, many users who aren’t and don’t want to be X gurus but who know a few tried and true xorg.conf hacks have gone into their systems over the last year only to discover they no longer have an xorg.conf. Now, maybe you can just add a file to replace the non-functioning background magic, but you’ll be left wondering what you’re giving up, what might break down the line, and so on. And you probably wont find a simple answer for a modern system yet. You’ll have to wade through mountains of mailing list and forum postings, and reconstruct the workings of the new style X server in your own mind, which is exactly what you wanted to avoid.)
So, for those who don’t pay much attention to these sorts of goings on in OpenWRT land (how often do most of us reconfigure our networks?), here’s a set of rules of thumb for recognizing the version of OpenWRT any given online tutorial applies to:
- If you will be changing NVRAM settings, it’s for the old WhiteRussian release. (You should probably upgrade if you’re still using this.)
- If you are editing config files which resemble those of a normal Linux system in /etc, it’s for Kamikaze 7.x series. Many of these config files will still be read in the current 8.09.x series if present, but don’t necessarily count on it. You should be able to figure out the launch process for each package by reading the init scripts.
- If you are editing files in /etc/config or using uci, this is for Kamikaze 8.09 or later. In this series the LuCi web interface is also on by default, if that’s your thing.* Occasionally something shows up in the forums which uses uci directives which don’t seem to exist in stable. Also, you may find yourself adding options which the init scripts do not yet process, so you will have to edit them in.
OpenWRT is indispensable, and like much great software, those using it would rather keep using and improving it than document it and clean up the existing mess of documentation. Hopefully this helps with a little of that weeding for the new user.
* You can remove the LuCi web interface from OpenWRT Kamikaze by killing the process and running:
opkg remove -recursive luci-*
April 23, 2008
April 4, 2008
In January of last year, Ned Batchelder flushed out an idea of Damien Katz’ and Jan Lenhardt’s– negative CAPTCHA. CAPTCHA® – as you know – stands for Completely Automated Public Turing test to tell Computers and Humans Apart, and it’s purpose is to lock out automated systems, particularly bots designed to abuse HTML forms for submitting comment spam to blogs, internet fora, and other sites that would prefer only flesh and blood wingnuts be allowed to spam them.
There are two problems you might see with that. First, you may block out those using text-based browsers, either for accessibility or because they’re just weird. A serious corollary of this is that you will significantly degrade the level of discussion at your site by excluding the most intelligent of humanoids, the vanguard who browse the web under cover of NoScript.
The way around the first set of problems is to take the human path: label the form “only fill this out if you are a stupid bot.” Those who fill it out deserve to be blocked because they probably wrote some snide comment in it. Or they’re a bot.
Ned’s piece proposes dealing with the latter problem with a certain amount of server side randomization, and backing it up – as we do CAPTCHA – with content analysis. And trained monkey moderators.
Of course nothing is impenetrable for the bad guys or infallible in serving the good guys, but it seems to me that, all things being equal, this is more accessible and less obtrusive for human users. At least until the bots and their lobbyists push through Section 508 Subpart (R) mandating equal access for the blood-flow and organic process impaired.
(Revivified and brought to my attention by Heiko Webers’ RoR Security Project.)