$ convert *.gif mydoc.pdf

Thanks again, ImageMagick.

Say you were using purely gcj from forever but you run across an application which discriminates against it. If you install Sun’s java (jdk/jre/jwhatever) and out of caution or nostalgia don’t uninstall gcj, how do you make sun-java the new system default?

#update-alternatives --config java

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.

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"

Run:
# /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.)

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-*

Epoch Fail Screen Cap

February 13, 2009

48 seconds...

48 seconds...

There’s an environment variable HISTFILE which determines where ksh saves your command history. By default, if HISTFILE is not set, ksh will save to ~/.sh_history. OpenBSD does not, however, include this default – so your command history is lost at the end of each session. That may be what you want, but if not, you can just add a line like this to ~/.profile:
export HISTFILE=~/.sh_history
Since ksh doesn’t include source you can use . ~/.profile to load your changes.